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
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
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
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