Re: secdir review of draft-housley-iesg-rfc3932bis-06

[Russ Housley <housley at vigilsec.com>]

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