Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

[Gregory Mirsky <[e-mail]>]

Hi Ben,
thank you for your thorough review and thoughtful comments. Please find my responses and proposed changes in-line and tagged GIM.

	Regards,
		Greg

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Monday, November 16, 2015 7:07 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have one minor (almost trivial) comment/question, and several nits:

Comment:
=========
- 4.1, paragraph 3:
Is it reasonable for a TLV in this standards-action registry to be have sub-tlvs with reduced registration requirements?  (And if so, is there a reason to exclude specifications that are not RFCs?)
GIM>> Yes. This is how it is done for all standard track registry TLVs for the entire LSP ping.
And yes we want RFCs to define the sub-TLVs (if the come out of the Specification need range) just because they go into a standard track specified TLV.

Nits:
====
-1, paragraph 1:
Missing "the" before "MPLS Transport Profile "
GIM>> Thank you, added.

- 1.0, last paragraph, last two sentences:
Who are “we” in these sentences? Does it make sense to talk about what “we” are or are not “configuring”?
GIM>> Indeed, re-worded as:
   It should be noted that this document does not specify how to configure on-
   demand throughput estimates based on saturating the connection as
   defined in [RFC6371].  Rather, only how to enable the estimation of
   the current throughput based on loss measurements.

2.1.1, first bullet in first list:
consider s/"both sides should be"/"both sides are"
GIM>> Agree, accepted.

-4.1, 2nd paragraph, first sentence:
Missing words? (What is IANA requested to do with the TLV? I assume register it. Also, what is the name of the new TLV?
Consider a cross-reference to table to for "this sub-registry"
GIM>> I think that missing are "to allocate" and the name of the TLV " MPLS OAM Functions":
   IANA is requested to allocate a new MPLS OAM Functions TLV from the
   standards action range (0-16383) and sub-TLVs as follows from sub-
   registry presented in Table 1, called "Sub-TLVs for TLV [TBA1]".

-4.2: "Assignments of bit positions 0 through 31"
If I read correctly, that's all the bits. Is this the same as saying the registry itself requires standards-action?
GIM>> Yes, the whole range is under standard-action allocation policy.

-5:
It's mildly odd to find the acknowledgements section between two substantive sections.
GIM>> Thank you, moved it.

-6, first paragraph:
Should "liveliness" be "liveness"?
GIM>> Yes, we're not checking its vitality.