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

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

Dan-

I don't believe mandatory functionality should be governed vendor specific extensions.
The needed exchange of mandatory technical information should be evident the specification itself, not in a vendor specific extension, per Req1.  I don't see this as an either/or issue in terms of requirements.  

I'll be in traveling the next few days and won't check mail until Sunday.  

Dorothy

-----Original Message-----
From: ext Dan Harkins [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 6:19 PM
To: Gellert Dorothy (Nokia-ES/MtView)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Capwap] Interoperability reqs into Objectives draft (was:
Comments on objectives draft) 

  Dorothy,

  The optional nature of vendor specific extensions is not the issue.
It's whether they're allowed at all or not. Some people-- and I gave
2 specific examples-- are operating under the assumption that they are
and want to use them to solve a real problem while at least one other
person (James Kempf) wants to disallow them entirely.

  All I want is to see some consensus on the subject. Either there is
consensus that proposals in the CAPWAP working group can specify a method
by which the (probably not very functional) minimum mandatory required
functionality is expanded by use of vendor specific extensions, or there
is consensus that the only thing that can be configured by the protocol
that comes out of CAPWAP are those that are part of the minimum mandatory
required functionality.

  If it's the former then we must all also agree that requirements in the
objectives draft that seem to prohibit the needed "exchange of technical
information so that interoperability can be acheived" does not apply to
functionality that is controlled by vendor specific extensions.

  I'm glad you've decided to ditch REQ4 in place of REQ1. I had misunderstood
you to say the opposite.

  Dan.

On Thu, 07 Apr 2005 17:33:55 PDT you wrote
> Dan,
> 
> One our goals for the 1st draft of the CAPWAP protocol is to meet the minimum
> mandatory requirements in the Objectives draft that is based on the charter, 
>taxonomy draft, and problem statement. 
> 
> Given this goal, and the idea that vendor specific extensions are generally o
>ptional, I don't see why vendor specific extensions need to be explicitly stat
>ed in the Objectives draft.  
> 
> I agree to move REQ 4 to the rejected category in the Objectives draft, since
> its been pointed out that this is a duplicate of REQ 1.
> 
> -Dorothy
> 
> 
> 
> -----Original Message-----
> From: ext Dan Harkins [mailto:[email-masked]]
> Sent: Thursday, April 07, 2005 4:55 PM
> To: Gellert Dorothy (Nokia-ES/MtView)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Capwap] Interoperability reqs into Objectives draft (was:
> Comments on objectives draft) 
> 
> 
>   I'd rather lose the sub-requirement because it is too specific. If
> the word "interoperate" gets us into trouble then REQ4's use of the
> word "interoperability" must surely get us into similar trouble.
> 
>   Actually, vendor specific extensions have been discussed in terms
> of 802.11 to allow 802.11 features that are not defined in the protocol
> spec to be configured (see Pat's message from today with message-id of
> <[email-masked]> or David Nelson's of
> <[email-masked]>
> 802.16, yea, that too. I'm specifically talking about 802.11 though.
> 
>   James just said he wants to not allow vendor extensions. I think the
> working group needs to decide on this. Are vendor specific extensions
> (which necessarily require the exchange of technical information so that
> interoperability can be acheived and therefore technically violate REQ4)
> going to be allowed so that the protocol can be extended to configure WLAN
> features that are not defined in the protocol itself?
> 
>   If not then I think that has to be very explicitly said as a reqirement.
> 
>   Dan.
> 
> On Thu, 07 Apr 2005 16:00:31 PDT you wrote
> > Dan-
> > 
> > Req 1 is Bert's proposal.   I substitued the CAPWAP protocol for the word s
>pe
> >cification and changed "any vendor or person" to be "Any AP or AC vendor or 
>an
> >y person".
> > 
> > It was pointed out that Req 4 is a subset of Req 1.  I would rather keep th
>e 
> >sub-requirement, because I think we get into trouble with the word "interope
>ra
> >te", and Req 4 is more specific.  
> > 
> > As far as vendor specific extensions, they don't replace defining the contr
>ol
> > aspect within the protocol as chartered.  So far the WG has discussed exten
>si
> >ons in terms of applicability to .16 or other L2 technologies.
> > 
> > Dorothy
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: ext Dan Harkins [mailto:[email-masked]]
> > Sent: Thursday, April 07, 2005 3:02 PM
> > To: Gellert Dorothy (Nokia-ES/MtView)
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [Capwap] Interoperability reqs into Objectives draft (was:
> > Comments on objectives draft) 
> > 
> > 
> >   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
> > > 
> > > I agree with James and Bert's proposal for Interoperability requirements 
>in
> > t
> > >he CAPWAP Objectives draft. 
> > > 
> > > We have some modest consensus on this point, and I'd like to close this i
>ss
> >ue
> > > 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 protoco
>l 
> >fr
> > >om the spec itself and by that it is required that all such implementation
>s 
> >do
> > > interoperate.
> > > REQ 2) An AP Vendor can make modifications to HW without any AC vendor in
>vo
> >lv
> > >ement.
> > > REQ 3) AP Vendors must not be bound to a specific MAC.
> > > REQ 4) AP vendors should not have to share technical specifications for h
>ar
> >dw
> > >are and software to AC vendors in order for interoperability to be achieve
>d.
> > > 
> > > WGLC for http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives
>-0
> >1.
> > >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 cou
>ld
> > > > only interoperate with the AC vendors that are willing to collaborate w
>it
> >h
> > > > 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 
>se
> >e
> > > 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 cos
>t
> > > > 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 requireme
>nt
> > > > will bind AP vendors to specific hardware versions and not allow them t
>o
> > > > either lower their cost, or make HW performance improvements, without t
>he
> > > > 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 b
>y
> > > 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 c
>od
> >e
> > > > to APs that share the same underlying hardware, such as the 802.11 MAC,
> a
> >s
> > > > they do. Having to support new 802.11 MACs is a very complex process, a
>nd
> > > > would require significant effort on behalf of the AC vendors, further
> > > > encouraging them to limit which AP vendors they wish to collaborate wit
>h.
> > > > 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 confident
>ia
> >l
> > > > information to AC vendors in order to get CAPWAP interoperability. The
> > > > adverse effect of not having this requirement means that AP vendors mus
>t
> > > > provide to third parties information whose privacy may be crucial to th
>e
> > > AP
> > > > vendor's success as a company.
> > > 
> > > This is another business point that I think doesn't belong in the documen
>t.
> > > 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 
>al
> >l
> > > the protocol work IETF does including the requirement for two independent
> > > interoperable implementations to go to DS, but somehow it seems to have b
>ee
> >n
> > > 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 ever
>y
> > > 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, mu
>st
> > > be
> > > > committed to creating open standards that allow for true interoperabili
>ty
> >,
> > > > while allowing AP and AC vendors to be fiscally responsible. I'd be hap
>py
> > > 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 pu
>t
> > > it), we need to approach this from an engineering standpoint. I don't thi
>nk
> > > 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
> > > 
> > 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap