From: Les Ginsberg (ginsberg)
Sent: 09 December 2022 00:30
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.
Of course. It is rough consensus and I learnt decades ago that I will often be
in the rough. But I also know from long before my involvement with the IETF
that I get feedback some years down the line along the lines that my
suggestions were better than they seemed at the time so I continue to make them
(I also know that I could word them better at times). Whatever you come up is
ok.
Tom Petch
More inline. Look for LES2.
> -Original Message-
> From: tom petch
> Sent: Thursday, December 8, 2022 9:00 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-rfc8920...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00
>
> From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
> Sent: 08 December 2022 15:38
>
> Tom -
>
> > -Original Message-
> > From: tom petch mailto:ie...@btconnect.com>>
> > Sent: Thursday, December 8, 2022 2:52 AM
> >
> > From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of
> > Christian Hopps
> > mailto:cho...@chopps.org>>
> > 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/
> >
> >
> > 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?
>
>
> 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.
>
>
>
> 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.
