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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf