Hi Donald,
On 09-Dec-24 18:48, Donald Eastlake wrote:
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.
It's an IETF consensus document with a normative reference to another
IETF document (which is also Informational) as well as to 3GPP
documents. The Acknowledgment says that it was developed by discussions
in the Broadband Forum but that doesn't stop it being an IETF document,
especially since it builds on PPoE.
Note, I have no quarrel whatever with the document; but it followed
the IETF publication process for non-WG documents so IMHO it's not
"external".
(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.
I think we are arguing about the precise meaning of "external". But yes,
that's correct; the traditional example was NFS. In the end, does
it matter, as long as we keep the rules flexible enough to cope with
special cases?
Regards
Brian
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
