Subject: [secdir] secdir review of draft-housley-iesg-rfc3932bis-06

From: Samuel Weiler <[email-masked]>
Date: Tue, 25 Nov 2008 14:36:45 -0500 (EST)

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document appears to change ONLY the IRTF review process -- the
IESG long ago quit reviewing the substance of independent documents
from a security perspective.  Accordingly, the security considerations
is correct:

    The process change described in this memo has no direct bearing on
    the security of the Internet.

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.

-- Sam

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Nov 2008 10:14:54 -0500

>"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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Nov 2008 09:15:56 +1300

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:
> 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.
> 
> informational document will be published with a note indicating that a
> standards-track alternative is available in RFC xxxx.
> 
> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>