laugh test - capwap

[Randy Bush <randy@psg.com>]

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-