Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt

Russ Housley <housley@vigilsec.com> Mon, 11 June 2012 15:43 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2921F8620 for <ietf@ietfa.amsl.com>; Mon, 11 Jun 2012 08:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uohJPR6uFlJx for <ietf@ietfa.amsl.com>; Mon, 11 Jun 2012 08:43:22 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96221F860E for <ietf@ietf.org>; Mon, 11 Jun 2012 08:43:22 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C6B60F24014; Mon, 11 Jun 2012 11:43:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id g21TvgMpVgFJ; Mon, 11 Jun 2012 11:43:08 -0400 (EDT)
Received: from [192.168.2.110] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EB487F2402B; Mon, 11 Jun 2012 11:43:32 -0400 (EDT)
Subject: Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <4FD595EB.7020401@gmail.com>
Date: Mon, 11 Jun 2012 11:43:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <981B0927-EC49-4AB0-985D-C80951487D89@vigilsec.com>
References: <20120609221936.12063.68465.idtracker@ietfa.amsl.com> <4FD47CF1.4080107@gmail.com> <4FD4C49F.8080508@gmail.com> <3E95A8C1-08F1-4519-95AF-1E99FA205B28@vpnc.org> <4FD595EB.7020401@gmail.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>, Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1084)
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 11 Jun 2012 15:43:23 -0000

Paul and Brian:

>>> Oh, one thing I now realise is that the draft doesn't state that
>>> the editor (in deciding what changes to adopt) and the IESG
>>> (in approving an update) will of course do so by a normal IETF
>>> consensus process (presumably ad hoc last calls) and subject
>>> to appeal like anything else. This is so obvious in the IETF
>>> context that I didn't even notice that it wasn't stated.
>> 
>> It is not what was intended.
>> 
>> - There was no mention to me of "ad hoc last calls", so I did not include them in the draft. 
> 
> Well, that was presumably an oversight. The IETF always works by
> a consensus process, afaik.

The IESG thinking on this is in line with Brian's thinking.  In the past, the Tao has been published as an informational RFC.  The approval process included community comment and IESG evaluation.  A parallel approval process ought to be used here.

Let's use of a well-known URL for the current approved Tao and a well-known URL for the draft of the Tao that is under consideration.  This will facilitate review of updates.

>> - Is there an appeals process for the content of the various web pages created by the IESG?
> 
> Yes. For many years there has been a presumption that the appeals
> process in section 6.5 of RFC 2026 can be applied to *any* IESG action.
> That being so, I suppose it isn't vital to write it down in every
> document, but it makes things clearer.

Indeed.  Any decision by the IESG is subject to the existing appeals process.

Russ