Sam,
I agree with Russ. I think the clearest possible result is the one
we achieved in the case appended below, but that required quite
some work in the absence of a well-defined procedure, even without
there being an independent submission to synchronize. I think the
draft makes such cases easier to get right.
Brian
3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A.
Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S.
Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT=33896
bytes) (Obsoletes RFC2598) (Status: PROPOSED STANDARD)
3247 Supplemental Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K.
Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C.
Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT=53786 bytes)
(Status: INFORMATIONAL)
3248 A Delay Bound alternative revision of RFC 2598. G. Armitage, B.
Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J.
Schnizlein. March 2002. (Format: TXT=21597 bytes) (Status:
INFORMATIONAL)
On 2008-11-27 04:14, Russ Housley wrote:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf