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

From: Gregory Mirsky <[email-masked]>
Date: Fri, 9 Jan 2015 06:41:48 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2015 14:19:14 +1300

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

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 10 Jan 2015 01:20:55 +0000

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-masked]] 
Sent: Friday, January 09, 2015 5:19 PM
To: Gregory Mirsky; [email-masked]; 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:
> Subject: Gen-ART Last Call review of 
> draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 12 Jan 2015 00:40:25 +0000

Hi Brian, et. al,
thank you for your comments and kind consideration. The new version with all updates we've discussed just been posted.

	Regards,
		Greg

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

Hi Greg,

Regards
   Brian

> IETF LC End Date: 2015-01-08

Subject: New Version Notification - draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 12 Jan 2015 00:38:05 +0000
List-Id: <[email-masked]>

A new version (-15) has been submitted for draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.