Subject: [Lsr] Update to OSPF Terminology (draft-fox-lsr-ospf-terminology)

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 Feb 2022 22:45:12 +0000

Hi!

Mike, Acee, and I just uploaded a (very) short draft to update the master/slave terminology from rfc2328/rfc5340.

   https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/   

As you all know, implementations use these terms as part of their CLI and debug output.  The intent is to agree on common terminology.  The draft currently only addresses that pair of terms, but we should also cover others, if any.

Please comment and send any feedback.

I would love to discuss this document over e-mail and, if possible, avoid taking meeting time in Vienna.

Thanks!

Alvaro.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 23 Feb 2022 20:21:47 -0500

Hi Alvaro, et al.

I support these changes, and thanks for taking this up.

I guess it makes sense to not go full-in and re-spin the base docs if there literally are no other changes (although one wonders if it will actually change things like CLIs if we don't).

That said, quite a few errata exist for both of these documents.

Maybe an even better way forward with these types of inclusivity updates, for base documents with errata, would be to re-spin the base doc incorporating the existing errata *and* the improved terminology.

Thanks,
Chris.

Alvaro Retana <[email-masked]> writes:

> As you all know, implementations use these terms as part of their CLI and debug
> output.  The intent is to agree on common terminology.  The draft currently only
> addresses that pair of terms, but we should also cover others, if any.
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 24 Feb 2022 12:53:22 +0000

On February 23, 2022 at 8:35:03 PM, Christian Hopps wrote:

Chris:

Hi!

> I support these changes, and thanks for taking this up.

:-)

> I guess it makes sense to not go full-in and re-spin the base docs if there
> literally are no other changes (although one wonders if it will actually
> change things like CLIs if we don't).
>
> Maybe an even better way forward with these types of inclusivity updates, for
> base documents with errata, would be to re-spin the base doc incorporating 
> the existing errata *and* the improved terminology.

Hmmm...  That sounds like a lot of work for a couple of words.

The concern with opening up a big document like rfc2328/rfc5340 is that other things may creep in: "let's fix this", "let's add that", "let's include the Updates", "what about security?", etc.

Adam Roach wrote a draft [1] that describes a process for changes like this (terminology + errata).  The IESG has used it a couple of times, but it is not formal.  It would be up to the AD to approve, communicate with the IESG, etc.

[BTW, I am not the AD for this WG, nor am I acting as an AD when discussing this document, and I will recuse myself from IESG discussions about it.]

Alvaro.

[1] https://datatracker.ietf.org/doc/html/draft-roach-bis-documents

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Feb 2022 13:58:33 +0000

Agree with Alvaro... There is nothing that says we can't do this document now and still redo the base documents with updated terminology and Errata incorporated. The latter is likely to be a multi-year process while hopefully the former can be done in a year given the right focus. 
Thanks,
Acee

On 2/24/22, 7:53 AM, "Alvaro Retana" <[email-masked]> wrote:

    Chris:

    Hi!

    :-)

    Alvaro.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 24 Feb 2022 09:02:58 -0500

Alvaro Retana <[email-masked]> writes:

> The concern with opening up a big document like rfc2328/rfc5340 is that other
> things may creep in: "let's fix this", "let's add that", "let's include the
> Updates", "what about security?", etc.

It's wouldn't be a lot of work and those fears need not be present if we start the process with things clearly defined. "The *only* changes allowed are to incorporate the already accepted errata, and the terminology change; no other changes will be accepted". That's it, nothing more allowed. That would be the first thing for the WG to agree on, the rest would be editorial changes and shouldn't require much time at all then.

This shouldn't be hard to do, and if it is, maybe we're just doing it wrong. :)

Thanks,
Chris.

>
> Adam Roach wrote a draft [1] that describes a process for changes like this
> (terminology + errata).  The IESG has used it a couple of times, but it is not
> formal.  It would be up to the AD to approve, communicate with the IESG, etc.
>
>

---

From: tom petch <[email-masked]>
Date: Thu, 24 Feb 2022 17:00:53 +0000

From: Lsr <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Sent: 24 February 2022 14:02

<tp>

The problem I have always had with RFC2328, rendering it unusable, is the formatting where spaces have been replace with tabs, at least on every copy I have downloaded from the RFC Editor web site, and several years of trying have never yielded the magic formula as to what the tab settings should be for the document to print in a usable format.

I would engage with a 2328bis

Tom Petch

Thanks,
Chris.