From pekkas@netcore.fi Fri Jan 2 09:13:26 2004 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 2 Jan 2004 11:13:26 +0200 (EET) Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <55749BC69138654EBBC4C50BA4F55610ADC382@AIREMAIL.airespace.com> Message-ID: I'll respond to two responses in one message.. [James Kempf] > Regarding IPR, the proposed WG charter is only to do an architectural > taxonomy. As such, I don't think there would be any IPR (except of course on > the contents of the document, which belongs to ISOC). Whether or not the WG > is rechartered to actually do protocol work depends on the outcome of the > architectural taxonomy work, and any IPR issues would naturally need to be > revisited at that time. True .. which is why IPR is not a *critical* issue at the moment. However, the WGs expect taxonomies to lead to something, e.g. the architecture and the protocol work. Then IPR starts to be very important. Either the WG has to be note that "Ok, the whole effort can be killed after the taxonomy -- there are not promises at all", or they can start charting the IPR situation as soon as possible to avoid "late surprises".. On Wed, 31 Dec 2003, Pat R. Calhoun wrote: > > On Wed, 31 Dec 2003, Pat R. Calhoun wrote: > > > > The main thing I'm concerned at this point is whether these vendors > > > > may have claimed IPR on these protocols, and whether this might > > > > interfere with the work of this potential WG. > > > > > > > > Has this been discussed? > > > > > > http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.txt > > > > That's good enough for me, at least, but what is the situation with > > the other represented vendors (etc.) who already have solutions on the > > table? It might not hurt to ask each of them explicitly.. > > Actually there are explicit rules about disclosing any IPR already in place > see section 10 of http://www.ietf.org/rfc/rfc2026.txt. So there is no need to > ask each explicitely, it's just part of the rules if they play. I know those rules pretty well, and they are full of holes (and unambiguity) an elephant could walk through. draft-ietf-ipr-technology-rights-12.txt (in RFC ed queue) is a bit better. The problem here is that actually the IPR holders may not need to disclose their IPR unless they participate in the discussion which covers their IPR, and their IPR is incorporated in documents. So, as this WG does not do any particular protocols, even if the vendors participated in the discussion, they might not be required to disclose their IPR. But this is a bit shady area. Therefore explicitly asking about it is a lot better, if the participants agree to tell anything about it :-) > I would also argue that CAPWAP is really concerned with larger scale WLAN > deployments so I think it is fair to assume that for the purposes of the > discussions on this list, the AP/NAS comparison is a fair statement. But still, I think this needs to go in the charter somehow, either by spelling out the assumptions in the specific scenario CAPWAP is interested of, or adjusting the language to be more generic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sgovindan@psl.com.sg Mon Jan 5 01:27:58 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Mon, 5 Jan 2004 09:27:58 +0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <000a01c3d32b$26ae08a0$7871510a@jadefox> The main thing I'm concerned at this point is whether these vendors may have claimed IPR on these protocols, and whether this might interfere with the work of this potential WG. The issue of IPRs is important and quite timely. However I do not think that this interferes with the CAPWAP work. The ultimate aim here is to establish a set of specifications that benefits the Internet community in the best possible way. This may possibly involve incorporating IPRs into a final standard. As long as the objectives of the proposed WG are met in the best fitting manner, I feel the issue of IPRs can be left aside. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 26/12/2003 From pekkas@netcore.fi Tue Jan 6 21:05:10 2004 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 6 Jan 2004 23:05:10 +0200 (EET) Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <000a01c3d32b$26ae08a0$7871510a@jadefox> Message-ID: On Mon, 5 Jan 2004, Saravanan Govindan wrote: > The main thing I'm concerned at this point is whether > these vendors may have claimed IPR on these protocols, and whether this > might interfere with the work of this potential WG. > > The issue of IPRs is important and quite timely. However I do not > think that this interferes with the CAPWAP work. The ultimate aim here > is to establish a set of specifications that benefits the Internet > community in the best possible way. This may possibly involve > incorporating IPRs into a final standard. As long as the objectives of > the proposed WG are met in the best fitting manner, I feel the issue of > IPRs can be left aside. Right. But the crutch here is what different folks think differently on what "benefits the Internet community in the best possible way". Some will probably state that no standard is better than a badly patent-encumbered standard, and wasting the time specifying such standards should be avoided if possible, hopefully before such work is even started in the first place. As an opposite view, some person from a company might be happily waiting for the standarization, seeing it as a way to license its IPR on the subject. These do have implications to the work being initiated or produced (or not).. so bringing the issues on the table sooner than later is probably a good idea. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pcalhoun@airespace.com Tue Jan 6 22:19:10 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 6 Jan 2004 14:19:10 -0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC448@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D4A3.4A3866F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable However, having said that, one could argue that if we were so concerned = about IPR that it would impact the IETF's ability to get anything done, I'd still be = mailing you this=20 note via snail mail :) At one point we have to live with the rules set forth in this = organization and focus on getting the job done. PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Pekka Savola Sent: Tue 1/6/2004 1:05 PM To: Saravanan Govindan Cc: iesg@ietf.org; capwap@frascone.com Subject: RE: [Capwap] Re: WG Review: Control and Provisioning of = Wireless Access Points (capwap) =20 On Mon, 5 Jan 2004, Saravanan Govindan wrote: > The main thing I'm concerned at this point is whether > these vendors may have claimed IPR on these protocols, and whether = this > might interfere with the work of this potential WG. >=20 > The issue of IPRs is important and quite timely. However I do not > think that this interferes with the CAPWAP work. The ultimate aim here > is to establish a set of specifications that benefits the Internet > community in the best possible way. This may possibly involve > incorporating IPRs into a final standard. As long as the objectives of > the proposed WG are met in the best fitting manner, I feel the issue = of > IPRs can be left aside. Right. But the crutch here is what different folks think differently on what "benefits the Internet community in the best possible way". =20 Some will probably state that no standard is better than a badly patent-encumbered standard, and wasting the time specifying such standards should be avoided if possible, hopefully before such work is even started in the first place. As an opposite view, some person from a company might be happily waiting for the standarization, seeing it as a way to license its IPR on the subject. These do have implications to the work being initiated or produced (or not).. so bringing the issues on the table sooner than later is=20 probably a good idea. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3D4A3.4A3866F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: WG Review: Control and Provisioning of Wireless = Access Points (capwap)

However, having said that, one could argue that if we = were so concerned about IPR that
it would impact the IETF's ability to get anything done, I'd still be = mailing you this
note via snail mail :)

At one point we have to live with the rules set forth in this = organization and focus on
getting the job done.

PatC


-----Original Message-----
From: capwap-admin@frascone.com on behalf of Pekka Savola
Sent: Tue 1/6/2004 1:05 PM
To: Saravanan Govindan
Cc: iesg@ietf.org; capwap@frascone.com
Subject: RE: [Capwap] Re: WG Review: Control and Provisioning of = Wireless Access Points (capwap)

On Mon, 5 Jan 2004, Saravanan Govindan wrote:
> <Pekka Savola> The main thing I'm concerned at this point is = whether
> these vendors may have claimed IPR on these protocols, and whether = this
> might interfere with the work of this potential WG.
>
> <SG> The issue of IPRs is important and quite timely. However = I do not
> think that this interferes with the CAPWAP work. The ultimate aim = here
> is to establish a set of specifications that benefits the = Internet
> community in the best possible way. This may possibly involve
> incorporating IPRs into a final standard. As long as the objectives = of
> the proposed WG are met in the best fitting manner, I feel the = issue of
> IPRs can be left aside.

Right.  But the crutch here is what different folks think = differently
on what "benefits the Internet community in the best possible = way". 
Some will probably state that no standard is better than a badly
patent-encumbered standard, and wasting the time specifying such
standards should be avoided if possible, hopefully before such work = is
even started in the first place.  As an opposite view, some = person
from a company might be happily waiting for the standarization, = seeing
it as a way to license its IPR on the subject.

These do have implications to the work being initiated or produced = (or
not).. so bringing the issues on the table sooner than later is
probably a good idea.

--
Pekka = Savola           &= nbsp;     "You each name yourselves king, yet = the
Netcore = Oy            = ;        kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap


