Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14

[Gregory Mirsky <[e-mail]>]

Hi Brian,
thank your for the most expedient response. I'll upload the new version over the weekend.

	Regards,
		Greg

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Friday, January 09, 2015 5:19 PM
To: Gregory Mirsky; [e-mail]; General Area Review Team
Subject: Re: Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14

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:[e-mail]]
> Sent: Wednesday, December 31, 2014 2:07 PM
> To: [e-mail]; 
> 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.
>