Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
draft-ietf-capwap-objectives-04

[Ballot discuss]
Section 5.1.8 implies that an authenticated key exchange is optional.
I think that BCP 107 will require an authenticated key exchange for
this protocol.

In the following text, please describe what security services are
meant; probable services include integrity and confidentiality.
>Once WTPs and WLAN controller have been mutually authenticated,
>  information exchanges between them must be secured against various
>  security threats.

[Ballot comment]
The introduction to section 5 implies that operator requirements are
valued less than non-objectives.  I don't think that is the message the IETF wants to send to the operator community.

>  The priorities are;

>  i.  Mandatory and Accepted Objectives
>  ii.  Desirable Objectives
>  iii.  Non-Objectives
>  iv.  Operator Requirements

[Ballot comment]
>  Protocol Requirement:
>
>  The CAPWAP protocol MUST support mutual authentication of WTPs and
>  the centralized controller.  It must also ensure that information
>  exchanges between them are secured.

Does that mean encrypted or only integrity-protected?

>  Protocol Requirement:
>
>  The design of the CAPWAP protocol MUST NOT allow for any compromises
>  to the WLAN system by external entities.

Strange phrasing. Suggestion:

  The design of the CAPWAP protocol MUST protect against any compromises
  of the WLAN system by external entities.

>  Protocol Requirement:
>
>  Any WTP or WLAN controller vendor or any person MUST be able to
>  implement the CAPWAP protocol from the specification itself and by
>  that it is required that all such implementations do interoperate.

Since this is a basic requirement of all IETF standards, why is it listed?

> 5.2.  Desirable Objectives

Why aren't the items in this section listed as SHOULD instead of MUST?

[Ballot comment]
I found this requirements:

5.3.2.  Technical Specifications

  Classification: General

  Description:

  The CAPWAP protocol must not require AC and WTP vendors to share
  technical specifications to establish compatibility.  The protocol
  specifications alone must be sufficient for compatibility.

  Protocol Requirement:

  WTP vendors SHOULD NOT have to share technical specifications for
  hardware and software to AC vendors in order for interoperability to
  be achieved.

To be a bit bizarre.  Description of what "technical specification" means might
be useful, but I think this is so basic a requirement (the protocol spec is what
gets multiple vendors to interoperability) that it just seems strange to include it.

PROTO-writeup (for the record):

-----Original Message-----
From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]
Sent: Thursday, February 09, 2006 06:58
To: Wijnen, Bert (Bert)
Cc: Dorothy.Gellert@nokia.com; David Kessens (E-mail)
Subject: write-up for the Objectives draft
Importance: High


Bert,

With acknowledgement from DorothyG due (as also in the case of earlier write-up)
The following is the write-up with the answers inline with the questions (unlike
The previous one for Evaluation Draft) for Objectives Draft
http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-04.txt.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?
        This has been reviewed by the chairs personally. The chairs believe this is ready for publication after due IESG review and process.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?
        It has had the benefit of review from WG members and rigorous review from IEEE802.11
        WLAN WG as well through our liaison Dorothy Stanley.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?
       
        the draft has gone through four revisions as a result of the extended review spanning
        nearly a year.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

        The informational draft breaks down requirements as a result of Objectives
        Exercise into (a) mandatory & accepted objectives (b) desired objectives and
        (c) non-objectives. While there remains a question whether (c) is indeed
        Redundant – it serves to provide a trail of why some objectives were considered
        Rejected by the WG. This is a meta-concern but the WG is comfortable with this.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?
       
        the WG has, initially very slowly, and later with involvement when the authors
        started listing objectives and seeking discussion, responded well. given the
        Objectives draft was to be the prime basis for deciding the baseline protocol
        And that meeting the right set of objectives is key to market success of the
        Resulting std. in which the industry stakeholders would invest in implementing
        Served to do enough justice to a look at the objectives. By and large the
        Candidate protocols under evaluation met most of the objectives.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

        No threats of appeal. No controversial proceeding on this draft’s count.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

        Yes.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

        this is an informational draft. no normative references to IDs

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary
            This document presents objectives for an interoperable protocol for
  the Control and Provisioning of Wireless Access Points (CAPWAP).  The
  document aims to establish a set of focused requirements for the
  development and evaluation of a CAPWAP protocol.  The objectives
  address Architecture, Operation, Security and Network Operator
  Requirements that are necessary to enable interoperability among
  wireless local area network (WLAN) architectural variants.


·              Working Group Summary:
Support for local-MAC and split-MAC (obj-5.1.1 related to logical groups) had generated quite some spirited discussions. It aims to seek support for both modes as identified in RFC4118. also worth noting is the NAT traversal requirement – which was not in initial revision; that brought a desired objective in (5.1.15).
Another noteworthy (accepted objective; but still debated on its variants) is the firmware update requirement (whether trigger is enough or more needs specified in
Protocol).
·              Protocol Quality: this is an informational objectives draft. no protocol is
    described.





Regards,

-mani & Dorothy

======

State Change Notice email list have been change to mmani@avaya.com, dorothy.gellert@nokia.com, saravanan.govindan@sg.panasonic.com, yaoth@huawei.com, zhouwenhui@chinamobile.com, lily.l.yang@intel.com, hong.cheng@sg.panasonic.com from mmani@avaya.com, dorothy.gellert@nokia.com