Re: I-D ACTION:draft-alvestrand-ipod-01.txt

John C Klensin <john-ietf@jck.com> Fri, 19 May 2006 11:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3TX-0004gy-UD; Fri, 19 May 2006 07:48:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3TW-0004gt-93 for ietf@ietf.org; Fri, 19 May 2006 07:48:58 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh3TU-0001pb-Rd for ietf@ietf.org; Fri, 19 May 2006 07:48:58 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fh3TU-0006mB-9T; Fri, 19 May 2006 07:48:56 -0400
Date: Fri, 19 May 2006 07:48:55 -0400
From: John C Klensin <john-ietf@jck.com>
To: Dave Crocker <dhc2@dcrocker.net>, ietf@ietf.org
Message-ID: <9039014BB7BCF1F4DB0DFE87@p3.JCK.COM>
In-Reply-To: <446D2CF7.2050004@dcrocker.net>
References: <E1FgoVV-0008GO-GS@stiedprstage1.ietf.org> <446D2CF7.2050004@dcrocker.net>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc:
Subject: Re: I-D ACTION:draft-alvestrand-ipod-01.txt
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


--On Thursday, 18 May, 2006 19:27 -0700 Dave Crocker
<dhc2@dcrocker.net> wrote:

> 
> 
> Internet-Drafts@ietf.org wrote:
>> 	Title		: IETF Operational Notes
>> 	Author(s)	: H. Alvestrand
>> 	Filename	: draft-alvestrand-ipod-01.txt
>> 	
>> This document describes a new document series intended for
>> use as a repository for IETF operations documents, which
>> should be more ephemeral than RFCs, but more referenceable
>> than internet-drafts, and with more clear handling procedures
>> than a random Web page.
>>   
> 
> This proposal considers using all of the existing mechanisms,
> except the one that seems most appropriate:  BCPs.
> 
> New publication mechanisms incur incremental overhead.
> 
> Why is it not sufficient to have the operational notes be
> published as
> BCPs? What problem is this solving and is it really that
> important to the IETF?

Dave,

I wonder if we are reading the same document.  While the
comments below highlight the differences from BCPs that seem
most important to me, it appears to me that these differences,
and others, appear fairly clearly in section 5 of the I-D.

(i) BCPs are, by precedent and as provided for by 2026,
published by the RFC Editor, formatted as RFCs, and go through
standard RFC processing, albeit with the BCP designation.  These
documents are published by the secretariat, using mechanisms
determined from time to time by the IESG.   Presumably, that
change in mechanism permits nearly-immediate publication of
changed "ION" documents, which would serve the community much
better than the opportunity to wonder whether the current
published document or some approved I-D is actually in effect.

(ii) While BCP numbers move from one RFC to another as content
is updated, these documents do not have archival designation or
numbers.  Personally, that scares me a little bit: I would
prefer to see these documents numbered or designated in a way
that makes version identities absolutely clear.  The I-D sort of
suggests that, but is insufficiently specific to know for sure
(see below).

(iii) BCPs are constrained to a rather specific approval process
involving Last Call and community consensus.  IONs are permitted
to be approved and published by the IESG alone, or other bodies
designated by the IESG, thereby sweeping up a variety of IESG
statements and assorted conventions that are now carried around
as semi-permanent I-Ds or random web pages.   While one can
debate the approval system, it is clear to me that having IETF
procedural materials for which people are held responsible
gathered together into a single document series and place is an
improvement.

I have two concerns about this document and the way in which it
is being processed.  For everyone's convenience, I'll put them
into a separate note.

    john


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