Capwap Mailing List: Re: The list of changes should be done according to David'scomments

[Romascanu, Dan (Dan) (dromasca]

In line. 

Regards,

Dan
 

> -----Original Message-----
> From: Black_David [at] emc.com [mailto:Black_David [at] emc.com] 
> Sent: Monday, December 14, 2009 6:01 PM
> To: Romascanu, Dan (Dan); young [at] h3c.com; capwap [at] frascone.com
> Cc: Black_David [at] emc.com
> Subject: RE: [Capwap] The list of changes should be done 
> according to David'scomments
> 
> More inline - it looks like we have an IANA Considerations 
> issue at a minimum,  --David
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com]
> > Sent: Monday, December 14, 2009 10:42 AM
> > To: Black, David; young [at] h3c.com; capwap [at] frascone.com
> > Subject: RE: [Capwap] The list of changes should be done 
> according to
> David'scomments
> > 
> > In line, leaving the still open issue.
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From: Black_David [at] emc.com [mailto:Black_David [at] emc.com]
> > 
> > ...
> > 
> > > > Section 9 refers to a usage of
> > > > Message Element Extensions which a vendor can chose to implement
> or
> > > not.
> > > > It is not normative text and multi-vendor 
> interoperability is not 
> > > > required.
> > >
> > > Multi-vendor interoperability is not required??  This 
> looks like an 
> > > assertion that the CAPWAP WTP and AC are always from the 
> same vendor 
> > > when this MIB is implemented - that doesn't sound right.
> > 
> > Maybe I mis-understood. The second field in the extension is a 
> > vendor-ID. Why is this here? If the purpose is multivendor 
> > interoperability we may not need it.
> 
> I suspect that you may have misunderstood, and the cause of 
> the misunderstanding is a new open issue that requires attention:
> 
> Section 9 says:
> 
>       CAPWAP Message Element          Vendor Identifier       
> Element ID
> 
>       CAPWAP Protocol Timers          Id assigned by IANA           1
>       CAPWAP Protocol Variables       Id assigned by IANA           2
> 
> That's badly specified.  It looks like what's going on here 
> is that this is a CAPWAP "Vendor Specific Payload" (37) for 
> which IANA is being asked to allocate a Vendor Identifier 
> (see RFC 5415, 4.6.39), but that request is not in the IANA 
> Considerations section of the draft.  At a minimum, this 
> omission needs to be corrected.

Yes. 

> 
> This sort of use of a vendor-id to signal a standardized 
> extension has been done elsewhere - IPsec NAT traversal is a 
> past example.
> 
> If this extension really is intended to be vendor-specific, 
> it belongs in a document entitled "Vendor-X's extensions to 
> the CAPWAP protocol" or something like that, and should not 
> be part of the standard MIB draft.
> 
> > > > I do not see why it ought to be in a separate document and why
> this
> > > > document should be standards track. Other opinions are welcome, 
> > > > though.
> > >
> > > The rationale for a separate document is that this is changing
> > > (extending)
> > > the CAPWAP protocol, and I'm surprised to find protocol 
> changes in a 
> > > MIB draft.  With the 5.7 concern resolved (that was a 
> modification 
> > > to a standards track RFC), a standards track draft is no longer 
> > > needed, but I still think a separate document may be preferable.
> > >
> > 
> > Why? These extensions are specially designed so that a WTP gets from
> the
> > ACs the information to instrument the MIB objects.
> 
> Is a protocol implementer going to expect to look at the MIB 
> document to find additional pieces of the protocol that need 
> to be implemented?

If he/she implements the MIB - otherwise they won't need it. 

And actually the same question can be asked if the MIB document is split
in two. 

> 
> Maybe ... as I noted earlier, I'm surprised to find a MIB 
> document defining protocol extensions, and I suspect I won't 
> be the only one who's surprised.
> 
> Thanks,
> --David
>