------_=_NextPart_001_01C3D4A3.4A3866F3-- From sgovindan@psl.com.sg Mon Jan 5 01:22:56 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Mon, 5 Jan 2004 09:22:56 +0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <000701c3d32a$1fdc3c00$7871510a@jadefox> Message-ID: <000801c3d32a$73bc3ff0$7871510a@jadefox> The main thing I'm concerned at this point is whether these vendors may have claimed IPR on these protocols, and whether this might interfere with the work of this potential WG. The issue of IPRs is important and quite timely. However I do not think that this interferes with the CAPWAP work. The ultimate aim here is to establish a set of specifications that benefits the Internet community in the best possible way. This may possibly involve incorporating IPRs into a final standard. As long as the objectives of the proposed WG are met in the best fitting manner, I feel the issue of IPRs can be left aside. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 26/12/2003 From bob.hinden@nokia.com Wed Jan 7 17:50:02 2004 From: bob.hinden@nokia.com (Bob Hinden) Date: Wed, 07 Jan 2004 09:50:02 -0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <000801c3d32a$73bc3ff0$7871510a@jadefox> References: <000701c3d32a$1fdc3c00$7871510a@jadefox> Message-ID: <4.3.2.7.2.20040107094308.02410408@mailhost.iprg.nokia.com> > The issue of IPRs is important and quite timely. However I do not >think that this interferes with the CAPWAP work. The ultimate aim here >is to establish a set of specifications that benefits the Internet >community in the best possible way. This may possibly involve >incorporating IPRs into a final standard. As long as the objectives of >the proposed WG are met in the best fitting manner, I feel the issue of >IPRs can be left aside. To put this another way, I believe that if a w.g. is created, the w.g. can choose to select a solution that includes known IPR or a solution that does not include IPR. This is something for the w.g. to discuss when comparing different solutions. Other than perhaps some mention in the charter, I don't see this as an issue that needs to be resolved now. Bob From smb@research.att.com Thu Jan 8 01:59:41 2004 From: smb@research.att.com (Steven M. Bellovin) Date: Wed, 07 Jan 2004 20:59:41 -0500 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: Your message of "Wed, 07 Jan 2004 09:50:02 PST." <4.3.2.7.2.20040107094308.02410408@mailhost.iprg.nokia.com> Message-ID: <20040108015941.8AC247B43@berkshire.research.att.com> In message <4.3.2.7.2.20040107094308.02410408@mailhost.iprg.nokia.com>, Bob Hin den writes: > >> The issue of IPRs is important and quite timely. However I do not >>think that this interferes with the CAPWAP work. The ultimate aim here >>is to establish a set of specifications that benefits the Internet >>community in the best possible way. This may possibly involve >>incorporating IPRs into a final standard. As long as the objectives of >>the proposed WG are met in the best fitting manner, I feel the issue of >>IPRs can be left aside. > >To put this another way, I believe that if a w.g. is created, the w.g. can >choose to select a solution that includes known IPR or a solution that does >not include IPR. This is something for the w.g. to discuss when comparing >different solutions. Other than perhaps some mention in the charter, I >don't see this as an issue that needs to be resolved now. That is indeed the intent of the IETF's IPR policy -- contributors have to disclose their IPR, but the wg evaluates the tradeoffs. --Steve Bellovin, http://www.research.att.com/~smb From Maurice_Goodfellow@eur.3com.com Thu Jan 8 15:37:15 2004 From: Maurice_Goodfellow@eur.3com.com (Maurice Goodfellow) Date: Thu, 8 Jan 2004 15:37:15 +0000 Subject: [Capwap] Data forwarding in the architecture Message-ID: <80256E15.00560B7F.00@notesmta.eur.3com.com> I am fairly new to monitoring this list so my apologies if this is something which has already been raised. I have been reading draft-mani-ietf-capwap-arch-00 (good document) and it seems to me that the architecture is missing a component. We have the APs which correspond to the aerials and the ACs which control the whole wireless network - maybe on multiple sites. I suggest that the architecture also needs to bring out the data forwarding element (DF?) as a separate item. In a large system, I would not want the AC to be forwarding all of my wireless traffic. It wouldn't scale and it means traffic unnecessarily traversing the network to the core where the ACs (probably) are. On the other hand, I would want to do some firewalling on the data flows. Having a firewall in each AP is not so hot either - they would probably all be different on each AP model and a nightmare to configure. For example, a network could be configured with the AC in (or beside) the core routers and the DF in the PoE switches attached to the AP devices. (In practise, I guess that the PoE switches would contain an optional AC and this would be switched off when the core AC is being used.) Maurice From mmani@avaya.com Thu Jan 8 22:36:33 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 8 Jan 2004 15:36:33 -0700 Subject: [Capwap] Data forwarding in the architecture Message-ID: Maurice, Thanks for the comments. Indeed this issue has been raised earlier. This draft (on architectural taxonomy) does not require data forwarding through AC. But it does intend to include description of architectural variant(s) which do(es). Since the verbiage appears not to be clear on data forwarding - we will clarify it in the next revision. Regards, -mani > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Maurice Goodfellow > Sent: Thursday, January 08, 2004 7:37 AM > To: capwap@frascone.com > Subject: [Capwap] Data forwarding in the architecture >=20 >=20 >=20 >=20 > I am fairly new to monitoring this list so my apologies if this is > something > which has already been raised. >=20 > I have been reading draft-mani-ietf-capwap-arch-00 (good document) and it > seems > to me that the > architecture is missing a component. We have the APs which correspond to > the > aerials and the ACs > which control the whole wireless network - maybe on multiple sites. I > suggest > that the architecture also > needs to bring out the data forwarding element (DF?) as a separate item. >=20 > In a large system, I would not want the AC to be forwarding all of my > wireless > traffic. It wouldn't scale > and it means traffic unnecessarily traversing the network to the core > where the > ACs (probably) are. > On the other hand, I would want to do some firewalling on the data flows. > Having a firewall in each AP > is not so hot either - they would probably all be different on each AP > model and > a nightmare to configure. >=20 > For example, a network could be configured with the AC in (or beside) the > core > routers and the DF in the > PoE switches attached to the AP devices. (In practise, I guess that the > PoE > switches would contain an > optional AC and this would be switched off when the core AC is being > used.) >=20 >=20 > Maurice >=20 From bwijnen@lucent.com Tue Jan 20 14:05:51 2004 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 20 Jan 2004 15:05:51 +0100 Subject: [Capwap] Proposed WG charter Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BB21@nl0006exch001u.nl.lucent.com> As a result of various reviews and discussions with the IEEE 802 groups (last week in Vancouver), the new proposed WG charter (to be discussed this week on IESG telechat) is as below. The changes are marked with a change bar in the left margin. IEEE will be starting a CI (Call for Interest) to start work on an architure document. That indeed belongs in IEEE. The change for us boils down to the fact that we want to be "done" with the first phase in 6 months. And the achitecture taxonomy document (Internet Draft) will then be checked and synced with ongoing work in IEEE. Depending on that IEEE review and sync-up we may decide that all of it better gets included in an IEEE based document or that we publish it (or parts of it) as an RFC. And based on that we can then decide if we want/should do more work. Thanks, Bert ------------ Status as of 20 Jan 2004: Proposed WG WG name: Control and Provisioning of Wireless Access Points (CAPWAP) Chairs: Mahalingam Mani Dorothy Gellert Operations and Management Area Director(s): Bert Wijnen David Kessens Operations and Management Area Advisor: Bert Wijnen IEEE Liaison to IETF: Dorothy Stanley (dstanley@agere.com) Technical Advisor: Bob O'Hara (bohara@airespace.com) Mailing Lists: General Discussion: capwap@frascone.com. To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap Archive: http://mail.frascone.com/pipermail/capwap/ Description: As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. Access points (APs) typically require complex management at the IP level. As the number of APs increases, the number of devices requiring complex management increases, in some cases, doubling the number of IP devices requiring management in a provider's network. In addition, because APs have no visibility beyond their own cell, a variety of problems ensue in large scale 802.11 networks. Load balancing between APs, dead cell detection, and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have introduced products that redistribute the functionality of 802.11 APs in various ways. However, because the 802.11 access network functional architecture is incompletely specified, the network interfaces between network entities in different vendors' products are defined in incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. Charter: As a first step, the CAPWAP Working Group will develop a problem statement and network architecture taxonomy describing the current set of approaches to providing more support for scalable 802.11 access networks. The problem statement will describe, at a high level, what the deployment, management, and usability concerns are with 802.11 networks based on the traditional autonomous AP architecture, and will link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture | The network architecture taxonomy document, when stable, will be | discussed with IEEE in order to validate and synchronize this work | with the work in iEEE. This may result in merging the work with | IEEE documentation in which case it may not need to be published | as an RFC. Such decision will be made in co-operation with IEEE. The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire | 6 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004: Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. | May 2004: Architecture document to expert review. | Jun 2004: Stable Architecture document for review/sync-up with IEEE | Jul 2004: Discuss results of IEEE review/sync-up | Aug 2004: Close WG or Re-charter From sgoswami@umich.edu Tue Jan 20 15:56:04 2004 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 20 Jan 2004 10:56:04 -0500 Subject: [Capwap] Proposed WG charter In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550362BB21@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550362BB21@nl0006exch001u.nl.lucent.com> Message-ID: <1074614164.400d4f94493ab@mail.umich.edu> Hi, thanks for the update. IESG called for comments on the CAPWAP charter. Have they take any action on those comments ? Would those be published ? For your information, the following was the notice sent out by IESG . http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html Subrata Quoting "Wijnen, Bert (Bert)" : > As a result of various reviews and discussions with the > IEEE 802 groups (last week in Vancouver), the new proposed > WG charter (to be discussed this week on IESG telechat) > is as below. The changes are marked with a change bar in > the left margin. > > IEEE will be starting a CI (Call for Interest) to start work > on an architure document. That indeed belongs in IEEE. > > The change for us boils down to the fact that we want to be > "done" with the first phase in 6 months. And the achitecture > taxonomy document (Internet Draft) will then be checked and > synced with ongoing work in IEEE. Depending on that IEEE review > and sync-up we may decide that all of it better gets included in > an IEEE based document or that we publish it (or parts of it) > as an RFC. And based on that we can then decide if we want/should > do more work. > > Thanks, > Bert > ------------ > > Status as of 20 Jan 2004: Proposed WG > > WG name: > > Control and Provisioning of Wireless Access Points (CAPWAP) > > Chairs: > Mahalingam Mani > Dorothy Gellert > > > Operations and Management Area Director(s): > > Bert Wijnen > David Kessens > > Operations and Management Area Advisor: > > Bert Wijnen > > IEEE Liaison to IETF: > > Dorothy Stanley (dstanley@agere.com) > > Technical Advisor: > > Bob O'Hara (bohara@airespace.com) > > Mailing Lists: > General Discussion: capwap@frascone.com. > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap > Archive: http://mail.frascone.com/pipermail/capwap/ > > Description: > > As the size and complexity of IEEE 802.11 wireless networks has > increased, problems in the deployment, management, and usability > of these networks have become evident. Access points (APs) > typically require complex management at the IP level. As the > number of APs increases, the number of devices requiring complex > management increases, in some cases, doubling the number of IP > devices requiring management in a provider's network. In addition, > because APs have no visibility beyond their own cell, a variety of > problems ensue in large scale 802.11 networks. Load balancing > between APs, dead cell detection, and correlating patterns of > usage between APs to detect attacks are difficult to impossible. > Finally, because each AP acts as its own Network Access Server > (NAS), a network provider is faced with the prospect of moving > from a situation where the NAS is a few machines with dialup > access in a machine room to a situation where hundreds or perhaps > thousands of devices scattered across a wide geographic area have > NAS functionality. Maintaining security on such a wide collection > of devices is a difficult challenge. > > In recent attempts to solve these problems, various vendors have > introduced products that redistribute the functionality of 802.11 > APs in various ways. However, because the 802.11 access network > functional architecture is incompletely specified, the network > interfaces between network entities in different vendors' > products are defined in incompatible ways. As a result, the > protocols between the network entities in different products are > not interoperable. > > Charter: > > As a first step, the CAPWAP Working Group will develop a problem > statement and network architecture taxonomy describing the > current set of approaches to providing more support for scalable > 802.11 access networks. The problem statement will describe, at > a high level, what the deployment, management, and usability > concerns are with 802.11 networks based on the traditional > autonomous AP architecture, and will link those concerns to > specific technical aspects of the autonomous AP architecture. > The network architecture taxonomy will: > > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entites in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > > Additionally, the architecture document will contain a threat > analysis that describes the security threats involved in each > network architectural approach. > > Specific Working Group deliverables are: > > - A problem statement document, > - A network architecture taxonomy document including > threat analysis. > > Specific non-goals of this work are: > - Any work requiring revising the 802.11 access network > functional architecture > > | The network architecture taxonomy document, when stable, will be > | discussed with IEEE in order to validate and synchronize this work > | with the work in iEEE. This may result in merging the work with > | IEEE documentation in which case it may not need to be published > | as an RFC. Such decision will be made in co-operation with IEEE. > > The CAPWAP WG will maintain a close working liaison with relevant > working groups in IEEE 802.11 and IEEE 802.1. Working Group > documents will be sent to an expert review board for review prior > to submission to the IESG. In order to facilitate quick > completion of this work, the Working Group charter will expire > | 6 months after it is approved by the IESG, at which time the > Working Group can either petition the IESG for a continuation > or recharter for further work on the interoperability problem. > > Goals and Milestones: > Feb 2004: Last call for problem statement draft. > Mar 2004: Discuss last call comments for problem statement > at IETF 59. > Mar 2004: Last Call for architecture description document. > Apr 2004: Submit problem statement to IESG for publication > approval. > | May 2004: Architecture document to expert review. > | Jun 2004: Stable Architecture document for review/sync-up with IEEE > | Jul 2004: Discuss results of IEEE review/sync-up > | Aug 2004: Close WG or Re-charter > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > Subrata Goswami, Ph.D. From bwijnen@lucent.com Tue Jan 20 19:39:51 2004 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 20 Jan 2004 20:39:51 +0100 Subject: [Capwap] Proposed WG charter Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BBD3@nl0006exch001u.nl.lucent.com> I (for the IESG) and I expect some others from IESG and from IAB have been following this mailing list and your comments to the IESG. As far as I can tell, the intended chairs and Technical Advisor have explained to you why we do not want to extend the charter any further than what we currently have. Hope this helps/explains Bert > -----Original Message----- > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > Sent: dinsdag 20 januari 2004 16:56 > To: Capwap (E-mail) > Subject: Re: [Capwap] Proposed WG charter > > > Hi, thanks for the update. IESG called for comments on the > CAPWAP charter. Have they take any action on those comments ? > Would those be published ? > > For your information, the following was the notice sent out > by IESG . > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > > > Subrata > > Quoting "Wijnen, Bert (Bert)" : > > > As a result of various reviews and discussions with the > > IEEE 802 groups (last week in Vancouver), the new proposed > > WG charter (to be discussed this week on IESG telechat) > > is as below. The changes are marked with a change bar in > > the left margin. > > > > IEEE will be starting a CI (Call for Interest) to start work > > on an architure document. That indeed belongs in IEEE. > > > > The change for us boils down to the fact that we want to be > > "done" with the first phase in 6 months. And the achitecture > > taxonomy document (Internet Draft) will then be checked and > > synced with ongoing work in IEEE. Depending on that IEEE review > > and sync-up we may decide that all of it better gets included in > > an IEEE based document or that we publish it (or parts of it) > > as an RFC. And based on that we can then decide if we want/should > > do more work. > > > > Thanks, > > Bert > > ------------ > > > > Status as of 20 Jan 2004: Proposed WG > > > > WG name: > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > > > > Chairs: > > Mahalingam Mani > > Dorothy Gellert > > > > > > Operations and Management Area Director(s): > > > > Bert Wijnen > > David Kessens > > > > Operations and Management Area Advisor: > > > > Bert Wijnen > > > > IEEE Liaison to IETF: > > > > Dorothy Stanley (dstanley@agere.com) > > > > Technical Advisor: > > > > Bob O'Hara (bohara@airespace.com) > > > > Mailing Lists: > > General Discussion: capwap@frascone.com. > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap > > Archive: http://mail.frascone.com/pipermail/capwap/ > > > > Description: > > > > As the size and complexity of IEEE 802.11 wireless networks has > > increased, problems in the deployment, management, and usability > > of these networks have become evident. Access points (APs) > > typically require complex management at the IP level. As the > > number of APs increases, the number of devices requiring complex > > management increases, in some cases, doubling the number of IP > > devices requiring management in a provider's network. In addition, > > because APs have no visibility beyond their own cell, a variety of > > problems ensue in large scale 802.11 networks. Load balancing > > between APs, dead cell detection, and correlating patterns of > > usage between APs to detect attacks are difficult to impossible. > > Finally, because each AP acts as its own Network Access Server > > (NAS), a network provider is faced with the prospect of moving > > from a situation where the NAS is a few machines with dialup > > access in a machine room to a situation where hundreds or perhaps > > thousands of devices scattered across a wide geographic area have > > NAS functionality. Maintaining security on such a wide collection > > of devices is a difficult challenge. > > > > In recent attempts to solve these problems, various vendors have > > introduced products that redistribute the functionality of 802.11 > > APs in various ways. However, because the 802.11 access network > > functional architecture is incompletely specified, the network > > interfaces between network entities in different vendors' > > products are defined in incompatible ways. As a result, the > > protocols between the network entities in different products are > > not interoperable. > > > > Charter: > > > > As a first step, the CAPWAP Working Group will develop a problem > > statement and network architecture taxonomy describing the > > current set of approaches to providing more support for scalable > > 802.11 access networks. The problem statement will describe, at > > a high level, what the deployment, management, and usability > > concerns are with 802.11 networks based on the traditional > > autonomous AP architecture, and will link those concerns to > > specific technical aspects of the autonomous AP architecture. > > The network architecture taxonomy will: > > > > - Describe the current set of approaches (including the > > traditional autonomous AP architecture) to partitioning > > 802.11 access network functionality between network > > entities, > > - List what the interfaces between the network entities > > are in each approach, > > - At a functional level, describe what the protocols on > > the interfaces between the network entites in each > > approach do, > > - Describe the advantages and disadvantages of each > > approach for scalable 802.11 access network deployment > > and management. > > > > Additionally, the architecture document will contain a threat > > analysis that describes the security threats involved in each > > network architectural approach. > > > > Specific Working Group deliverables are: > > > > - A problem statement document, > > - A network architecture taxonomy document including > > threat analysis. > > > > Specific non-goals of this work are: > > - Any work requiring revising the 802.11 access network > > functional architecture > > > > | The network architecture taxonomy document, when stable, will be > > | discussed with IEEE in order to validate and synchronize this work > > | with the work in iEEE. This may result in merging the work with > > | IEEE documentation in which case it may not need to be published > > | as an RFC. Such decision will be made in co-operation with IEEE. > > > > The CAPWAP WG will maintain a close working liaison with relevant > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > > documents will be sent to an expert review board for review prior > > to submission to the IESG. In order to facilitate quick > > completion of this work, the Working Group charter will expire > > | 6 months after it is approved by the IESG, at which time the > > Working Group can either petition the IESG for a continuation > > or recharter for further work on the interoperability problem. > > > > Goals and Milestones: > > Feb 2004: Last call for problem statement draft. > > Mar 2004: Discuss last call comments for problem statement > > at IETF 59. > > Mar 2004: Last Call for architecture description document. > > Apr 2004: Submit problem statement to IESG for publication > > approval. > > | May 2004: Architecture document to expert review. > > | Jun 2004: Stable Architecture document for > review/sync-up with IEEE > > | Jul 2004: Discuss results of IEEE review/sync-up > > | Aug 2004: Close WG or Re-charter > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > Subrata Goswami, Ph.D. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > From sgoswami@umich.edu Tue Jan 20 20:39:13 2004 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 20 Jan 2004 15:39:13 -0500 Subject: [Capwap] Proposed WG charter In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550362BBD3@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550362BBD3@nl0006exch001u.nl.lucent.com> Message-ID: <1074631153.400d91f1257f1@mail.umich.edu> Thanks Bert, I remember that there was some discussion last month. I guess that "explanation" should be taken as the IESG response - correct ? Subrata Quoting "Wijnen, Bert (Bert)" : > I (for the IESG) and I expect some others from IESG and from IAB > have been following this mailing list and your comments to the > IESG. As far as I can tell, the intended chairs and Technical > Advisor have explained to you why we do not want to extend > the charter any further than what we currently have. > > Hope this helps/explains > Bert > > > -----Original Message----- > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > Sent: dinsdag 20 januari 2004 16:56 > > To: Capwap (E-mail) > > Subject: Re: [Capwap] Proposed WG charter > > > > > > Hi, thanks for the update. IESG called for comments on the > > CAPWAP charter. Have they take any action on those comments ? > > Would those be published ? > > > > For your information, the following was the notice sent out > > by IESG . > > > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > > > > > > Subrata > > > > Quoting "Wijnen, Bert (Bert)" : > > > > > As a result of various reviews and discussions with the > > > IEEE 802 groups (last week in Vancouver), the new proposed > > > WG charter (to be discussed this week on IESG telechat) > > > is as below. The changes are marked with a change bar in > > > the left margin. > > > > > > IEEE will be starting a CI (Call for Interest) to start work > > > on an architure document. That indeed belongs in IEEE. > > > > > > The change for us boils down to the fact that we want to be > > > "done" with the first phase in 6 months. And the achitecture > > > taxonomy document (Internet Draft) will then be checked and > > > synced with ongoing work in IEEE. Depending on that IEEE review > > > and sync-up we may decide that all of it better gets included in > > > an IEEE based document or that we publish it (or parts of it) > > > as an RFC. And based on that we can then decide if we want/should > > > do more work. > > > > > > Thanks, > > > Bert > > > ------------ > > > > > > Status as of 20 Jan 2004: Proposed WG > > > > > > WG name: > > > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > > > > > > Chairs: > > > Mahalingam Mani > > > Dorothy Gellert > > > > > > > > > Operations and Management Area Director(s): > > > > > > Bert Wijnen > > > David Kessens > > > > > > Operations and Management Area Advisor: > > > > > > Bert Wijnen > > > > > > IEEE Liaison to IETF: > > > > > > Dorothy Stanley (dstanley@agere.com) > > > > > > Technical Advisor: > > > > > > Bob O'Hara (bohara@airespace.com) > > > > > > Mailing Lists: > > > General Discussion: capwap@frascone.com. > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap > > > Archive: http://mail.frascone.com/pipermail/capwap/ > > > > > > Description: > > > > > > As the size and complexity of IEEE 802.11 wireless networks has > > > increased, problems in the deployment, management, and usability > > > of these networks have become evident. Access points (APs) > > > typically require complex management at the IP level. As the > > > number of APs increases, the number of devices requiring complex > > > management increases, in some cases, doubling the number of IP > > > devices requiring management in a provider's network. In addition, > > > because APs have no visibility beyond their own cell, a variety of > > > problems ensue in large scale 802.11 networks. Load balancing > > > between APs, dead cell detection, and correlating patterns of > > > usage between APs to detect attacks are difficult to impossible. > > > Finally, because each AP acts as its own Network Access Server > > > (NAS), a network provider is faced with the prospect of moving > > > from a situation where the NAS is a few machines with dialup > > > access in a machine room to a situation where hundreds or perhaps > > > thousands of devices scattered across a wide geographic area have > > > NAS functionality. Maintaining security on such a wide collection > > > of devices is a difficult challenge. > > > > > > In recent attempts to solve these problems, various vendors have > > > introduced products that redistribute the functionality of 802.11 > > > APs in various ways. However, because the 802.11 access network > > > functional architecture is incompletely specified, the network > > > interfaces between network entities in different vendors' > > > products are defined in incompatible ways. As a result, the > > > protocols between the network entities in different products are > > > not interoperable. > > > > > > Charter: > > > > > > As a first step, the CAPWAP Working Group will develop a problem > > > statement and network architecture taxonomy describing the > > > current set of approaches to providing more support for scalable > > > 802.11 access networks. The problem statement will describe, at > > > a high level, what the deployment, management, and usability > > > concerns are with 802.11 networks based on the traditional > > > autonomous AP architecture, and will link those concerns to > > > specific technical aspects of the autonomous AP architecture. > > > The network architecture taxonomy will: > > > > > > - Describe the current set of approaches (including the > > > traditional autonomous AP architecture) to partitioning > > > 802.11 access network functionality between network > > > entities, > > > - List what the interfaces between the network entities > > > are in each approach, > > > - At a functional level, describe what the protocols on > > > the interfaces between the network entites in each > > > approach do, > > > - Describe the advantages and disadvantages of each > > > approach for scalable 802.11 access network deployment > > > and management. > > > > > > Additionally, the architecture document will contain a threat > > > analysis that describes the security threats involved in each > > > network architectural approach. > > > > > > Specific Working Group deliverables are: > > > > > > - A problem statement document, > > > - A network architecture taxonomy document including > > > threat analysis. > > > > > > Specific non-goals of this work are: > > > - Any work requiring revising the 802.11 access network > > > functional architecture > > > > > > | The network architecture taxonomy document, when stable, will be > > > | discussed with IEEE in order to validate and synchronize this work > > > | with the work in iEEE. This may result in merging the work with > > > | IEEE documentation in which case it may not need to be published > > > | as an RFC. Such decision will be made in co-operation with IEEE. > > > > > > The CAPWAP WG will maintain a close working liaison with relevant > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > > > documents will be sent to an expert review board for review prior > > > to submission to the IESG. In order to facilitate quick > > > completion of this work, the Working Group charter will expire > > > | 6 months after it is approved by the IESG, at which time the > > > Working Group can either petition the IESG for a continuation > > > or recharter for further work on the interoperability problem. > > > > > > Goals and Milestones: > > > Feb 2004: Last call for problem statement draft. > > > Mar 2004: Discuss last call comments for problem statement > > > at IETF 59. > > > Mar 2004: Last Call for architecture description document. > > > Apr 2004: Submit problem statement to IESG for publication > > > approval. > > > | May 2004: Architecture document to expert review. > > > | Jun 2004: Stable Architecture document for > > review/sync-up with IEEE > > > | Jul 2004: Discuss results of IEEE review/sync-up > > > | Aug 2004: Close WG or Re-charter > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > Subrata Goswami, Ph.D. > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > Subrata Goswami, Ph.D. From bwijnen@lucent.com Tue Jan 20 20:50:06 2004 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 20 Jan 2004 21:50:06 +0100 Subject: [Capwap] Proposed WG charter Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BBEE@nl0006exch001u.nl.lucent.com> Basically yes, because you do indeed not see your requested extension reflected in the charter. As I said, it will be on IESG agenda again this Thursday, so if you want to re-emphasize it to the IESG once more, then I guess now is the time. You would have to explain of course why you think the answer you have had sofar are not acceptable. Thanks, Bert > -----Original Message----- > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > Sent: dinsdag 20 januari 2004 21:39 > To: Capwap (E-mail) > Subject: RE: [Capwap] Proposed WG charter > > > Thanks Bert, I remember that there was some discussion last > month. I guess that "explanation" should be taken as the > IESG response - correct ? > > Subrata > > > > Quoting "Wijnen, Bert (Bert)" : > > > I (for the IESG) and I expect some others from IESG and from IAB > > have been following this mailing list and your comments to the > > IESG. As far as I can tell, the intended chairs and Technical > > Advisor have explained to you why we do not want to extend > > the charter any further than what we currently have. > > > > Hope this helps/explains > > Bert > > > > > -----Original Message----- > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > Sent: dinsdag 20 januari 2004 16:56 > > > To: Capwap (E-mail) > > > Subject: Re: [Capwap] Proposed WG charter > > > > > > > > > Hi, thanks for the update. IESG called for comments on the > > > CAPWAP charter. Have they take any action on those comments ? > > > Would those be published ? > > > > > > For your information, the following was the notice sent out > > > by IESG . > > > > > > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > > > > > > > > > Subrata > > > > > > Quoting "Wijnen, Bert (Bert)" : > > > > > > > As a result of various reviews and discussions with the > > > > IEEE 802 groups (last week in Vancouver), the new proposed > > > > WG charter (to be discussed this week on IESG telechat) > > > > is as below. The changes are marked with a change bar in > > > > the left margin. > > > > > > > > IEEE will be starting a CI (Call for Interest) to start work > > > > on an architure document. That indeed belongs in IEEE. > > > > > > > > The change for us boils down to the fact that we want to be > > > > "done" with the first phase in 6 months. And the achitecture > > > > taxonomy document (Internet Draft) will then be checked and > > > > synced with ongoing work in IEEE. Depending on that IEEE review > > > > and sync-up we may decide that all of it better gets included in > > > > an IEEE based document or that we publish it (or parts of it) > > > > as an RFC. And based on that we can then decide if we > want/should > > > > do more work. > > > > > > > > Thanks, > > > > Bert > > > > ------------ > > > > > > > > Status as of 20 Jan 2004: Proposed WG > > > > > > > > WG name: > > > > > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > > > > > > > > Chairs: > > > > Mahalingam Mani > > > > Dorothy Gellert > > > > > > > > > > > > Operations and Management Area Director(s): > > > > > > > > Bert Wijnen > > > > David Kessens > > > > > > > > Operations and Management Area Advisor: > > > > > > > > Bert Wijnen > > > > > > > > IEEE Liaison to IETF: > > > > > > > > Dorothy Stanley (dstanley@agere.com) > > > > > > > > Technical Advisor: > > > > > > > > Bob O'Hara (bohara@airespace.com) > > > > > > > > Mailing Lists: > > > > General Discussion: capwap@frascone.com. > > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap > > > > Archive: http://mail.frascone.com/pipermail/capwap/ > > > > > > > > Description: > > > > > > > > As the size and complexity of IEEE 802.11 wireless > networks has > > > > increased, problems in the deployment, management, > and usability > > > > of these networks have become evident. Access points (APs) > > > > typically require complex management at the IP level. As the > > > > number of APs increases, the number of devices > requiring complex > > > > management increases, in some cases, doubling the number of IP > > > > devices requiring management in a provider's network. > In addition, > > > > because APs have no visibility beyond their own cell, > a variety of > > > > problems ensue in large scale 802.11 networks. Load balancing > > > > between APs, dead cell detection, and correlating patterns of > > > > usage between APs to detect attacks are difficult to > impossible. > > > > Finally, because each AP acts as its own Network Access Server > > > > (NAS), a network provider is faced with the prospect of moving > > > > from a situation where the NAS is a few machines with dialup > > > > access in a machine room to a situation where > hundreds or perhaps > > > > thousands of devices scattered across a wide > geographic area have > > > > NAS functionality. Maintaining security on such a > wide collection > > > > of devices is a difficult challenge. > > > > > > > > In recent attempts to solve these problems, various > vendors have > > > > introduced products that redistribute the > functionality of 802.11 > > > > APs in various ways. However, because the 802.11 > access network > > > > functional architecture is incompletely specified, the network > > > > interfaces between network entities in different vendors' > > > > products are defined in incompatible ways. As a result, the > > > > protocols between the network entities in different > products are > > > > not interoperable. > > > > > > > > Charter: > > > > > > > > As a first step, the CAPWAP Working Group will > develop a problem > > > > statement and network architecture taxonomy describing the > > > > current set of approaches to providing more support > for scalable > > > > 802.11 access networks. The problem statement will > describe, at > > > > a high level, what the deployment, management, and usability > > > > concerns are with 802.11 networks based on the traditional > > > > autonomous AP architecture, and will link those concerns to > > > > specific technical aspects of the autonomous AP architecture. > > > > The network architecture taxonomy will: > > > > > > > > - Describe the current set of approaches (including the > > > > traditional autonomous AP architecture) to partitioning > > > > 802.11 access network functionality between network > > > > entities, > > > > - List what the interfaces between the network entities > > > > are in each approach, > > > > - At a functional level, describe what the protocols on > > > > the interfaces between the network entites in each > > > > approach do, > > > > - Describe the advantages and disadvantages of each > > > > approach for scalable 802.11 access network deployment > > > > and management. > > > > > > > > Additionally, the architecture document will contain a threat > > > > analysis that describes the security threats involved in each > > > > network architectural approach. > > > > > > > > Specific Working Group deliverables are: > > > > > > > > - A problem statement document, > > > > - A network architecture taxonomy document including > > > > threat analysis. > > > > > > > > Specific non-goals of this work are: > > > > - Any work requiring revising the 802.11 access network > > > > functional architecture > > > > > > > > | The network architecture taxonomy document, when > stable, will be > > > > | discussed with IEEE in order to validate and > synchronize this work > > > > | with the work in iEEE. This may result in merging the > work with > > > > | IEEE documentation in which case it may not need to > be published > > > > | as an RFC. Such decision will be made in co-operation > with IEEE. > > > > > > > > The CAPWAP WG will maintain a close working liaison > with relevant > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > > > > documents will be sent to an expert review board for > review prior > > > > to submission to the IESG. In order to facilitate quick > > > > completion of this work, the Working Group charter will expire > > > > | 6 months after it is approved by the IESG, at which time the > > > > Working Group can either petition the IESG for a continuation > > > > or recharter for further work on the interoperability problem. > > > > > > > > Goals and Milestones: > > > > Feb 2004: Last call for problem statement draft. > > > > Mar 2004: Discuss last call comments for problem statement > > > > at IETF 59. > > > > Mar 2004: Last Call for architecture description document. > > > > Apr 2004: Submit problem statement to IESG for publication > > > > approval. > > > > | May 2004: Architecture document to expert review. > > > > | Jun 2004: Stable Architecture document for > > > review/sync-up with IEEE > > > > | Jul 2004: Discuss results of IEEE review/sync-up > > > > | Aug 2004: Close WG or Re-charter > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > Subrata Goswami, Ph.D. > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > Subrata Goswami, Ph.D. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > From sgoswami@umich.edu Tue Jan 20 22:20:39 2004 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 20 Jan 2004 17:20:39 -0500 Subject: [Capwap] Proposed WG charter In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550362BBEE@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550362BBEE@nl0006exch001u.nl.lucent.com> Message-ID: <1074637239.400da9b7a9826@mail.umich.edu> Thanks Bert, I will reiterate my concerns here briefly for IESG. 1. The CAPWAP WG is too narrowly focused on .11, there a number of other less popular ( or hyped - take your pick) wireless MAN/LAN/PAN technologies which is around and would be around for a long time. 2. There are substatntial differences in the wireless MAN, LAN, and PAN technologies so that retrofitting an upper layer protocol designed exclusively for .11 would be difficult if not impossible (to say 802.15.1 or 802.15.3). For example, 802.15.1 and 802.11 both have very different security protocols. Subrata Quoting "Wijnen, Bert (Bert)" : > Basically yes, because you do indeed not see your > requested extension reflected in the charter. > > As I said, it will be on IESG agenda again this Thursday, > so if you want to re-emphasize it to the IESG once more, > then I guess now is the time. You would have to explain > of course why you think the answer you have had sofar > are not acceptable. > > Thanks, > Bert > > > -----Original Message----- > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > Sent: dinsdag 20 januari 2004 21:39 > > To: Capwap (E-mail) > > Subject: RE: [Capwap] Proposed WG charter > > > > > > Thanks Bert, I remember that there was some discussion last > > month. I guess that "explanation" should be taken as the > > IESG response - correct ? > > > > Subrata > > > > > > > > Quoting "Wijnen, Bert (Bert)" : > > > > > I (for the IESG) and I expect some others from IESG and from IAB > > > have been following this mailing list and your comments to the > > > IESG. As far as I can tell, the intended chairs and Technical > > > Advisor have explained to you why we do not want to extend > > > the charter any further than what we currently have. > > > > > > Hope this helps/explains > > > Bert > > > > > > > -----Original Message----- > > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > > Sent: dinsdag 20 januari 2004 16:56 > > > > To: Capwap (E-mail) > > > > Subject: Re: [Capwap] Proposed WG charter > > > > > > > > > > > > Hi, thanks for the update. IESG called for comments on the > > > > CAPWAP charter. Have they take any action on those comments ? > > > > Would those be published ? > > > > > > > > For your information, the following was the notice sent out > > > > by IESG . > > > > > > > > > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > > > > > > > > > > > > Subrata > > > > > > > > Quoting "Wijnen, Bert (Bert)" : > > > > > > > > > As a result of various reviews and discussions with the > > > > > IEEE 802 groups (last week in Vancouver), the new proposed > > > > > WG charter (to be discussed this week on IESG telechat) > > > > > is as below. The changes are marked with a change bar in > > > > > the left margin. > > > > > > > > > > IEEE will be starting a CI (Call for Interest) to start work > > > > > on an architure document. That indeed belongs in IEEE. > > > > > > > > > > The change for us boils down to the fact that we want to be > > > > > "done" with the first phase in 6 months. And the achitecture > > > > > taxonomy document (Internet Draft) will then be checked and > > > > > synced with ongoing work in IEEE. Depending on that IEEE review > > > > > and sync-up we may decide that all of it better gets included in > > > > > an IEEE based document or that we publish it (or parts of it) > > > > > as an RFC. And based on that we can then decide if we > > want/should > > > > > do more work. > > > > > > > > > > Thanks, > > > > > Bert > > > > > ------------ > > > > > > > > > > Status as of 20 Jan 2004: Proposed WG > > > > > > > > > > WG name: > > > > > > > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > > > > > > > > > > Chairs: > > > > > Mahalingam Mani > > > > > Dorothy Gellert > > > > > > > > > > > > > > > Operations and Management Area Director(s): > > > > > > > > > > Bert Wijnen > > > > > David Kessens > > > > > > > > > > Operations and Management Area Advisor: > > > > > > > > > > Bert Wijnen > > > > > > > > > > IEEE Liaison to IETF: > > > > > > > > > > Dorothy Stanley (dstanley@agere.com) > > > > > > > > > > Technical Advisor: > > > > > > > > > > Bob O'Hara (bohara@airespace.com) > > > > > > > > > > Mailing Lists: > > > > > General Discussion: capwap@frascone.com. > > > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap > > > > > Archive: http://mail.frascone.com/pipermail/capwap/ > > > > > > > > > > Description: > > > > > > > > > > As the size and complexity of IEEE 802.11 wireless > > networks has > > > > > increased, problems in the deployment, management, > > and usability > > > > > of these networks have become evident. Access points (APs) > > > > > typically require complex management at the IP level. As the > > > > > number of APs increases, the number of devices > > requiring complex > > > > > management increases, in some cases, doubling the number of IP > > > > > devices requiring management in a provider's network. > > In addition, > > > > > because APs have no visibility beyond their own cell, > > a variety of > > > > > problems ensue in large scale 802.11 networks. Load balancing > > > > > between APs, dead cell detection, and correlating patterns of > > > > > usage between APs to detect attacks are difficult to > > impossible. > > > > > Finally, because each AP acts as its own Network Access Server > > > > > (NAS), a network provider is faced with the prospect of moving > > > > > from a situation where the NAS is a few machines with dialup > > > > > access in a machine room to a situation where > > hundreds or perhaps > > > > > thousands of devices scattered across a wide > > geographic area have > > > > > NAS functionality. Maintaining security on such a > > wide collection > > > > > of devices is a difficult challenge. > > > > > > > > > > In recent attempts to solve these problems, various > > vendors have > > > > > introduced products that redistribute the > > functionality of 802.11 > > > > > APs in various ways. However, because the 802.11 > > access network > > > > > functional architecture is incompletely specified, the network > > > > > interfaces between network entities in different vendors' > > > > > products are defined in incompatible ways. As a result, the > > > > > protocols between the network entities in different > > products are > > > > > not interoperable. > > > > > > > > > > Charter: > > > > > > > > > > As a first step, the CAPWAP Working Group will > > develop a problem > > > > > statement and network architecture taxonomy describing the > > > > > current set of approaches to providing more support > > for scalable > > > > > 802.11 access networks. The problem statement will > > describe, at > > > > > a high level, what the deployment, management, and usability > > > > > concerns are with 802.11 networks based on the traditional > > > > > autonomous AP architecture, and will link those concerns to > > > > > specific technical aspects of the autonomous AP architecture. > > > > > The network architecture taxonomy will: > > > > > > > > > > - Describe the current set of approaches (including the > > > > > traditional autonomous AP architecture) to partitioning > > > > > 802.11 access network functionality between network > > > > > entities, > > > > > - List what the interfaces between the network entities > > > > > are in each approach, > > > > > - At a functional level, describe what the protocols on > > > > > the interfaces between the network entites in each > > > > > approach do, > > > > > - Describe the advantages and disadvantages of each > > > > > approach for scalable 802.11 access network deployment > > > > > and management. > > > > > > > > > > Additionally, the architecture document will contain a threat > > > > > analysis that describes the security threats involved in each > > > > > network architectural approach. > > > > > > > > > > Specific Working Group deliverables are: > > > > > > > > > > - A problem statement document, > > > > > - A network architecture taxonomy document including > > > > > threat analysis. > > > > > > > > > > Specific non-goals of this work are: > > > > > - Any work requiring revising the 802.11 access network > > > > > functional architecture > > > > > > > > > > | The network architecture taxonomy document, when > > stable, will be > > > > > | discussed with IEEE in order to validate and > > synchronize this work > > > > > | with the work in iEEE. This may result in merging the > > work with > > > > > | IEEE documentation in which case it may not need to > > be published > > > > > | as an RFC. Such decision will be made in co-operation > > with IEEE. > > > > > > > > > > The CAPWAP WG will maintain a close working liaison > > with relevant > > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > > > > > documents will be sent to an expert review board for > > review prior > > > > > to submission to the IESG. In order to facilitate quick > > > > > completion of this work, the Working Group charter will expire > > > > > | 6 months after it is approved by the IESG, at which time the > > > > > Working Group can either petition the IESG for a continuation > > > > > or recharter for further work on the interoperability problem. > > > > > > > > > > Goals and Milestones: > > > > > Feb 2004: Last call for problem statement draft. > > > > > Mar 2004: Discuss last call comments for problem statement > > > > > at IETF 59. > > > > > Mar 2004: Last Call for architecture description document. > > > > > Apr 2004: Submit problem statement to IESG for publication > > > > > approval. > > > > > | May 2004: Architecture document to expert review. > > > > > | Jun 2004: Stable Architecture document for > > > > review/sync-up with IEEE > > > > > | Jul 2004: Discuss results of IEEE review/sync-up > > > > > | Aug 2004: Close WG or Re-charter > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > > > > Subrata Goswami, Ph.D. > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > Subrata Goswami, Ph.D. > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > Subrata Goswami, Ph.D. From Marcus Brunner Wed Jan 21 09:23:37 2004 From: Marcus Brunner (Marcus Brunner) Date: Wed, 21 Jan 2004 10:23:37 +0100 Subject: [Capwap] Proposed WG charter In-Reply-To: <1074637239.400da9b7a9826@mail.umich.edu> References: <7D5D48D2CAA3D84C813F5B154F43B1550362BBEE@nl0006exch001u.nl.lucen t.com> <1074637239.400da9b7a9826@mail.umich.edu> Message-ID: <2063346.1074680617@[10.1.1.130]> Subrata, Lets start with one technology and get the work done. The extension towards several different technology is definitly a good idea, but this can be done later. Marcus --On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote: > Thanks Bert, I will reiterate my concerns here briefly for IESG. > > 1. The CAPWAP WG is too narrowly focused on .11, there a number of other > less popular ( or hyped - take your pick) wireless MAN/LAN/PAN > technologies which is around and would be around for a long time. > 2. There are substatntial differences in the wireless MAN, LAN, and PAN > technologies so that retrofitting an upper layer protocol designed > exclusively for .11 would be difficult if not impossible (to say > 802.15.1 or 802.15.3). > For example, 802.15.1 and 802.11 both have very different > security protocols. > > Subrata > > > Quoting "Wijnen, Bert (Bert)" : > >> Basically yes, because you do indeed not see your >> requested extension reflected in the charter. >> >> As I said, it will be on IESG agenda again this Thursday, >> so if you want to re-emphasize it to the IESG once more, >> then I guess now is the time. You would have to explain >> of course why you think the answer you have had sofar >> are not acceptable. >> >> Thanks, >> Bert >> >> > -----Original Message----- >> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > Sent: dinsdag 20 januari 2004 21:39 >> > To: Capwap (E-mail) >> > Subject: RE: [Capwap] Proposed WG charter >> > >> > >> > Thanks Bert, I remember that there was some discussion last >> > month. I guess that "explanation" should be taken as the >> > IESG response - correct ? >> > >> > Subrata >> > >> > >> > >> > Quoting "Wijnen, Bert (Bert)" : >> > >> > > I (for the IESG) and I expect some others from IESG and from IAB >> > > have been following this mailing list and your comments to the >> > > IESG. As far as I can tell, the intended chairs and Technical >> > > Advisor have explained to you why we do not want to extend >> > > the charter any further than what we currently have. >> > > >> > > Hope this helps/explains >> > > Bert >> > > >> > > > -----Original Message----- >> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > > > Sent: dinsdag 20 januari 2004 16:56 >> > > > To: Capwap (E-mail) >> > > > Subject: Re: [Capwap] Proposed WG charter >> > > > >> > > > >> > > > Hi, thanks for the update. IESG called for comments on the >> > > > CAPWAP charter. Have they take any action on those comments ? >> > > > Would those be published ? >> > > > >> > > > For your information, the following was the notice sent out >> > > > by IESG . >> > > > >> > > > >> > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html >> > > > >> > > > >> > > > Subrata >> > > > >> > > > Quoting "Wijnen, Bert (Bert)" : >> > > > >> > > > > As a result of various reviews and discussions with the >> > > > > IEEE 802 groups (last week in Vancouver), the new proposed >> > > > > WG charter (to be discussed this week on IESG telechat) >> > > > > is as below. The changes are marked with a change bar in >> > > > > the left margin. >> > > > > >> > > > > IEEE will be starting a CI (Call for Interest) to start work >> > > > > on an architure document. That indeed belongs in IEEE. >> > > > > >> > > > > The change for us boils down to the fact that we want to be >> > > > > "done" with the first phase in 6 months. And the achitecture >> > > > > taxonomy document (Internet Draft) will then be checked and >> > > > > synced with ongoing work in IEEE. Depending on that IEEE review >> > > > > and sync-up we may decide that all of it better gets included in >> > > > > an IEEE based document or that we publish it (or parts of it) >> > > > > as an RFC. And based on that we can then decide if we >> > want/should >> > > > > do more work. >> > > > > >> > > > > Thanks, >> > > > > Bert >> > > > > ------------ >> > > > > >> > > > > Status as of 20 Jan 2004: Proposed WG >> > > > > >> > > > > WG name: >> > > > > >> > > > > Control and Provisioning of Wireless Access Points (CAPWAP) >> > > > > >> > > > > Chairs: >> > > > > Mahalingam Mani >> > > > > Dorothy Gellert >> > > > > >> > > > > >> > > > > Operations and Management Area Director(s): >> > > > > >> > > > > Bert Wijnen >> > > > > David Kessens >> > > > > >> > > > > Operations and Management Area Advisor: >> > > > > >> > > > > Bert Wijnen >> > > > > >> > > > > IEEE Liaison to IETF: >> > > > > >> > > > > Dorothy Stanley (dstanley@agere.com) >> > > > > >> > > > > Technical Advisor: >> > > > > >> > > > > Bob O'Hara (bohara@airespace.com) >> > > > > >> > > > > Mailing Lists: >> > > > > General Discussion: capwap@frascone.com. >> > > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap >> > > > > Archive: http://mail.frascone.com/pipermail/capwap/ >> > > > > >> > > > > Description: >> > > > > >> > > > > As the size and complexity of IEEE 802.11 wireless >> > networks has >> > > > > increased, problems in the deployment, management, >> > and usability >> > > > > of these networks have become evident. Access points (APs) >> > > > > typically require complex management at the IP level. As the >> > > > > number of APs increases, the number of devices >> > requiring complex >> > > > > management increases, in some cases, doubling the number of IP >> > > > > devices requiring management in a provider's network. >> > In addition, >> > > > > because APs have no visibility beyond their own cell, >> > a variety of >> > > > > problems ensue in large scale 802.11 networks. Load balancing >> > > > > between APs, dead cell detection, and correlating patterns of >> > > > > usage between APs to detect attacks are difficult to >> > impossible. >> > > > > Finally, because each AP acts as its own Network Access Server >> > > > > (NAS), a network provider is faced with the prospect of moving >> > > > > from a situation where the NAS is a few machines with dialup >> > > > > access in a machine room to a situation where >> > hundreds or perhaps >> > > > > thousands of devices scattered across a wide >> > geographic area have >> > > > > NAS functionality. Maintaining security on such a >> > wide collection >> > > > > of devices is a difficult challenge. >> > > > > >> > > > > In recent attempts to solve these problems, various >> > vendors have >> > > > > introduced products that redistribute the >> > functionality of 802.11 >> > > > > APs in various ways. However, because the 802.11 >> > access network >> > > > > functional architecture is incompletely specified, the network >> > > > > interfaces between network entities in different vendors' >> > > > > products are defined in incompatible ways. As a result, the >> > > > > protocols between the network entities in different >> > products are >> > > > > not interoperable. >> > > > > >> > > > > Charter: >> > > > > >> > > > > As a first step, the CAPWAP Working Group will >> > develop a problem >> > > > > statement and network architecture taxonomy describing the >> > > > > current set of approaches to providing more support >> > for scalable >> > > > > 802.11 access networks. The problem statement will >> > describe, at >> > > > > a high level, what the deployment, management, and usability >> > > > > concerns are with 802.11 networks based on the traditional >> > > > > autonomous AP architecture, and will link those concerns to >> > > > > specific technical aspects of the autonomous AP architecture. >> > > > > The network architecture taxonomy will: >> > > > > >> > > > > - Describe the current set of approaches (including the >> > > > > traditional autonomous AP architecture) to partitioning >> > > > > 802.11 access network functionality between network >> > > > > entities, >> > > > > - List what the interfaces between the network entities >> > > > > are in each approach, >> > > > > - At a functional level, describe what the protocols on >> > > > > the interfaces between the network entites in each >> > > > > approach do, >> > > > > - Describe the advantages and disadvantages of each >> > > > > approach for scalable 802.11 access network deployment >> > > > > and management. >> > > > > >> > > > > Additionally, the architecture document will contain a threat >> > > > > analysis that describes the security threats involved in each >> > > > > network architectural approach. >> > > > > >> > > > > Specific Working Group deliverables are: >> > > > > >> > > > > - A problem statement document, >> > > > > - A network architecture taxonomy document including >> > > > > threat analysis. >> > > > > >> > > > > Specific non-goals of this work are: >> > > > > - Any work requiring revising the 802.11 access network >> > > > > functional architecture >> > > > > >> > > > > | The network architecture taxonomy document, when >> > stable, will be >> > > > > | discussed with IEEE in order to validate and >> > synchronize this work >> > > > > | with the work in iEEE. This may result in merging the >> > work with >> > > > > | IEEE documentation in which case it may not need to >> > be published >> > > > > | as an RFC. Such decision will be made in co-operation >> > with IEEE. >> > > > > >> > > > > The CAPWAP WG will maintain a close working liaison >> > with relevant >> > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group >> > > > > documents will be sent to an expert review board for >> > review prior >> > > > > to submission to the IESG. In order to facilitate quick >> > > > > completion of this work, the Working Group charter will expire >> > > > > | 6 months after it is approved by the IESG, at which time the >> > > > > Working Group can either petition the IESG for a continuation >> > > > > or recharter for further work on the interoperability problem. >> > > > > >> > > > > Goals and Milestones: >> > > > > Feb 2004: Last call for problem statement draft. >> > > > > Mar 2004: Discuss last call comments for problem statement >> > > > > at IETF 59. >> > > > > Mar 2004: Last Call for architecture description document. >> > > > > Apr 2004: Submit problem statement to IESG for publication >> > > > > approval. >> > > > > | May 2004: Architecture document to expert review. >> > > > > | Jun 2004: Stable Architecture document for >> > > > review/sync-up with IEEE >> > > > > | Jul 2004: Discuss results of IEEE review/sync-up >> > > > > | Aug 2004: Close WG or Re-charter >> > > > > _______________________________________________ >> > > > > Capwap mailing list >> > > > > Capwap@frascone.com >> > > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > > >> > > > >> > > > >> > > > Subrata Goswami, Ph.D. >> > > > _______________________________________________ >> > > > Capwap mailing list >> > > > Capwap@frascone.com >> > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > >> > > _______________________________________________ >> > > Capwap mailing list >> > > Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > > >> > >> > >> > Subrata Goswami, Ph.D. >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap >> > >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > > > Subrata Goswami, Ph.D. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From lily.l.yang@intel.com Wed Jan 21 15:20:11 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 21 Jan 2004 07:20:11 -0800 Subject: [Capwap] Proposed WG charter Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB13E@orsmsx410.jf.intel.com> But in order to make the future extension possible and successful, it is also important to state that up front so that the work is done in an extensible way. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Marcus Brunner Sent: Wednesday, January 21, 2004 1:24 AM To: sgoswami@umich.edu Cc: Capwap (E-mail) Subject: RE: [Capwap] Proposed WG charter Subrata, Lets start with one technology and get the work done. The extension towards=20 several different technology is definitly a good idea, but this can be done=20 later. Marcus --On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote: > Thanks Bert, I will reiterate my concerns here briefly for IESG. > > 1. The CAPWAP WG is too narrowly focused on .11, there a number of other > less popular ( or hyped - take your pick) wireless MAN/LAN/PAN > technologies which is around and would be around for a long time. > 2. There are substatntial differences in the wireless MAN, LAN, and PAN > technologies so that retrofitting an upper layer protocol designed > exclusively for .11 would be difficult if not impossible (to say > 802.15.1 or 802.15.3). > For example, 802.15.1 and 802.11 both have very different > security protocols. > > Subrata > > > Quoting "Wijnen, Bert (Bert)" : > >> Basically yes, because you do indeed not see your >> requested extension reflected in the charter. >> >> As I said, it will be on IESG agenda again this Thursday, >> so if you want to re-emphasize it to the IESG once more, >> then I guess now is the time. You would have to explain >> of course why you think the answer you have had sofar >> are not acceptable. >> >> Thanks, >> Bert >> >> > -----Original Message----- >> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > Sent: dinsdag 20 januari 2004 21:39 >> > To: Capwap (E-mail) >> > Subject: RE: [Capwap] Proposed WG charter >> > >> > >> > Thanks Bert, I remember that there was some discussion last >> > month. I guess that "explanation" should be taken as the >> > IESG response - correct ? >> > >> > Subrata >> > >> > >> > >> > Quoting "Wijnen, Bert (Bert)" : >> > >> > > I (for the IESG) and I expect some others from IESG and from IAB >> > > have been following this mailing list and your comments to the >> > > IESG. As far as I can tell, the intended chairs and Technical >> > > Advisor have explained to you why we do not want to extend >> > > the charter any further than what we currently have. >> > > >> > > Hope this helps/explains >> > > Bert >> > > >> > > > -----Original Message----- >> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > > > Sent: dinsdag 20 januari 2004 16:56 >> > > > To: Capwap (E-mail) >> > > > Subject: Re: [Capwap] Proposed WG charter >> > > > >> > > > >> > > > Hi, thanks for the update. IESG called for comments on the >> > > > CAPWAP charter. Have they take any action on those comments ? >> > > > Would those be published ? >> > > > >> > > > For your information, the following was the notice sent out >> > > > by IESG . >> > > > >> > > > >> > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html >> > > > >> > > > >> > > > Subrata >> > > > >> > > > Quoting "Wijnen, Bert (Bert)" : >> > > > >> > > > > As a result of various reviews and discussions with the >> > > > > IEEE 802 groups (last week in Vancouver), the new proposed >> > > > > WG charter (to be discussed this week on IESG telechat) >> > > > > is as below. The changes are marked with a change bar in >> > > > > the left margin. >> > > > > >> > > > > IEEE will be starting a CI (Call for Interest) to start work >> > > > > on an architure document. That indeed belongs in IEEE. >> > > > > >> > > > > The change for us boils down to the fact that we want to be >> > > > > "done" with the first phase in 6 months. And the achitecture >> > > > > taxonomy document (Internet Draft) will then be checked and >> > > > > synced with ongoing work in IEEE. Depending on that IEEE review >> > > > > and sync-up we may decide that all of it better gets included in >> > > > > an IEEE based document or that we publish it (or parts of it) >> > > > > as an RFC. And based on that we can then decide if we >> > want/should >> > > > > do more work. >> > > > > >> > > > > Thanks, >> > > > > Bert >> > > > > ------------ >> > > > > >> > > > > Status as of 20 Jan 2004: Proposed WG >> > > > > >> > > > > WG name: >> > > > > >> > > > > Control and Provisioning of Wireless Access Points (CAPWAP) >> > > > > >> > > > > Chairs: >> > > > > Mahalingam Mani >> > > > > Dorothy Gellert >> > > > > >> > > > > >> > > > > Operations and Management Area Director(s): >> > > > > >> > > > > Bert Wijnen >> > > > > David Kessens >> > > > > >> > > > > Operations and Management Area Advisor: >> > > > > >> > > > > Bert Wijnen >> > > > > >> > > > > IEEE Liaison to IETF: >> > > > > >> > > > > Dorothy Stanley (dstanley@agere.com) >> > > > > >> > > > > Technical Advisor: >> > > > > >> > > > > Bob O'Hara (bohara@airespace.com) >> > > > > >> > > > > Mailing Lists: >> > > > > General Discussion: capwap@frascone.com. >> > > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap >> > > > > Archive: http://mail.frascone.com/pipermail/capwap/ >> > > > > >> > > > > Description: >> > > > > >> > > > > As the size and complexity of IEEE 802.11 wireless >> > networks has >> > > > > increased, problems in the deployment, management, >> > and usability >> > > > > of these networks have become evident. Access points (APs) >> > > > > typically require complex management at the IP level. As the >> > > > > number of APs increases, the number of devices >> > requiring complex >> > > > > management increases, in some cases, doubling the number of IP >> > > > > devices requiring management in a provider's network. >> > In addition, >> > > > > because APs have no visibility beyond their own cell, >> > a variety of >> > > > > problems ensue in large scale 802.11 networks. Load balancing >> > > > > between APs, dead cell detection, and correlating patterns of >> > > > > usage between APs to detect attacks are difficult to >> > impossible. >> > > > > Finally, because each AP acts as its own Network Access Server >> > > > > (NAS), a network provider is faced with the prospect of moving >> > > > > from a situation where the NAS is a few machines with dialup >> > > > > access in a machine room to a situation where >> > hundreds or perhaps >> > > > > thousands of devices scattered across a wide >> > geographic area have >> > > > > NAS functionality. Maintaining security on such a >> > wide collection >> > > > > of devices is a difficult challenge. >> > > > > >> > > > > In recent attempts to solve these problems, various >> > vendors have >> > > > > introduced products that redistribute the >> > functionality of 802.11 >> > > > > APs in various ways. However, because the 802.11 >> > access network >> > > > > functional architecture is incompletely specified, the network >> > > > > interfaces between network entities in different vendors' >> > > > > products are defined in incompatible ways. As a result, the >> > > > > protocols between the network entities in different >> > products are >> > > > > not interoperable. >> > > > > >> > > > > Charter: >> > > > > >> > > > > As a first step, the CAPWAP Working Group will >> > develop a problem >> > > > > statement and network architecture taxonomy describing the >> > > > > current set of approaches to providing more support >> > for scalable >> > > > > 802.11 access networks. The problem statement will >> > describe, at >> > > > > a high level, what the deployment, management, and usability >> > > > > concerns are with 802.11 networks based on the traditional >> > > > > autonomous AP architecture, and will link those concerns to >> > > > > specific technical aspects of the autonomous AP architecture. >> > > > > The network architecture taxonomy will: >> > > > > >> > > > > - Describe the current set of approaches (including the >> > > > > traditional autonomous AP architecture) to partitioning >> > > > > 802.11 access network functionality between network >> > > > > entities, >> > > > > - List what the interfaces between the network entities >> > > > > are in each approach, >> > > > > - At a functional level, describe what the protocols on >> > > > > the interfaces between the network entites in each >> > > > > approach do, >> > > > > - Describe the advantages and disadvantages of each >> > > > > approach for scalable 802.11 access network deployment >> > > > > and management. >> > > > > >> > > > > Additionally, the architecture document will contain a threat >> > > > > analysis that describes the security threats involved in each >> > > > > network architectural approach. >> > > > > >> > > > > Specific Working Group deliverables are: >> > > > > >> > > > > - A problem statement document, >> > > > > - A network architecture taxonomy document including >> > > > > threat analysis. >> > > > > >> > > > > Specific non-goals of this work are: >> > > > > - Any work requiring revising the 802.11 access network >> > > > > functional architecture >> > > > > >> > > > > | The network architecture taxonomy document, when >> > stable, will be >> > > > > | discussed with IEEE in order to validate and >> > synchronize this work >> > > > > | with the work in iEEE. This may result in merging the >> > work with >> > > > > | IEEE documentation in which case it may not need to >> > be published >> > > > > | as an RFC. Such decision will be made in co-operation >> > with IEEE. >> > > > > >> > > > > The CAPWAP WG will maintain a close working liaison >> > with relevant >> > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group >> > > > > documents will be sent to an expert review board for >> > review prior >> > > > > to submission to the IESG. In order to facilitate quick >> > > > > completion of this work, the Working Group charter will expire >> > > > > | 6 months after it is approved by the IESG, at which time the >> > > > > Working Group can either petition the IESG for a continuation >> > > > > or recharter for further work on the interoperability problem. >> > > > > >> > > > > Goals and Milestones: >> > > > > Feb 2004: Last call for problem statement draft. >> > > > > Mar 2004: Discuss last call comments for problem statement >> > > > > at IETF 59. >> > > > > Mar 2004: Last Call for architecture description document. >> > > > > Apr 2004: Submit problem statement to IESG for publication >> > > > > approval. >> > > > > | May 2004: Architecture document to expert review. >> > > > > | Jun 2004: Stable Architecture document for >> > > > review/sync-up with IEEE >> > > > > | Jul 2004: Discuss results of IEEE review/sync-up >> > > > > | Aug 2004: Close WG or Re-charter >> > > > > _______________________________________________ >> > > > > Capwap mailing list >> > > > > Capwap@frascone.com >> > > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > > >> > > > >> > > > >> > > > Subrata Goswami, Ph.D. >> > > > _______________________________________________ >> > > > Capwap mailing list >> > > > Capwap@frascone.com >> > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > >> > > _______________________________________________ >> > > Capwap mailing list >> > > Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > > >> > >> > >> > Subrata Goswami, Ph.D. >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap >> > >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > > > Subrata Goswami, Ph.D. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From pcalhoun@airespace.com Wed Jan 21 15:56:22 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 21 Jan 2004 07:56:22 -0800 Subject: [Capwap] Proposed WG charter Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC64F@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E037.375C901B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You can't potentially even start to envision all future=20 technologies at this time. Doing so will be a huge distraction from the current WG. I say we move with the current proposed charter as is. PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Wed 1/21/2004 7:20 AM To: Marcus Brunner; sgoswami@umich.edu Cc: Capwap (E-mail) Subject: RE: [Capwap] Proposed WG charter =20 But in order to make the future extension possible and successful, it is also important to state that up front so that the work is done in an extensible way. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Marcus Brunner Sent: Wednesday, January 21, 2004 1:24 AM To: sgoswami@umich.edu Cc: Capwap (E-mail) Subject: RE: [Capwap] Proposed WG charter Subrata, Lets start with one technology and get the work done. The extension towards=20 several different technology is definitly a good idea, but this can be done=20 later. Marcus --On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote: > Thanks Bert, I will reiterate my concerns here briefly for IESG. > > 1. The CAPWAP WG is too narrowly focused on .11, there a number of other > less popular ( or hyped - take your pick) wireless MAN/LAN/PAN > technologies which is around and would be around for a long time. > 2. There are substatntial differences in the wireless MAN, LAN, and PAN > technologies so that retrofitting an upper layer protocol designed > exclusively for .11 would be difficult if not impossible (to say > 802.15.1 or 802.15.3). > For example, 802.15.1 and 802.11 both have very different > security protocols. > > Subrata > > > Quoting "Wijnen, Bert (Bert)" : > >> Basically yes, because you do indeed not see your >> requested extension reflected in the charter. >> >> As I said, it will be on IESG agenda again this Thursday, >> so if you want to re-emphasize it to the IESG once more, >> then I guess now is the time. You would have to explain >> of course why you think the answer you have had sofar >> are not acceptable. >> >> Thanks, >> Bert >> >> > -----Original Message----- >> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > Sent: dinsdag 20 januari 2004 21:39 >> > To: Capwap (E-mail) >> > Subject: RE: [Capwap] Proposed WG charter >> > >> > >> > Thanks Bert, I remember that there was some discussion last >> > month. I guess that "explanation" should be taken as the >> > IESG response - correct ? >> > >> > Subrata >> > >> > >> > >> > Quoting "Wijnen, Bert (Bert)" : >> > >> > > I (for the IESG) and I expect some others from IESG and from IAB >> > > have been following this mailing list and your comments to the >> > > IESG. As far as I can tell, the intended chairs and Technical >> > > Advisor have explained to you why we do not want to extend >> > > the charter any further than what we currently have. >> > > >> > > Hope this helps/explains >> > > Bert >> > > >> > > > -----Original Message----- >> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] >> > > > Sent: dinsdag 20 januari 2004 16:56 >> > > > To: Capwap (E-mail) >> > > > Subject: Re: [Capwap] Proposed WG charter >> > > > >> > > > >> > > > Hi, thanks for the update. IESG called for comments on the >> > > > CAPWAP charter. Have they take any action on those comments ? >> > > > Would those be published ? >> > > > >> > > > For your information, the following was the notice sent out >> > > > by IESG . >> > > > >> > > > >> > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html >> > > > >> > > > >> > > > Subrata >> > > > >> > > > Quoting "Wijnen, Bert (Bert)" : >> > > > >> > > > > As a result of various reviews and discussions with the >> > > > > IEEE 802 groups (last week in Vancouver), the new proposed >> > > > > WG charter (to be discussed this week on IESG telechat) >> > > > > is as below. The changes are marked with a change bar in >> > > > > the left margin. >> > > > > >> > > > > IEEE will be starting a CI (Call for Interest) to start work >> > > > > on an architure document. That indeed belongs in IEEE. >> > > > > >> > > > > The change for us boils down to the fact that we want to be >> > > > > "done" with the first phase in 6 months. And the achitecture >> > > > > taxonomy document (Internet Draft) will then be checked and >> > > > > synced with ongoing work in IEEE. Depending on that IEEE review >> > > > > and sync-up we may decide that all of it better gets included in >> > > > > an IEEE based document or that we publish it (or parts of it) >> > > > > as an RFC. And based on that we can then decide if we >> > want/should >> > > > > do more work. >> > > > > >> > > > > Thanks, >> > > > > Bert >> > > > > ------------ >> > > > > >> > > > > Status as of 20 Jan 2004: Proposed WG >> > > > > >> > > > > WG name: >> > > > > >> > > > > Control and Provisioning of Wireless Access Points (CAPWAP) >> > > > > >> > > > > Chairs: >> > > > > Mahalingam Mani >> > > > > Dorothy Gellert >> > > > > >> > > > > >> > > > > Operations and Management Area Director(s): >> > > > > >> > > > > Bert Wijnen >> > > > > David Kessens >> > > > > >> > > > > Operations and Management Area Advisor: >> > > > > >> > > > > Bert Wijnen >> > > > > >> > > > > IEEE Liaison to IETF: >> > > > > >> > > > > Dorothy Stanley (dstanley@agere.com) >> > > > > >> > > > > Technical Advisor: >> > > > > >> > > > > Bob O'Hara (bohara@airespace.com) >> > > > > >> > > > > Mailing Lists: >> > > > > General Discussion: capwap@frascone.com. >> > > > > To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap >> > > > > Archive: http://mail.frascone.com/pipermail/capwap/ >> > > > > >> > > > > Description: >> > > > > >> > > > > As the size and complexity of IEEE 802.11 wireless >> > networks has >> > > > > increased, problems in the deployment, management, >> > and usability >> > > > > of these networks have become evident. Access points (APs) >> > > > > typically require complex management at the IP level. As the >> > > > > number of APs increases, the number of devices >> > requiring complex >> > > > > management increases, in some cases, doubling the number of IP >> > > > > devices requiring management in a provider's network. >> > In addition, >> > > > > because APs have no visibility beyond their own cell, >> > a variety of >> > > > > problems ensue in large scale 802.11 networks. Load balancing >> > > > > between APs, dead cell detection, and correlating patterns of >> > > > > usage between APs to detect attacks are difficult to >> > impossible. >> > > > > Finally, because each AP acts as its own Network Access Server >> > > > > (NAS), a network provider is faced with the prospect of moving >> > > > > from a situation where the NAS is a few machines with dialup >> > > > > access in a machine room to a situation where >> > hundreds or perhaps >> > > > > thousands of devices scattered across a wide >> > geographic area have >> > > > > NAS functionality. Maintaining security on such a >> > wide collection >> > > > > of devices is a difficult challenge. >> > > > > >> > > > > In recent attempts to solve these problems, various >> > vendors have >> > > > > introduced products that redistribute the >> > functionality of 802.11 >> > > > > APs in various ways. However, because the 802.11 >> > access network >> > > > > functional architecture is incompletely specified, the network >> > > > > interfaces between network entities in different vendors' >> > > > > products are defined in incompatible ways. As a result, the >> > > > > protocols between the network entities in different >> > products are >> > > > > not interoperable. >> > > > > >> > > > > Charter: >> > > > > >> > > > > As a first step, the CAPWAP Working Group will >> > develop a problem >> > > > > statement and network architecture taxonomy describing the >> > > > > current set of approaches to providing more support >> > for scalable >> > > > > 802.11 access networks. The problem statement will >> > describe, at >> > > > > a high level, what the deployment, management, and usability >> > > > > concerns are with 802.11 networks based on the traditional >> > > > > autonomous AP architecture, and will link those concerns to >> > > > > specific technical aspects of the autonomous AP architecture. >> > > > > The network architecture taxonomy will: >> > > > > >> > > > > - Describe the current set of approaches (including the >> > > > > traditional autonomous AP architecture) to partitioning >> > > > > 802.11 access network functionality between network >> > > > > entities, >> > > > > - List what the interfaces between the network entities >> > > > > are in each approach, >> > > > > - At a functional level, describe what the protocols on >> > > > > the interfaces between the network entites in each >> > > > > approach do, >> > > > > - Describe the advantages and disadvantages of each >> > > > > approach for scalable 802.11 access network deployment >> > > > > and management. >> > > > > >> > > > > Additionally, the architecture document will contain a threat >> > > > > analysis that describes the security threats involved in each >> > > > > network architectural approach. >> > > > > >> > > > > Specific Working Group deliverables are: >> > > > > >> > > > > - A problem statement document, >> > > > > - A network architecture taxonomy document including >> > > > > threat analysis. >> > > > > >> > > > > Specific non-goals of this work are: >> > > > > - Any work requiring revising the 802.11 access network >> > > > > functional architecture >> > > > > >> > > > > | The network architecture taxonomy document, when >> > stable, will be >> > > > > | discussed with IEEE in order to validate and >> > synchronize this work >> > > > > | with the work in iEEE. This may result in merging the >> > work with >> > > > > | IEEE documentation in which case it may not need to >> > be published >> > > > > | as an RFC. Such decision will be made in co-operation >> > with IEEE. >> > > > > >> > > > > The CAPWAP WG will maintain a close working liaison >> > with relevant >> > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group >> > > > > documents will be sent to an expert review board for >> > review prior >> > > > > to submission to the IESG. In order to facilitate quick >> > > > > completion of this work, the Working Group charter will expire >> > > > > | 6 months after it is approved by the IESG, at which time the >> > > > > Working Group can either petition the IESG for a continuation >> > > > > or recharter for further work on the interoperability problem. >> > > > > >> > > > > Goals and Milestones: >> > > > > Feb 2004: Last call for problem statement draft. >> > > > > Mar 2004: Discuss last call comments for problem statement >> > > > > at IETF 59. >> > > > > Mar 2004: Last Call for architecture description document. >> > > > > Apr 2004: Submit problem statement to IESG for publication >> > > > > approval. >> > > > > | May 2004: Architecture document to expert review. >> > > > > | Jun 2004: Stable Architecture document for >> > > > review/sync-up with IEEE >> > > > > | Jul 2004: Discuss results of IEEE review/sync-up >> > > > > | Aug 2004: Close WG or Re-charter >> > > > > _______________________________________________ >> > > > > Capwap mailing list >> > > > > Capwap@frascone.com >> > > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > > >> > > > >> > > > >> > > > Subrata Goswami, Ph.D. >> > > > _______________________________________________ >> > > > Capwap mailing list >> > > > Capwap@frascone.com >> > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > >> > > _______________________________________________ >> > > Capwap mailing list >> > > Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > > >> > >> > >> > Subrata Goswami, Ph.D. >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap >> > >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > > > Subrata Goswami, Ph.D. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E037.375C901B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Proposed WG charter

You can't potentially even start to envision all = future
technologies at this time. Doing so will be a huge distraction
from the current WG.

I say we move with the current proposed charter as is.

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Yang, Lily L
Sent: Wed 1/21/2004 7:20 AM
To: Marcus Brunner; sgoswami@umich.edu
Cc: Capwap (E-mail)
Subject: RE: [Capwap] Proposed WG charter

But in order to make the future extension possible and successful, it = is
also important to state that up front so that the work is done in an
extensible way.

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of Marcus Brunner
Sent: Wednesday, January 21, 2004 1:24 AM
To: sgoswami@umich.edu
Cc: Capwap (E-mail)
Subject: RE: [Capwap] Proposed WG charter

Subrata,

Lets start with one technology and get the work done. The extension
towards
several different technology is definitly a good idea, but this can = be
done
later.

Marcus

--On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote:

> Thanks Bert, I will reiterate my concerns here briefly for = IESG.
>
> 1. The CAPWAP WG is too narrowly focused on .11, there a number = of
other
>    less popular ( or hyped - take your pick) = wireless MAN/LAN/PAN
>    technologies which is around and would be around = for a long time.
> 2. There are substatntial differences in the wireless MAN, LAN, = and
PAN
>    technologies so that retrofitting an upper layer = protocol designed
>    exclusively for .11 would be difficult if not = impossible (to say
>    802.15.1 or 802.15.3).
>    For example,  802.15.1 and 802.11 both have = very different
>    security protocols.
>
> Subrata
>
>
> Quoting "Wijnen, Bert (Bert)" = <bwijnen@lucent.com>:
>
>> Basically yes, because you do indeed not see your
>> requested extension reflected in the charter.
>>
>> As I said, it will be on IESG agenda again this Thursday,
>> so if you want to re-emphasize it to the IESG once more,
>> then I guess now is the time. You would have to explain
>> of course why you think the answer you have had sofar
>> are not acceptable.
>>
>> Thanks,
>> Bert
>>
>> > -----Original Message-----
>> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu]
>> > Sent: dinsdag 20 januari 2004 21:39
>> > To: Capwap (E-mail)
>> > Subject: RE: [Capwap] Proposed WG charter
>> >
>> >
>> > Thanks Bert, I remember that there was some discussion = last
>> > month.  I guess that "explanation" should = be taken as the
>> > IESG response - correct ?
>> >
>> > Subrata
>> >
>> >
>> >
>> > Quoting "Wijnen, Bert (Bert)" = <bwijnen@lucent.com>:
>> >
>> > > I (for the IESG) and I expect some others from IESG = and from IAB
>> > > have been following this mailing list and your = comments to the
>> > > IESG. As far as I can tell, the intended chairs and = Technical
>> > > Advisor have explained to you why we do not want to = extend
>> > > the charter any further than what we currently = have.
>> > >
>> > > Hope this helps/explains
>> > > Bert
>> > >
>> > > > -----Original Message-----
>> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu]
>> > > > Sent: dinsdag 20 januari 2004 16:56
>> > > > To: Capwap (E-mail)
>> > > > Subject: Re: [Capwap] Proposed WG charter
>> > > >
>> > > >
>> > > > Hi, thanks for the update. IESG called for = comments on the
>> > > > CAPWAP charter. Have they take any action on = those comments ?
>> > > > Would those be published ?
>> > > >
>> > > > For your information, the following was the = notice sent out
>> > > > by IESG .
>> > > >
>> > > >
>> >
http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.ht= ml
>> > > >
>> > > >
>> > > > Subrata
>> > > >
>> > > > Quoting "Wijnen, Bert (Bert)" = <bwijnen@lucent.com>:
>> > > >
>> > > > > As a result of various reviews and = discussions with the
>> > > > > IEEE 802 groups (last week in Vancouver), = the new proposed
>> > > > > WG charter (to be discussed this week on = IESG telechat)
>> > > > > is as below. The changes are marked with a = change bar in
>> > > > > the left margin.
>> > > > >
>> > > > > IEEE will be starting a CI (Call for = Interest) to start work
>> > > > > on an architure document. That indeed = belongs in IEEE.
>> > > > >
>> > > > > The change for us boils down to the fact = that we want to be
>> > > > > "done" with the first phase in 6 = months. And the achitecture
>> > > > > taxonomy document (Internet Draft) will = then be checked and
>> > > > > synced with ongoing work in IEEE. Depending = on that IEEE
review
>> > > > > and sync-up we may decide that all of it = better gets included
in
>> > > > > an IEEE based document or that we publish = it (or parts of it)
>> > > > > as an RFC. And based on that we can then = decide if we
>> > want/should
>> > > > > do more work.
>> > > > >
>> > > > > Thanks,
>> > > > > Bert
>> > > > > ------------
>> > > > >
>> > > > > Status as of 20 Jan 2004:  Proposed = WG
>> > > > >
>> > > > > WG name:
>> > > > >
>> > > > >   Control and Provisioning of = Wireless Access Points (CAPWAP)
>> > > > >
>> > > > > Chairs:
>> > > > >   Mahalingam Mani = <mmani@avaya.com>
>> > > > >   Dorothy Gellert = <dorothy.gellert@nokia.com>
>> > > > >
>> > > > >
>> > > > > Operations and Management Area = Director(s):
>> > > > >
>> > > > >   Bert Wijnen = <bwijnen@lucent.com>
>> > > > >   David Kessens = <david.kessens@nokia.com>
>> > > > >
>> > > > > Operations and Management Area Advisor:
>> > > > >
>> > > > >   Bert Wijnen = <bwijnen@lucent.com>
>> > > > >
>> > > > > IEEE Liaison to IETF:
>> > > > >
>> > > > >   Dorothy Stanley = (dstanley@agere.com)
>> > > > >
>> > > > > Technical Advisor:
>> > > > >
>> > > > >   Bob O'Hara = (bohara@airespace.com)
>> > > > >
>> > > > > Mailing Lists:
>> > > > >   General Discussion: = capwap@frascone.com.
>> > > > >   To Subscribe:
http://mail.fra= scone.com/mailman/listinfo/capwap
>> > > > >   Archive: http://mail.frascone.= com/pipermail/capwap/
>> > > > >
>> > > > > Description:
>> > > > >
>> > > > >   As the size and complexity of = IEEE 802.11 wireless
>> > networks has
>> > > > >   increased, problems in the = deployment, management,
>> > and usability
>> > > > >   of these networks have become = evident. Access points (APs)
>> > > > >   typically require complex = management at the IP level. As
the
>> > > > >   number of APs increases, the = number of devices
>> > requiring complex
>> > > > >   management increases, in some = cases, doubling the number of
IP
>> > > > >   devices requiring management in = a provider's network.
>> > In addition,
>> > > > >   because APs have no visibility = beyond their own cell,
>> > a variety of
>> > > > >   problems ensue in large scale = 802.11 networks. Load
balancing
>> > > > >   between APs, dead cell = detection, and correlating patterns
of
>> > > > >   usage between APs to detect = attacks are difficult to
>> > impossible.
>> > > > >   Finally, because each AP acts = as its own Network Access
Server
>> > > > >   (NAS), a network provider is = faced with the prospect of
moving
>> > > > >   from a situation where the NAS = is a few machines with
dialup
>> > > > >   access in a machine room to a = situation where
>> > hundreds or perhaps
>> > > > >   thousands of devices scattered = across a wide
>> > geographic area have
>> > > > >   NAS functionality. Maintaining = security on such a
>> > wide collection
>> > > > >   of devices is a difficult = challenge.
>> > > > >
>> > > > >   In recent attempts to solve = these problems, various
>> > vendors have
>> > > > >   introduced products that = redistribute the
>> > functionality of 802.11
>> > > > >   APs in various ways. However, = because the 802.11
>> > access network
>> > > > >   functional architecture is = incompletely specified, the
network
>> > > > >   interfaces between network = entities in different vendors'
>> > > > >   products are defined in = incompatible ways. As a result, the
>> > > > >   protocols between the network = entities in different
>> > products are
>> > > > >   not interoperable.
>> > > > >
>> > > > > Charter:
>> > > > >
>> > > > >   As a first step, the CAPWAP = Working Group will
>> > develop a problem
>> > > > >   statement and network = architecture taxonomy describing the
>> > > > >   current set of approaches to = providing more support
>> > for scalable
>> > > > >   802.11 access networks. The = problem statement will
>> > describe, at
>> > > > >   a high level, what the = deployment, management, and
usability
>> > > > >   concerns are with 802.11 = networks based on the traditional
>> > > > >   autonomous AP architecture, and = will link those concerns to
>> > > > >   specific technical aspects of = the autonomous AP
architecture.
>> > > > >   The network architecture = taxonomy will:
>> > > > >
>> > > > >   - Describe the current set of = approaches (including the
>> > > > >     traditional = autonomous AP architecture) to partitioning
>> > > > >     802.11 access = network functionality between network
>> > > > >     entities,
>> > > > >   - List what the interfaces = between the network entities
>> > > > >     are in each = approach,
>> > > > >   - At a functional level, = describe what the protocols on
>> > > > >     the interfaces = between the network entites in each
>> > > > >     approach do,
>> > > > >   - Describe the advantages and = disadvantages of each
>> > > > >     approach for = scalable 802.11 access network deployment
>> > > > >     and management.
>> > > > >
>> > > > >   Additionally, the architecture = document will contain a
threat
>> > > > >   analysis that describes the = security threats involved in
each
>> > > > >   network architectural = approach.
>> > > > >
>> > > > >   Specific Working Group = deliverables are:
>> > > > >
>> > > > >   - A problem statement = document,
>> > > > >   - A network architecture = taxonomy document including
>> > > > >     threat = analysis.
>> > > > >
>> > > > >   Specific non-goals of this work = are:
>> > > > >   - Any work requiring revising = the 802.11 access network
>> > > > >     functional = architecture
>> > > > >
>> > > > > | The network architecture taxonomy = document, when
>> > stable, will be
>> > > > > | discussed with IEEE in order to validate = and
>> > synchronize this work
>> > > > > | with the work in iEEE. This may result in = merging the
>> > work with
>> > > > > | IEEE documentation in which case it may = not need to
>> > be published
>> > > > > | as an RFC. Such decision will be made in = co-operation
>> > with IEEE.
>> > > > >
>> > > > >   The CAPWAP WG will maintain a = close working liaison
>> > with relevant
>> > > > >   working groups in IEEE 802.11 = and IEEE 802.1. Working Group
>> > > > >   documents will be sent to an = expert review board for
>> > review prior
>> > > > >   to submission to the IESG. In = order to facilitate quick
>> > > > >   completion of this work, the = Working Group charter will
expire
>> > > > > | 6 months after it is approved by the = IESG, at which time
the
>> > > > >   Working Group can either = petition the IESG for a
continuation
>> > > > >   or recharter for further work = on the interoperability
problem.
>> > > > >
>> > > > >   Goals and Milestones:
>> > > > >   Feb  2004: Last call for = problem statement draft.
>> > > > >   Mar  2004: Discuss last = call comments for problem statement
>> > > > = >           &nb= sp;  at IETF 59.
>> > > > >   Mar  2004: Last Call for = architecture description document.
>> > > > >   Apr  2004: Submit problem = statement to IESG for publication
>> > > > = >           &nb= sp;  approval.
>> > > > > | May  2004: Architecture document to = expert review.
>> > > > > | Jun  2004: Stable Architecture = document for
>> > > > review/sync-up with IEEE
>> > > > > | Jul  2004: Discuss results of IEEE = review/sync-up
>> > > > > | Aug  2004: Close WG or = Re-charter
>> > > > > = _______________________________________________
>> > > > > Capwap mailing list
>> > > > > Capwap@frascone.com
>> > > > > http://mail.fra= scone.com/mailman/listinfo/capwap
>> > > > >
>> > > >
>> > > >
>> > > > Subrata Goswami, Ph.D.
>> > > > = _______________________________________________
>> > > > Capwap mailing list
>> > > > Capwap@frascone.com
>> > > > http://mail.fra= scone.com/mailman/listinfo/capwap
>> > > >
>> > > _______________________________________________
>> > > Capwap mailing list
>> > > Capwap@frascone.com
>> > > http://mail.fra= scone.com/mailman/listinfo/capwap
>> > >
>> >
>> >
>> > Subrata Goswami, Ph.D.
>> > _______________________________________________
>> > Capwap mailing list
>> > Capwap@frascone.com
>> > http://mail.fra= scone.com/mailman/listinfo/capwap
>> >
>> _______________________________________________
>> Capwap mailing list
>> Capwap@frascone.com
>> http://mail.fra= scone.com/mailman/listinfo/capwap
>>
>
>
> Subrata Goswami, Ph.D.
> _______________________________________________
> Capwap mailing list
> Capwap@frascone.com
> http://mail.fra= scone.com/mailman/listinfo/capwap



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus<= BR>



_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap


------_=_NextPart_001_01C3E037.375C901B-- From john.loughney@nokia.com Wed Jan 21 16:10:49 2004 From: john.loughney@nokia.com (john.loughney@nokia.com) Date: Wed, 21 Jan 2004 18:10:49 +0200 Subject: [Capwap] Proposed WG charter Message-ID: Hi all, > You can't potentially even start to envision all future > technologies at this time. Doing so will be a huge distraction > from the current WG. >=20 > I say we move with the current proposed charter as is. I agree. I think we take the current charter and move forward. There is nothing stopping individuals from writing drafts on any potention shortcomings of the architecture as it applies to other technologies. If the drafts are well written and identify significant shortcomings, I imagine that they can be considered when the WG is rechartered. I think it is important to have as crisp of a charter as possible so the work doesn't drift off into the weeds. br, John From sgoswami@umich.edu Wed Jan 21 16:23:48 2004 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Wed, 21 Jan 2004 11:23:48 -0500 Subject: [Capwap] Proposed WG charter In-Reply-To: <55749BC69138654EBBC4C50BA4F55610ADC64F@AIREMAIL.airespace.com> References: <55749BC69138654EBBC4C50BA4F55610ADC64F@AIREMAIL.airespace.com> Message-ID: <1074702228.400ea794b3d0a@mail.umich.edu> Pat, do not overlook the present technologies. Subrata Quoting "Pat R. Calhoun" : > You can't potentially even start to envision all future > technologies at this time. Doing so will be a huge distraction > from the current WG. > > I say we move with the current proposed charter as is. > > PatC > -----Original Message----- > From: capwap-admin@frascone.com on behalf of Yang, Lily L > Sent: Wed 1/21/2004 7:20 AM > To: Marcus Brunner; sgoswami@umich.edu > Cc: Capwap (E-mail) > Subject: RE: [Capwap] Proposed WG charter > > But in order to make the future extension possible and successful, it is > also important to state that up front so that the work is done in an > extensible way. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Marcus Brunner > Sent: Wednesday, January 21, 2004 1:24 AM > To: sgoswami@umich.edu > Cc: Capwap (E-mail) > Subject: RE: [Capwap] Proposed WG charter > > Subrata, > > Lets start with one technology and get the work done. The extension > towards > several different technology is definitly a good idea, but this can be > done > later. > > Marcus > > --On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote: > > > Thanks Bert, I will reiterate my concerns here briefly for IESG. > > > > 1. The CAPWAP WG is too narrowly focused on .11, there a number of > other > > less popular ( or hyped - take your pick) wireless MAN/LAN/PAN > > technologies which is around and would be around for a long time. > > 2. There are substatntial differences in the wireless MAN, LAN, and > PAN > > technologies so that retrofitting an upper layer protocol designed > > exclusively for .11 would be difficult if not impossible (to say > > 802.15.1 or 802.15.3). > > For example, 802.15.1 and 802.11 both have very different > > security protocols. > > > > Subrata > > > > > > Quoting "Wijnen, Bert (Bert)" : > > > >> Basically yes, because you do indeed not see your > >> requested extension reflected in the charter. > >> > >> As I said, it will be on IESG agenda again this Thursday, > >> so if you want to re-emphasize it to the IESG once more, > >> then I guess now is the time. You would have to explain > >> of course why you think the answer you have had sofar > >> are not acceptable. > >> > >> Thanks, > >> Bert > >> > >> > -----Original Message----- > >> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > >> > Sent: dinsdag 20 januari 2004 21:39 > >> > To: Capwap (E-mail) > >> > Subject: RE: [Capwap] Proposed WG charter > >> > > >> > > >> > Thanks Bert, I remember that there was some discussion last > >> > month. I guess that "explanation" should be taken as the > >> > IESG response - correct ? > >> > > >> > Subrata > >> > > >> > > >> > > >> > Quoting "Wijnen, Bert (Bert)" : > >> > > >> > > I (for the IESG) and I expect some others from IESG and from IAB > >> > > have been following this mailing list and your comments to the > >> > > IESG. As far as I can tell, the intended chairs and Technical > >> > > Advisor have explained to you why we do not want to extend > >> > > the charter any further than what we currently have. > >> > > > >> > > Hope this helps/explains > >> > > Bert > >> > > > >> > > > -----Original Message----- > >> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > >> > > > Sent: dinsdag 20 januari 2004 16:56 > >> > > > To: Capwap (E-mail) > >> > > > Subject: Re: [Capwap] Proposed WG charter > >> > > > > >> > > > > >> > > > Hi, thanks for the update. IESG called for comments on the > >> > > > CAPWAP charter. Have they take any action on those comments ? > >> > > > Would those be published ? > >> > > > > >> > > > For your information, the following was the notice sent out > >> > > > by IESG . > >> > > > > >> > > > > >> > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > >> > > > > >> > > > > >> > > > Subrata > >> > > > > >> > > > Quoting "Wijnen, Bert (Bert)" : > >> > > > > >> > > > > As a result of various reviews and discussions with the > >> > > > > IEEE 802 groups (last week in Vancouver), the new proposed > >> > > > > WG charter (to be discussed this week on IESG telechat) > >> > > > > is as below. The changes are marked with a change bar in > >> > > > > the left margin. > >> > > > > > >> > > > > IEEE will be starting a CI (Call for Interest) to start work > >> > > > > on an architure document. That indeed belongs in IEEE. > >> > > > > > >> > > > > The change for us boils down to the fact that we want to be > >> > > > > "done" with the first phase in 6 months. And the achitecture > >> > > > > taxonomy document (Internet Draft) will then be checked and > >> > > > > synced with ongoing work in IEEE. Depending on that IEEE > review > >> > > > > and sync-up we may decide that all of it better gets included > in > >> > > > > an IEEE based document or that we publish it (or parts of it) > >> > > > > as an RFC. And based on that we can then decide if we > >> > want/should > >> > > > > do more work. > >> > > > > > >> > > > > Thanks, > >> > > > > Bert > >> > > > > ------------ > >> > > > > > >> > > > > Status as of 20 Jan 2004: Proposed WG > >> > > > > > >> > > > > WG name: > >> > > > > > >> > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > >> > > > > > >> > > > > Chairs: > >> > > > > Mahalingam Mani > >> > > > > Dorothy Gellert > >> > > > > > >> > > > > > >> > > > > Operations and Management Area Director(s): > >> > > > > > >> > > > > Bert Wijnen > >> > > > > David Kessens > >> > > > > > >> > > > > Operations and Management Area Advisor: > >> > > > > > >> > > > > Bert Wijnen > >> > > > > > >> > > > > IEEE Liaison to IETF: > >> > > > > > >> > > > > Dorothy Stanley (dstanley@agere.com) > >> > > > > > >> > > > > Technical Advisor: > >> > > > > > >> > > > > Bob O'Hara (bohara@airespace.com) > >> > > > > > >> > > > > Mailing Lists: > >> > > > > General Discussion: capwap@frascone.com. > >> > > > > To Subscribe: > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > Archive: http://mail.frascone.com/pipermail/capwap/ > >> > > > > > >> > > > > Description: > >> > > > > > >> > > > > As the size and complexity of IEEE 802.11 wireless > >> > networks has > >> > > > > increased, problems in the deployment, management, > >> > and usability > >> > > > > of these networks have become evident. Access points (APs) > >> > > > > typically require complex management at the IP level. As > the > >> > > > > number of APs increases, the number of devices > >> > requiring complex > >> > > > > management increases, in some cases, doubling the number of > IP > >> > > > > devices requiring management in a provider's network. > >> > In addition, > >> > > > > because APs have no visibility beyond their own cell, > >> > a variety of > >> > > > > problems ensue in large scale 802.11 networks. Load > balancing > >> > > > > between APs, dead cell detection, and correlating patterns > of > >> > > > > usage between APs to detect attacks are difficult to > >> > impossible. > >> > > > > Finally, because each AP acts as its own Network Access > Server > >> > > > > (NAS), a network provider is faced with the prospect of > moving > >> > > > > from a situation where the NAS is a few machines with > dialup > >> > > > > access in a machine room to a situation where > >> > hundreds or perhaps > >> > > > > thousands of devices scattered across a wide > >> > geographic area have > >> > > > > NAS functionality. Maintaining security on such a > >> > wide collection > >> > > > > of devices is a difficult challenge. > >> > > > > > >> > > > > In recent attempts to solve these problems, various > >> > vendors have > >> > > > > introduced products that redistribute the > >> > functionality of 802.11 > >> > > > > APs in various ways. However, because the 802.11 > >> > access network > >> > > > > functional architecture is incompletely specified, the > network > >> > > > > interfaces between network entities in different vendors' > >> > > > > products are defined in incompatible ways. As a result, the > >> > > > > protocols between the network entities in different > >> > products are > >> > > > > not interoperable. > >> > > > > > >> > > > > Charter: > >> > > > > > >> > > > > As a first step, the CAPWAP Working Group will > >> > develop a problem > >> > > > > statement and network architecture taxonomy describing the > >> > > > > current set of approaches to providing more support > >> > for scalable > >> > > > > 802.11 access networks. The problem statement will > >> > describe, at > >> > > > > a high level, what the deployment, management, and > usability > >> > > > > concerns are with 802.11 networks based on the traditional > >> > > > > autonomous AP architecture, and will link those concerns to > >> > > > > specific technical aspects of the autonomous AP > architecture. > >> > > > > The network architecture taxonomy will: > >> > > > > > >> > > > > - Describe the current set of approaches (including the > >> > > > > traditional autonomous AP architecture) to partitioning > >> > > > > 802.11 access network functionality between network > >> > > > > entities, > >> > > > > - List what the interfaces between the network entities > >> > > > > are in each approach, > >> > > > > - At a functional level, describe what the protocols on > >> > > > > the interfaces between the network entites in each > >> > > > > approach do, > >> > > > > - Describe the advantages and disadvantages of each > >> > > > > approach for scalable 802.11 access network deployment > >> > > > > and management. > >> > > > > > >> > > > > Additionally, the architecture document will contain a > threat > >> > > > > analysis that describes the security threats involved in > each > >> > > > > network architectural approach. > >> > > > > > >> > > > > Specific Working Group deliverables are: > >> > > > > > >> > > > > - A problem statement document, > >> > > > > - A network architecture taxonomy document including > >> > > > > threat analysis. > >> > > > > > >> > > > > Specific non-goals of this work are: > >> > > > > - Any work requiring revising the 802.11 access network > >> > > > > functional architecture > >> > > > > > >> > > > > | The network architecture taxonomy document, when > >> > stable, will be > >> > > > > | discussed with IEEE in order to validate and > >> > synchronize this work > >> > > > > | with the work in iEEE. This may result in merging the > >> > work with > >> > > > > | IEEE documentation in which case it may not need to > >> > be published > >> > > > > | as an RFC. Such decision will be made in co-operation > >> > with IEEE. > >> > > > > > >> > > > > The CAPWAP WG will maintain a close working liaison > >> > with relevant > >> > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > >> > > > > documents will be sent to an expert review board for > >> > review prior > >> > > > > to submission to the IESG. In order to facilitate quick > >> > > > > completion of this work, the Working Group charter will > expire > >> > > > > | 6 months after it is approved by the IESG, at which time > the > >> > > > > Working Group can either petition the IESG for a > continuation > >> > > > > or recharter for further work on the interoperability > problem. > >> > > > > > >> > > > > Goals and Milestones: > >> > > > > Feb 2004: Last call for problem statement draft. > >> > > > > Mar 2004: Discuss last call comments for problem statement > >> > > > > at IETF 59. > >> > > > > Mar 2004: Last Call for architecture description document. > >> > > > > Apr 2004: Submit problem statement to IESG for publication > >> > > > > approval. > >> > > > > | May 2004: Architecture document to expert review. > >> > > > > | Jun 2004: Stable Architecture document for > >> > > > review/sync-up with IEEE > >> > > > > | Jul 2004: Discuss results of IEEE review/sync-up > >> > > > > | Aug 2004: Close WG or Re-charter > >> > > > > _______________________________________________ > >> > > > > Capwap mailing list > >> > > > > Capwap@frascone.com > >> > > > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > > >> > > > > >> > > > > >> > > > Subrata Goswami, Ph.D. > >> > > > _______________________________________________ > >> > > > Capwap mailing list > >> > > > Capwap@frascone.com > >> > > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > >> > > _______________________________________________ > >> > > Capwap mailing list > >> > > Capwap@frascone.com > >> > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > >> > > >> > > >> > Subrata Goswami, Ph.D. > >> > _______________________________________________ > >> > Capwap mailing list > >> > Capwap@frascone.com > >> > http://mail.frascone.com/mailman/listinfo/capwap > >> > > >> _______________________________________________ > >> Capwap mailing list > >> Capwap@frascone.com > >> http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > > > Subrata Goswami, Ph.D. > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > Subrata Goswami, Ph.D. From sgoswami@umich.edu Wed Jan 21 16:35:03 2004 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Wed, 21 Jan 2004 11:35:03 -0500 Subject: [Capwap] Proposed WG charter In-Reply-To: References: Message-ID: <1074702903.400eaa37c6449@mail.umich.edu> Continuing along the same line of reasoning, with a more general WG charter, there is nothing stopping individuls from writting drafts on any specific wireless PHY/MAC. More over, the WG does not have to be rechartered to include additional PHY/MAC. Why is developing a CAPWAP that supports multiple protocol is a distraction ? The real world has these "distractions" by the way in real products. Subrata Quoting john.loughney@nokia.com: > Hi all, > > > You can't potentially even start to envision all future > > technologies at this time. Doing so will be a huge distraction > > from the current WG. > > > > I say we move with the current proposed charter as is. > > I agree. I think we take the current charter and move forward. > There is nothing stopping individuals from writing drafts on > any potention shortcomings of the architecture as it applies > to other technologies. If the drafts are well written and > identify significant shortcomings, I imagine that they can > be considered when the WG is rechartered. > > I think it is important to have as crisp of a charter as possible > so the work doesn't drift off into the weeds. > > br, > John > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > Subrata Goswami, Ph.D. From kempf@docomolabs-usa.com Wed Jan 21 18:17:58 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 21 Jan 2004 10:17:58 -0800 Subject: [Capwap] Proposed WG charter References: <26BDFAFFB541B047B24179002EBE6D278CB13E@orsmsx410.jf.intel.com> Message-ID: <00d601c3e04a$e6ae7320$5b6015ac@dclkempt40> In case this is not obvious from the proposed new charter, the intent of this new charter is to get the taxonomy work done quickly and pass it off to the IEEE so that they can use it in their WG which will define an interoperable architecture for 802.11 APs. To put it somewhat bluntly, the IESG and IAB are not convinced at this point that, in the absence of such an architecture, there is anything for the IETF to do in the area of interoperable protocol design, since there are no crisply defined open interfaces for which IP protocols might be defined. After such an architecture has been defined (and as part of the definition process), it should become more clear about whether the IETF has a role to play in defining interoperable protocols on the open interfaces that are part of the architecture. W.r.t. other radio protocols, the DIRAC work from UCLA is a general framework that would solve many of the problems for a variety of radio protocols, however, the IESG has been a bit skeptical about the distributed routing architecture approach in general, and in particular with respect to FORCES. I asked Bill Fenner, Routing AD, about DIRAC during the CAPWAP meeting in Minneapolis, and he indicated that he saw DIRAC and CAPWAP as an even more extreme example of such a distributed routing architecture, and therefore not something the Routing Area would be sponsoring. I think what you are seeing here is the historical reluctance of IETF to get involved in detailed architecture work, as opposed to large scale, Internet architecture work, unless the detailed architecture is directly relevant to a specific protocol design problem. IETF works best when there is a clearly defined protocol problem that doesn't involve a lot of architectural uncertainly, and it works most quickly if there is an interoperable protocol already designed (perhaps by a consortium or vendor group) which needs some tuning and perhaps some additional work in areas like interoperability and security prior to standardization. jak ----- Original Message ----- From: "Yang, Lily L" To: "Marcus Brunner" ; Cc: "Capwap (E-mail)" Sent: Wednesday, January 21, 2004 7:20 AM Subject: RE: [Capwap] Proposed WG charter > But in order to make the future extension possible and successful, it is > also important to state that up front so that the work is done in an > extensible way. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Marcus Brunner > Sent: Wednesday, January 21, 2004 1:24 AM > To: sgoswami@umich.edu > Cc: Capwap (E-mail) > Subject: RE: [Capwap] Proposed WG charter > > Subrata, > > Lets start with one technology and get the work done. The extension > towards > several different technology is definitly a good idea, but this can be > done > later. > > Marcus > > --On Dienstag, 20. Januar 2004 17:20 -0500 sgoswami@umich.edu wrote: > > > Thanks Bert, I will reiterate my concerns here briefly for IESG. > > > > 1. The CAPWAP WG is too narrowly focused on .11, there a number of > other > > less popular ( or hyped - take your pick) wireless MAN/LAN/PAN > > technologies which is around and would be around for a long time. > > 2. There are substatntial differences in the wireless MAN, LAN, and > PAN > > technologies so that retrofitting an upper layer protocol designed > > exclusively for .11 would be difficult if not impossible (to say > > 802.15.1 or 802.15.3). > > For example, 802.15.1 and 802.11 both have very different > > security protocols. > > > > Subrata > > > > > > Quoting "Wijnen, Bert (Bert)" : > > > >> Basically yes, because you do indeed not see your > >> requested extension reflected in the charter. > >> > >> As I said, it will be on IESG agenda again this Thursday, > >> so if you want to re-emphasize it to the IESG once more, > >> then I guess now is the time. You would have to explain > >> of course why you think the answer you have had sofar > >> are not acceptable. > >> > >> Thanks, > >> Bert > >> > >> > -----Original Message----- > >> > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > >> > Sent: dinsdag 20 januari 2004 21:39 > >> > To: Capwap (E-mail) > >> > Subject: RE: [Capwap] Proposed WG charter > >> > > >> > > >> > Thanks Bert, I remember that there was some discussion last > >> > month. I guess that "explanation" should be taken as the > >> > IESG response - correct ? > >> > > >> > Subrata > >> > > >> > > >> > > >> > Quoting "Wijnen, Bert (Bert)" : > >> > > >> > > I (for the IESG) and I expect some others from IESG and from IAB > >> > > have been following this mailing list and your comments to the > >> > > IESG. As far as I can tell, the intended chairs and Technical > >> > > Advisor have explained to you why we do not want to extend > >> > > the charter any further than what we currently have. > >> > > > >> > > Hope this helps/explains > >> > > Bert > >> > > > >> > > > -----Original Message----- > >> > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > >> > > > Sent: dinsdag 20 januari 2004 16:56 > >> > > > To: Capwap (E-mail) > >> > > > Subject: Re: [Capwap] Proposed WG charter > >> > > > > >> > > > > >> > > > Hi, thanks for the update. IESG called for comments on the > >> > > > CAPWAP charter. Have they take any action on those comments ? > >> > > > Would those be published ? > >> > > > > >> > > > For your information, the following was the notice sent out > >> > > > by IESG . > >> > > > > >> > > > > >> > > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27787.html > >> > > > > >> > > > > >> > > > Subrata > >> > > > > >> > > > Quoting "Wijnen, Bert (Bert)" : > >> > > > > >> > > > > As a result of various reviews and discussions with the > >> > > > > IEEE 802 groups (last week in Vancouver), the new proposed > >> > > > > WG charter (to be discussed this week on IESG telechat) > >> > > > > is as below. The changes are marked with a change bar in > >> > > > > the left margin. > >> > > > > > >> > > > > IEEE will be starting a CI (Call for Interest) to start work > >> > > > > on an architure document. That indeed belongs in IEEE. > >> > > > > > >> > > > > The change for us boils down to the fact that we want to be > >> > > > > "done" with the first phase in 6 months. And the achitecture > >> > > > > taxonomy document (Internet Draft) will then be checked and > >> > > > > synced with ongoing work in IEEE. Depending on that IEEE > review > >> > > > > and sync-up we may decide that all of it better gets included > in > >> > > > > an IEEE based document or that we publish it (or parts of it) > >> > > > > as an RFC. And based on that we can then decide if we > >> > want/should > >> > > > > do more work. > >> > > > > > >> > > > > Thanks, > >> > > > > Bert > >> > > > > ------------ > >> > > > > > >> > > > > Status as of 20 Jan 2004: Proposed WG > >> > > > > > >> > > > > WG name: > >> > > > > > >> > > > > Control and Provisioning of Wireless Access Points (CAPWAP) > >> > > > > > >> > > > > Chairs: > >> > > > > Mahalingam Mani > >> > > > > Dorothy Gellert > >> > > > > > >> > > > > > >> > > > > Operations and Management Area Director(s): > >> > > > > > >> > > > > Bert Wijnen > >> > > > > David Kessens > >> > > > > > >> > > > > Operations and Management Area Advisor: > >> > > > > > >> > > > > Bert Wijnen > >> > > > > > >> > > > > IEEE Liaison to IETF: > >> > > > > > >> > > > > Dorothy Stanley (dstanley@agere.com) > >> > > > > > >> > > > > Technical Advisor: > >> > > > > > >> > > > > Bob O'Hara (bohara@airespace.com) > >> > > > > > >> > > > > Mailing Lists: > >> > > > > General Discussion: capwap@frascone.com. > >> > > > > To Subscribe: > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > Archive: http://mail.frascone.com/pipermail/capwap/ > >> > > > > > >> > > > > Description: > >> > > > > > >> > > > > As the size and complexity of IEEE 802.11 wireless > >> > networks has > >> > > > > increased, problems in the deployment, management, > >> > and usability > >> > > > > of these networks have become evident. Access points (APs) > >> > > > > typically require complex management at the IP level. As > the > >> > > > > number of APs increases, the number of devices > >> > requiring complex > >> > > > > management increases, in some cases, doubling the number of > IP > >> > > > > devices requiring management in a provider's network. > >> > In addition, > >> > > > > because APs have no visibility beyond their own cell, > >> > a variety of > >> > > > > problems ensue in large scale 802.11 networks. Load > balancing > >> > > > > between APs, dead cell detection, and correlating patterns > of > >> > > > > usage between APs to detect attacks are difficult to > >> > impossible. > >> > > > > Finally, because each AP acts as its own Network Access > Server > >> > > > > (NAS), a network provider is faced with the prospect of > moving > >> > > > > from a situation where the NAS is a few machines with > dialup > >> > > > > access in a machine room to a situation where > >> > hundreds or perhaps > >> > > > > thousands of devices scattered across a wide > >> > geographic area have > >> > > > > NAS functionality. Maintaining security on such a > >> > wide collection > >> > > > > of devices is a difficult challenge. > >> > > > > > >> > > > > In recent attempts to solve these problems, various > >> > vendors have > >> > > > > introduced products that redistribute the > >> > functionality of 802.11 > >> > > > > APs in various ways. However, because the 802.11 > >> > access network > >> > > > > functional architecture is incompletely specified, the > network > >> > > > > interfaces between network entities in different vendors' > >> > > > > products are defined in incompatible ways. As a result, the > >> > > > > protocols between the network entities in different > >> > products are > >> > > > > not interoperable. > >> > > > > > >> > > > > Charter: > >> > > > > > >> > > > > As a first step, the CAPWAP Working Group will > >> > develop a problem > >> > > > > statement and network architecture taxonomy describing the > >> > > > > current set of approaches to providing more support > >> > for scalable > >> > > > > 802.11 access networks. The problem statement will > >> > describe, at > >> > > > > a high level, what the deployment, management, and > usability > >> > > > > concerns are with 802.11 networks based on the traditional > >> > > > > autonomous AP architecture, and will link those concerns to > >> > > > > specific technical aspects of the autonomous AP > architecture. > >> > > > > The network architecture taxonomy will: > >> > > > > > >> > > > > - Describe the current set of approaches (including the > >> > > > > traditional autonomous AP architecture) to partitioning > >> > > > > 802.11 access network functionality between network > >> > > > > entities, > >> > > > > - List what the interfaces between the network entities > >> > > > > are in each approach, > >> > > > > - At a functional level, describe what the protocols on > >> > > > > the interfaces between the network entites in each > >> > > > > approach do, > >> > > > > - Describe the advantages and disadvantages of each > >> > > > > approach for scalable 802.11 access network deployment > >> > > > > and management. > >> > > > > > >> > > > > Additionally, the architecture document will contain a > threat > >> > > > > analysis that describes the security threats involved in > each > >> > > > > network architectural approach. > >> > > > > > >> > > > > Specific Working Group deliverables are: > >> > > > > > >> > > > > - A problem statement document, > >> > > > > - A network architecture taxonomy document including > >> > > > > threat analysis. > >> > > > > > >> > > > > Specific non-goals of this work are: > >> > > > > - Any work requiring revising the 802.11 access network > >> > > > > functional architecture > >> > > > > > >> > > > > | The network architecture taxonomy document, when > >> > stable, will be > >> > > > > | discussed with IEEE in order to validate and > >> > synchronize this work > >> > > > > | with the work in iEEE. This may result in merging the > >> > work with > >> > > > > | IEEE documentation in which case it may not need to > >> > be published > >> > > > > | as an RFC. Such decision will be made in co-operation > >> > with IEEE. > >> > > > > > >> > > > > The CAPWAP WG will maintain a close working liaison > >> > with relevant > >> > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > >> > > > > documents will be sent to an expert review board for > >> > review prior > >> > > > > to submission to the IESG. In order to facilitate quick > >> > > > > completion of this work, the Working Group charter will > expire > >> > > > > | 6 months after it is approved by the IESG, at which time > the > >> > > > > Working Group can either petition the IESG for a > continuation > >> > > > > or recharter for further work on the interoperability > problem. > >> > > > > > >> > > > > Goals and Milestones: > >> > > > > Feb 2004: Last call for problem statement draft. > >> > > > > Mar 2004: Discuss last call comments for problem statement > >> > > > > at IETF 59. > >> > > > > Mar 2004: Last Call for architecture description document. > >> > > > > Apr 2004: Submit problem statement to IESG for publication > >> > > > > approval. > >> > > > > | May 2004: Architecture document to expert review. > >> > > > > | Jun 2004: Stable Architecture document for > >> > > > review/sync-up with IEEE > >> > > > > | Jul 2004: Discuss results of IEEE review/sync-up > >> > > > > | Aug 2004: Close WG or Re-charter > >> > > > > _______________________________________________ > >> > > > > Capwap mailing list > >> > > > > Capwap@frascone.com > >> > > > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > > >> > > > > >> > > > > >> > > > Subrata Goswami, Ph.D. > >> > > > _______________________________________________ > >> > > > Capwap mailing list > >> > > > Capwap@frascone.com > >> > > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > >> > > _______________________________________________ > >> > > Capwap mailing list > >> > > Capwap@frascone.com > >> > > http://mail.frascone.com/mailman/listinfo/capwap > >> > > > >> > > >> > > >> > Subrata Goswami, Ph.D. > >> > _______________________________________________ > >> > Capwap mailing list > >> > Capwap@frascone.com > >> > http://mail.frascone.com/mailman/listinfo/capwap > >> > > >> _______________________________________________ > >> Capwap mailing list > >> Capwap@frascone.com > >> http://mail.frascone.com/mailman/listinfo/capwap > >> > > > > > > Subrata Goswami, Ph.D. > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > From mmani@avaya.com Mon Jan 26 17:09:17 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 26 Jan 2004 10:09:17 -0700 Subject: [Capwap] CAPWAP WG approval. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E42F.2166C2D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 The CAPWAP charter has been approved by the IESG (per Bert Wijnen, the AD) and the WG commences formal work. The formal announcement due anytime from the IESG secretariat. While that happens - this email is an attempt to start ahead with the WG charter. =20 The charter (find appended) remains as Bert posted last - but for cosmetic changes in terminology (IEEE to IEEE 802 and such). =20 The charter timeline is a short one expecting to wrap up architecture taxonomy work by July timeframe. The problem statement is expected to make WG last call before March. =20 In order to stick as close to the timeline as feasible - this is a call for contributions and inputs early and soon. =20 The WG will meet in Seoul in March. Early contributions will facilitate discussion on list - and also inclusion in meeting agenda if need be. =20 Regards, -mani (Mahalingam Mani) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D WG name: =20 Control and Provisioning of Wireless Access Points (CAPWAP) =20 Chairs: Mahalingam Mani Dorothy Gellert =20 Operations and Management Area Director(s): =20 Bert Wijnen David Kessens =20 Operations and Management Area Advisor: =20 Bert Wijnen =20 IEEE Liaison to IETF: =20 Dorothy Stanley (dstanley@agere.com) =20 Technical Advisor: =20 Bob O'Hara (bohara@airespace.com) =20 Mailing Lists: General Discussion: capwap@frascone.com.=20 To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap Archive: http://mail.frascone.com/pipermail/capwap/ =20 Description: =20 As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of these networks have become evident. Access points (APs) typically require complex management at the IP level. As the number of APs increases, the number of devices requiring complex management increases, in some cases, doubling the number of IP devices requiring management in a provider's network. In addition, because APs have no visibility beyond their own cell, a variety of problems ensue in large scale 802.11 networks. Load balancing between APs, dead cell detection, and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. =20 In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs in various ways. However, because the 802.11 access network functional architecture is incompletely specified, the network interfaces between network entities in different vendors' products are defined in incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. =20 Charter: =20 As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set of approaches to providing more support for scalable 802.11 access networks. The problem statement will describe, at a high level, what the deployment, management, and usability concerns are with 802.11 networks based on the traditional autonomous AP architecture, and will link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: =20 - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. =20 Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach. =20 Specific Working Group deliverables are: =20 - A problem statement document, - A network architecture taxonomy document including threat analysis. =20 Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture =20 The network architecture taxonomy document, when stable, will be discussed with IEEE 802 in order to validate and synchronize this work with the work in IEEE 802. This may result in merging the work with IEEE 802 documentation in which case it may not need to be published as an RFC. Such decision will be made in co-operation with IEEE. =20 The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire 6 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem. =20 Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004: Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Jun 2004: Stable Architecture document for review/sync-up with IEEE 802 Jul 2004: Discuss results of IEEE 802 review/sync-up=20 Aug 2004: Close WG or Re-charter =20 ------_=_NextPart_001_01C3E42F.2166C2D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The CAPWAP charter has been approved by the IESG (per = Bert Wijnen, the AD) and the WG commences formal work.

The formal announcement due anytime from the IESG secretariat. While that happens - this email is an attempt to start = ahead with the WG charter.

 

The charter (find appended) remains as Bert posted = last – but for cosmetic changes in terminology (IEEE to IEEE 802 and = such).

 

The charter timeline is a short one  expecting = to wrap up architecture taxonomy work by July timeframe. The problem statement = is expected to make WG last call before March.

 

In order to stick as close to the timeline as = feasible – this is a call for contributions and inputs early and = soon.

 

The WG will meet in Seoul in = March. Early contributions will facilitate discussion on list – and also = inclusion in meeting agenda if need be.

 

Regards,

-mani

(Mahalingam Mani)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

WG = name:

 

  Control and Provisioning of Wireless Access Points (CAPWAP)

 

Chairs:

  Mahalingam = Mani <mmani@avaya.com>

  Dorothy = Gellert <dorothy.gellert@nokia.com>

 

Operations and = Management Area Director(s):

 

  = Bert Wijnen <bwijnen@lucent.com>

  = David Kessens <david.kessens@nokia.com>

 

Operations and = Management Area Advisor:

 

  Bert Wijnen <bwijnen@lucent.com>

 

IEEE Liaison to = IETF:

 

  Dorothy = Stanley (dstanley@agere.com)

 

Technical = Advisor:

 

  Bob O'Hara (bohara@airespace.com)

 

Mailing = Lists:

  General = Discussion: capwap@frascone.com.

  To = Subscribe: http://mail.fra= scone.com/mailman/listinfo/capwap

  Archive: http://mail.frascone.= com/pipermail/capwap/

 

Description:

 

  As the size = and complexity of IEEE 802.11 wireless networks has

  increased, = problems in the deployment, management, and usability

  of these = networks have become evident. Access points (APs)

  typically = require complex management at the IP level. As the

  number of = APs increases, the number of devices requiring complex

  management = increases, in some cases, doubling the number of IP

  devices = requiring management in a provider's network. In addition,

  because APs = have no visibility beyond their own cell, a variety of

  problems = ensue in large scale 802.11 networks. Load balancing

  between APs, = dead cell detection, and correlating patterns of

  usage = between APs to detect attacks are difficult to impossible.

  Finally, = because each AP acts as its own Network Access Server

  (NAS), a = network provider is faced with the prospect of moving

  from a = situation where the NAS is a few machines with dialup

  access in a = machine room to a situation where hundreds or perhaps

  thousands of = devices scattered across a wide geographic area have

  NAS = functionality. Maintaining security on such a wide collection

  of devices = is a difficult challenge.

 

  In recent = attempts to solve these problems, various vendors have

  introduced = products that redistribute the functionality of 802.11

  APs in = various ways. However, because the 802.11 access network

  functional architecture is incompletely specified, the network

  interfaces = between network entities in different vendors'

  products are = defined in incompatible ways. As a result, the

  protocols = between the network entities in different products are

  not = interoperable.

 

Charter:

 

  As a first = step, the CAPWAP Working Group will develop a problem

  statement = and network architecture taxonomy describing the

  current set = of approaches to providing more support for scalable

  802.11 = access networks. The problem statement will describe, at

  a high = level, what the deployment, management, and usability

  concerns are = with 802.11 networks based on the traditional

  autonomous = AP architecture, and will link those concerns to

  specific = technical aspects of the autonomous AP architecture.

  The network architecture taxonomy will:

 

  - Describe = the current set of approaches (including the

    = traditional autonomous AP architecture) to partitioning

    = 802.11 access network functionality between network

    = entities,

  - List what = the interfaces between the network entities

    = are in each approach,

  - At a = functional level, describe what the protocols on

    = the interfaces between the network entites in each

    = approach do,

  - Describe = the advantages and disadvantages of each

    = approach for scalable 802.11 access network deployment

    = and management.

 

  = Additionally, the architecture document will contain a threat

  analysis = that describes the security threats involved in each

  network architectural approach.

 

  Specific = Working Group deliverables are:

 

  - A problem = statement document,

  - A network architecture taxonomy document including

    = threat analysis.

 

  Specific = non-goals of this work are:

  - Any work = requiring revising the 802.11 access network

    = functional architecture

 

  The network architecture taxonomy document, when stable, will be

  discussed = with IEEE 802 in order to validate and synchronize this

  work with = the work in IEEE 802. This may result in merging the

  work with = IEEE 802 documentation in which case it may not need

  to be = published as an RFC. Such decision will be made in

  co-operation = with IEEE.

 

  The CAPWAP = WG will maintain a close working liaison with relevant

  working = groups in IEEE 802.11 and IEEE 802.1. Working Group

  documents = will be sent to an expert review board for review prior

  to = submission to the IESG. In order to facilitate quick

  completion = of this work, the Working Group charter will expire

  6 months = after it is approved by the IESG, at which time the

  Working = Group can either petition the IESG for a continuation

  or recharter = for further work on the interoperability problem.

 

  Goals and = Milestones:

  Feb  = 2004: Last call for problem statement draft.

  Mar  = 2004: Discuss last call comments for problem statement

           &= nbsp; at IETF 59.

  Mar  = 2004: Last Call for architecture description document.

  Apr  = 2004: Submit problem statement to IESG for publication

           &= nbsp; approval.

  May  = 2004: Architecture document to expert review.

  Jun  = 2004: Stable Architecture document for review/sync-up

           &= nbsp; with IEEE 802

  Jul  = 2004: Discuss results of IEEE 802 review/sync-up

  Aug  = 2004: Close WG or Re-charter

 

------_=_NextPart_001_01C3E42F.2166C2D7-- From peyush.agarwal@st.com Wed Jan 28 12:22:33 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Wed, 28 Jan 2004 17:52:33 +0530 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <00dc01c3e599$6857b000$0904b40a@dlh.st.com> Hi, The "Capabilities Negotiation" has been proposed in the Architecture = draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding = 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the = capabilities supported by the AP, therefore the requirement of = 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. From bob@airespace.com Wed Jan 28 17:11:41 2004 From: bob@airespace.com (Bob O'Hara) Date: Wed, 28 Jan 2004 09:11:41 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610D3973A@AIREMAIL.airespace.com> Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Wed Jan 28 17:29:06 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 28 Jan 2004 09:29:06 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB187@orsmsx410.jf.intel.com> TXkgdW5kZXJzdGFuZGluZzogQmVhY29ucyBjb250YWluIGluZm9ybWF0aW9uIG1vc3RseSBoZWxw ZnVsIGZvciB0aGUgY2xpZW50cyB0byBkZWNpZGUgd2hpY2ggQVAgdG8gYXNzb2NpYXRlIHdpdGgg b24gd2hhdCBjaGFubmVsIGV0Yy4gVGhlIGNhcGFiaWxpdGllcyBuZWdvdGlhdGlvbiBpbiB0aGUg YXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIEFQIGFuZCBBQy4g QmVjYXVzZSB0aGVyZSBhcmUgc2V2ZXJhbCB2YXJpYW50cyBvZiBhcmNoaXRlY3R1cmUgdGhhdCBD QVBXQVAgbWF5IGJlIGNhbGxlZCB0byBzdXBwb3J0ICh2YXJ5aW5nIGZyb20gdGhlIHRyYWRpdGlv bmFsIGZhdCBBUCB0byB0aGUgbGlnaHQgd2VpZ2h0IEFQIG1vZGVsIHRvIHRoZSBleHRyZW1lbHkg Y2VudHJhbGl6ZWQgbW9kZWwgb2YgdXNpbmcgQVAgb25seSBhcyByZW1vdGUgYW50ZW5uYSBmb3Ig UngvVHgpLCBzb21lIGtpbmQgb2YgbmVnb3RpYXRpb24gbWlnaHQgaGVscCBib3RoIHNpZGVzIGRl dGVybWluZSB3aGF0IGtpbmQgb2YgYXJjaGl0ZWN0dXJlIHRoZSBjdXJyZW50IG5ldHdvcmsgaXMg dXNpbmcgLS0gaWYgaXQgaXMgZmF0IEFQIG1vZGVsLCBhIGxvdCBvZiB0aGUgZGVjaXNpb25zIG1p Z2h0IGJlIG1hZGUgYnkgQVBzIGF1dG9ub21vdXNseSAod2hpbGUgb3RoZXJzIG1pZ2h0IHN0aWxs IGJlIG1hZGUgYnkgQUMpOyBidXQgaWYgaXQgaXMgdmVyeSBsaWdodCAoYW5kIHNvIGR1bWIpIEFQ LCBtb3N0IG9mIHRoZSBkZWNpc2lvbnMgbWlnaHQgYmUgbWFkZSBieSBBQyBpbnN0ZWFkLg0KDQpO b3cgaGF2aW5nIHNhaWQgdGhhdCwgaXQgZG9lc24ndCBtZWFuIHdlJ3ZlIHRob3VnaHQgdGhyb3Vn aCB0aGlzIHByb2JsZW0uIFF1ZXN0aW9ucyByZW1haW46DQoxKSBIb3cgbWFueSBhcmNoaXRlY3R1 cmFsIHZhcmlhbnRzIGFyZSB0aGVyZSA/IChBbnN3ZXJpbmcgdGhpcyBxdWVzdGlvbiBpcyBleGFj dGx5IHRoZSBwb2ludCBvZiBkb2luZyB0YXhhbm9teSBmaXJzdCkNCjIpIElzIGl0IHRlY2huaWNh bGx5IGZlYXNpYmxlIGZvciBvbmUgc3RhbmRhcmQgQ0FQV0FQIHByb3RvY29sIHRvIHN1cHBvcnQg YWxsIHRoZXNlIGRpZmZlcmVudCB2YXJpYW50cz8gKHRoZSBpbnRlcm9wZXJhYmlsaXR5IHByb2Js ZW0pDQozKSBXaGF0IGlmIHRoZSBhbnN3ZXIgdG8gMikgaXMgbm8/IERvZXMgdGhhdCBtZWFuIHdl IGFyZSBzdHVjayB3aXRoIHRoZSBwcm9wcmlldGFyeSBzb2x1dGlvbnMgKHRoZSBjdXJyZW50IHN0 YXRlIG9mIGFmZmFpcnMpPw0KDQpBbGwgdGhlc2UgYXJlIHVwIGZvciB0aGUgV0cgdG8gZGViYXRl LiBBbmQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBjaGFydGVyIGFza3MgdGhlIFdHIHRv IHN0YXJ0IHdpdGggIGFuc3dlcmluZyBxdWVzdGlvbiAxKS4NCg0KTGlseQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2Fwd2FwLWFkbWluQGZyYXNjb25lLmNvbSBbbWFpbHRv OmNhcHdhcC1hZG1pbkBmcmFzY29uZS5jb21dT24NCkJlaGFsZiBPZiBQZXl1c2ggQUdBUldBTA0K U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDA0IDQ6MjMgQU0NClRvOiBjYXB3YXBAZnJh c2NvbmUuY29tDQpTdWJqZWN0OiBbQ2Fwd2FwXSBSZWcuIENhcGFiaWxpdGllcyBOZWdvdGlhdGlv biBiZXR3ZWVuIEFQIC0gQVINCg0KDQpIaSwNCg0KVGhlICJDYXBhYmlsaXRpZXMgTmVnb3RpYXRp b24iIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcmNoaXRlY3R1cmUgZHJhZnQgKGRyYWZ0LW1h bmktaWV0Zi1jYXB3YXAtYXJjaC0wMCkgd2l0aCB0aGUgaW50ZW50aW9uIG9mIGRlY2lkaW5nICd0 aGUgYXBwbGljYWJsZSBBUEkncyBiZXR3ZWVuIEFQIGFuZCBBQycuDQoJVGhlIDgwMi4xMSAnQmVh Y29ucycgYWxyZWFkeSBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIGNhcGFiaWxpdGll cyBzdXBwb3J0ZWQgYnkgdGhlIEFQLCB0aGVyZWZvcmUgdGhlIHJlcXVpcmVtZW50IG9mICdjYXBh YmlsaXRpZXMgbmVnb3RpYXRpb24nIGlzIG5vdCBjbGVhciB0byBtZS4NClBsZWFzZSBjbGFyaWZ5 Lg0KDQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KUmVnYXJkcywNClBleXVzaC4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNhcHdhcCBtYWlsaW5nIGxp c3QNCkNhcHdhcEBmcmFzY29uZS5jb20NCmh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFu L2xpc3RpbmZvL2NhcHdhcA0K From iesg-secretary@ietf.org Wed Jan 28 20:44:20 2004 From: iesg-secretary@ietf.org (The IESG) Date: Wed, 28 Jan 2004 15:44:20 -0500 Subject: [Capwap] WG Action: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <200401282044.PAA27244@ietf.org> A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. Control and Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Current Status: Active Working Group Chairs: Mahalingam Mani Dorothy Gellert Operations and Management Area Director(s): Bert Wijnen David Kessens Operations and Management Area Advisor: Bert Wijnen IEEE Liaison to IETF: Dorothy Stanley (dstanley@agere.com) Technical Advisor: Bob O'Hara (bohara@airespace.com) Mailing Lists: General Discussion: capwap@frascone.com. To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap Archive: http://mail.frascone.com/pipermail/capwap/ Description: As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. Access points (APs) typically require complex management at the IP level. As the number of APs increases, the number of devices requiring complex management increases, in some cases, doubling the number of IP devices requiring management in a provider's network. In addition, because APs have no visibility beyond their own cell, a variety of problems ensue in large scale 802.11 networks. Load balancing between APs, dead cell detection, and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have introduced products that redistribute the functionality of 802.11 APs in various ways. However, because the 802.11 access network functional architecture is incompletely specified, the network interfaces between network entities in different vendors' products are defined in incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. Charter: As a first step, the CAPWAP Working Group will develop a problem statement and network architecture taxonomy describing the current set of approaches to providing more support for scalable 802.11 access networks. The problem statement will describe, at a high level, what the deployment, management, and usability concerns are with 802.11 networks based on the traditional autonomous AP architecture, and will link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The network architecture taxonomy document, when stable, will be discussed with IEEE 802 in order to validate and synchronize this work with the work in IEEE 802. This may result in merging the work with IEEE 802 documentation in which case it may not need to be published as an RFC. Such decision will be made in co-operation with IEEE. The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire 6 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004: Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Jun 2004: Stable Architecture document for review/sync-up with IEEE 802 Jul 2004: Discuss results of IEEE 802 review/sync-up Aug 2004: Close WG or Re-charter From soohong.park@samsung.com Fri Jan 30 01:46:50 2004 From: soohong.park@samsung.com (S. Daniel Park) Date: Fri, 30 Jan 2004 10:46:50 +0900 Subject: [Capwap] AR name and AP name Message-ID: <00e501c3e6d2$eda351d0$b7cbdba8@LocalHost> Hello Capwap I am wondering how APs and ARs know its name in lwapp architecture. Is it a manual configuration by administrator ? Thanks in advance Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. From peyush.agarwal@st.com Fri Jan 30 06:01:37 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Fri, 30 Jan 2004 11:31:37 +0530 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR In-Reply-To: <55749BC69138654EBBC4C50BA4F55610D3973A@AIREMAIL.airespace.com> Message-ID: <00f201c3e6f6$886d3eb0$0904b40a@dlh.st.com> That sounds good & informative. But again to make the things more clear; using Capability Negotiations = is it possible that we have a topology where: AC is on ARCH - x and=20 the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing = everything in APs as well as ACs!!=20 Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with = the 802.11 capabilities advertised in the 802.11 Beacon frame. The = capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This = was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is = which parts of the 802.11 MAC management functionality would be implemented in = the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, = and some others that implement all of it in the AP. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture = draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of = 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Fri Jan 30 18:07:17 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 30 Jan 2004 10:07:17 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB198@orsmsx410.jf.intel.com> It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and=20 the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!!=20 Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Fri Jan 30 18:09:44 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 30 Jan 2004 10:09:44 -0800 Subject: [Capwap] AR name and AP name Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB199@orsmsx410.jf.intel.com> What do you mean by names? An AP knows it is an AP, so does an AC. Or are you talking about some form of ID/namespace? -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of S. Daniel Park Sent: Thursday, January 29, 2004 5:47 PM To: capwap@frascone.com Subject: [Capwap] AR name and AP name Hello Capwap I am wondering how APs and ARs know its name in lwapp architecture. Is it a manual configuration by administrator ? Thanks in advance Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics.=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From bob@airespace.com Fri Jan 30 18:20:25 2004 From: bob@airespace.com (Bob O'Hara) Date: Fri, 30 Jan 2004 10:20:25 -0800 Subject: [Capwap] AR name and AP name Message-ID: <55749BC69138654EBBC4C50BA4F55610D3993B@AIREMAIL.airespace.com> The LWAPP draft simply carries the names from AR to AP, and AP to AR. It does not state any requirements as to how these names are created, discovered, or applied. One solution is just as you suggest, allow the names to be created and applied manually by an administrator. Another alternative might be to automatically create a name for each device that reflects some permanent (or semi-permanent) information about the device, such as its address. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of S. Daniel Park Sent: Thursday, January 29, 2004 5:47 PM To: capwap@frascone.com Subject: [Capwap] AR name and AP name Hello Capwap I am wondering how APs and ARs know its name in lwapp architecture. Is it a manual configuration by administrator ? Thanks in advance Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics.=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From kempf@docomolabs-usa.com Fri Jan 30 22:25:01 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 30 Jan 2004 14:25:01 -0800 Subject: [Capwap] AR name and AP name References: <55749BC69138654EBBC4C50BA4F55610D3993B@AIREMAIL.airespace.com> Message-ID: <035f01c3e782$7faa0740$606015ac@dclkempt40> I would assume the name would depend on what is in the certificate, if a cert is being used for security between the AC and AP. That's typically an X.500 name or a DNS name. If the AP is using 802.1x or some other authentication protocol, then the name could be an NAI or something like that. How do other vendors do this? jak ----- Original Message ----- From: "Bob O'Hara" To: "S. Daniel Park" ; Sent: Friday, January 30, 2004 10:20 AM Subject: RE: [Capwap] AR name and AP name > The LWAPP draft simply carries the names from AR to AP, and AP to AR. > It does not state any requirements as to how these names are created, > discovered, or applied. One solution is just as you suggest, allow the > names to be created and applied manually by an administrator. Another > alternative might be to automatically create a name for each device that > reflects some permanent (or semi-permanent) information about the > device, such as its address. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of S. Daniel Park > Sent: Thursday, January 29, 2004 5:47 PM > To: capwap@frascone.com > Subject: [Capwap] AR name and AP name > > > > Hello Capwap > > > I am wondering how APs and ARs know its name in lwapp architecture. > Is it a manual configuration by administrator ? > > Thanks in advance > > > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > From pcalhoun@airespace.com Sat Jan 31 21:47:49 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sat, 31 Jan 2004 13:47:49 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC7EE@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E844.4C38B85E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The goal is not to describe the 802.11 capabilities to the client, but = rather for the AR and the AP to exchange their own capabilities. For = instance, is an AP capable of performing TKIP or AES encryption, etc. PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Peyush AGARWAL Sent: Wed 1/28/2004 4:22 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 Hi, The "Capabilities Negotiation" has been proposed in the Architecture = draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding = 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the = capabilities supported by the AP, therefore the requirement of = 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E844.4C38B85E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

The goal is not to describe the 802.11 capabilities to = the client, but rather for the AR and the AP to exchange their own = capabilities. For instance, is an AP capable of performing TKIP or AES = encryption, etc.

PatC


-----Original Message-----
From: capwap-admin@frascone.com on behalf of Peyush AGARWAL
Sent: Wed 1/28/2004 4:22 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR

Hi,

The "Capabilities Negotiation" has been proposed in the = Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention = of deciding 'the applicable API's between AP and AC'.
        The 802.11 'Beacons' already = contains the information of the capabilities supported by the AP, = therefore the requirement of 'capabilities negotiation' is not clear to = me.
Please clarify.

Thanks in advance.

Regards,
Peyush.

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap


------_=_NextPart_001_01C3E844.4C38B85E-- From pcalhoun@airespace.com Sat Jan 31 22:01:19 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sat, 31 Jan 2004 14:01:19 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC7F0@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E845.FE3564D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and=20 the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!!=20 Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E845.FE3564D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

I'm deeply concerned about the concept of = "architecture variants". What
this smells like to me is having multiple different architectures = that
don't interoperate. I see this as adding complexity to the market = (and
more specifically to the end user), and hampering interoperability.

Of course, we'll always have stand-alone APs... and I don't see why = the
IETF needs to be concerned about those. We should be focused on how = to
provide a scalable solution.

my 2 cents,

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Yang, Lily L
Sent: Fri 1/30/2004 10:07 AM
To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

It is conceivable that AP could just stick to one architecture = variant,
depending on the target market, price point, etc., while AC might = have
more flexibility to support multiple variants, esp. if the functions
required on AC for b is a superset for a., then supporting b means = it
can also support a -- but this could be grossly simplified view, so
don't take it too literally. But there might be ways to accomplish = some
level of interoperability across the spectrum.

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of Peyush AGARWAL
Sent: Thursday, January 29, 2004 10:02 PM
To: 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

That sounds good & informative.

But again to make the things more clear; using Capability = Negotiations
is it
possible that we have a topology where:

        AC is on ARCH - x and
        the APs present in the = network are on ARCH - a, b, c (where
a/b/c !=3D
x) ?

If the answer is yes, I feel that one has to end up implementing
everything
in APs as well as ACs!!

Regards,
Peyush.





-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Bob O'Hara
Sent: Wednesday, January 28, 2004 10:42 PM
To: Peyush AGARWAL; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


Peyush,

The negotiation between the AP and AR would not have anything to do = with
the
802.11 capabilities advertised in the 802.11 Beacon frame.  The
capabilities
in the proposed negotiation between AP and AR would have to do with = what
functions are available at either end of that protocol exchange.  = This
was
included in the draft to address the various functional splits that = are
already present in the several products already in the market.

One example of a function that might be part of this negotiation is
which
parts of the 802.11 MAC management functionality would be implemented = in
the
AP and which parts would be implemented in the AR. There are examples = of
products in the market that implement all of the MAC management in = the
AR-equivalent device, some that move various parts of that to the = AP,
and
some others that implement all of it in the AP.

 -Bob


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Peyush AGARWAL
Sent: Wednesday, January 28, 2004 4:23 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR


Hi,

The "Capabilities Negotiation" has been proposed in the = Architecture
draft
(draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the
applicable API's between AP and AC'.
        The 802.11 'Beacons' already = contains the information of the
capabilities supported by the AP, therefore the requirement of
'capabilities
negotiation' is not clear to me. Please clarify.

Thanks in advance.

Regards,
Peyush.

_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap


------_=_NextPart_001_01C3E845.FE3564D4-- From lily.l.yang@intel.com Sat Jan 31 22:24:37 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Sat, 31 Jan 2004 14:24:37 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB1A7@orsmsx410.jf.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E849.030E5AD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. =20 I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E849.030E5AD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

I understand the concern. I don’t know how much interoperability we = can achieve either. But it seems like that is the market reality we are = facing today. So we need to figure out what role, if there is a role, for IETF = to do here to achieve any interoperability. I think that is why the charter = calls for some architectural study first. The feasibility is still an open = question to me.

 

I believe even the standalone AP = can still benefit from the existence of a centralized controller to achieve = network-wide RF management and configuration. Of course, then it is not a strictly = “standalone” AP any more, but it may still be a pretty fat AP, handling some local = decisions (e.g., association) on its own, without forwarding every single packet = to the controller. I would think IETF/CAPWPA can still play a role in such = architecture.

 

-----Original = Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Saturday, January = 31, 2004 2:01 PM
To: Yang, Lily L; Peyush = AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] = Reg. Capabilities Negotiation between AP - AR

 

I'm deeply = concerned about the concept of "architecture variants". What
this smells like to me is having multiple different architectures = that
don't interoperate. I see this as adding complexity to the market = (and
more specifically to the end user), and hampering interoperability.

Of course, we'll always have stand-alone APs... and I don't see why = the
IETF needs to be concerned about those. We should be focused on how = to
provide a scalable solution.

my 2 cents,

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Yang, Lily L
Sent: Fri 1/30/2004 10:07 AM
To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

It is conceivable that AP could just stick to one architecture = variant,
depending on the target market, price point, etc., while AC might = have
more flexibility to support multiple variants, esp. if the functions
required on AC for b is a superset for a., then supporting b means = it
can also support a -- but this could be grossly simplified view, so
don't take it too literally. But there might be ways to accomplish = some
level of interoperability across the spectrum.

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of Peyush AGARWAL
Sent: Thursday, January 29, 2004 10:02 PM
To: 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

That sounds good & informative.

But again to make the things more clear; using Capability = Negotiations
is it
possible that we have a topology where:

        AC is on ARCH - x and
        the APs present in the = network are on ARCH - a, b, c (where
a/b/c !=3D
x) ?

If the answer is yes, I feel that one has to end up implementing
everything
in APs as well as ACs!!

Regards,
Peyush.





-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Bob O'Hara
Sent: Wednesday, January 28, 2004 10:42 PM
To: Peyush AGARWAL; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


Peyush,

The negotiation between the AP and AR would not have anything to do = with
the
802.11 capabilities advertised in the 802.11 Beacon frame.  The
capabilities
in the proposed negotiation between AP and AR would have to do with = what
functions are available at either end of that protocol exchange.  = This
was
included in the draft to address the various functional splits that = are
already present in the several products already in the market.

One example of a function that might be part of this negotiation is
which
parts of the 802.11 MAC management functionality would be implemented = in
the
AP and which parts would be implemented in the AR. There are examples = of
products in the market that implement all of the MAC management in = the
AR-equivalent device, some that move various parts of that to the = AP,
and
some others that implement all of it in the AP.

 -Bob


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Peyush AGARWAL
Sent: Wednesday, January 28, 2004 4:23 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR


Hi,

The "Capabilities Negotiation" has been proposed in the = Architecture
draft
(draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the
applicable API's between AP and AC'.
        The 802.11 'Beacons' already contains the information of the
capabilities supported by the AP, therefore the requirement of
'capabilities
negotiation' is not clear to me. Please clarify.

Thanks in advance.

Regards,
Peyush.

_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap

=00 ------_=_NextPart_001_01C3E849.030E5AD7-- From pcalhoun@airespace.com Sat Jan 31 22:41:02 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Sat, 31 Jan 2004 14:41:02 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC7F5@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E84B.4E2E8218 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe you are correct. It really boils down to one of three options: 1. Leave things as-is, 2. Implement a centralized network management component (what you are = describing) 3. A centralized controller approach Of course, option 1 will always exist, and there are markets where this = approach makes sense. As far as option 2, I believe that there are some pretty severe = drawbacks. For instance, RF management really needs access to RF information on a = packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of = various measurements some of which are specific to each clients. It is possible for APs to = constantly be polled for this information and let a network manager run algorithms. However, I believe = that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may = recall the NASes that would be polled frequently for "user information", and the fact that = these events caused a severe CPU drain on the NASes. RF information is even more dynamic, and I = suspect that there would be additional problems. There is also the issue where this option STILL = requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in = flash, and this is a=20 big concern for IT managers. Lastly, it seems like everyone (even the = incumbents are moving towards option 3). Obviously, I'm in favor of option 3. If you just look at the cellular = market, which evolved through the first two options, I believe that the current RAN approach of = centralizing functionality in the base station has made these networks scale.=20 I believe that we would try to benefit from the lessons learned in both = the dial-up and the cellular networks here in CAPWAP. PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. =20 I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E84B.4E2E8218 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

I believe you are correct. It really boils down to one = of three options:

1. Leave things as-is,
2. Implement a centralized network management component (what you are = describing)
3. A centralized controller approach

Of course, option 1 will always exist, and there are markets where this = approach
makes sense.

As far as option 2, I believe that there are some pretty severe = drawbacks. For instance,
RF management really needs access to RF information on a = packet-by-packet basis. RF information
is not just a single value (e.g. 1 is good), but really consists of = various measurements some
of which are specific to each clients. It is possible for APs to = constantly be polled for this
information and let a network manager run algorithms. However, I believe = that for those of us
that have lived through the dial-up NAS markets in the mid-90s, some may = recall the NASes that
would be polled frequently for "user information", and the = fact that these events caused a severe
CPU drain on the NASes. RF information is even more dynamic, and I = suspect that there would be
additional problems. There is also the issue where this option STILL = requires that security
information (specifically passwords for RADIUS, SNMP, etc) be stored in = flash, and this is a
big concern for IT managers. Lastly, it seems like everyone (even the = incumbents are moving towards
option 3).

Obviously, I'm in favor of option 3. If you just look at the cellular = market, which evolved through
the first two options, I believe that the current RAN approach of = centralizing functionality in the
base station has made these networks scale.

I believe that we would try to benefit from the lessons learned in both = the dial-up and the cellular
networks here in CAPWAP.

PatC


-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM
To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

I understand the concern. I don't know how much interoperability we = can
achieve either. But it seems like that is the market reality we are
facing today. So we need to figure out what role, if there is a = role,
for IETF to do here to achieve any interoperability. I think that is = why
the charter calls for some architectural study first. The feasibility = is
still an open question to me.



I believe even the standalone AP can still benefit from the existence = of
a centralized controller to achieve network-wide RF management and
configuration. Of course, then it is not a strictly = "standalone" AP any
more, but it may still be a pretty fat AP, handling some local = decisions
(e.g., association) on its own, without forwarding every single = packet
to the controller. I would think IETF/CAPWPA can still play a role = in
such architecture.



-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Saturday, January 31, 2004 2:01 PM
To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR



I'm deeply concerned about the concept of "architecture = variants". What
this smells like to me is having multiple different architectures = that
don't interoperate. I see this as adding complexity to the market = (and
more specifically to the end user), and hampering interoperability.

Of course, we'll always have stand-alone APs... and I don't see why = the
IETF needs to be concerned about those. We should be focused on how = to
provide a scalable solution.

my 2 cents,

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Yang, Lily L
Sent: Fri 1/30/2004 10:07 AM
To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

It is conceivable that AP could just stick to one architecture = variant,
depending on the target market, price point, etc., while AC might = have
more flexibility to support multiple variants, esp. if the functions
required on AC for b is a superset for a., then supporting b means = it
can also support a -- but this could be grossly simplified view, so
don't take it too literally. But there might be ways to accomplish = some
level of interoperability across the spectrum.

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of Peyush AGARWAL
Sent: Thursday, January 29, 2004 10:02 PM
To: 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

That sounds good & informative.

But again to make the things more clear; using Capability = Negotiations
is it
possible that we have a topology where:

        AC is on ARCH - x and
        the APs present in the = network are on ARCH - a, b, c (where
a/b/c !=3D
x) ?

If the answer is yes, I feel that one has to end up implementing
everything
in APs as well as ACs!!

Regards,
Peyush.





-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Bob O'Hara
Sent: Wednesday, January 28, 2004 10:42 PM
To: Peyush AGARWAL; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


Peyush,

The negotiation between the AP and AR would not have anything to do = with
the
802.11 capabilities advertised in the 802.11 Beacon frame.  The
capabilities
in the proposed negotiation between AP and AR would have to do with = what
functions are available at either end of that protocol exchange.  = This
was
included in the draft to address the various functional splits that = are
already present in the several products already in the market.

One example of a function that might be part of this negotiation is
which
parts of the 802.11 MAC management functionality would be implemented = in
the
AP and which parts would be implemented in the AR. There are examples = of
products in the market that implement all of the MAC management in = the
AR-equivalent device, some that move various parts of that to the = AP,
and
some others that implement all of it in the AP.

 -Bob


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Peyush AGARWAL
Sent: Wednesday, January 28, 2004 4:23 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR


Hi,

The "Capabilities Negotiation" has been proposed in the = Architecture
draft
(draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the
applicable API's between AP and AC'.
        The 802.11 'Beacons' already = contains the information of the
capabilities supported by the AP, therefore the requirement of
'capabilities
negotiation' is not clear to me. Please clarify.

Thanks in advance.

Regards,
Peyush.

_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap





------_=_NextPart_001_01C3E84B.4E2E8218--