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

[Romascanu, Dan (Dan) (dromasca]

Fine with me.

Thank you for the attentive review. 

Dan
 

> -----Original Message-----
> From: Black_David [at] emc.com [mailto:Black_David [at] emc.com] 
> Sent: Monday, December 14, 2009 7:48 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
> 
> Dan,
> 
> The draft authors clearly need to fix the IANA problem, 
> including telling IANA exactly what needs to be allocated.  
> As noted below, I'm reasonably confident that they're using a 
> vendor-id for a standardized extension to the CAPWAP protocol.
> 
> At this point, I suggest that you and I should "agree to disagree"
> about whether to split the protocol extensions out of this 
> MIB draft.  As things stand, I'd guess that this topic will 
> wind up on the IESG's plate to sort out.
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com]
> > Sent: Monday, December 14, 2009 11:13 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.
> > 
> > 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
> > >
> 
>