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:[email protected]]
Sent: Friday, January 09, 2015 5:19 PM
To: Gregory Mirsky;
[email protected]; 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:[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
