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

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

OK

   Les

> -----Original Message-----
> From: Lsr <[e-mail]> On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, March 03, 2021 10:41 AM
> To: Donald Eastlake <[e-mail]>; 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
> 
> Speaking as WG member:
> 
> As long as we are revising, I'd suggest changing "ISIS" in the title and several
> times in the text to "IS-IS" consistent with other IS-IS RFCs (at least the
> newer ones).
> Thanks,
> Acee
> 
> On 3/3/21, 1:32 PM, "Donald Eastlake" <[e-mail]> wrote:
> 
>     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."
> 
>     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]".
> 
>     3. Use of "new" throughout the document for codepoints that were
>     assigned for RFC 5316 more than a decade ago should be eliminated.
> 
>     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.
> 
>     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)
>        +-+-+-+-+-+-+-+-+-+-+-+-
> 
> 
>     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