Could we try and do this in smaller bite size pieces?
E.g,. perhaps something along the lines of …
- 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.
- 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.
- 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.
- 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/j8Si3b0cqnQSX5a5Ee8NIVdyZg4/
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/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
>
|
