On Sun, Dec 1, 2024 at 2:15 PM Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > ... > > Today external specifications should be in the Independent series not subject > to IETF consensus, and I think that has removed the ambiguity for anyone > who reads the boilerplate. ...
I do not think things are so simple. 0. I really do not like glib statements that imply it is trivial to get something published as an RFC by the ISE. Some people say, without much thought, "Just publish it in the Independent stream." Documents do get turned down by the ISE. I have had dealings with a number of ISEs and, while I have respected each of them, each has, to a greater or lesser extent, their own priorities, sense of judgement, etc. Note, in particular, that the ISE is not under the IESG so there is no particular reason that importance to the IESG or an AD should necessarily translate to importance to the ISE. In fact, it would be quite reasonable for an ISE to feel that if something is really important to the IETF, then the IETF should go to the effort of reviewing and publishing it, not the ISE. 1. A document that creates a new IANA Registry or that needs a code point assigned that requires IETF consensus or the like (RFC 8726) must be an IETF stream document. For an example of which I am a co-author, see RFC 8822. (I believe the reasoning in the case of registry creation is that the IETF funds IANA and the creation of a new registry imposes additional work on IANA for an indefinite time into the future.) (While it would theoretically be possible to do this with two documents, trying to coordinate IETF Stream and Independent Stream documents with cross references seems difficult and complex.) 2. When an external protocol specification is moved to IETF change control, say an IETF WG, a common first/early step is that the existing non-IETF specification is published as an Informational RFC. It seems entirely reasonable for this to be published in the IETF stream and I see no reason for the ISE to be involved or for the ISE process to be able to delay or complicate the usual process here even though the entire content of such an RFC may be an externally developed specification. 3. Even if neither case 1 or 2 applies, surely it depends on the importance and urgency of publishing the informational RFC and to what extent facets of the IETF review process, which is generally not used/available for Independent Stream documents, might be important. Again, the IESG and ADs have no authority whatsoever over the ISE or the priorities of the ISE. These are all generally reasonable people and I'm not saying the ISE won't listen to things that an AD has to say but, on the other hand, there is no reason the publication of some Informational RFC that is felt to be urgent by an AD should be constrained by the ISE schedule / queue-length / priorities. ∞: I think that the change requiring an IETF Last Call and IETF consensus for all IETF stream Informational documents was wrong. I'm fine with the IESG deciding that, in some cases, an Informational draft doesn't need an IETF Last Call -- although, of course, in that case, the boilerplate should state that it does not have IETF consensus. Why exactly should the IESG have no authority to publish non-consensus Informational RFCs when the ISE is free to do so? Why should the IESG be handicapped in this way? (I'd be fine with changing the name of the consensus or the non-consensus IETF Stream Informational RFCs so as to make the distinction clearer. Perhaps the Informational RFCs with IETF consensus should be "Consensus Informational" RFCs instead of just "Informational" RFCs.) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > >... > Brian _______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
