Subject: [Capwap] Comments on objectives draft

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 5 Apr 2005 19:42:50 -0700

All,
 
I'd like to add the following to the objectives draft.
 
1. Interoperability does not require a business contract of any form. 
An AP vendor MUST be able to participate in the CAPWAP world without
requiring that it fulfill any contracts or other business transactions with
any AC vendors. This means that an AP vendor should be able to interoperate
with any CAPWAP protocol compliant AC with no additional relationships. The
adverse effect of not having this requirement means that AP vendors could
only interoperate with the AC vendors that are willing to collaborate with
them, which will disenfranchise specific companies. 
 
2. AP Vendor can make modifications to HW without any AC vendor involvement.
An AP vendor may chose to make hardware modifications, possibly for cost
reasons, without the need to involve any AC vendors. In the real world,
there are many times where 3rd party contract manufacturers will change
hardware components for cost reasons, causing the old code to no longer work
on the new AP hardware. The adverse effect of not having this requirement
will bind AP vendors to specific hardware versions and not allow them to
either lower their cost, or make HW performance improvements, without the
need to go back to the AC vendors - and most likely at a price.
 
3. AP Vendors must not be bound to a specific MAC.
The natural tendency of AC vendors will be to only want to port their code
to APs that share the same underlying hardware, such as the 802.11 MAC, as
they do. Having to support new 802.11 MACs is a very complex process, and
would require significant effort on behalf of the AC vendors, further
encouraging them to limit which AP vendors they wish to collaborate with.
The adverse effect of not having this requirement will limit which companies
can strive in this new market and will hamper AP innovation.
 
4. AP Vendors must not be required to disclose IP
An AP vendor MUST NOT be required to disclose proprietary and confidential
information to AC vendors in order to get CAPWAP interoperability. The
adverse effect of not having this requirement means that AP vendors must
provide to third parties information whose privacy may be crucial to the AP
vendor's success as a company.
 
5. AP Vendors must not take the brunt of porting code onto their AP for
every AC vendor
An AP vendor must not require that it be provided source code from every AC
vendor that it wishes to interoperate with. The adverse effect of not having
this requirement will require significant investment on the AP vendors to
support various AC protocols, both in terms of time and money. 
 
My justification for the above requirements is that we, as the IETF, must be
committed to creating open standards that allow for true interoperability,
while allowing AP and AC vendors to be fiscally responsible. I'd be happy to
donate final text for the objectives draft, if the co-authors would so
desire.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

---

From: Dan Harkins <[email-masked]>
Date: Tue, 05 Apr 2005 23:56:10 -0700

Pat,

  This is the Internet ENGINEERING (!!!) Task Force. 

  Let me just show the rediculousness of your post by pointing out how
the _first_ two sentences of your _first_ point would've applied to, oh
let's say TLS: 

	A <TLS client> vendor MUST be able to participate in the <TLS>
	world (sic) without requiring that it fulfill any contracts or
	other business transactions with any <TLS server> vendors. This
	means that a <TLS client> vendor should be able to interoperate
	with any <TLS> protocol compliant <server> with no additional
	relationships.

That would prohibit the embedding of CA certificates in browsers. And
that would preclude the single most popular use of TLS in the world
today. It also implies that the one mandatory ciphersuite would have to
be an unauthenticated Diffie-Hellman. Thank God you were not involved in
the TLS Working Group! 

  If you have any _technical_ objections to anything relating to CAPWAP 
please forward them to the list. 

  Dan.

On Tue, 05 Apr 2005 19:42:50 PDT you wrote
> CTO, Wireless Networking Business Unit

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

---

From: "Pat Calhoun" <[email-masked]>
Date: Wed, 6 Apr 2005 06:45:33 -0700

Dan,

There's a significant difference between my original requirement
and the TLS agreement that you describe below. Certainly, a business 
relationship is required in order to have certificates signed, but the
nature of the business relationship is significantly different from
what is being required by the SLAPP proposal.

A TLS business arrangement is limited in scope. It does not 
require any co-development of products in order to be compliant (other
than support for TLS itself and the certificate profiles, which are well
known.

However, since you insist on doing down this road, I'll apply the SLAPP
requirements to the TLS protocol that you seem to believe has so much
commonality with CAPWAP: 
    Can you imagine if Microsoft needed to provide the source code to 
    IE to any web server developers, to have them embed their
    technologies within IE? Do you really think that Microsoft would be
    willing to share their source code? Do you really believe that this
    model would foster/motivate other companies from being able to design
    web servers?

Oh, and just for fun, let me use another analogy:
    Imagine if the SLAPP model was used with IP routers. Instead of defining
    a routing protocol, which is obviously too complex to get it right to
    begin with, let's focus on a simpler problem. Router manufacturers can
    build hardware, and then license software from software routing
companies
    that port their code and download to the router hardware. This now
    guarantees interoperability because all "router hardware" now runs the
same
    code.

Obviously, this is apples and oranges, so it would really be best that
we stick to the problem at hand. That said, I am willing to make a change
to the original requirement to the following which I believe addresses
your TLS comment:
"Once a standard is available from the IETF, interoperability does not
require a co-development business contract of any form."
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The business arrangement being imposed by the SLAPP protocol is a 
completely different beast from TLS. It now mandates that any AP vendor that
wishes to participate in the CAPWAP eco-system now must create a 
co-development relationship with AC vendors, providing detailed schematics
and data sheets about the chipset that is embedded within the AP. This
is significantly easier to do when the AC vendor's AP happens to share
the same MAC as the AP vendor in question, although there are probably
still some hardware differences which require some BSP-like work on 
behalf of the AC vendor. However, the real issues occur when the AP itself
uses a completely different MAC (or some other really innovative technology
that the AP vendor has no desire to share with any AC companies).

The SLAPP proposal requires that the AP vendor provide their data sheets, 
schematics and so on to the AC vendor, who must then port their code to the
new platform. So who ends up paying for this development cost? The AP or
AC vendor? Will you include such a MUST statement binding either side to
taking the responsibility of the development cost in your draft?

I also have a significant objection about the fact that the AP vendor must
provide their IPR to the AC vendor in order to interoperate. Although it's
possible there is a precedence here, I certainly cannot think of one.
Requiring that the AP vendor provide their IPR to the AC, or the inverse
that the AC provide their source code to the AP vendor, is frankly not
acceptable.

Yes, this is the IETF, and we are focused on interoperability from a
solution
stand-point. What SLAPP is doing here is not creating a standard, it creates
a solution that will disenfranchise a number of companies or individuals
from participating in interoperability. Should a grad student opt to do
a research project on the CAPWAP protocol, which AC vendor would be willing
to work with the said student? There's obviously no money involved in
this, so there's really no motivation on the part of the AC vendors to
help this student out.

Do I have technical objections to the draft? Yes, and I listed them below.
Unfortunately, you opted to respond to my original comments by nit picking 
on the actual language of one of the requirements, which I have provided 
new text for. However, in the end you really haven't addressed the core
issues
other than stating that business contracts work in one world, and therefore 
they are acceptable for any other solution, regardless of the cost, impact
and
scope. Although this is an engineering forum, the end result must also be
sound from a business stand-point.

So, I'd like to hear more your comments on:
1. Interoperability does not require a co-development business contract
   of any form.
2. AP Vendor can make modifications to HW without any AC vendor involvement.
3. AP Vendors must not be bound to a specific MAC.
4. AP Vendors must not be required to disclose IP An AP vendor MUST 
   NOT be required to disclose proprietary and confidential 
   information
5. AP Vendors must not take the brunt of porting code onto their AP 
   for every AC vendor

Pat Calhoun
> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Tuesday, April 05, 2005 11:56 PM
> To: Pat Calhoun
> Cc: [email-masked]
> Subject: Re: [Capwap] Comments on objectives draft 
> 
>   Pat,
> 
>   Let me just show the rediculousness of your post by 
> pointing out how the _first_ two sentences of your _first_ 
> point would've applied to, oh let's say TLS: 
> 
> That would prohibit the embedding of CA certificates in 
> browsers. And that would preclude the single most popular use 
> of TLS in the world today. It also implies that the one 
> mandatory ciphersuite would have to be an unauthenticated 
> Diffie-Hellman. Thank God you were not involved in the TLS 
> Working Group! 
> 
>   If you have any _technical_ objections to anything relating 
> to CAPWAP please forward them to the list. 
> 
>   Dan.
> 
> > requiring that it fulfill any contracts or other business 
> transactions 
> > with any AC vendors. This means that an AP vendor should be able to 
> > interoperate with any CAPWAP protocol compliant AC with no 
> additional 
> > relationships. The adverse effect of not having this 
> requirement means 
> > that AP vendors could only interoperate with the AC vendors 
> that are 
> > willing to collaborate with them, which will disenfranchise 
> specific companies.
> >  
> > An AP vendor may chose to make hardware modifications, possibly for 
> > cost reasons, without the need to involve any AC vendors. 
> In the real 
> > world, there are many times where 3rd party contract manufacturers 
> > will change hardware components for cost reasons, causing 
> the old code 
> > to no longer work on the new AP hardware. The adverse effect of not 
> > having this requirement will bind AP vendors to specific hardware 
> > versions and not allow them to either lower their cost, or make HW 
> > performance improvements, without the need to go back to 
> the AC vendors - and most likely at a price.
> >  
> > The natural tendency of AC vendors will be to only want to 
> port their 
> > code to APs that share the same underlying hardware, such as the 
> > 802.11 MAC, as they do. Having to support new 802.11 MACs is a very 
> > complex process, and would require significant effort on 
> behalf of the 
> > AC vendors, further encouraging them to limit which AP 
> vendors they wish to collaborate with.
> > The adverse effect of not having this requirement will limit which 
> > companies can strive in this new market and will hamper AP 
> innovation.
> >  
> > 4. AP Vendors must not be required to disclose IP An AP vendor MUST 
> > NOT be required to disclose proprietary and confidential 
> information 
> > to AC vendors in order to get CAPWAP interoperability. The adverse 
> > effect of not having this requirement means that AP vendors must 
> > provide to third parties information whose privacy may be 
> crucial to 
> > the AP vendor's success as a company.
> >  
> > 5. AP Vendors must not take the brunt of porting code onto their AP 
> > for every AC vendor An AP vendor must not require that it 
> be provided 
> > source code from every AC vendor that it wishes to 
> interoperate with. 
> > The adverse effect of not having this requirement will require 
> > significant investment on the AP vendors to support various AC 
> > protocols, both in terms of time and money.
> >  
> > My justification for the above requirements is that we, as 
> the IETF, 
> > must be committed to creating open standards that allow for true 
> > interoperability, while allowing AP and AC vendors to be fiscally 
> > responsible. I'd be happy to donate final text for the objectives 
> > draft, if the co-authors would so desire.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Apr 2005 09:43:15 -0700

Pat,

Comments.

> them, which will disenfranchise specific companies.

I think Dan has a point about this (though I don't agree with his way of
expressing it). IETF documents never say anything about business
considerations. We can argue this point on the mailing list, but I don't see
this being in the document. Any point along these lines needs to be made
from a technical standpoint, regarding implementation or deployment.

> need to go back to the AC vendors - and most likely at a price.

This is a reasonable technical point, and should simplify evolving and
maintaining the implementation for both the AP vendor and the AC vendor by
decoupling them. Otherwise, neither side gets the benefit of an
interoperable protocol.

companies
> can strive in this new market and will hamper AP innovation.

Again, a good technical point.

> vendor's success as a company.

This is another business point that I think doesn't belong in the document.
Perhaps one could rephrase it as "AP vendors should not have to share
technical specifications for hardware and software to AC vendors in order
for interoperability to be achieved." This point is actually implicit in all
the protocol work IETF does including the requirement for two independent
interoperable implementations to go to DS, but somehow it seems to have been
lost in the current discussion, so it is probably a good idea to make it
explict.

> support various AC protocols, both in terms of time and money.

I think the point is OK, but I think it just repeats what is said in the
second point. If the protocol is designed such that there is some
interdependency between the code on the AC and AP, rather than a protocol
interface that has no code dependencies, then porting certainly will be
required.

> donate final text for the objectives draft, if the co-authors would so

Sure. But IETF being an engineering organization (as Dan so forcefully put
it), we need to approach this from an engineering standpoint. I don't think
that should be so difficult.

            jak

---

From: Dan Harkins <[email-masked]>
Date: Wed, 06 Apr 2005 09:57:01 -0700

Pat,

  Your analogies fall apart because they are poor not because of apples
or oranges or any other fruit. You brought up routing protocols. CAPWAP
isn't a routing protocol, but service providers do enter into very serious
and complex business arrangements to be BGP peers of each other. Yet
another example of the rediculousness of talking about "fiscal
responsibility" and "business relationships" when designing a protocol.

  This is the Internet ENGINEERING Task Force, Pat. It's not the 
Internet Wannbe-MBA Task Force. Let's discuss the _technical_ merits
of proposals and not ham-handedly try to prohibit proposals with reference
to "co-development contracts", "fiscal responsibility" or grants and
contracts to pay graduate students.

  Can you show me an RFC that discusses how grants and contracts would
be paid for graduate students to do research on it? And April 1st RFCs
don't count. <Cue Jeopardy music>wait 30 seconds<Stop Jeopardy music> I
didn't think so. So don't bring it up here. Engineering Pat, engineering.

  My comments? OK here they are:

1.interoperability does not require a co-development business contract
  of any form.

   I am unaware of any precedence for this sort of thing in the IETF
   and believe its introduction here is, as I mentioned, a ham-fisted
   attempt to exclude a single protocol.

2. AP Vendors can make modifications to HW without AC vendor involvement.

   I do not believe that CAPWAP should be HW specific. Nor am I aware
   of any proposals in CAPWAP that would lock in HW.

   Mandating a particular MAC has no place in an IETF standard. Mentioning
   it in the objectives draft would be unnecessarily redundant.

4. AP Vendors must not be required to discolse IP An (sic) AP vendor
   MUST NOT be required to disclose proprietary and confidential information.

   Yet another technically irrelevant point. Furthermore I don't think
   you see the massive loophole in what you're proposing. Such a 
   statement not only has no place in the objectives draft it does
   not further the goal you so desperately want to reach.

for every AC vendor.

   I would certainly hope that the work involved in implementing CAPWAP
   would be an even 50-50 split between the AP and AC sides. This is a
   noble design goal but I don't think it belongs in the objectives draft.

  At least your faux veneer of impartiality has been removed. You are
explicitly mentioning the target of your campaign.

  Dan.

On Wed, 06 Apr 2005 06:45:33 PDT you wrote

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 7 Apr 2005 07:14:13 -0700

>   Your analogies fall apart because they are poor not because 
> of apples or oranges or any other fruit. You brought up 
> routing protocols. CAPWAP isn't a routing protocol, but 
> service providers do enter into very serious and complex 
> business arrangements to be BGP peers of each other. Yet 
> another example of the rediculousness of talking about 
> "fiscal responsibility" and "business relationships" when 
> designing a protocol.

All personal insults aside, the comparison I provided was in fact
not invalid. If you read my comment, you'll notice that I was
not in fact trying to equate the CAPWAP protocol to any routing
protocols, per se, but rather describe how the concepts being 
proposed in SLAPP are to this example of not defining an actual
routing protocol.

I will try once more, and hopefully this time in a way that is clearer.
The SLAPP protocol does not define a control protocol, it simply defines
a discovery mechanism and then a method to download firmware from the
AC to the AP. So there's a clear statement that there will be multiple
control protocols (one per AC vendor), as well as an assumption that
every AC vendor will keep the control protocol close to its chest.

The side effect is that the SLAPP protocol requires that AC vendors
port their AP software to 3rd party AP vendors hardware. As a consequence,
the SLAPP proposal does not allow an AP vendor to participate in the CAPWAP
eco-system without explicit co-development with the AC vendors.

So let's say I am an AP vendor, that is NOT using a standard reference
design from some 802.11 MAC vendor. I decide that the market is moving in
the direction of the CAPWAP architecture. In order to be able to play in
this space, I need to 1) pick the ACs that I wish to interoperate with, and
2) ask those AC vendors to port their AP code to my hardware.

