Re: [Idr] Revised proposed IDR charter
John Leslie <john@jlc.net> Wed, 03 February 2010 02:06 UTC
Return-Path: <john@jlc.net>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185523A6982 for <idr@core3.amsl.com>; Tue, 2 Feb 2010 18:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
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 8Dbx2O+EIo8M for <idr@core3.amsl.com>; Tue, 2 Feb 2010 18:06:48 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 58B603A695A for <idr@ietf.org>; Tue, 2 Feb 2010 18:06:48 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id C54F033C38; Tue, 2 Feb 2010 21:07:28 -0500 (EST)
Date: Tue, 02 Feb 2010 21:07:28 -0500
From: John Leslie <john@jlc.net>
To: Ross Callon <rcallon@juniper.net>
Message-ID: <20100203020728.GA11287@verdi>
References: <52635EAD-5E0B-4975-BFA5-B315036F59C8@juniper.net> <1D51EAE9-FBFC-450A-9F95-9932086A667C@tcb.net> <DF7F294AF4153D498141CBEFADB177049A1B5DCC9C@EMBX01-WF.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DF7F294AF4153D498141CBEFADB177049A1B5DCC9C@EMBX01-WF.jnpr.net>
User-Agent: Mutt/1.4.1i
Cc: idr List <idr@ietf.org>, Adrian Farrel <Adrian.Farrel@huawei.com>, Danny McPherson <danny@tcb.net>
Subject: Re: [Idr] Revised proposed IDR charter
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 02:06:50 -0000
Ross Callon <rcallon@juniper.net> wrote: > To: Danny McPherson <danny@tcb.net> ]] On Jan 28, 2010, at 1:53 AM, John G. Scudder wrote: ]] ]]] The IDR working group also has an oversight role for all extensions ]]] made to BGP for other uses that may be developed in other working ]]] groups. IDR will review extensions made to BGP in other working ]]] groups at least at WG document adoption and during working group ]]] last calls. The IDR working group will also provide advice and ]]] guidance on BGP to other working groups as requested. In some cases ]]] the IDR WG chairs may work with the chairs of other working groups ]]] and the IESG to move BGP work into the IDR WG instead of the another ]]] WG. ]] ]] How is it the IDR WG intends to be involved in WG document adoption ]] in other WGs (e.g., PWE3, L2VPN, L3VPN, etc..) from a process ]] perspective? I can understand how cross-WG LCs function, but not the ]] adoption process. > > The text "...review extensions made to BGP in other working groups at > least at WG document adoption and during working group last calls" > implies that the call (in a different working group) for adoption of > a document that has significant implications on BGP would be copied to > the IDR working group. Also, WG last calls would also be copied to the > IDR working group. This should make life easier when documents that > have implications on BGP get to the IESG for review, and the routing > ADs (or others) ask the obvious question: "What does the IDR working > group think of this?". While this may answer Danny to the extent of what is intended, IMHO it doesn't answer in terms of how this is formalized. WGCs are not expected to read every charter of every other WG to find things like this. The best of intents can get lost in just a few years... More fundamentally, this description of the intended effect is not consistent with the initial statement: " " The IDR working group also has an oversight role for all extensions " made to BGP for other uses that may be developed in other working " groups. What Ross describes is more a liaison role than an "oversight" role. And I really don't know of a practical way to implement an "oversight" role _by_ a WG (as opposed to an individual). Nor do I believe this is the appropriate role. BGP, alas, _is_ a bit fragile. I get very nervous when I hear folks wanting to piggyback something on _the_same_ BGP session that we use to propagate routes. But someone wanting to use the BGP _protocol_ to establish entirely separate sessions doesn't worry me. If we've done our job right in describing the protocol, there should be nothing to worry about. I'd be much more comfortable if the charter talked of a blocking role for a few dangerous things like piggybacking sessions, rather than an "oversight" role so murkily defined. But in practice, I think the blocking role needs to be written into the BGP specs, not put in a charter which may not get read at an appropriate time. > "Oversight" and "review" doesn't imply a tyrannical ability to stop > all work. It does mean that they get to comment. As is usual in the > IETF, we can expect that most proposals will go forward with little > or no controversy (you co-chair a WG which may be an exception), and > that when controversy does show up the WG chairs, and if necessary > the ADs, will need to get together and look for rough consensus. That indeed is the meaning of "review" (leaving aside the issue of what magic makes it happen at all). That is not the usual meaning of "oversight." "Oversight" usually means a duty to set conditions which must be fulfilled. (Whether such a duty/power is "tyrannical" is a semantic question I choose not to pursue.) I personally doubt this proposed charter language will accomplish a useful goal. I instead believe any revision to the BGP specs should lay out what the problems might be, and outline a process to follow such as the one Ross outlined. -- John Leslie <john@jlc.net>
- [Idr] Revised proposed IDR charter John G. Scudder
- Re: [Idr] Revised proposed IDR charter Danny McPherson
- Re: [Idr] Revised proposed IDR charter Jari Arkko
- Re: [Idr] Revised proposed IDR charter Ross Callon
- Re: [Idr] Revised proposed IDR charter John Leslie
- Re: [Idr] Revised proposed IDR charter John G. Scudder
- Re: [Idr] Revised proposed IDR charter John G. Scudder
- Re: [Idr] Revised proposed IDR charter Danny McPherson
- Re: [Idr] Revised proposed IDR charter John G. Scudder
- Re: [Idr] Revised proposed IDR charter Danny McPherson
- Re: [Idr] Revised proposed IDR charter Eric Rosen
- Re: [Idr] Revised proposed IDR charter Jeffrey Haas
- Re: [Idr] Revised proposed IDR charter Jari Arkko
- Re: [Idr] Revised proposed IDR charter Ross Callon
- Re: [Idr] Revised proposed IDR charter Susan Hares