Subject: RE: SLAPP and IETF DS Interoperability Requirement (was: Re: [Capwap] Comments on objectives draft)

From: "Bob O'Hara" <[email-masked]>
Date: Tue, 12 Apr 2005 23:20:02 -0700

If we go back to our problem statement and objectives, I believe there
is a thread that can be paraphrased as "provisioning 802.11 access
points to provide WLAN service" is what the eventual CAPWAP protocol
will do.  There are a number of other items, but this is the nut beneath
the shell.  

From my reading of the SLAPP document, I cannot see that the protocol
described in the draft accomplishes this provisioning in any manner.
Some subsequently downloaded protocol code may accomplish the
provisioning.  But, that provisioning protocol is not described in the
SLAPP draft.

While there are many in the WG that are expert in 802.11, I have been
asked to be the 802.11 technical advisor for the WG.  I admit, as an
author of a competing protocol draft, that I am biased in its favor.
But, I can find not a single item in the SLAPP draft that relates to
actually provisioning a WLAN to operate on an access point of any
architecture described in our taxonomy draft.  As such, I believe that
SLAPP does not meet the minimum technical requirements (no matter how
low those requirements are reasonably set) to be considered a viable
proposal to be considered by the WG.  I agree with Pat that a protocol
that does not deliver the provisioning aspect is not an improvement over
the current (lack of) standards.

I challenge the SLAPP authors, or any other person, to show me where I
am wrong in my statements.

 -Bob
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Tuesday, April 12, 2005 6:25 AM
To: 'Mani, Mahalingam (Mahalingam)'; 'James Kempf'; 'Wijnen, Bert
(Bert)'; 'Dan Harkins'
Cc: [email-masked]
Subject: RE: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft)

> The answer I think is clearly "no". This is because the SLAPP 
> spec doesn't address the control protocol, it just addresses 
> discovery, negotiation of a (probably proprietary) control 
> protocol, and download of code to run the control protocol, 
> as Partha mentioned in his email. In order to actually 
> achieve interoperablity *on the control protocol*, the AC and 
> AP vendors would have to exchange an additional specification 
> that would not be part of the Normative References in the 
> specification being put forward for advancement to Draft Standard.
> 
> From this, I conclude that SLAPP does not address the goals 
> of the CAPWAP charter, since the CAPWAP charter clearly 
> defines an interoperable control protocol as one of the 
> deliverables for the Working Group. Therefore, I would 
> venture that SLAPP is not a valid candidate for consideration 
> as a CAPWAP protocol, and it should not be considered in the 
> upcoming protocol decision phase (whatever that might be).

So in my mind, the way that we should be evaluating these protocols
is simple. The end protocol should be sufficiently detailed to ensure
that the WTP and the AC are capable of providing 802.11 services to
mobile devices, while solving the problems described in the problem
statement, and being flexible enough to support the supported 
architectures defined in the taxonomy document.

I believe that in the end, if we have a protocol that allows a WTP
to communicate in some fashion with an AC, but cannot actually 
provide WLAN services to the end station, then we would have created a
solution that isn't even as good as what we have today in autonomous
AP architectures.

That said, the whole vendor specific (aka "herbs and spices") 
discussion in my mind means that once basic services are provided to
the mobile devices, it should be possible for a given vendor to
provide some added value (perceived or otherwise) by owning both
ends of the link - allowing for additional innovation.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
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: Dan Harkins <[email-masked]>
Date: Tue, 12 Apr 2005 23:42:23 -0700

Bob,

  If you admit to bias then I'm not sure what value any technical advice
you provide us could have.

  I call on you to resign.

  Dan.

On Tue, 12 Apr 2005 23:20:02 PDT you wrote

---

From: "Pat Calhoun" <[email-masked]>
Date: Wed, 13 Apr 2005 05:37:42 -0700

I object. Even though Bob may be biased towards a specific protocol,
he has been extremely fair in his communications in both IETF and IEEE,
and a seasoned standars person that has been through this several times.
Bob has been involved in 802.11 for well over 13 years, and is certainly
someone that we cannot ignore in the WG as a subject matter expert.

I'm personally still waiting for a response to:
> I challenge the SLAPP authors, or any other person, to show 
> me where I am wrong in my statements.

Pat Calhoun

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Tuesday, April 12, 2005 11:42 PM
> To: Bob O'Hara
> Cc: [email-masked]
> Subject: Re: SLAPP and IETF DS Interoperability Requirement 
> (was: Re: [Capwap] Comments on objectives draft) 
> 
>   Bob,
> 
>   If you admit to bias then I'm not sure what value any 
> technical advice you provide us could have.
> 
>   I call on you to resign.
> 
>   Dan.
> 
> > will do.  There are a number of other items, but this is the nut 
> > beneath the shell.
> > 
> > that does not deliver the provisioning aspect is not an improvement 
> > over the current (lack of) standards.
> > 
> > > The answer I think is clearly "no". This is because the 
> SLAPP spec 
> > > doesn't address the control protocol, it just addresses 
> discovery, 
> > > negotiation of a (probably proprietary) control protocol, and 
> > > download of code to run the control protocol, as Partha 
> mentioned in 
> > > his email. In order to actually achieve interoperablity *on the 
> > > control protocol*, the AC and AP vendors would have to 
> exchange an 
> > > additional specification that would not be part of the Normative 
> > > References in the specification being put forward for 
> advancement to 
> > > Draft Standard.
> > > 
> > > From this, I conclude that SLAPP does not address the 
> goals of the 
> > > CAPWAP charter, since the CAPWAP charter clearly defines an 
> > > interoperable control protocol as one of the deliverables for the 
> > > Working Group. Therefore, I would venture that SLAPP is 
> not a valid 
> > > candidate for consideration as a CAPWAP protocol, and it 
> should not 
> > > be considered in the upcoming protocol decision phase 
> (whatever that 
> > > might be).
> > 
> > So in my mind, the way that we should be evaluating these 
> protocols is 
> > simple. The end protocol should be sufficiently detailed to ensure 
> > I believe that in the end, if we have a protocol that 
> allows a WTP to 
> > communicate in some fashion with an AC, but cannot actually provide 
> > WLAN services to the end station, then we would have created a 
> > provide some added value (perceived or otherwise) by owning 
> both ends 
> > of the link - allowing for additional innovation.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems

---

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

Bob,

  The -01 version of SLAPP accomplishes "provisioning 802.11 access
points to provide WLAN Service" through the downloading of a bootable
image onto the AP. The AP boots that image and is provisioned by a
control protocol contained there. The technique described by SLAPP does,
indeed, end up provisioning the AP to provide WLAN service and examples
of this exist today. 

  Dan.