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

Jari Arkko <jari.arkko@piuha.net> Thu, 29 November 2007 13:33 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 1IxjVx-0006yM-W1; Thu, 29 Nov 2007 08:33:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjVv-0006ww-T5; Thu, 29 Nov 2007 08:33:11 -0500
Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxjVv-0006ck-EU; Thu, 29 Nov 2007 08:33:11 -0500
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E466F19867C; Thu, 29 Nov 2007 15:33:09 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9F3C6198676; Thu, 29 Nov 2007 15:33:09 +0200 (EET)
Message-ID: <474EBF98.4000509@piuha.net>
Date: Thu, 29 Nov 2007 15:33:12 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com><CC3C6CC7EE08DA90C239082B@p3.JCK.COM> <E1IxV26-0006Ne-TG@megatron.ietf.org> <40F79287-713F-4167-8DC3-0DA35D565D54@cisco.com> <23E55AFB-7AE6-4142-9ACC-0C2969B5D1DF@nist.gov> <474EAEAB.9070702@dcrocker.net>
In-Reply-To: <474EAEAB.9070702@dcrocker.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: IAB <iab@ietf.org>, ietf@ietf.org, IESG IESG <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

I agree with what Dave, Tim, and Harald said. Besides, if we really
wanted a delay, we should pay the RFC Editor less and ask them to
provide slower service :-) But please keep this as a secret from the IAOC...

I would also like to point out its not the bits that are dangerous in a
mistakenly or inappropriately approved document. It is the status that
the IETF gives to these bits that matter. E.g., Proposed Standard,
product of such and such WG. The bits are already out there in many
places; we cannot withdraw them. What we can control is the status that
the IETF gives for those bits. The modern tools we have for viewing IETF
documents can make it plainly obvious to people what the status of an
RFC is.

But I would also caution a little bit against thinking that the
solutions are easy. I think we should have a short deadline for
notifying intent to appeal. However, a 5 page document may still get
through the RFC Editor in a surprisingly small amount of time. And we
can move a document to historic, but what about the other documents that
referred to it? We can delay only the documents that we know will be
appealed, but this appears to have obvious DoS problems.

Nevertheless, I think repairing damage if it occurs is probably the
right answer. Possibly combined with a short intent-to-appeal period, so
that we can try to do the right thing as soon as possible.

Jari


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