IETF Logo Mail Archive

Re: Should the RFC Editor publish an RFC in less than 2 months?

Sam Hartman <hartmans-ietf@mit.edu> Thu, 29 November 2007 00:10 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWyn-0005mO-NQ; Wed, 28 Nov 2007 19:10:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWyk-0005Ws-Ad; Wed, 28 Nov 2007 19:10:06 -0500
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWyi-0002R2-PR; Wed, 28 Nov 2007 19:10:06 -0500
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 887DB4815; Wed, 28 Nov 2007 19:10:02 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <E1IxTPt-0006r4-ST@ietf.org> <p0624081fc373a6b5e8fb@[10.20.30.108]>
Date: Wed, 28 Nov 2007 19:10:02 -0500
In-Reply-To: <p0624081fc373a6b5e8fb@[10.20.30.108]> (Paul Hoffman's message of "Wed, 28 Nov 2007 15:18:34 -0800")
Message-ID: <tsl4pf5di91.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: iab@ietf.org, ietf@ietf.org, iesg@ietf.org
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

>>>>> "Paul" == Paul Hoffman <paul.hoffman@vpnc.org> writes:

    Paul> One easy solution to the problem is to not change anything
    Paul> in the current IETF or RFC rules. If an RFC has been
    Paul> published before the appeal is brought, and that appeal is
    Paul> ultimately successful, a new RFC is issued that obsoletes
    Paul> the old RFC. That new RFC can essentially be a NULL,
    Paul> although hopefully it would have an explanation why an empty
    Paul> RFC is obsoleting a non-empty one. That new RFC can also be
    Paul> partially populated; for example, if the resolution of the
    Paul> appeal is to pull a contentious section or appendix.

I would be happy with this solution.

    Paul> Given the extreme rarity of the situation where an appeal
    Paul> leads to non-publication or changed publication, it seems
    Paul> wasteful to create new rules (and spend lots of time arguing
    Paul> about them) when no new rules are needed.

I agree.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email