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

[Black_David (Black_David]

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.

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?

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

> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com]
> > > Sent: Monday, December 14, 2009 5:10 AM
> > > To: young; capwap [at] frascone.com; Black, David
> > > Subject: RE: [Capwap] The list of changes should be done
> > according to
> > David'scomments
> > >
> > > See in-line.
> > >
> > > Regards,
> > >
> > > Dan
> > >
> > >
> > > > -----Original Message-----
> > > > From: young [mailto:young [at] h3c.com]
> > > > Sent: Monday, December 14, 2009 11:28 AM
> > > > To: capwap [at] frascone.com; Black_David [at] emc.com
> > > > Subject: [Capwap] The list of changes should be done according
to
> > > > David'scomments
> > > >
> > > > Hi, David:
> > > >
> > > > According to the latest discussion in the mailing list,
> > here I gave
> > > > a list of changes should be done according to your review
> > comments.
> > > >
> > > > [*] Intended document status is now Informational.  That
> > needs to be
> > > > changed on the title page, but more importantly, someone (draft
> > > > shepherd?) should double-check whether the requested IANA
> > > > allocations are appropriate for an Informational document. If
> > > > there's a problem here, the IESG should be warned that a process
> > > > exception may be needed, as I think the allocations are
necessary
> > > > for this draft.
> > > > [Status]
> > > > Dan's working on it.
> > >
> > > The IANA allocations required by this document can be made in an
> > > Informational RFC.
> > >
> > > >
> > > ...
> > >
> > > >
> > > > [*] The text in Section 5.7 attempts to modify RFC 5415.
> > > > That's not a good idea for an Informational document.  It
> > is ok to
> > > > say that if the additional requirements are not followed,
> > this MIB
> > > > will not be useful or usable.
> > > > [Editors]
> > > > The WG already made the consensus on it after IETF 75th,
> > and the WG
> > > > agree to use the following text. The section 4.6.40
> > [RFC5415] does
> > > > not clarify that the WTP's Base MAC  address MUST be
> > included in the
> > > > WTP Board Data message element.  This is a known errata item and
> > > > assumed to be fixed in future by the editors of the RFC5415.
> > > > [Status] Dan or Margaret please confirm it.
> > >
> > > Confirmed. The WG agreed on this change and on the Errata
> > as being a
> > > clarification to RFC 5415 which does not impact interoperability.
> > >
> > > ...
> > > >
> > > > [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB
> > > > draft?  MIB drafts generally do not make changes to the protocol
> > > > that they provide management for.  This section, and the
> > changes in
> > > > Section 5.7 ought to be in a separate draft that could be
> > standards
> > > > track.
> > > > [Editors]
> > > > 1) Margaret or Dan, please confirm whether is it allowed
> > to have the
> > > > Message Element Extension in the MIB drafts?
> > >
> > > Content of 5.7 was addressed above. 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. 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.
> > >
> > >
> >
> >