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
