Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

From: Paul Jakma <[email-masked]>
Date: Thu, 1 May 2008 11:51:11 +0100 (BST)

Hi John,

Could it be made slightly clearer that it means the same parameter 
type? (Yeah, seems obvious once you think about it, but it could 
perhaps make a difference to tired readers :) ). E.g. something like:

On Wed, 30 Apr 2008, John G. Scudder wrote:

> Enke,
>
> Would adding this paragraph at the end of section 4 cover your point?
>
>    The Capabilities Optional Parameter SHOULD only be included in the
>    OPEN message once.  If the BGP speaker wishes to include multiple
>    capabilities in the OPEN message, it SHOULD do so as discussed above,
>    by listing all those capabilities within the same Capabilities
>    Optional Parameter.  However, for backward compatibility a BGP
>    speaker MUST be prepared to receive an OPEN message which contains
>    multiple Capabilities Optional Parameters, each of which contains one
                                               ^
                                            for a given type

>    or more capabilities.  The set of capabilities should be processed
>    the same in either case, whether the it is listed within a single
>    Capabilities Optional Parameter, or within multiple.
                                                        ^
                                                    , for a given type

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
DISCLAIMER:
Use of this advanced computing technology does not imply an endorsement
of Western industrial civilization.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 1 May 2008 10:51:41 -0400

Hi Paul,

The paragraph actually refers to the "Capabilities Optional Parameter"  
itself within the OPEN message, i.e. OPEN parameter type 2.  RFC 4271  
and its predecessors don't fully specify the handling of OPEN optional  
parameters, and in specific are silent as to whether a given OPEN  
optional parameter can appear more than once, so Enke's suggestion  
amounts to doing that here, which seems reasonable under the  
circumstances.

Here's a revised paragraph, see if it's clearer:

   The Capabilities Optional Parameter (OPEN parameter type 2) SHOULD
   only be included in the OPEN message once.  If the BGP speaker wishes
   to include multiple capabilities in the OPEN message, it SHOULD do so
   as discussed above, by listing all those capabilities as TLVs within
   a single Capabilities Optional Parameter.  However, for backward
   compatibility a BGP speaker MUST be prepared to receive an OPEN
   message which contains multiple Capabilities Optional Parameters,
   each of which contains one or more capabilities TLVs.  The set of
   capabilities should be processed the same in either case, whether it
   is enumerated within a single Capabilities Optional Parameter of the
   OPEN message, or split across multiple.

Thanks for the feedback!

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 3 May 2008 13:33:03 -0400

On Wed, Apr 30, 2008 at 06:33:04AM -0700, Yakov Rekhter wrote:
> There is a request (see attached) to accept draft-scudder-idr-rfc3392-bis
> as an IDR WG item. Please send your comments to the list. The deadline
> for comments is May 14.

I support making this a WG work item.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 3 May 2008 13:34:26 -0400

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

---

From: Brian Dickson <[email-masked]>
Date: Sat, 03 May 2008 18:04:44 -0400

> I support making this a WG work item.

+1

I also support this being a WG item.

Brian Dickson

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 4 May 2008 05:05:20 -0400

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeffrey Haas
> Sent: Saturday, May 03, 2008 1:34 PM
> To: [email-masked]
> Subject: Re: [Idr] Fwd: New Version Notification 
> fordraft-scudder-idr-rfc3392-bis-
>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 5 May 2008 12:44:22 -0400

> than good by renaming an existing code point, as John suggested.

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

> "required" in the error subcode is a recipe for further confusion that

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

> 	- Dependent Capability(s) Unsupported

What would this mean?

> 	- Desired Capability(s) Unsupported

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

> support ORF prior for the successful peering).

Yes, or the IPv6 example in the draft.

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

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

I've removed the comma in the working version.

> Perhaps, "As suggested by the overview of Operations section  

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

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

Done.

Thanks for the comments.

--John