Original text:
 “The design of the =
CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by =
external entities.”
Original text: 
“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.”

<=
font
size=3D2 face=3DArial>Clarification: 
This objective arose during =
discussions on the scope of the CAPWAP protocol in managing WLAN =
systems. The intent was to highlight the 'completeness' of protocol in =
terms of achieving its interoperability =
goals.
--XX—

 =

4. Section: 5.2 Desirable =
Objectives

Comment: 
“Why aren't the items =
in this section listed as SHOULD instead of =
MUST?”

Original =
text:
Protocol Requirements for =
all objectives categorized as Desirable Objectives include those in =
subsections 5.2.1 through 5.2.5. =

<=
font
size=3D2 face=3DArial>Clarification: 
The Desirable Objectives as =
a category can be listed as 'SHOULD'. However, the individual objectives =
that make up the category are still 'MUST', because they represent =
mandatory operations for the protocol - provided that the protocol =
chooses to realize a Desirable =
Objective.
--XX—

 =

Sam Hartman’s =
Review

 =

5. Section: 5.1.8 CAPWAP =
Protocol Security, Description

Comment: =

“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.”

Original text: (Last =
paragraph of Description)
“CAPWAP MUST NOT =
prevent the use of asymmetric authentication. The security =
considerations of such asymmetric authentication are described in the =
Security Considerations =
section.”

Suggested new text: From =
Charles Clancy [To be inserted after above-paragraph of original text] =
– 
“If the CAPWAP =
protocol meets the criteria to require automated key management per BCP =
107, then mutual authentication MUST be accomplished via an =
authenticated key =
exchange."

Suggested new text: =

Add reference to BCP =
107.
<=
font
size=3D2 face=3DArial>--XX—

 =

6. Section: 5.1.8 CAPWAP =
Protocol Security, Description, Paragraph =
5

Comment: 
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.

Original =
text:
Once WTPs and WLAN =
controller have been mutually authenticated, information exchanges =
between them must be secured against various security =
threats.

Suggested text: From =
Charles Clancy- 
"Once WTPs and WLAN =
controller have been mutually authenticated, information exchanges =
between them must be secured against various security threats. So the =
CAPWAP protocol MUST provide integrity-protection and replay-protection. =
The protocol SHOULD provide confidentiality through =
encryption."
--XX—

 =

7. Section: 5 Objectives, =
Introduction

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

Original =
text:
“The objectives =
described in this document have been prioritized based on their =
immediate significance in the development and evaluation of a control =
and provisioning protocol for large-scale WLAN deployments. =
Additionally, one category is provided for requirements gathered from =
network service operators.  These are specific need that arise from =
operators' experiencese in deploying and managing large-scale WLANs. The =
priorities are;

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

The priorities have been =
assigned to individual objectives in accordance with working group =
discussions.”

Suggested new text: =

“The objectives =
described in this document have been prioritized based on their =
immediate significance in the development and evaluation of a control =
and provisioning protocol for large-scale WLAN =
deployments.

The priorities =
are;

i.  Mandatory and =
Accepted Objectives
ii.  Desirable =
Objectives
iii.  =
Non-Objectives

The priorities have been =
assigned to individual objectives in accordance with working group =
discussions.

Furthermore, a distinct =
category of objectives is provided based on requirements gathered from =
network service operators.  These are specific needs that arise from =
operators' experiences in deploying and managing large-scale =
WLANs.

a. Operator =
Requirements”

 =

--XX—

Original =
text:
 “The design of the CAPWAP protocol MUST NOT allow for any =
compromises to the WLAN system by external =
entities.”
Original =
text: 
“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.”

Clarification: 
This objective arose during discussions on the scope of the =
CAPWAP protocol in managing WLAN systems. The intent was to highlight =
the 'completeness' of protocol in terms of achieving its =
interoperability goals.
--XX—

4. Section: 5.2 Desirable =
Objectives

Comment: =

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

Original =
text:
Protocol =
Requirements for all objectives categorized as Desirable Objectives =
include those in subsections 5.2.1 through 5.2.5. =

Clarification: 
The Desirable Objectives as a category can be listed as =
'SHOULD'. However, the individual objectives that make up the category =
are still 'MUST', because they represent mandatory operations for the =
protocol - provided that the protocol chooses to realize a Desirable =
Objective.
--XX—

Sam =
Hartman’s Review

5. Section: 5.1.8 CAPWAP Protocol Security, =
Description

Comment: =

“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.”

Original =
text: (Last paragraph of =
Description)
“CAPWAP MUST NOT prevent the use of asymmetric =
authentication. The security considerations of such asymmetric =
authentication are described in the Security Considerations section.R=
21;

Suggested =
new text: From Charles Clancy [To be inserted after above-paragraph of =
original text] – 
“If the CAPWAP protocol meets the criteria to require =
automated key management per BCP 107, then mutual authentication MUST =
be accomplished via an authenticated key =
exchange."

Suggested =
new text: 
Add reference to =
BCP 107.
--XX—

6. Section: 5.1.8 CAPWAP Protocol Security, Description, =
Paragraph 5

Comment: =

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.

Original text:
Once WTPs and WLAN controller have been mutually authenticated, =
information exchanges between them must be secured against various =
security threats.

Suggested text: From Charles Clancy- =

"Once WTPs and WLAN =
controller have been mutually authenticated, information exchanges =
between them must be secured against various security threats. So the =
CAPWAP protocol MUST provide integrity-protection and =
replay-protection. The protocol SHOULD provide confidentiality through =
encryption."
--XX—=

7. Section: 5 Objectives, =
Introduction

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

Original =
text:
“The =
objectives described in this document have been prioritized based on =
their immediate significance in the development and evaluation of a =
control and provisioning protocol for large-scale WLAN deployments. =
Additionally, one category is provided for requirements gathered from =
network service operators.  These are specific need that arise =
from operators' experiencese in deploying and managing large-scale =
WLANs. The priorities are;

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

The =
priorities have been assigned to individual objectives in accordance =
with working group =
discussions.”

Suggested =
new text: 
“The =
objectives described in this document have been prioritized based on =
their immediate significance in the development and evaluation of a =
control and provisioning protocol for large-scale WLAN =
deployments.

The =
priorities are;

i.  =
Mandatory and Accepted Objectives
ii.  Desirable =
Objectives
iii.  =
Non-Objectives

The =
priorities have been assigned to individual objectives in accordance =
with working group =
discussions.

Furthermore, a distinct category of objectives is provided based =
on requirements gathered from network service operators.  These =
are specific needs that arise from operators' experiences in =
deploying and managing large-scale =
WLANs.

a. =
Operator Requirements”

--XX—

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

                          Workshop Program and Call for Participation<=
/span>
---------------------
---------------------

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+

   =
Type:  TBD

   =
Length:  1

   =
Operating Mode:  The selected mode for WTP =
operation

        0: Control-bias =
mode, WTP operates in Split-MAC =
mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode 