[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: laugh test - capwap
The suggested charter seems to state that the WG-to-be
(if ever) needs to look at existing protocols (first).
That is good.
I know that from the NM community I have heard concerns that
there is a risk of proliferation of protocols to do a lot of
the same thing all over again. So we need to make sure that
the WG will not just start off creating new protocols while
existing ones might be able to do the job.
Thanks,
Bert
> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: maandag 29 september 2003 3:08
> To: iesg
> Cc: iab
> Subject: laugh test - capwap
>
>
> capwap proponents have sent a proposed charter to me, though this
> final verseion seems not to have been circulated on the list. they
> said (indented text, which is slightly edited, is proponents')
>
> After list discussion, Dorothy [Stanley of IEEE 802.11] and I
> would like to propose the CAPWAP WG charter below. The charter
> has an initial problem statement and architecture component
> (already underway and expected to be short), then a protocol
> design component. Note that particular attention was paid to
> what the WG would not do, these points are listed in nongoals,
> to clearly delineate this work from what the IEEE 802.11 WG
> does.
>
> first, they propose some chairs:
>
> For working group chairs, we looked around for people with the
> following qualities:
>
> - Experience in IETF process and politics, who could navigate
> the tricky shoals of concensus building to bring the work to
> the harbor of successful conclusion (:-),
>
> - Support, at minimum, and active interest, perferably, from
> their employer (if any) to avoid conflicts between their day
> job and IETF work,
>
> - Technical knowledge of 802.11 and preferably participation
> in the 802.11 WG.
>
> In the event that we could not find two people with all these
> qualities, we were prepared to propose candidates that
> complemented each other.
>
> We came up with the following suggestions:
>
> Co-chair 1: John Loughney, Nokia
> <john.loughney@nokia.com>. John has extensive IETF experience
> (Diameter draft editor, NSIS chair), and support from Nokia.
>
> Co-chair 2: Mahalingam Mani, Avaya <mmani@avaya.com>.
> Mahalingam has participated in the 802.11 WG and was involved
> in the formation of, and contributions to the 802 LinkSec group
> (working on link level security for 802 protocols), and support
> from Avaya.
>
> Alternate Co-chair 2: Dorothy Gellert, Nokia
> <dorothy.gellert@nokia.com>. Dorothy has extensive 802.11
> technical experience and has participated in the 802.11 WG.
>
> We are proposing Dorothy as a backup because we did not want to
> have two co-chairs from the same company, and Dorothy doesn't
> have any IETF experience, so she would not complement
> Mahalingam in that respect. However, we talked to several
> people who recommended Dorothy highly so we wanted to include
> her in case Mahalingam was unacceptable for some reason.
>
> i note that this is a serious change from the previous proposal for
> chairs, which was dorothy stanley and bill arbaugh. i know bill
> was overloaded, but it is not clear to me why dorothy stanley is no
> longer a player. it would be good to have someone with feet in
> both camps, ieee and ietf.
>
> then they give the appended draft charter, which i have edited
> slightly for completeness, english, and normalization of format.
>
> i would be very interested in feedback, especially from folk other
> than the proponents (HINT HINT).
>
> randy
>
> ---
>
> Control and Provisioning of Wireless Access Points (capwap)
>
> Area:
> OPS
>
> Chairs:
> TBD
>
> Operations and Management Area Director(s):
> Randy Bush <randy@psg.com>
> Bert Wijnen <bwijnen@lucent.com>
>
> Operations and Management Area Advisor:
> Randy Bush <randy@psg.com>
>
> Mailing List:
> List: lwapp@frascone.com
> Subscribe: lwapp-request@frascone.com
> Body: subscribe in Subject line
> Archive: http://mail.frascone.com/pipermail/public/lwapp/
>
> Description of Working Group:
>
> As the size and complexity of IEEE 802.11 wireless networks have
> increased, problems in the deployment, management, and usability of
> these networks have become evident.
> draft-calhoun-capwap-problem-statement-00.txt describes some of
> those problems. In addition, security considerations have become
> increasingly important as IEEE 802.11 networks have been deployed
> in situations where their use in accessing sensitive data must be
> restricted for business or other reasons. While there are many
> possible approaches to solving these problems, most of them involve
> IP-level protocols in some fashion. To the extent changes to
> existing IETF protocols are necessary or new IP-level protocols
> must be standardized to facilitate interoperability, this work is
> an appropriate topic for the IETF.
>
> [ note that the last sentence makes no sense to me. i suspect that
> there is an s/IETF/IEEE/ needed somewhere in it. ]
>
> The charter of the CAPWAP Working Group is to investigate and
> design a protocol for the purpose of simplifying the deployment,
> management, and usability of IEEE 802.11 wireless networks for
> Internet use. The Working Group will attempt to utilize existing
> IETF protocols where possible, but will engage in new design if
> necessary. The Working Group's designs will focus on the "split
> AP" architecture. The split AP architecture centralizes processing
> of access point (AP) management functions, such as inter-AP
> configuration and control, and non-realtime host functions, such as
> data transport and host authentication, in a management entity,
> typically an access router (AR). The IEEE 802.11 APs continue to
> perform real-time host functions. The split AP architecture does
> not involve any changes in IEEE 802.11 standards, since the IEEE
> 802.11 specification says nothing about the architecture of the
> IEEE 802.11 access point. This new architecture has been adopted
> by many manufacturers, each with some variation. Creating an
> interoperable protocol between the AP and the AR will benefit the
> network operator community by allowing operators to build networks
> with equipment from a variety of conforming vendors.
>
> Specific Working Group work items are:
> - Clear problem statement and description of the split AP
> architecture,
> - CAPWAP security requirements, defining the needs for security
> between the AP and the AR both for host data transport and for
> AP-AR signalling and control,
> - A protocol for implementing the split AP architecture,
> including the following functionality:
> . Discovery of ARs by APs (this work should point to existing
> IETF standards, if possible)
> . Auto-organization of APs and ARs into a managed wireless
> access network, including failover if an AR should fail,
> . A tunneling protocol for IEEE 802.11 non-realtime
> host-related signalling and data between the AP and the AR,
> . Support for configuration of the AP by the AR, including
> secure download and booting of code to the AP (some aspects
> of this task may involve existing IETF standards),
> . Security for both tunneled host data and AR-AP signaling, as
> necessary to address the requirements (this work may involve
> utilizing existing IETF standards).
>
> The intent of the CAPWAP Working Group is to complete the protocol
> specification as quickly as prudently possible and to serve as a
> forum for discussion of issues found when testing interoperability,
> in typical IETF fashion.
>
> While not specifically a work item, the Working Group will attempt
> to make all designs as independent of the IEEE 802.11 radio
> protocol as possible, so that the protocol might, in the future be
> used with other radio protocols. However, in any situation where a
> tradeoff between simplicity/speed of design completion and
> extensibility is required, the Working Group will opt for the
> former. The Working Group will also co-ordinate closely with the
> IEEE 802.11 WG.
>
> Specific non-goals of this work are:
>
> - Support for general, inter-subnet micromobility,
> - Interoperable APIs for downloaded AP code images,
> - Any IP-layer work that would require changes to the IEEE 802.11
> MAC layer,
> - Dependence on yet to be approved IEEE 802.11 work or drafts,
> - Support for an inter-AP communication protocol, like IEEE
> 802.11f,
> - Direct joint development of protocols with the IEEE 802.11 WG.
>
> Working Group protocol documents and the security requirements will
> be sent to the Security Area Advisory Group (SAAG) for review prior
> to submission to the IESG.
>
> Goals and Milestones:
>
> Mar 2004 Complete problem statement draft and architecture
> description and submit to IESG for publication as
> Informational.
>
> Mar 2004 Complete security requirements and submit to SAAG for
> review. Submit to IESG for publication as Informational
> when SAAG review is complete.
>
> Nov 2004 First draft of CAPWAP protocol complete and ready for
> review.
>
> Mar 2005 Complete CAPWAP protocol and submit to SAAG for review.
> Submit to IESG for publication as Proposed Standard when
> SAAG review is complete.
>
> -30-
>
>