Subject: [Capwap] Interoperability reqs into Objectives draft (was: Comments on objectives draft)

From: <[email-masked]>
Date: Thu, 7 Apr 2005 14:19:26 -0700

I agree with James and Bert's proposal for Interoperability requirements in the CAPWAP Objectives draft. 

We have some modest consensus on this point, and I'd like to close this issue in order to incorporate these requirements into the Objectives draft.

To summarize, these are the new requirements:

REQ 1) Any AP or AC vendor or any person can implement the CAPWAP protocol from the spec itself and by that it is required that all such implementations do interoperate.
REQ 2) An AP Vendor can make modifications to HW without any AC vendor involvement.
REQ 3) AP Vendors must not be bound to a specific MAC.
REQ 4) AP vendors should not have to share technical specifications for hardware and software to AC vendors in order for interoperability to be achieved.

WGLC for http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-01.txt  for the IEEE experts Review ends Monday, 4/11/05.

Regards,
Dorothy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext James Kempf
Sent: Wednesday, April 06, 2005 9: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 14:32:13 -0700

Dorothy, I think that (1) and (4) are one and the same. We could trim down
to 3.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, April 07, 2005 2:19 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Interoperability reqs into Objectives draft (was: 
> Comments on objectives draft)
> 
> 
> I agree with James and Bert's proposal for Interoperability 
> requirements in the CAPWAP Objectives draft. 
> 
> We have some modest consensus on this point, and I'd like to 
> close this issue in order to incorporate these requirements 
> into the Objectives draft.
> 
> REQ 1) Any AP or AC vendor or any person can implement the 
> CAPWAP protocol from the spec itself and by that it is 
> required that all such implementations do interoperate.
> REQ 4) AP vendors should not have to share technical 
> specifications for hardware and software to AC vendors in 
> order for interoperability to be achieved.
> 
> WGLC for 
> http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectiv
es-01.txt  for the IEEE experts Review ends Monday, 4/11/05.
> > 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.
> 
> > 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.
> 
> > 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.
> > 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
> 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
> > 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
> 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: Thu, 07 Apr 2005 15:01:32 -0700

How does REQ4 square with vendor-specific extensions? In fact, how does
REQ1 square with vendor-specific extensions? There are numerous RFCs that
allow for vendor-specific extensions and for interoperability between
two distinct groups to be acheived they have to exchange technical 
specifications that are outside the protocol spec itself. I hope that
CAPWAP would allow the same.

  As it stands I think REQ1 and REQ4 are unnecessarily restrictive and,
as written, will severly hamper CAPWAP.

  Personally, I liked Bert's proposal. It was succinct and to the point.
I recommend striking REQ1-REQ4 in place of Bert's proposal. 

  Dan.

On Thu, 07 Apr 2005 14:19:26 PDT you wrote
> We have some modest consensus on this point, and I'd like to close this issue
> in order to incorporate these requirements into the Objectives draft.
> 
> REQ 1) Any AP or AC vendor or any person can implement the CAPWAP protocol fr
>om the spec itself and by that it is required that all such implementations do
> interoperate.
> REQ 4) AP vendors should not have to share technical specifications for hardw
>are and software to AC vendors in order for interoperability to be achieved.
> 
> WGLC for http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-01.
>txt  for the IEEE experts Review ends Monday, 4/11/05.
> 
> Regards,
> Dorothy
> 
> 
> 
>