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

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Mon, 11 Apr 2005 20:59:07 -0600

The proposals being up - they are fair game for critical analysis in the
list. However,

More inline...

-mani
======

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Thursday, April 07, 2005 10:03 AM
To: Wijnen, Bert (Bert); Pat Calhoun; 'Dan Harkins'
Cc: [email-masked]
Subject: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft)

So in line with Bert's comments, I've been pondering whether it would be
possible for SLAPP to achieve the interoperability requirement that IETF
has
for moving a protocol from Proposed Standard to Draft Standard (I'm
assuming
other people in the WG care about the protocol ultimately going to Draft
Standard, I certainly do). The requirement is that there need to be two
independently built interoperable implementations done from the
specification that is being put forward for advancement to Draft
Standard.
It is one of the few hard and fast rules that IETF has.

As I see it, the basic issue is this:

    Is it possible for two AC implementors and two AP implementors
    *using the SLAPP spec* to achieve independently implemented
    interoperable implementations *of the control protocol* without
    reference to any other specification except those that are listed
    as Normative References in the specification and without
    exchanging any code?

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).

[Mani, Mahalingam (Mahalingam)] we will not presuppose the evaluation
process for lack of meeting Objectives criteria - which will be part of
evaluation process. We should hold such judgments until the protocol
evaluation process starts. It is fair to provide at least until after
Objectives WGLC for all protocol drafts to make course corrections
before sitting in judgment over their suitability. That is not to
discourage debating the merits, demerits, lack or richness of features.

-mani

Comments?

            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: "James Kempf" <[email-masked]>
Date: Mon, 11 Apr 2005 20:10:42 -0700

Mani,

This sounds fine to me.

            jak

----- Original Message ----- 
From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Wijnen, Bert (Bert)"
<[email-masked]>; "Pat Calhoun" <[email-masked]>; "Dan Harkins"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 11, 2005 7:59 PM
Subject: RE: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft)

More inline...

-mani
======

-----Original Message-----

-mani

Comments?

            jak

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 12 Apr 2005 06:25:05 -0700

> 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