3932bis approval

Jari Arkko <jari.arkko@piuha.net> Fri, 20 November 2009 14:44 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF5128C15A for <ietf@core3.amsl.com>; Fri, 20 Nov 2009 06:44:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level:
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQfi00RVYqgO for <ietf@core3.amsl.com>; Fri, 20 Nov 2009 06:44:13 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id F40C728C166 for <ietf@ietf.org>; Fri, 20 Nov 2009 06:44:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F3616D4953; Fri, 20 Nov 2009 16:44:09 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHd2vR73x1uf; Fri, 20 Nov 2009 16:44:09 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2D833D491E; Fri, 20 Nov 2009 16:44:09 +0200 (EET)
Message-ID: <4B06AB38.7060701@piuha.net>
Date: Fri, 20 Nov 2009 16:44:08 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>, RFC Interest <rfc-interest@rfc-editor.org>
Subject: 3932bis approval
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 14:44:14 -0000

Hi,

We have obviously had a lengthy process around the update to RFC 3932. 
Including some heated discussion and differing opinions. The document 
specifies IESG procedures for checking RFC editor submissions for 
conflicts with IETF work. We have already earlier resolved the issue of 
whether the IESG notes are used for all documents (as they are today) or 
if they are exceptional (the new model we want to follow).

The remaining difficulty was who to give the final authority to decide 
about IESG notes. In the course of the discussions a thought emerged 
that we could think about this in terms of arbitration via a third 
party. The draft specifies the details of this process in Section 4, 
which basically states that if for some reason the IESG and RFC Editor 
have not come to a common understanding after rounds of discussion, 
there is an opportunity for the IESG to ask the IAB to arbitrate the 
matter. The IAB can then either direct a particular outcome or leave the 
final decision to the RFC Editor.

I realize that it is hard to come up with any model that satisfies 
everyone. For instance, there are members of the community who believe 
any direction -- even from the IAB -- would reduce the independence of 
the RFC Editor. However, it is my belief that the above represents a 
compromise that helps people on different sides of the argument accept 
the end result. I know this does not satisfy everyone, but I believe we 
have rough consensus to move forward. Given that RFC 3932bis is in the 
interface between the IETF and RFC Editor functions, I also wanted to 
ensure that the IAB finds the result acceptable. During this process I 
have been struggling to find a model that would work for everyone both 
in the IESG and IAB. Russ and I spent some time in Hiroshima to talk 
about this with them, and we now have an OK from this perspective. 
Perhaps a bit grudgingly acceptance in some cases.

My conclusion is that this is the closest that we can come to an 
agreement over this. 3932bis represents a significant improvement over 
the current situation. My sense of the opinion of the common IETF 
participant is that we should get it over with and stop wasting our time 
on boilerplates and process :-) As a result, I have decided clear the 
final Discuss that was blocking the approval of the document.

The final document is available at 
http://tools.ietf.org/html/draft-housley-iesg-rfc3932bis. I hope that we 
will soon see new RFCs come out with the new headers, and most 
independent submission RFCs without IESG notes. The IESG has already 
processed a number of documents where our recommendation was to not have 
any note.

Jari