Subject: RE: [Capwap] Comments on objectives draft

From: "Nelson, David" <[email-masked]>
Date: Wed, 6 Apr 2005 10:22:18 -0400

Pat Calhoun writes...

> My justification for the above requirements is that we, as the 
> IETF, must be committed to creating open standards that allow 
> for true interoperability, ....

I concur with Pat's suggested requirements/objectives.  Too often in the IETF today we lose sight of our heritage of multi-vendor interoperability, "plug-fests", and the notion that the RFC needs to completely specify what is required in the on-the-wire protocol for interoperable implementations.

If all we wish to accomplish is to standardize "frameworks" for vendors to implement proprietary mechanisms or bi-lateral agreements for limited interoperability, then I think we might as well call it a day and go home. 

-- Dave

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 7 Apr 2005 14:36:45 -0400

Dan Harkins writes...

> Let's say that LWAPP is advanced as the CAPWAP protocol. It does not
> contain ways to allow the wiz-bang MAC to control the coloring of RF.
> So you have wait for 18 months for a rev of the document and hope that
> AC vendors rev their code along with the document so your wiz-bang MAC
> can demonstrate its wiz-bang features. That is a serious drag. The new
> feature might not be used for a couple of years, if ever. That means
> stifling of innovation.

There is always some tension between product feature innovation and
short time-to-market cycles vs. standardization and multi-vendor
interoperability.

> Or there's the "vendor extensions" part of LWAPP, sort of. An AP can
> identify itself using the Vendor Specific payload to indicate that it
> is the new MAC that does RF coloring. Then what? Some
yet-to-be-defined
> Vendor Control payload?

In an application space where the feature set is evolving, protocols
need to be designed to separate the protocol state machine and message
formats (transport) from the message semantics and managed object
definitions (data model).  In SNMP we have MIBs, in COPS we have PIBs,
in RADIUS we have Attributes, in Diameter we have AVPs, etc.  The fact
that future features need to be accommodated does *not* dictate that the
protocol cannot be standardized and interoperable, but only that the
data model needs to be sufficiently extensible.