Sam:
That said, I'm puzzled by the continued inclusion of "rejected
alternative bypass" as a reason to delay publication. In section 4,
this document proposes that readers could be confused by the order of
publication of documents. At the same time, this document is removing
the mandatory IESG note from independent submissions in favor of a new
header (defined in another doc, listed as a normative reference). If
that header is sufficient to dispel confusion when it comes to the
substantive matters of "we haven't reviewed this", can't it also be
relied on to be adequate to avoid confusion arising from publication
order? Accordingly, I suggest removing reason 3, as least so far as
"rejected alternative bypass" is concerned.
There are two scenarios to consider. They are AD-sponsored
informational RFC and independent submission informational RFC.
1. AD-sponsored informational RFC
Here the title page will indicate IETF Stream for both
documents. The publication of the rejected alternative prior to the
standards-track document leaves a time period where people that are
not watching carefully do not know that the standards-track
alternative is in the works. If one only watches the RFC series, it
is unclear that the other document is coming, and the first one
indicates that is a product of the IETF.
Today, the AD will hold the rejected alternative until the
standards-track document is in the RFC Editor queue, and the
informational document will be published with a note indicating that
a standards-track alternative is available in RFC xxxx.
2. Independent submission informational RFC
Here the title page will indicate that the standards-track document
is part of the IETF Stream and that the rejected alternative will
indicate that the informational document is part of the Independent
Submission Stream. The publication of the rejected alternative prior
to the standards-track document leaves a time period where people
that are not watching carefully do not know that the standards-track
alternative is in the works. If one only watches the RFC series, it
is unclear that the other document is coming, but no one should be
confused that the informational document was the product of the IETF.
Today, the IESG asks the RFC Editor to hold the rejected alternative
until the standards-track document is in the RFC Editor queue, and
the informational document will be published with a note indicating
that a standards-track alternative is available in RFC xxxx. That is
the point of the response you are questioning.
Russ
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf