IETF Logo Mail Archive

Re: [Idr] Revised proposed IDR charter

Danny McPherson <danny@tcb.net> Wed, 03 February 2010 11:58 UTC

Return-Path: <danny@tcb.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 439983A6C09 for <idr@core3.amsl.com>; Wed, 3 Feb 2010 03:58:25 -0800 (PST)
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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ygLOym1iUN8f for <idr@core3.amsl.com>; Wed, 3 Feb 2010 03:58:24 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 8DC383A6C06 for <idr@ietf.org>; Wed, 3 Feb 2010 03:58:24 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 969EC2684E9; Wed, 3 Feb 2010 04:59:06 -0700 (MST)
Received: from [10.0.10.53] (host-135-196-34-178.lines.viateldsl.com [135.196.34.178]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 03 Feb 2010 04:59:06 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=135.196.34.178; client-port=59534; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <213C5E3B-6E40-4967-A54C-A3408AF881D5@juniper.net>
Date: Wed, 03 Feb 2010 04:59:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A92F9E6-05AE-4E1D-8368-C9B0B113B05F@tcb.net>
References: <52635EAD-5E0B-4975-BFA5-B315036F59C8@juniper.net> <1D51EAE9-FBFC-450A-9F95-9932086A667C@tcb.net> <213C5E3B-6E40-4967-A54C-A3408AF881D5@juniper.net>
To: "John G. Scudder" <jgs@juniper.net>
X-Mailer: Apple Mail (2.1077)
Cc: idr List <idr@ietf.org>, "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>, "idr-ads@tools.ietf.org" <idr-ads@tools.ietf.org>
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 11:58:25 -0000

On Feb 3, 2010, at 4:26 AM, John G. Scudder wrote:
> 
> I see it as an applicability statement, not a statement of technical guarantee.  As you know, there many things in BGP that aren't *guaranteed* but depend on correct deployment practices.

Right, but assumptions about "restricted environments" and 
"correct deployment" in a global routing system protocol 
often results in negative systemic effects.  We've seen this 
several times already with 32-bit ASNs.  

Perhaps the charter should say "avoid extensions that require
restricted environments or correct deployment".  But alas, 
that's apparently not practical here..

-danny

v2.23.0 | Report a Bug | By Email