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

["John G. Scudder" <jgs at juniper.net>]

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 at ietf.org
https://www.ietf.org/mailman/listinfo/idr