Hi, On Sun, Dec 8, 2024 at 6:48 PM Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > On 09-Dec-24 11:15, Donald Eastlake wrote: > > 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. > > I certainly didn't mean to imply that.
I haven't heard you explicitly say that but I've heard others say similar things. > > 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. > > But that isn't an "external" specification, is it? The various > GOST crypto algorithms clearly are, reproduced as RFCs in English > for convenience. RFC 8822 is a specification developed in the Broadband Forum for use in the Broadband Forum. How is that not "external"? The 5G Access Gateway Function mentioned in the Abstract is in BBF TR 456. > (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. > > I agree - that's a spec that is in the process of becoming an IETF > spec. So there are exceptions to your statement that external specifications should be published in the Independent Stream, in this case if they might become an IETF 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. > > No, but again: that's IETF work, not an external spec. My message was primarily in response to your statement that external specifications should be published in the Independent Stream. My point 3 should, perhaps, have started with "Even if neither case 1 or 2 applies to an external specification, ..." While there is some relation, the question of whether "external specifications" have to be published in the Independent Stream and whether all IETF Stream Informational RFCs should require IETF consensus are different questions. My points 1 and 2 above are cases where I think an external specification should be published in the IETF Stream. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > > ∞: 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? > > Because the I in ISE stands for Independent, and the S in IESG > stands for Steering, I think. But rfc-interest is probably not the > place to re-litigate RFC 8789. > > Brian > > > 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
