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>