--On Friday, August 9, 2024 09:09 +1200 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: >... > Then determine in what ways current practice differs from what the > cleaned up versions say. And what other documents might also be > non-trivially affected. > > 15 RFCs update RFC 2026. 292 RFCs cite it, according to the tracker. > 5 RFCs update RFC 2418. 36 RFCs cite it. > > Also determine what we want to change, if anything. For example, I > would want to see draft-loughney-newtrk-one-size-fits-all seriously > considered. As we generate more and more process and procedural RFCs, record more binding process decisions and requirements in IESG Statements or other web pages, and move toward more specialized mailing lists and WGs for procedural topics, another example would be creating one or two new labels to separate BCPs that apply to protocols and other technical specifications from BCPs that describe how the IETF does things and makes decisions, starting, of course, with the replacements for RFC 2026 and 2418 and their many friends. See https://mailarchive.ietf.org/arch/msg/mod-discuss/plXipvvmx16VCRa4gYgUoZcImQA for a more detailed discussion about one particular case. > Finally decide how granular we want the result to be. We long ago > split out the IPR stuff - do we want to further split 2026 and 2418 > into more than two documents? Do we want codify stuff that is still > folklore? > > Big job, but IMHO necessary. I agree with you about the importance and necessity and am really pleased that Rich is willing to take this on. Ad that same time, scars from the outcome of NEWTRK have still not healed. I think we should give some consideration to the lessons we might or should have learned. Unless we have a plan about keeping the scope _very_ narrow (e.g., resolving inconsistencies as those updates are assembled plus _only_ the above two example issues), doing that consolidation and replacement is going to require a great deal of community time. It will also require a great deal of IESG time, and that is for an IESG that is almost certainly more overloaded today than its predecessor was when the NEWTRK work as being done. Noting that a revision process in which everything was open for discussion, it would be, IMHO, close to dumb to invest the energy in determining what we want to change or even starting to put draft documents together unless there was clear consensus in the IESG that putting in the time would be worthwhile and where that time was going to come from. IIR, you were IETF Chair at the time of the NEWTRK debacle. If so, insights from you about what went wrong there and how it might be avoided in future broad-scope efforts would probably be very helpful to the IESG and the broader community. > Acronym needed, to succeed POISED, POISED95, POISSON, NEWTRK, PESCI > and PUFI. Right. If my concerns hinted at above are even close to relevant, perhaps we should look for an expansion for RATHOLE. :-( john
