+1 to doing this work. Thanks Rich for starting this effort.
+1 to something like draft-loughney-newtrk-one-size-fits-all. I had started writing a similar draft.
I imagine that this will become a huge bikeshed, but I would also like there to be consideration as to whether we should review whether the other existing IETF categories are right. E.g., perhaps we should
have a category for “Architecture/Framework” documents. Today, I think that they are often classified as Informational, with correspondingly a bit less review. But given that they are invariably cited by standards track documents, they also end up being
a down ref. Instead, I would either like a separate category for these documents at the same level as IS/PS or for the description of IS/PS to include architecture/framework documents.
In terms of splitting documents – I would like the really core stages of the IETF standards process to be in an BCP, but any of the details that can change would be better on IETF webpages, still with community
consensus, but with a lighter process than publishing a new RFC, and also much easier to have a single set of pages that describe the current process for participants to follow rather than dozens of process RFCs + dozens of IESG statements. An example of
this might be the IESG balloting procedures, which Mark, IIRC, recently tried to codify into an RFC. I personally think that this would be a mistake (we have too many process RFCs) but having these rules/conventions on IETF webpages with some level of community
consensus might be a reasonable alternative.
In summary, yes to a BOF, with 3 goals:
- To cleanup what we have.
- To take efforts to try and simplify and streamline the process where possible.
- To make the process easier to find/follow for all participants in general, but particularly for new IETF participants.
Regards,
Rob
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Date: Thursday, 8 August 2024 at 22:10
To: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Internet-Draft draft-rsalz-2026bis-00.txt is now available.
On 09-Aug-24 08:22, Scott O. Bradner wrote:
> 1/ RFC 2026 was the product of significant discussion in a IETF working group - any update should follow
> the same path
+1. Start with a BOF. A proper clean-up of these two documents is badly needed. (So kudos to Rich for triggering a discussion.)
>
> 2/ it was an error to put the copyright & IPR rules in RFC 2026 - far better that the copyright & IPR rules are in
> separate RFCs (which also were the products of significant discussions in a working group)
I think the first step, for both 2026 and 2418, should be to produce versions with all updates and errata applied - in other words, start with what we actually have today. That would automatically include removal of all the IPR stuff, which as Scott says needs
to remain separate, as it is today. It's clerical work, but essential. (I don't know whether Rich has attempted this because his drafts don't tell me.)
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.
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.
Acronym needed, to succeed POISED, POISED95, POISSON, NEWTRK, PESCI and PUFI.
Brian
|
