Rob, Plus or minus quibbles about details, I think that, if it is possible, this would be the right way to go. I've got two strategic concerns that, I think, should be considered as part of devising a path forward. * As Brian and I have pointed out in different ways, the IETF's track record for successfully engaging with significant changes to standards track procedures has, starting with NEWTRK if not earlier, been fairly miserable. We should be careful that "bite size pieces" raises the odds of success rather than, e.g., running out of energy partway (in the community, the IESG, or both) and creating a new way to fail or end up in a silly state. I think (or at least hope) that is possible, but, especially given the track record, it should get some careful attention, not just hope that things will work out. * If we are going to have technical practice specifications that are self-contained and stable in BCP and standards track documents in the RFC Series and IETF procedural specifications that are produced by a different process and that are documented in a combination of RFCs and Web pages, splitting the "BCP" designation so it is not used for both becomes, IMO, even more important. I see Brian's comment, "Our system of immutable RFCs isn't well adapted to this", as probably reinforcing the wisdom of the type of approach you propose. That does not stop me from being concerned about the relationship of those, and other, ideas with the track record, an apparent proliferation of bikesheds around any process discussion in recent years, possibilities of increasing the substitution of closed-door discussions for community consensus, and complaints about IESG overload relative to engaging with major, IETF-wide, issues. This isn't going to be quick and easy no matter how we slice it. And, fwiw, I agree with Rich: we will be much better positioned to have a "what is to be done, how, and what the target(s) should be" discussion after we have a complete integrated document on the table and at least informal and general consensus that the integration didn't miss or foul up any important changes/ relationships that have already been specified. john --On Tuesday, August 27, 2024 09:37 +0000 "Rob Wilton (rwilton)" <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote: > Could we try and do this in smaller bite size pieces? > > E.g,. perhaps something along the lines of … > > > 1. Bring all the existing updates to RFC 2026 together (as Rich > is doing – thanks Rich!), and probably split out the IPR (no > changes to the process, perhaps except clarifications). Republish > as a couple of new RFCs. This should be a step change improvement > to the process (for ADs and the community) since there are now many > less documents to read/consider when they are trying to figure out > the nuances of the existing IETF process. 2. Work out a > mechanism to split the core IETF process documentation into what > must be in RFCs/BCPs (i.e., categories of docs, what steps a doc > must pass through, etc), and what part of the process can sensibly > be documented on webpages along with defining, a hopefully lighter > weight, change/review process for those webpages. 3. > Split/migrate the existing IETF process into what must be in the > RFCs/BCP and what moves to webpages (hopefully also incorporating > appropriate IESG statements). If we want to change core parts of > the IETF process, i.e., the parts that are documented in BCPs, then > this may be a time to consider this, but this could also be > deferred, to reduce risk). Moving text to webpages may be quite a > lot of work, but it is possible that the IESG could request that > the LLC to help with this work. I.e., it doesn't necessarily > have to all be done by the community. 4. Now we have reached a > stable point with the minimal core IETF processes document in > RFCs/BCPs and the rest on IETF webpages (backed by git). All > future changes, clarifications to the process documented on the > webpages should be easier to do, particularly as smaller changes. > > I appreciate that all of this would be a lot of work, and by > splitting it up in phases we would be increasing that overall > amount of work done, but I think that this would end up getting us > to a better place for the long term future of the IETF, and by > splitting it up we hopefully reduce the risk of ending up in > failure. > > We would need various consensus checks for 1, 2, 3, but if the > process isn't being changed, then those consensus checks should > be limited to (i) whether the split between what is documented in > RFCs vs webpages is correct (bike shed risk here), and (ii) whether > that text matches the existing documentation (i.e., no changes to > the process have been inadvertently introduced). > > Regards, > Rob > > > > From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> > Date: Tuesday, 20 August 2024 at 06:21 > To: John C Klensin <john-ietf@xxxxxxx>, ietf@xxxxxxxx > <ietf@xxxxxxxx> Cc: chair@xxxxxxxx <chair@xxxxxxxx> > Subject: Re: Internet-Draft draft-rsalz-2026bis-00.txt is now > available. John, > >> 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. > > (I've left the rest of John's message below in case anyone needs > more context.) > > Yes, I was the very new IETF and IESG Chair when NEWTRK's output > failed to get past the IESG. For background, I took over from > Harald Alvestrand as Chair (and General Area AD) in March 2005, and > the crucial discussion took place at the IESG retreat meeting in > April 2005, where there was essentially no consensus (not even > rough) for the ISD proposal. > > The result was this: > https://mailarchive.ietf.org/arch/msg/newtrk/j8Si3b0cqnQSX5a5Ee8NIV > dyZg4/ > > The work continued during 2005 > (https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd > /history/) but it remained the case that there was no enthusiasm > for any such change in the IESG, nor even for reducing the number > of stages in the standards track (that came later), or even for an > attempt to clean up the existing process documents. > > By the end of 2005 the NEWTRK WG was more or less non-functional, > which I guess was due to the damper of the IESG response. After > NEWTRK was formally closed, I made a couple of attempts to start > non-WG efforts (baptised PESCI and PUFI) but they failed. > > Looking back on some of the related email in my personal archive, > I think one of the main problems was that just keeping the > existing process running, from I-D submission to RFC publication, > was so fragile that many ADs were trying to avoid process change > at all costs. At the time, remember, we didn't even have an IETF > Administrative Director (IAD) (until June 2005), we didn't own > our own intellectual property (until the end of 2005), the data > tracker was minimal and supported by pro bono effort, and the > stability of the RFC Editor process was in doubt. There is simply > no comparison with the stability that sound financing and the > advent of the LLC have brought us. > > One thing is clear to me, however. If we want to make a success > of clarifying and improving the standards process, we need the > IESG on board from the start. > > *In April/May 2005 when the above email was composed, only two > or three IESG members were on the NEWTRK list.* > > The ADs need to be part of the process, and hopefully part of > the rough consensus, *before* any resulting documents get near to > being ready for formal IESG review. So I've added a Cc. > > Regards > Brian Carpenter > > On 20-Aug-24 06:47, John C Klensin wrote: >> >> >> --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/plXipvvmx16VCRa4 >> gYgUoZcImQA 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 >>
