Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

Robert Elz <kre@munnari.OZ.AU> Wed, 09 September 2009 12:54 UTC

Return-Path: <kre@munnari.OZ.AU>
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 624F03A6813; Wed, 9 Sep 2009 05:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Rm5y351lMLhy; Wed, 9 Sep 2009 05:53:59 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by core3.amsl.com (Postfix) with ESMTP id 3986328C122; Wed, 9 Sep 2009 05:53:56 -0700 (PDT)
Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id n89CsM4p001499; Wed, 9 Sep 2009 19:54:22 +0700 (ICT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id n89CsEC5005342; Wed, 9 Sep 2009 19:54:14 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
In-Reply-To: <tsl7hw89xk1.fsf@mit.edu>
References: <tsl7hw89xk1.fsf@mit.edu> <C6CBEDBD.14737%tim.polk@nist.gov> <tslvdjtctaq.fsf@mit.edu> <4936942A-5277-4112-B839-214E24EDCD73@NLnetLabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 09 Sep 2009 19:54:14 +0700
Message-ID: <6609.1252500854@epsilon.noi.kre.to>
Sender: kre@munnari.OZ.AU
Cc: Olaf Kolkman <olaf@NLnetLabs.nl>, "Polk, William T." <william.polk@nist.gov>, IETF Discussion <ietf@ietf.org>, IESG <iesg@ietf.org>
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: Wed, 09 Sep 2009 12:54:00 -0000

    Date:        Wed, 09 Sep 2009 07:17:50 -0400
    From:        Sam Hartman <hartmans-ietf@mit.edu>
    Message-ID:  <tsl7hw89xk1.fsf@mit.edu>

  | Right; I think I made it fairly clear in my reply to John Klensin that
  | I disagreed fairly strongly with that and argued why I believed that
  | the IETF needs a special role to attach a note to something.  No
  | discussion prior or since has changed my mind.

Ask yourself if you'd have the same opinion if the IETF was publishing
its output in IEEE Transactions on Networking (or any similar publication),
or even something like the NY Times.

Would you still expect the IESG to be able to tell the editor of that
publication what they are required to do?

Then note that this is exactly the same ralationship that the RFC
editor should have with the IETF.

In any case, if the editor is failing to perform adequately, the correct
response is to replace the editor - there is no rational consittuency here
in which to seek consensus (no matter who does the seeking) and no-one
rational to handle appeals, so I'm not in favour of John K's compromise
proposal.

Simply allow the editor the discretion to make his/her own decisions
(in this case, it will become the ISE with co-ordination from the RFC editor)
and then if they're failing (which mostly means, not getting things published, 
but might also mean sub-standad publications), then replace them with
someone who can do better.

Nothing more than that is needed.

kre