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

"John G. Scudder" <jgs@juniper.net> Mon, 05 May 2008 16:48 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 D1FD828C0E1; Mon, 5 May 2008 09:48:21 -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 724713A6C35 for <idr@core3.amsl.com>; Mon, 5 May 2008 09:48:19 -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 A57FyZKJ8kCL for <idr@core3.amsl.com>; Mon, 5 May 2008 09:48:18 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 7B81328C174 for <idr@ietf.org>; Mon, 5 May 2008 09:46:21 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 09:43:29 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 09:44:24 -0700
Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m45GiNx92085; Mon, 5 May 2008 09:44:23 -0700 (PDT) (envelope-from jgs@juniper.net)
Message-Id: <B7B50088-5A6F-4060-BEEF-65CFF4D3D782@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Rajiv Asati (rajiva) <rajiva@cisco.com>
In-Reply-To: <15B86BC7352F864BB53A47B540C089B605658437@xmb-rtp-20b.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Mon, 5 May 2008 12:44:22 -0400
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> <15B86BC7352F864BB53A47B540C089B605658437@xmb-rtp-20b.amer.cisco.com>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 05 May 2008 16:44:24.0910 (UTC) FILETIME=[46C8FEE0:01C8AECF]
Cc: idr idr <idr@ietf.org>
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

On May 4, 2008, at 5:05 AM, Rajiv Asati (rajiva) wrote:
> 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.

I'll defer to WG consensus on this point, once it becomes clear.

> 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.

Well, we could use some variant on your "Desired Capability"  
formulation, e.g. "Desired Capability Missing".  (I think  
"unsupported" leads to confusion.)  OTOH, "required" is probably a  
little more correct than "desired" -- if I'm going to drop the session  
if it's missing, I don't just desire it, I demand it.  I guess if we  
want to avoid adjectives which have understood meanings elsewhere in  
BGP (e.g. "required" or "mandatory") we could try some other  
adjective, like "demanded" or "insisted-upon" or even the "i-insist-on- 
a-capability-you-haven't-sent-so-am-petulantly-closing-the-session-so- 
there" error, but I fear it might become silly.  Perfect being the  
enemy of good, I'd be fine with "desired".

> 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

What would this mean?

> 	- Desired Capability(s) Unsupported

I take this to be a different name for the current message.

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

Yes, or the IPv6 example in the draft.

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

That would go considerably beyond the scope of what the -bis draft is  
currently attempting, which is merely to clarify the existing  
standard.  For that matter, adding new NOTIFICATION subcodes as  
opposed to merely renaming the existing one would as well.  I'm not  
strictly opposed to this if there's WG consensus to do so, but I  
myself would be happy to just clarify current practice.

> 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"?

I've removed the comma in the working version.

> 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, ..".

I've changed it to "As explained in the Overview of Operations section".

> 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..".

Done.

Thanks for the comments.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr