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

[John C Klensin <[e-mail]>]

--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