There is an assumption in this specification that the AC vendors will be
willing to work with me, and have their control protocol work with my AP.
I think the question we need to ask ourselves is why would they? Certainly
not out of the goodness of their heart. So if a proposal cannot guarantee
any level of interoperability, then why is this even being considered in
the IETF?

>    attempt to exclude a single protocol.

No Dan, I completely disagree. When one looks at the technical merits of
a protocol, we must not only evaluate whether a protocol satisfies 
requirements, but we must also determine whether it even makes business
sense. Frankly, does it make sense to design something that no one can use
because of the business model behind it?

Again, as I mentioned above, if I were an AP vendor, I would have to chose
which companies I want to interoperate with, and then somehow convince them
to port their code to my AP. The SLAPP specification cannot guarantee that
the AC vendors I want to interoperate with will be willing to port their
code
to my hardware. So where does that leave me as an AP vendor? How does the
SLAPP proposal guarantee interoperability?

>    of any proposals in CAPWAP that would lock in HW.

Dan, let's at least be honest here. Using the above example, if I were to
rely on the AC vendor for porting their AP code to my hardware, then I'm
locked in. As we all know, some of the lower layers of the code that runs on
an access point include such things as OSes and device drivers, which are
very
hardware specific. If my AP company wishes to make a change to its hardware
design, possible for cost reduction purposes (like changing the flash
component),
I would have to go back to the AC vendors to update the AP firmware to
support my new AP hardware.

