Re: [mpls] Concerned by the silence [Was: Working Group Last Call : draft-ietf-mpls-lsp-ping-registries-update-04]

[Martin Vigoureux <[e-mail]>]

Hi

I should read the docs in my queue instead but ...

       a sub-registry is used when a code point allocated in a registry
       need code points scoped by that or a set of code points.
this is a bit hard to parse. at least s/need/needs/


    The range of each TLV and sub-TLV registry is divided into two
    blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that
    require a response if not recognized.  The other block has the range
    from 32768 to 65535 for TLVs and sub-TLVs that may be silently
    dropped, stepped over or an error message sent, if not recognized.
this seems like saying exactly the same thing than what the two bullet 
points above (in the draft) say.


In:
    o  If the unrecognized TLV or sub-TLV is from the Experimental Use
       range (37140-37143) or from the FCFS range (31744-32767) a the
       Return Code of 2 ("One or more of the TLVs was not understood")
       will be sent in the echo response.
and in the table of:
3.2.  Common Registration Procedures for TLVs and sub-TLVs

    37140-37143 | Experimental Use  | Reserved, not to be assigned
is the range correct?
shouldn't it be 31740-31743?
BTW, This table doesn't have a number like all other. May be you should 
call it Table 1 (and renumber all other).


Section 2 says:
    o  In the listing of assiged code points the term "Vendor Private
       Use" is changed to "Private Use".
but 3.3.1 says:
    o  In the listing of assignments the term "Vendor Private Use" is
       changed to "First Come First Served (FCFS)".

note there are other differences:
    o  A note "Not to be assigned" is added for the registration
       procedures "Private Use" and "Experimental Use".
    o  A note saying "Not to be assigned" is added for the registration
       procedures "Experimental Use".

    o  In the lists that capture the assignment status, the fields that
       are reserved, i.e.  0 (zero), Private Use and Experimental Use are
       clearly marked as such.
    o  In the list that captures assignment status, the fields that are
       reserved, i.e.  0 (zero) and Experimental Use are clearly marked.
Not sure whether they are intentional.


    Some referenced RFCs use the concept "mandatory TLVs" and "mandatory
    sub-TLVs" to indicate that, if a TLV or sub-TLV of the range 0-16383
    or 16384-31743 in a message is not understood, an error message needs
    to be sent in response.
RFC 8029 talks about mandatory TLVs for a range up to 32767:
    Types less than 32768 (i.e., with the high-order bit equal to 0) are
    mandatory TLVs
BTW you says that clearly in 4.1, so I think this should be consistent here.


You say:
    The Value field contains the TLVs, including sub-TLVs, that were
    not understood, encoded as sub-TLVs.
But 8209 was saying:
    The Value field contains the TLVs that were not understood, encoded
    as sub-TLVs.
This is not only a "removing mandatory" change. you seem to now impose 
that sub-TLVs be sent. Is that the intent?


In Tables 10, 12, 14, 16, 18 20
    | 37140-37144 | Experimental Use  | Reserved, not to be assigned    |
    | 31748-32767 | FCFS              | This range is for Sub-TLVs that |
are these ranges correct?
shouldn't they be
    | 31740-31743 | Experimental Use  | Reserved, not to be assigned    |
    | 31744-32767 | FCFS              | This range is for TLVs anf sub- |


Nits:
s/This docuemtment/This document/
s/An exasmple/An example/
s/contaimer for regiistries/container for registries/
s/sunregistry/sub-registry/
s/assiged/assigned/
s/range for "RFC Required" range/"RFC Required" range/
s/i.e.  0/i.e., 0/ (2 occurences)
s/registry [IANA-RC] registry/registry [IANA-RC]/
s/sennt/sent/
s/First come, first served/First Come First Served/
s/defintions/definitions/
s/Experimetal Use/Experimental Use/
s/a the/a/
s/srange (64508-64511).  or/range (64508-64511) or/
s/sub- TLVs/sub-TLVs/
s/TLVs an sub/TLVs and sub/
s/TLVs anf sub/TLVs and sub/
s/First Come Frst Served (FCFS)/First Come First Served (FCFS)/
s/Experiemental Use/Experimental Use/
s/The first set are/The first set is/
s/the second set are/the second set is/
s/the range there the/the range of/?
s/The text in those two paragraphs are/The text in those two paragraphs is/
s/resereved/reserved/ (9 occurences)
s/Four code point has/Four code points have/ (3 occurences)
s/Two small sets, 4 code points each, has/Two small sets, 4 code points 
each, have/ (7 occurences)
s/recognised/recognized/


beyond that, I support this document moving forward.

-m

Le 2020-10-02 à 17:59, Adrian Farrel a écrit :
> I know this is not the most exciting document the working group has ever
> produced, but as shepherd I need to see some comments and expressions of
> support.
> 
> Thanks,
> Adrian
> -----Original Message-----
> From: mpls <[e-mail]> On Behalf Of Adrian Farrel
> Sent: 24 September 2020 17:32
> To: 'mpls' <[e-mail]>
> Cc: [e-mail]
> Subject: [mpls] Working Group Last Call :
> draft-ietf-mpls-lsp-ping-registries-update-04
> 
> Hi MPLS WG,
> 
> As previously noted, I'm the shepherd for this document and I'm running the
> working group last call as agreed by the chairs.
> 
> This email starts a two-week last call on
> draft-ietf-mpls-lsp-ping-registries-update-04
> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/
> 
> Please send your opinions to the mailing list before October 9th.
> 
> While yes/no opinions are not without value, it is far more helpful if you
> can indicate whether you have read the latest version of the draft, and what
> the reasons are for your opinions.
> 
> Of course, all of your review comments will be helpful in improving the
> document.
> 
> Best,
> Adrian
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>