Re: [Idr] Fwd: New Version Notification fordraft-scudder-idr-rfc3392-bis-

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Sun, 04 May 2008 09:09 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF9F28C2AF; Sun, 4 May 2008 02:09:08 -0700 (PDT)
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 C93263A6863 for <idr@core3.amsl.com>; Sun, 4 May 2008 02:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rZ7qokVaoYSm for <idr@core3.amsl.com>; Sun, 4 May 2008 02:09:04 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 443CD28C2AF for <idr@ietf.org>; Sun, 4 May 2008 02:08:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,433,1204520400"; d="scan'208";a="7113456"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 May 2008 05:08:38 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4498cgt006801; Sun, 4 May 2008 05:08:38 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4498cDZ016681; Sun, 4 May 2008 09:08:38 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 May 2008 05:08:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 4 May 2008 05:05:20 -0400
Message-ID: <15B86BC7352F864BB53A47B540C089B605658437@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <20080503173426.GB23560@scc.mi.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] Fwd: New Version Notification fordraft-scudder-idr-rfc3392-bis-
Thread-Index: AcitQ/eO7Q1Kz3mdQFe5UnTNY8Ng4QAZJcUQ
References: <200804301333.m3UDX4x97759@magenta.juniper.net><0B82A4F5-4D76-427B-8CB3-386C0F6A64F2@tcb.net><ECC75E57-CBCA-4E48-B88F-23442E398F65@bgp.nu> <20080503173426.GB23560@scc.mi.org>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "Jeffrey Haas" <jhaas@pfrc.org>, <idr@ietf.org>, <jgs@bgp.nu>
X-OriginalArrivalTime: 04 May 2008 09:08:38.0748 (UTC) FILETIME=[70CA11C0:01C8ADC6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3196; t=1209892118; x=1210756118; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20<rajiva@cisco.com > |Subject:=20RE=3A=20[Idr]=20Fwd=3A=20New=20Version=20Notifi cation=20fordraft-scudder-idr-rfc3392-bis- |Sender:=20 |To:=20=22Jeffrey=20Haas=22=20<jhaas@pfrc.org>,=20<idr@ietf .org>,=20<jgs@bgp.nu>; bh=XfJcFm+SmnbxZEWscyJbGoeqvih6ybZIdF8ybO1kjjo=; b=YPo319P+1H2667l4gbn7uBVhuoySyaLCXcjJ1K6XZoy6DRZd/UK9LewN2+ KyuuTwJJuIEc52Zuxjo4m/1mXFt59vmXKK2Wvt0feSeSJM144jSUZG0eDTKk Np76kqjKsl;
Authentication-Results: rtp-dkim-2; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Subject: Re: [Idr] Fwd: New Version Notification fordraft-scudder-idr-rfc3392-bis-
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Hi,

While I agree that the text in RFC3392 is a bit vague and desires a bit
of clarity, I don't agree that changing the naming of the subcode is
going to resolve the confusion. If any, it would indeed do more harm
than good by renaming an existing code point, as John suggested.

The fact that the capabilities itself is an optional parameter, saying
"required" in the error subcode is a recipe for further confusion that
we should avoid.

Perhaps, the right way (to me) is to introduce the new subcode that
differentiates the errors resulting in the NOTIFICATION message. For
example, new subcodes for 
	- Dependent Capability(s) Unsupported 
	- Desired Capability(s) Unsupported 
	- ..

(An example for the latter would be if a speaker wanted the peer to
support ORF prior for the successful peering).

Otherwise, we need to start thinking about nominating certain
capabilities as mandatory instead of optional. 


Besides that, there are few places where the readability of the document
could be improved upon - 

1) In the below excerpt from 2nd last para in section 3 -

....
   this capability be used on a peering but determines that its peer
   doesn't support this capability, the speaker MAY send a NOTIFICATION
   message to the peer, and terminate peering (see Section "Extensions
....

Should it not be "peer, and MAY terminate peering" or "...peer and
terminate peering"? 


2) 1st sentence of 2nd para of section 5. 
....
   As the Overview of Operations section notes, the Unsupported
   Capability NOTIFICATION is a way for a BGP speaker to complain that
.....

Perhaps, "As suggested by the overview of Operations section notes, ..".

3) last para in section 3 - 

...
   If a BGP speaker receives from its peer a capability which it does
   not itself support, it SHOULD ignore that capability.  In particular,

It seems fair to say "...which it doesn't itself support or recognize,
it..".


Cheers,
Rajiv



> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On 
> Behalf Of Jeffrey Haas
> Sent: Saturday, May 03, 2008 1:34 PM
> To: idr@ietf.org
> Subject: Re: [Idr] Fwd: New Version Notification 
> fordraft-scudder-idr-rfc3392-bis-
> 
> On Wed, Apr 30, 2008 at 05:31:11PM -0400, John G. Scudder wrote:
> > On Apr 30, 2008, at 10:02 AM, Danny McPherson wrote:
> > > One minor comment..   I think we should rename "Unsupported  
> > > Capability"
> > > to "Required Capability Missing", and given that the 
> codepoint itself
> > > isn't
> > > changing, just the descriptor, there should be no issues here.
> > 
> > Clearly this is OK by me if the WG is happy with it.
> 
> I would strongly support this.  I found the original naming very
> confusing when working through this in implementation some years ago.
> The usual method of consulting the archives only confused matters
> further as the feature evolved from capabilities *negotiation* into
> advertisement.
> 
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr