Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-oam-req-05

I have no objection to the publication of this document as an RFC. I do
have a number of small comments you may wish to address along the way.

---

Section 3

   Section: The term Section refers to a partial segment of a path

Is there a difference between a segment of a path and a partial 
segment of a path? From the example, it appears not. You might strike
"partial".

---

Section 4.2.1

   An RBridge SHOULD have the ability to verify the above connectivity
   tests on sections. As an example, assume RB1 is connected to RB5 via
   RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to
   RB5 connectivity on the section from RB3 to RB5. The difference is
   that the ingress and egress TRILL nicknames in this case are RB1 and
   RB5 as opposed to RB3 and RB5, even though the message itself may
   originate at RB3.

I find the placement of a requirement "SHOULD" in the example
disconcerting. It is also not clear from this text whether there is any
special casing of the requirement such that the section must terminate 
at the end point of the path under test (e.g., would the section from 
RB1 to RB4 have been equally acceptable in the example? what about RB2
to RB4?). Maybe a little text tweaking would clariy this.

---

Section 4.3

   OAM SHOULD provide the ability to perform a Continuity Check on
   sections of any selectable path within the network.

I suspect this should be "on any section of any selectable path"

---

Should 4.8 restate the importance of keeping OAM within the campus, and
perhaps add the importance of not allowing OAM into the campus 
(especially "discovered OAM packets" that pop out of a tunnel)?

Should 4.8 also point out the concerns associated with path tracing and
exposure of network internals?

---

I think you have used RFC 6291 in a normative way.

===

I also found a bunch of nits...

---

You or the RFC Editor will want to fix the expansion of OAM to match
what they have in their list of standard abbreviations at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
This is consistent with RFC 6291.
The difference is the running comma.

---                                                                               

Abstract
"This document presents,"
Superfluous comma.

---

Section 1
   Success of any mission critical network depends on the ability to
   proactively monitor networks for faults, performance, etc. as well
   as its ability to efficiently and quickly troubleshoot defects and
   failures.
s/monitor networks/monitor it/
s/its/the/

---

Section 1
   In this document we define the Requirements for TRILL OAM.
s/Requirements/requirements/

---

You will need to sort out the separation between Authors and
Contributing Authors. Put the front page names in a separate section
called Authors Addresses.

A note related to the shepherd writeup (a fine one; thanks, Don).

   Lastly, the nits checker doesn't like 
   it that the Authors' Addresses section is called "Contributing 
   Authors".

The RFC Editor won't like this either, but not just because of the title: they will want one section that contains the authors that are listed at the top of the document, and another that contains the others; such is their style.  That said, this is best left to the RFC Editor to sort out with you, and I suggest that the IESG shouldn't bother with it.

I found the Terminology section to be particularly clear and helpful.

Would a TRILL OAM system collect any TRILL-specific data that would need to be protected from a confidentiality point of view?  For example, might there be anything exposed about the topology, anything about flows, paths, or sections, which administrators would want to keep prying eyes away from?  Is there nothing related to that that ought to be included in the security considerations?

Thanks for addressing my concerns.

Thank you for addressing my concerns.