Hi Greg, Looks good to me. Thanks. I expect I will be asked to formally review this again when it reached the IESG agenda.
Regards Brian On 09/01/2015 19:41, Gregory Mirsky wrote: > Hi Brian, > greatly appreciate your comments. Please find proposed changes to address > your comments in the attached copy. > > Happy New Year and kind regards, > Greg > > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Wednesday, December 31, 2014 2:07 PM > To: [email protected]; General Area > Review Team > Subject: Gen-ART Last Call review of > draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14.txt > Reviewer: Brian Carpenter > Review Date: 2015-01-01 > IETF LC End Date: 2015-01-08 > IESG Telechat date: > > Summary: Almost ready > -------- > > Major issue: > ------------ > > In "3.1.3. Configuration of Fault Management Signals": > > " If an > implementation wishes to modify... " > GIM>> "In order to modify the default configuration the "MPLS OAM FMS > sub-TLV" MUST be included." > > " However, by setting the "Fault Management subscription" flag in the > "MPLS OAM FMS sub-TLV", a client LSP can indicate that it would like > an association to be created to the server MEP(s) on any intermediate > nodes." > GIM>> Please see changes in the attached copy. > > I find "wishes" and "would like" to be very strange verbs. Do they refer to > operator choices or programmer choices? Implementations and client LSPs don't > have a faculty of choice. Please clarify which human is making a choice and > what the default is. > > There are a few other places where words like "desire" and "intend" > are used of objects, not of humans. I think all of these need to be clarified > in terms of what is the default behaviour, whether it is set by the > programmer or by the operator, and how it is changed (by an NMS for example). > Otherwise the spec seems to call for intelligent devices or for magic. > > Minor issues: > ------------- > > In "3.1. MPLS-TP OAM Configuration Operation Overview": > > > " ... If placed in LSP_ATTRIBUTES nodes that are not > able to process the OAM Configuration TLV will forward the message > without generating an error, this is not the case if placed in the > LSP_REQUIRED_ATTRIBUTES object." > > Grammar: the comma should be a semi-colon or a period. > > Technical: Does this mean that an error MUST be generated if the MPLS OAM FMS > sub-TLV is in a LSP_REQUIRED_ATTRIBUTES object in such a node? > If so, please say so clearly. > > GIM>> Please check proposed changes in the attached copy. > > In "3.2.1. CV Flag Rules of Use": > > " Moreover, if the CV flag is set, the CC flag MUST be set as well as > performing Connectivity Verification implies performing Continuity > Check. " > > Please fix the syntax. I can see several possible meanings for this sentence. > Maybe it means: > > If the CV flag is set, the CC flag MUST also be set, because > performing Connectivity Verification implies performing Continuity > Check as well. > GIM>> Accepted and changed accordingly (in the attached copy). > > " The format of an MPLS-TP CV/CC message is shown in [RFC6428] > and it requires, together with the BFD Control packet information, > the "LSP MEP-ID". " > > Ditto. I'm guessing this means: > > The format of an MPLS-TP CV/CC message is shown in [RFC6428]. > It MUST contain the BFD Control packet information and the > "LSP MEP-ID". > GIM>> Please find proposed resolution in the attached copy. > > In "8. Security Considerations": > > " In particular, a > network element could be overloaded if an attacker were to request > high frequency liveliness monitoring ..." > > So would it be appropriate to recommend some kind of rate limits on > liveliness monitoring? > GIM>> I consider that to be a part of OAM Resource Management solution. A > system can support a combination of OAM CC/CV sessions and the number of > sessions will be defined by intensity, intervals at which these sessions to > operate. Handling requests for OAM resources, I think, is outside the scope > of this document. Perhaps pointing to the potential attack vector, as done in > the document, is reasonable. > > Nits: > ----- > > In "3.2. MPLS OAM Configuration sub-TLV" > > " Then all OAM functions that > have their corresponding flags set in the ?OAM Function Flags sub- > TLV? MUST be assigned their default values or left disabled." > > The "?" marks must be an error. > GIM>> Yes, it should be quote, not question marks, as throughout the document. > > I noted one comma error above that is confusing. Actually there are numerous > comma errors: missing commas, unnecessary commas, and commas that should be > semi-colons or periods. Hopefully the RFC Editor will catch them. > GIM>> Am getting ready for that. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
