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 protected]> wrote: 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). > > 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. 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
