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
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt John C Klensin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Spencer Dawkins
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt John C Klensin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Harald Alvestrand
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt John C Klensin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt John C Klensin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt John C Klensin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Harald Alvestrand
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Dave Crocker
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt JFC (Jefsey) Morfin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Jeffrey Hutzelman
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt JFC (Jefsey) Morfin
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Harald Alvestrand
- Re: I-D ACTION:draft-alvestrand-ipod-01.txt Brian E Carpenter