Subject: Re: [Capwap] Comments on objectives draft

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 7 Apr 2005 18:10:00 +0800

Dear All,

James makes a good point. While the proposed requirements are
interesting, they seem to broadly address commercial aspects of WLANs.
It would be useful to understand how they affect the technical aspects
of protocol design. 

Saravanan 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of James Kempf
> Sent: Thursday, April 07, 2005 12:43 AM
> To: Pat Calhoun; [email-masked]
> Subject: Re: [Capwap] Comments on objectives draft
> 
> Pat,
> 
> Comments.
> 
> > 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.
> >
> 
> 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.
> 
> > 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.
> >
> 
> 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.
> 
> > 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.
> 
> Again, a good technical point.
> 
> >
> > 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.
> 
> 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.
> 
> >
> > 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.
> >
> 
> 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.
> 
> > 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.
> >
> 
> 
> 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
> 
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

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

> It would be useful to understand how they affect the 
> technical aspects of protocol design. 
> 
Saravanan,

I believe that it is in the best interest of both the IETF and the
market, to create a solution that guarantees interoperability. Putting
aside the cost associated with some of the issues I listed, a proposal
that creates additional restrictions on which vendors may interoperate
doesn't help anyone.

As I mentioned in another thread, I think mass confusion would reign
if an IT manager had to not only look at whether an AP was "CAPWAP
enabled", but also had to read the fine print to determine whether the
AP could actually interoperate with the AC deployed by the customer.

Imagine if the routing folks had decided to not create a protocol, but
instead just a way to "negotiate" a protocol. Deploying an IP network
would require that all the devices not only be capable of "negotiating",
but also that the devices support the same protocol - which has been
left proprietary. 

It's all about interoperability...

PatC