Re: Internet-Draft draft-rsalz-2026bis-00.txt is now available.

[Brian E Carpenter <[e-mail]>]

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
> <[e-mail]> 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
>