Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-registries-update-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 18, 2021 at 12:45:44AM +0800, Loa Andersson wrote:
> Benjamin,
> 
> There is a little glitch in that RFC 8029 and RFC 8611 are not fully 
> aligned.
> 
> See inline.
> 
> 
> 
> On 17/02/2021 23:51, Benjamin Kaduk wrote:
> > Hi Loa,
> > 
> > On Wed, Feb 17, 2021 at 02:53:07PM +0800, Loa Andersson wrote:
> >> Benjamin,
> >>
> >> Tnx for review and suggestions.
> >>
> >> Response to the Discuss. I'm a bit embarrassed over table 22, I don't
> >> what happened.
> >>
> >> On 17/02/2021 12:40, Benjamin Kaduk via Datatracker wrote:
> >>> Benjamin Kaduk has entered the following ballot position for
> >>> draft-ietf-mpls-lsp-ping-registries-update-08: Discuss
> >>>
> >>> 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-registries-update/
> >>>
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>>
> >>>
> >> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>>   A few super-boring inconsistencies that make the document unfit to
> >>> publish as-is but should be mostly trivial to resolve ((3) and (4)
> >>> might be a little tedious but should be mechanical):
> >>>
> >>> (1) Section 3.3.1 says:
> >>>
> >>> be silently dropped if not recognized.  The code points for
> >>> experimental use are taken from the ranges previously called 'Vendor
> >>> Private Use', the remainder of which now form part of 'RFC
> >>> Required'.
> >>>
> >>> but I don't think this sentence matches what's proposed in Section 6.
> >>> I am seeing the code points for experimental use coming out of the
> >>> range that is currently described as "specification required", with
> >>> the entirety of the range currently described as "vendor private use"
> >>> being converted to FCFS.
> >>
> >> Yes you are right, this was a late change because taking the
> >> "Experimental Use" code point from "RFC Required" made sure that we did
> >> not have any collisions with code points in use.
> >>
> >> Would the following be OK?
> >>
> >> NEW
> >>        be silently dropped if not recognized.  The code points for
> >>        experimental use are taken from the ranges previously (RFC
> >>        8029) called 'Specification Required' and (RFC 8611) "RFC
> >>        Required".
> > 
> > I think so, thanks.
> > 
> >>>
> >>> (2) Section 4.1 says:
> >>>
> >>> Mandatory and optional are used to indicate whether a response is
> >>> needed if a TLV or sub-TLV is not understood on pages 14 and 15 in
> >>> Section 3 of RFC 8029.
> >>>
> >>> but I think the text being modified is on pages 15 and 16 of RFC
> >>> 8029 (the page numbers are in the footer, not the header, of the
> >>> plain text output format).
> >>
> >> My mistake, will change  to:
> >>
> >> NEW:
> >>        Mandatory and optional are used to indicate whether a response is
> >>        needed if a TLV or sub-TLV is not understood on pages 15 and 16 in
> >>        Section 3 of RFC 8029.
> > 
> > +1
> > 
> >>>
> >>> (3) Section 6.2.3 describes changes to the procedures for the
> >>> Sub-TLVs for TLV 6 sub-registry, but the changes described assume
> >>> that the registration procedures are as described by RFC 8029.
> >>> However, the registration procedures have already been changed by RFC
> >>> 8611, so the changes described no longer make sense.  (E.g., there is
> >>> not currently a "specification required" procedure active for any
> >>> range of this sub-registry.)  We do, however, still need to make some
> >>> changes to the registration procedures, specifically to convert the
> >>> "Private Use" ranges to FCFS and carve out the "Experimental Use"
> >>> blocks.
> >>
> >> If I read this correctly the one thing we need to do is to remove one
> >> bullet:
> >>
> >>
> >>      o  The "Specification Required" registration procedure has been
> >>         changed to "RFC Required", the comment "Experimental RFC Required"
> >>         has been removed.
> > 
> > I don't think that's quite everything; we also want.
> > 
> > OLD:
> >     o  The code points registration procedure "Vendor Private Use" has
> >        been removed and replaced with "First Come, First Served" code
> >        points.
> > NEW:
> >     o  The code points registration procedure "Private Use" has
> >        been removed and replaced with "First Come, First Served" code
> >        points.
> 
> NEW:
>        o RFC 8029 was published before RFC 8126 and uses the old
>          terminology for some registration procedures, e.g "Vendor
>          Private Use". RFC 8611 was published after RFC 8126 and uses
>          the new terminology, e.g. "Private Use". Both "Vendor Private
>          Use" and "Private Use has been removed and replaced with "First
>          Come, First Served" code points.

That looks accurate to me, and well phrased.
I was not entirely sure whether we need the full complexity of it given
that the text in question is in Section 6.2.3 that is scoped to a single
sub-registry, and that sub-registry (IIRC) only lists the one RFC (8611) as
reference, which hopefully means that it's currently only using a single
set of terminology.

But to be clear, I am not objecting to your NEW version :)

Thanks,

Ben