Subject: RE: [Capwap] A simpler approach to CAPWAP

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 11 Mar 2005 13:00:02 -0700

Keerti,

See inline.

-mani
======

[...]

You ruling something out, means nothing to me. I am disappointed that
the chairs fail to recognize the real issues and continue to pursue
academic objectives without regard to market realities.

[Mani, Mahalingam (Mahalingam)] this is not an academic objective. If it
turns out to achieve something in the academic realm as well - I am sure
the erudite ones in the WG will be glad to have contributed.

The chairs have no intentions to tolerate proposals that make a mockery
of IETF or CAPWAP objectives and charter.

Nor proposals for the sake of one.

Nor to detract from charter goals the WG has shown consensus (including
the current proponent-s) on; while still being open to arguments on
serious validation issues, if any, including the charter; this will
require more than mere assertions.

I would urge, finally, to keep the debate, discussions and objective
statements focusing on problems and/or issues at hand and not mix
unjustifiable rhetoric.

> As an AC vendor, the last thing that I really want to do is to have to
[Mani, Mahalingam (Mahalingam)] [...]

Keerti Melkote
Founder
Aruba Networks

> Pat R Calhoun
> CTO/Founder
> Airespace, Inc.
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
>
[Mani, Mahalingam (Mahalingam)] -mani
_______________________________________________
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: Keerti Melkote <[email-masked]>
Date: Fri, 11 Mar 2005 12:22:49 -0800

Mani,

See inline.

-Keerti

> of IETF or CAPWAP objectives and charter.

If questioning objectives is a mockery of the IETF or  CAPWAP, then I
fail to see how this is in the spirit of open debate which the IETF
has always stood for.

The fact remains that there is not a single substantive argument which
says a download protocol does not meet the market objective of
interoperability between ACs and WTPs. The arguments seem to center
around the fact that the method of communication seem proprietary but
never the fact that an AC and a WTP from different vendors can be made
interoperable.

However, we continue to proceed without accepting this as an alternative to the
heavy duty protocols that have been submitted today. I agree that it
does not deliver interoperability of the kind this group seems to
prefer. But customers are NOT asking for this. They are asking for
interoperability. Full Stop. Not of a specific kind.

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 14 Mar 2005 23:48:07 +0800

Hi Keerti,

Not sure how this single download protocl helps to achieve interoperability.
It seems that the AC and WTP vendors need to have certain private
arrangement (anyway, the AC vendors builts the image to be run by the WTP).
Then, what prevents them to go one step further to negotiate their own
downloading procedures. Couldn't see the need for a standard here. I guess
it has been discussed long time back in this mailing list, and probably that
is why it is decided out of problem scope of the current WG.  The CAPWAP is
introduced to obviate the direct relationship between WTP vendors and AC
vendors. The downloading method obviously dosen't meet this goal.

cheers

Cheng

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Keerti Melkote
> Sent: Saturday, March 12, 2005 4:23 AM
> To: Mani, Mahalingam (Mahalingam)
> Cc: Pat R. Calhoun; [email-masked]
> Subject: Re: [Capwap] A simpler approach to CAPWAP
> 
> 
> Mani,
> 
> See inline.
> 
> -Keerti
> 
> 
> On Fri, 11 Mar 2005 13:00:02 -0700, Mani, Mahalingam 
> (Mahalingam) <[email-masked]> wrote:
> > Keerti,
> > 
> > See inline.
> > 
> > -mani
> > ======
> > 
> > [...]
> > >
> > 
> > [Mani, Mahalingam (Mahalingam)] this is not an academic 
> objective. If 
> > it turns out to achieve something in the academic realm as 
> well - I am 
> > sure the erudite ones in the WG will be glad to have contributed.
> > 
> > The chairs have no intentions to tolerate proposals that make a 
> > mockery of IETF or CAPWAP objectives and charter.
> > 
> 
> If questioning objectives is a mockery of the IETF or  
> CAPWAP, then I fail to see how this is in the spirit of open 
> debate which the IETF has always stood for.
> 
> The fact remains that there is not a single substantive 
> argument which says a download protocol does not meet the 
> market objective of interoperability between ACs and WTPs. 
> The arguments seem to center around the fact that the method 
> of communication seem proprietary but never the fact that an 
> AC and a WTP from different vendors can be made interoperable.
> 
> However, we continue to proceed without accepting this as an 
> alternative to the heavy duty protocols that have been 
> submitted today. I agree that it does not deliver 
> interoperability of the kind this group seems to prefer. But 
> customers are NOT asking for this. They are asking for 
> > Nor to detract from charter goals the WG has shown consensus 
> > (including the current proponent-s) on; while still being open to 
> > arguments on serious validation issues, if any, including 
> the charter; 
> > this will require more than mere assertions.
> > 
> > > As an AC vendor, the last thing that I really want to do 
> is to have 
> > > to
> > [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> > 
> >
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Mar 2005 13:51:52 -0800

Keerti,

> never the fact that an AC and a WTP from different vendors can be made

I believe several postings have raised the issue about whether a broad set
of interoperable WTPs and ACs could be achieved using this technique. The
primary arguments have involved the degree to which the WTP and AC vendors
need to know the details of each other's hardware, and the tendency thereby
for WTP and AC vendors to drift into islands of interoperability where the
relevent NDAs and such are signed. Thus, a download protocol might be more
likely to lead to proprietary vendor-lock in, since a service provider would
need to select a particular island and stick with it, rather than be able to
choose from a broad variety of interoperable vendors as is the case with
most other networking gear today.

> interoperability. Full Stop. Not of a specific kind.

I can't claim to be a customer of Aruba, and, as in all matters IETF, I
speak as an individual, but since I work for a wireless service provider, I
believe I have some insight into what's in the best interest of wireless
service providers, who are or will ultimately be customers of AC and WTP
vendors. I believe an interoperable WLAN RAN protocol is clearly to the
benefit of wireless service providers. Interoperable protocols (what
ultimately IETF is all about) have proven time and again to benefit
customers of networking gear, and I don't see any indications that this is
any different. In fact, as I've mentioned before on this thread, the entire
situation is very reminiscent of the time about 8-10 years ago when 3GPP
standardized the UMTS RAN protocols. The RAN protocol in GSM was not
standardized, and wireless service providers insisted on standardizing it in
3G. Today, it is possible to set up a multi-vendor UMTS RAN, whereas that
was not the case with GSM.*

            jak

*In fact, I believe it is now also possible to set up a multivendor GSM RAN,
since 3GPP approved the new GERAN protocol standard.