Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
RFC 4564

Note: This ballot was opened for revision 04 and is now closed.

(Bert Wijnen) Yes

(Brian Carpenter) No Objection

Comment (2006-02-16)
No email
send info
>   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?

(Ted Hardie) No Objection

Comment (2006-02-15)
No email
send info
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.

(Sam Hartman) (was Discuss) No Objection

Comment (2006-02-16)
No email
send info
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