Hi Les, See below at <de>
On Wed, Mar 3, 2021 at 3:47 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Donald - > > Thanx for your careful review and your support of the draft. > Replies inline. > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Donald Eastlake > > Sent: Wednesday, March 03, 2021 10:32 AM > > To: Christian Hopps <[email protected]> > > Cc: [email protected]; [email protected]; [email protected]; lsr- > > [email protected]; [email protected]; [email protected] > > 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 [email protected] > Les > > > > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > [email protected] > > > > On Wed, Feb 17, 2021 at 10:30 AM Christian Hopps <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
