[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 at ietf.org [mailto:idr-bounces at ietf.org] On 
> Behalf Of Jeffrey Haas
> Sent: Saturday, May 03, 2008 1:34 PM
> To: idr at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr