Hi Paul, > On May 24, 2023, at 11:02 PM, Paul Wouters via Datatracker <[email protected]> > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-lsr-ospf-terminology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am a little puzzled by a standalone document that changes these words. > Implementers are still forced to read the original RFCs this document updates > and the original words are all over the place in those documents. It would > have > made more sense to me to incorporate these new words in bis documents.
I’m not sure why you are “puzzled”. I must assume you are familiar with the IETF process so you should understand that doing of BIS version of all these documents would be a significant undertaking and which would take a lot of work and time. However, you may not appreciate why this is still a very important document as it allows vendors to update their documentation, error/trace messages, and show command output with the new inclusive OSPF terminology. > I agree > with Eric that IANA should keep the old name in a note for clarification. I tend to agree with Alvaro that we shouldn’t do this. We can reference this new RFC in the IANA registry. Thanks, Acee > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