How does this help the market, the AC vendor, or my AP company?

>    it in the objectives draft would be unnecessarily redundant.

Interesting. I feel compelled to mention it because I believe that the 
proposal makes it necessary.

More examples. Let's say my AP company creates the wiz-bang MAC that can
send RF packets with distinct color, making RF no longer transparent (yes,
this makes no sense, but let's stick to the issue, not the example). In this
case, I go to the AC vendor of my choosing, and beg them to port their code
to my hardware. The primary issue here is that the AC vendor has no
development
experience with my cool MAC. So not only are not likely to want to work with
my company, but even less so because now the task of porting their code to
my AP will be even harder.

Of course, one of my competitors has a very standard access point, using a 
standard reference design from one of the MAC manufacturers. They are much
more
likely to get AC vendor to work with them, because this is now an easy task.

The end result to the market? Innovation from companies like mine, which
create
Differentiated Aps, are put in a position where we can no longer compete.
Sure
this is not a "technical point", but still one that we cannot really ignore.

>    not further the goal you so desperately want to reach.

Really? In my previous example, in order for AC vendor to port their code to
my hardware, I've had to provide them with technical descriptions of how my
MAC works, the data sheets, etc. Why am I motivated to provide my company's
IPR,
which BTW is what keeps me in business, to an AC vendor, who can then turn 
around and replicate my chipset?

Sure, I'll agree this is not a "technical point" in terms of protocol
design,
but I honestly think it's foolish for us to ignore the fact that companies 
really do want to make money, and that standards aren't just for bed side 
reading.

> 
> 5. AP Vendors must not take the brunt of porting code onto 
> their AP for every AC vendor.
> 

Let's be clear here. The SLAPP protocol can go one of two ways. AC vendors
keep the protocol close to their chest and port their code to the AP vendors
that they feel like. On the other hand, AP vendors deal have to write 'n'
control
protocols, where 'n' is the number of AC vendors that the AP vendor in
question
wants to interoperate with.

If a proposal such as SLAPP were to be adopted, here is what products would
look
like. I'm an IT manager that wishes to create a WLAN network. I choose
an AC vendor, and then look at the number of "CAPWAP enabled" access points
available. The only problem is that "CAPWAP enabled" actually doesn't mean
that
the AP will interoperate with my AC. I actually have to read the fine print
to
determine whether the AP in question also supports the proprietary control
protocol used by the AC vendor. If I don't, I have a really nice door stop.

To conclude, while this is an engineering organization, I think we owe
it to ourselves to design a protocol that really does define an
interoperable
protocol instead of simply punting with a claim that doing so would be "too
complex".

Pat Calhoun

---

From: Dan Harkins <[email-masked]>
Date: Thu, 07 Apr 2005 11:07:15 -0700

Pat,

  We will just have to agree to disagree on whether market objectives
have a place in an IETF document (you still haven't found me any
precedence for such a thing, by the way).

  But this is interesting....

On Thu, 07 Apr 2005 07:14:13 PDT you wrote
> my AP will be even harder.

If RF coloring (yes, makes no sense but I'll go with it) is an important
feature that customers want it would behoove an AC vendor to support it
before to his competitors. The more important the feature the more likely
AC vendors would be knocking on _his_ door. If the new wiz-bang feature is
not something that a customer particularly cares about then you may be right,
the AP vendor would have to search out AC vendors and "beg". But since it's
not that important of a feature then what's the problem? You seem very hung
up on the business aspects of technology but you don't seem to get basic
capitalism.

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.

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? 

But how will that work because that will require the wiz-bang MAC company
to disclose its proprietary information to selected AC vendors so they can
understand this vendor-specific blob of bits and send down another
vendor-specific blob of bits to allow the AP to color the RF? Surely that
runs into the "market objectives" issues you raised with SLAPP.

Not only that but then you have the polyglot problem with this "standard".
The version of the "standard" an AC speaks to one AP may be quite different
that the version of the "standard" it speaks to another (because one has
wiz-bang features and therefore vendor extensions that another doesn't
have, or even worse they both support the same features which are not
defined in the "standard" but use different ways to configure them).

> this is not a "technical point", but still one that we cannot really ignore.

Pat! You're killing me :-)

"companies like [your's]...can no longer compete." That is just too outrageous
to be taken seriously. Your company is one of the most successful technology
companies in the world and SLAPP is not going to destroy it. Relax.

[snip]
> wants to interoperate with.

And let's also be clear. LWAPP can go one of two ways. It can stifle 
innovation because of its necessarily rigid nature (it can only specify
a finite amount of things to control and some things, as you noted above
haven't been invented yet) or AC vendors speak a polyglot of the "standard"--
some APs have features others don't, and even worse, some APs have features
others do but because it's not part of the RFC they are configured in
different ways.

Actually, there's a 3rd way LWAPP could go. It could do both. It could
stifle innovation for important new features-- if I had a better example
than your RF coloring I wouldn't mention it here-- AND become a polyglot 
for trivial things-- blink the lights on an AP in some particular
combination. The worst of both worlds.

  Dan.

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 7 Apr 2005 13:42:06 -0700

> If RF coloring (yes, makes no sense but I'll go with it) is 
> an important feature that customers want it would behoove an 
> AC vendor to support it before to his competitors. The more 
> important the feature the more likely AC vendors would be 
> knocking on _his_ door. If the new wiz-bang feature is not 
> something that a customer particularly cares about then you 
> may be right, the AP vendor would have to search out AC 
> vendors and "beg". But since it's not that important of a 
> feature then what's the problem? You seem very hung up on the 
> business aspects of technology but you don't seem to get 
> basic capitalism.

Yes, I am hung up on it. My belief is that technologies must be
created with a driving market force. Creating a technology for
technology's sake seems pointless to me. In any case, let's move
off this topic - it really isn't the issue at hand.

> 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? 

Dan, what is being proposed here exists in many other successful
protocols. Nothing abnormal or unusual a out vendor specific 
attributes.

> The version of the "standard" an AC speaks to one AP may be 
> quite different that the version of the "standard" it speaks 
> to another (because one has wiz-bang features and therefore 
> vendor extensions that another doesn't have, or even worse 
> they both support the same features which are not defined in 
> the "standard" but use different ways to configure them).

I think that's the crux of the problem, and I disagree. I believe that
a protocol should allow for a light weight access point to provide
WLAN service to mobile devices. How the AP manages the RF, whether
it sends packets invisibly with some opaque coloring scheme, is really
up to the AP. The end, though, is that the user gets service, and the
AP is centrally provisioned and controlled.

> "companies like [your's]...can no longer compete." That is 
> just too outrageous to be taken seriously. Your company is 
> one of the most successful technology companies in the world 
> and SLAPP is not going to destroy it. Relax.

Dan, I was citing an example where I was pretending to be an AP
startup. My statement was only for illustrative purposes and had
nothing to do with my employer.

> And let's also be clear. LWAPP can go one of two ways. It can 
> stifle innovation because of its necessarily rigid nature (it 
> can only specify a finite amount of things to control and 
> some things, as you noted above haven't been invented yet) or 
> AC vendors speak a polyglot of the "standard"-- some APs have 
> features others don't, and even worse, some APs have features 
> others do but because it's not part of the RFC they are 
> configured in different ways.

I think there are plenty of extensible protocols that allow different
implementations to interoperate, but also allow for vendors to add
whatever they believe they need to provide some level of differentiated
service. That's not the problem. My belief is that the WG is trying to
create a protocol where an AP can WLAN service to mobile devices - that's
all.

Pat Calhoun

---

From: Dan Harkins <[email-masked]>
Date: Thu, 07 Apr 2005 14:39:37 -0700

Pat,

On Thu, 07 Apr 2005 13:42:06 PDT you wrote
> off this topic - it really isn't the issue at hand.

If driving market force is part of your belief then you would not
be so wrong on SLAPP. I just demonstrated how your view of it
stifling innovation was erroneous, and used driving market force
as the way. Business aspects of technology may not be the issue
at hand (anymore, thank God) but your incorrect characterization
of SLAPP is.

> protocols. Nothing abnormal or unusual a out vendor specific 

Yes, they do. I've put them in a very successful protocol myself.
Nothing unusual about them. As I mentioned in my email to James I
would be against any attempt to remove them from LWAPP.

I brought them up not because I thought they were unusual or weird
or illegal or some such nonsense. I brought them up because they
are the logical outcome of LWAPP and accepting "givens" is part of a
logical discussion-- given A we will arrive at B.

Either LWAPP is complete as a control and provisioning protocol and
that will stifle innovation or it is an incomplete control and
provisioning protocol that requires vendor-specific attributes to fill
out. Given the latter, the result is a multitude of different "standard"
protocols that an AC has to support, one for each AP it needs to
manage.

> AP is centrally provisioned and controlled.

So what we're talking about is just the degree of opaque coloring.

With SLAPP how an AC sends packets invisibly with some opaque coloring
scheme is up to the AC. And the user gets service and the AP is
centrally provisioned and controlled. Ta-da! :-)

If you believe that how packets are opaquely colored is up to the AP
then how can you disagree with the statement that you will end up with
the polyglot problem? 

> create a protocol where an AP can WLAN service to mobile devices - that's

No, the working group is trying to create a protocol where a slew of APs 
(from different vendors) are controled and centrally managed by an AC.
An AP providing WLAN service to mobile devices does not require a protocol.
We have that today in spades. Hence the belief that a protocol to centrally
control and manage the APs is needed, hence CAPWAP. If "all" that was needed
was the ability for an AP to provide WLAN service to mobile devices we
would not need an IETF working group, IEEE 802.11 solved that problem
already.

  Dan.