Tom -
I don’t want to prolong this thread beyond reason. But I would like to make a few points. I generally find your diligence and attention to detail admirable and usually concur with your recommendations. But in this case, I still have some hesitancy. I do want you to know your comments are being seriously considered, even if - in the end - the drafts are not changed in the way you suggest. More inline. Look for LES2. > -----Original Message----- > From: tom petch <[email protected]> > Sent: Thursday, December 8, 2022 9:00 AM > To: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps > <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00 > > From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> > Sent: 08 December 2022 15:38 > > Tom - > > > -----Original Message----- > > From: tom petch <[email protected]<mailto:[email protected]>> > > Sent: Thursday, December 8, 2022 2:52 AM > > > > From: Lsr <[email protected]<mailto:[email protected]>> on behalf of > > Christian Hopps > > <[email protected]<mailto:[email protected]>> > > Sent: 07 December 2022 13:20 > > This begins a 2 week WG Last Call, ending Dec 21, 2022, for: > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ > > > > <tp> > > Clicking on the URL in Section 15 of the HTML-formatted I-D pulls up a list > > of > > 8642 messages; this may be a quirk of my user-friendly browsers although > it > > does happen with all of them which suggests not. > > [LES:] I'll look into fixing this in the next revision. Thanx. > > > The I-D might benefit from a Terminology section. SABM, for example, is a > > well-known abbreviation in link layer protocols but not in the sense it is > used > > here. > > > [LES:] The first use of SABM (in Section 5 TLV ASCII art) is followed by: > > "SABM Length: Standard Application Identifier Bit Mask Length in octets." > > Do you really think this is not sufficient? > > <tp> > yes, I really think that it is not sufficient. It is a very dense I-D as the > lists in s.5 > and s.6 show so I think that a terminology section would help. I was working > with SABM for decades before OSPF repurposed that abbreviation; others > might stumble with e.g LFA or SR although those I do not. > [LES2:] The use of SABM acronym is to make the ASCII art more readable. There is no additional use of this acronym other than in Section 15 which summarizes the changes introduced by the bis draft. Given this contained usage, the probability of confusing this usage with preexisting usage for a Layer 2 protocol like LAPB seems quite low to me - though clearly the possibility came to your mind. And I want you to know that I am old enough to have worked with LAPB, so it isn’t a generational gap. 😊 Although terminology sections are usually benign, given that this document references many acronyms defined elsewhere, the introduction of duplicate definitions always gives me pause - because it is always possible that unintentional differences in wording might suggest a different definition when none is intended. This is why I always prefer references rather than duplication. So, I am reluctant...but I will discuss your suggestion with co-authors. > > > The IANA registry has 28 references to RFC8920; should this be updated? > > [LES:] The IANA section states: > > "This specification updates two existing registries:..." > > Based on this instruction, I assume the IANA folks will update the existing > references to the new RFC. > > <tp> > > I never have a problem with giving IANA precise instructions. They are very > good at doing what they are told (even when it is not sensible!). Here you > are asking them to look beyond the IANA Considerations, note that the > references on the website are to an RFC that is being obsoleted and infer the > action needed. > [LES2:] First, I want to say that, in my experience, IANA is simply very good at what they do. That includes following instructions as well as knowing when to question those instructions. Given that the text here is identical to the text in the draft that became RFC 8920 and that IANA was able to "do the right thing" once - I am not sharing your concern. Les > Tell them! > > Tom Petch > Les > > > > > Tom Petch > > > > > > Authors, > > > > Please indicate to the list, your knowledge of any IPR related to this > > work. > > > > Thanks, > > Chris.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
