Re: [Teas] [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

["Les Ginsberg (ginsberg)" <[e-mail]>]

Donald -

Thanx for your careful review and your support of the draft.
Replies inline.

> -----Original Message-----
> From: Lsr <[e-mail]> On Behalf Of Donald Eastlake
> Sent: Wednesday, March 03, 2021 10:32 AM
> To: Christian Hopps <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; lsr-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> Hi,
> 
> I have a few comments. Sorry to send these so late in the process. I
> support publication of this draft regardless of whether any action is
> taken on my comments.
> 
> 1. Since there are non-allocation actions, I suggest that the first
> sentence of Section 6 be more like "IANA is requested to take the
> following actions."
> 

[Les:] I understand your point.
However, in this case we are inheriting allocations made by RFC5316 AND adding a new code point for the new IPv6 local ASBR identifier sub-TLV.
Being 100% accurate requires identifying what has been done already vs what is new.
But once the RFC is published the text will change to " IANA has made..." (as it is in RFC 5316) for all the code points (new and old).
Having worked w IANA folks many times, I have great confidence that they will get things right even with the current less than 100% strictly accurate text - so I prefer not to invest time here.
Hope that is OK with you.


> 2. It should be called out as an explicit IANA action to replace all
> References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> with References to "[this document]".
> 

[Les:] OK

> 3. Use of "new" throughout the document for codepoints that were
> assigned for RFC 5316 more than a decade ago should be eliminated.
> 

[Les:] Well, this document replaces RFC 5316. Which means future readers need not ever look at RFC 5316. In which case the distinction between what was "new" in 5316 and what is "new" in 5316bis becomes moot. 
So while I agree that strictly speaking you are correct I am not convinced that doing as you suggest aids clarity. 

> 4. I generally think it is better for implementation requirements to
> be in the main text rather than the IANA Considerations, so I suggest
> moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> 25, 222, or 223 and MUST be ignored if they are included in any of
> these TLVs." up to near the end of Section 3.1.

[Les:] I have looked at other documents with similar cases (i.e., a sub-TLV that is permitted in only a subset of the TLVs in the combined registry) and they do not have such a statement at all. The "N" indication in the registry columns is deemed sufficient.
I am therefore inclined to remove the Note altogether.

> 
> 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> the prose table at the beginning of 3.1 with the following. In any
> case note that the usual IETF admonition regarding the reserved bits,
> that they MUST be sent as zero and ignored on receipt, seems to be
> missing in the document.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Router ID                                     (4 octets)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   default metric                              | (3 octets)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |S|D| Rsvd      |                                 (1 octet)
>    +-+-+-+-+-+-+-+-+
>    |sub-TLVs length|                                 (1 octet)
>    +-+-+-+-+-+-+-+-+-+-+-+-
>    | sub-TLVs ...                                    (0-246 octets)
>    +-+-+-+-+-+-+-+-+-+-+-+-
> 
>      - S, D: Flooding-scope and up/down information discussed below.
>      - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
>              on receipt.
>      - sub-TLVs length: gives the total number of octets of sub-TLVs,
>              which is variable from zero to 246 octets, as an unsigned
>              integer. sub-TLVs are structured as shown below. sub-TLVs
>              with an unknown type MUST be ignored. If the value of the
>              sub-TLVs length field is larger than 246, or the last
>              sub-TLV extends beyond the sub-TLVs length, the TLV is
>              malformed and MUST be ignored.
> 
>    +-+-+-+-+-+-+-+-+
>    | sub-type      |                                 (1 octet)
>    +-+-+-+-+-+-+-+-+
>    | sub-TLV length|                                 (1 octet)
>    +-+-+-+-+-+-+-+-+-+-+-+-
>    | sub-TLV value ...                               (variable)
>    +-+-+-+-+-+-+-+-+-+-+-+-

[Les:] OK
It was not done this way in RFC 5316. When writing bis documents I am biased to NOT changing existing presentation if there is no actual change in functionality to that section.
But I agree diagrams are easier to read and it would be more consistent with other sections of the document.

   Les

> 
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
> 
> On Wed, Feb 17, 2021 at 10:30 AM Christian Hopps <[e-mail]>
> wrote:
> >
> > Hi LSR and TEAS,
> >
> > This begins a joint WG last call for:
> >
> >   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> >
> > Please discuss any issues on the LSR mailing list. The WGLC will end March
> 3, 2021.
> >
> > Authors, please indicate wether you are aware of any IPR related to this
> document to the list.
> >
> > Thanks,
> > Chris, Acee, (Lou and Pavan).
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr