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

Hi Les,

See below at <de>

On Wed, Mar 3, 2021 at 3:47 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Donald -
>
> Thanx for your careful review and your support of the draft.
> Replies inline.
>
> > -----Original Message-----
> > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Donald Eastlake
> > Sent: Wednesday, March 03, 2021 10:32 AM
> > To: Christian Hopps <chopps@chopps.org>
> > Cc: teas-chairs@ietf.org; teas-ads@ietf.org; teas@ietf.org; lsr-
> > chairs@ietf.org; lsr@ietf.org; lsr-ads@ietf.org
> > 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.
>

<de> I agree that IANA will fix this so it is OK to not change.

> > 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.

 <de> I was not suggesting making any distinction between what is or isn't
new in 5316bis, except by implication in the IANA Considerations Section.
I actually just don't see any need to use the word "new" in this document.

> 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.
>

<de> OK.

> > 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.
>

<de> I think there are actually two intertwined changes: a change to
presentation and more specific RFC 2119 language. I think both are an
improvement so thanks for agreeing to them.

<de>Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

>    Les
>
> >
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >  2386 Panoramic Circle, Apopka, FL 32703 USA
> >  d3e3e3@gmail.com
> >
> > On Wed, Feb 17, 2021 at 10:30 AM Christian Hopps <chopps@chopps.org>
> > 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
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>