Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

Olaf Kolkman <olaf@NLnetLabs.nl> Fri, 28 August 2009 08:55 UTC

Return-Path: <olaf@NLnetLabs.nl>
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 136EA28C13B for <ietf@core3.amsl.com>; Fri, 28 Aug 2009 01:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level:
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799]
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 uhkqb8j0Hs+o for <ietf@core3.amsl.com>; Fri, 28 Aug 2009 01:55:54 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id B508D28C116 for <ietf@ietf.org>; Fri, 28 Aug 2009 01:55:53 -0700 (PDT)
Received: from [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb] ([IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n7S8tiUk005961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2009 10:55:45 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl)
Message-Id: <23D63F9D-731B-45C8-9A87-735A669DE88B@NLnetLabs.nl>
From: Olaf Kolkman <olaf@NLnetLabs.nl>
To: IETF Discussion <ietf@ietf.org>
In-Reply-To: <4A973D42.8030203@dcrocker.net>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-1-412116148"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Date: Fri, 28 Aug 2009 10:55:39 +0200
References: <20090601135553.76CC73A6DB6@core3.amsl.com> <4A23EA07.8030709@piuha.net> <4A23EC17.1010303@piuha.net> <DC08019F-8EAC-40FF-BCE9-66AA0F473DFB@NLnetLabs.nl> <86C717D4-1B08-4155-8B98-FF11EC80501E@cisco.com> <20090827155712.F1FE89A4738@odin.smetech.net> <4A973005.3070506@gmail.com> <4A973D42.8030203@dcrocker.net>
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 28 Aug 2009 10:55:45 +0200 (CEST)
Cc: Dave CROCKER <dcrocker@bbiw.net>
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, 28 Aug 2009 08:55:55 -0000

On Aug 28, 2009, at 4:13 AM, Dave CROCKER wrote:

>
>
>
>>>>> I am under
>>>> the understanding the the IESG Note in RFC is provided by the  
>>>> IESG not
>>>> by the RFC Editor. Is there a document that says otherwise? (I'm
>>>> certainly open to the possibility that perhaps these documents  
>>>> should
>>>> not have an IESG note but that seems a different issue)
>>> My understanding of this text is that the IESG can recommend text,
>>> including an IESG Note.  The RFC Editor can accept it or not.


As Russ said: the IESG can suggest text, which can be an IESG note.  
The RFC Editor, more specifically the Independent Submission Editor,  
is responsible for the followup, which includes the possibility of the  
variation described below.

FWIW (and in my no-hats opinion) this 'negotiation' between IESG and  
ISE should all happen well before the RFC is submitted to the  
production center and the RFC Series Editor (RSE) should in general  
not be part of this loop. Only if the ISE and the IESG cannot come to  
agreement then the RSE is called in as described in RFC5620 section  
4.1.3.



> ...
>> I'm pretty sure, though, that there has been pushback and negotiation
>> on quite a few occasions. It's important that the RFC Editor keeps
>> this power, in the general interest of checks and balances.
>
>
> +1.
>
> One can debate various details and costs about the RFC Editor  
> function.  But it really is quite useful to have the editor exert an  
> independent review of IESG efforts to modify an RFC.
>
> Not because the IESG is suspect, but because it is deeply involved  
> in the topics it comments on and that could cause misguided  
> decisions.  By contrast, the RFC Editor can consider suggested IESG  
> notes with detachment.
>
> My impression, too, is that this has produced revised IESG text.
>
> d/
> -- 






________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam