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

[Martin Vigoureux <[e-mail]>]

Loa,

please see in-line.

-m

Le 2020-10-09 à 9:46, Loa Andersson a écrit :
> Martin,
> 
> Thanks for the support! I have started preparing version-05 of this 
> document.
> 
> I have included the first version of my working copy, mostly to show 
> what I have done and so that commenters can check how their comments
> have been addressed.
> 
> I have addressed most of your comments, but left a few question in this 
> mail. And will addressed the faulty registry ranges together with the 
> comments from Tom on the same subject.
> 
> Thanks for taking the time.
> 
> 
> On 05/10/2020 06:03, Martin Vigoureux wrote:
>> 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/
> 
> I have fixed the s/need/needs/
> 
> But I would be happy to get some help with this, what is there now is 
> the third or fourth iteration
> 
> What about:
> 
>         a sub-registry is used when a code point, or a set of code
>         points allocated in a single registry, needs "sub-code points"
>         scoped by the code point or the set of code points.
> 
> Any help appreciated.
either is fine. IMO s/need/needs/ made me understand the sentence so the 
new iteration is not particularly needed.

> 
> 
>>
>>
>>     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.
> 
> Yes I think you are right, the text and bullets have converged over 
> time; should I drop the text or the bullets?
I'd keep the bullets but you are the editor.
>>
>>
>> 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).
> 
> yes - you are right. However, Tom have listed morer of the same, I will 
> do a separate spin and update all the ranges
ok
>>
>>
>> Section 2 says:
>>     o  In the listing of assiged code points the term "Vendor Private
>>        Use" is changed to "Private Use"
> 
> .
> Yes - this is correct. The Message Types, Reply Modes and Return Codes 
> registries (section 2) keep the Private Use" registration policies.
> Note: I wanted to chage this to FCFS, but since range was only 4 
> possible allocation, and this is to small for an FCFS range, we kept the 
> Private Use regostrion policy.
>> but 3.3.1 says:
>>     o  In the listing of assignments the term "Vendor Private Use" is
>>        changed to "First Come First Served (FCFS)".
> 
> Yes - that is section 3 that discusses the TLVs and sub-TLVs (that have 
> sufficient space for a FCFS registrion policy). So this is correct.
>>
>> 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".
> 
> Correct for the same reason as above.
>>
>>     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.
>>
> This is correst for the same reason as above
ok
>> >
>>     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.
>>
> So you say that this would be better
> 
>      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-32767
>      in a message is not understood, an error message needs to be sent in
>      response.
yes
>>
>> 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?
>>
> 
> I think my text is correct, RFC 8029 is a bit vague. But RFC 8029 
> implies that a TLV that includes a unrecognized sub-TLV an error message 
> should be sent. But you need to return the entire TLV (with its 
> sub-TLVs). If you return  the sub-TLV only the might be several sub-TLVs 
> in the message that has the same type. You need the entire TLV for context.
ok
> 
>>
>> 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- |
>>
> Probably not, I'll check this as when I take care of  the corresponding 
> comments from Tom.
do you mean that they are probably not correct or that my suggestion is 
probably not correct?
>>
>> Nits:
>> s/This docuemtment/This document/                       + (+-sign 
>> means that it is fixed)
>> s/An exasmple/An example/                               +
>> s/contaimer for regiistries/container for registries/   +
>> s/sunregistry/sub-registry/                             +
>> s/assiged/assigned/                                     - (fixed 
>> becasue of another comment)
>> s/range for "RFC Required" range/"RFC Required" range/  +
>> s/i.e.  0/i.e., 0/ (2 occurences)                       + (sometimes I 
>> wish I understood how
>                                                               to use the 
> comma in English :)).
>> s/registry [IANA-RC] registry/registry [IANA-RC]/       +
>> s/sennt/sent/                                           - (fixed 
>> becasue of another comment) 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/?
> The sentence say:
>      the second set is for the
>      range there the TLV or sub-TLV that may be silently
>      dropped if not recognized.
> What about:
> 
>      the second set is for the
>      range there the TLV or sub-TLV may be silently
>      dropped if not recognized.
> 
> Changed. Comment?
hmmmm, not sure to understand what you mean here.

> 
>> 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.
> 
> Martin, tnx!!
> 
> /Loa
>>
>> -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
>>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>