Subject: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Apr 2007 22:24:44 -0400

Hi All,

As you have seen in previous e-mail from the editors, we discussed 8  
issues at the CAPWAP WG meeting in Prague.  This message is an  
attempt to confirm our consensus on those issues, and to close all  
eight issues by April 9th, so that the changes can be made in the  
CAPWAP documents and sent to the IEEE for review starting on April 10th.

Please Note:  This is a ONE WEEK consensus call ending on APRIL 9th,  
2007.

Usually, we have two week consensus calls, but given that the agreed  
resolutions were sent to the  mailing two weeks ago, and that there  
has been little or no objection to the proposed changes on the  
mailing list, we are having  a ONE WEEK consensus call, in order to  
allow the group to meet our IEEE review deadline.  If anyone has a  
strong objection to holding a one week consensus call on one or more  
of these issues, please let us know, and we will extend the consensus  
call for those issues to two weeks.

Three of the open issues are editorial, which means that the editors  
will make the fixes and close these issues.  Please let us know if  
there is any objection to closing the three issues listed below after  
the corresponding editorial changes have been made.

248 Both IPv4 and IPv6 Addresses not required.
250 Clarification onDTLSRehandshake/DTLSPeerAuthorize/ 
DTLSIncomingSession
252 Hearbeat timer is undefined

The resolution to one issue had been previously agreed on the list,  
but the edits were not included in the -02 draft, due to an  
oversight.  The changes were mentioned in the meeting and  
recirculated to the list by Pat Calhoun on March 19th, and there has  
been no objection to making them.  So, unless there is any objection  
before April 9th, the agreed change will be made by the editors, and  
the issue will be closed.

217 What is frame format with WTP encrypts/decrypts?

There were also four substantive issues discussed by the group:

247 MAC Addresses can be larger than 6 octets

For this issue, we agreed that we should be able to handle 8-byte MAC  
addresses in the CAPWAP protocol, and that it would be good to be  
flexible to other MAC address lengths.  There was general agreement  
in the room for a solution that replaced raw MAC addresses with a  
type-address pair.  Pat Calhoun proposed text on the list on March  
19th that uses the type-address pair, and Puneet Agarwal raised an  
objection indicating that he would prefer a type-length-address  
triplet.  No one else has offered support for the type-length-address  
triplet approach, so the chairs believe that we have rough consensus  
to proceed with the type-address approach, as discussed in Prague.

249 UDP-Lite as optional transport for CAPWAP

There was general agreement in Prague that UDP-Lite should be the  
mandatory transport for IPv6, with a checksum coverage length of 8.   
Text to this effect was circulated on the list on March 19th, and  
there has been no objection.  There was a question about CAPWAP's use  
of UDP ports, and a separate issues (#254) has been opened to clarify  
that behavior.  So, seeing no objection, the chairs believe that the  
group has consensus to make the changes circulated on March 19th to  
address this issue.

251 Retransmission of control packets is not exponential

There was agreement in Prague that this needed to be fixed.  Proposed  
text was sent to the list by Pat Calhoun on March 19th, and no  
objections or questions have been raised about that text.  So, the  
chairs believe that the WG has consensus to resolve this issue by  
making the change proposed on the list.

138 Support and negotiation of WTP data encryption in the CAPWAP  
protocol

This was the most contentious issue discussed in Prague, and it was  
difficult for us to reach consensus within the room about how to  
close this issue.  In the end, we reached consensus that the working  
group could accept the following resolution:

    To provide system component interoperability, the WTP and AC must
    support 802.11 encryption/decryption at the WTP.  The WTP and AC MAY
    support 802.11 encryption/decryption at the AC.

This text was circulated on the list by Pat Calhoun on March 19th.   
There has been no objection on the mailing list, so the chairs  
believe that the WG has rough consensus to proceed with this change,  
as circulated on the list.

Mani, Dorothy & Margaret
The CAPWAP Co-Chairs

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

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

---

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Fri, 6 Apr 2007 11:03:13 -0700

Here is my feedback on the consensus request.

Issue #217: Figure 3 needs to be made conistent with the proposed text.
             The Protected field should say "WTP/AC".

Issue #247 - Support the proposed text using "Length" field only.

Issue #249 - Support making UDP-lite mandatory for IPv6.

Issue #138 - Have expressed support in separate email in favor of
             making only encryption/decryption at WTP mandatory.

Thanks,
Abhijit

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Monday, April 02, 2007 7:25 PM
To: capwap
Cc: Dorothy Gellert
Subject: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249,
#250,#251 & #252

Hi All,

As you have seen in previous e-mail from the editors, we discussed 8
issues at the CAPWAP WG meeting in Prague.  This message is an attempt
to confirm our consensus on those issues, and to close all eight issues
by April 9th, so that the changes can be made in the CAPWAP documents
and sent to the IEEE for review starting on April 10th.

Usually, we have two week consensus calls, but given that the agreed
resolutions were sent to the  mailing two weeks ago, and that there has
been little or no objection to the proposed changes on the mailing list,
we are having  a ONE WEEK consensus call, in order to allow the group to
meet our IEEE review deadline.  If anyone has a strong objection to
holding a one week consensus call on one or more of these issues, please
let us know, and we will extend the consensus call for those issues to
two weeks.

Three of the open issues are editorial, which means that the editors
will make the fixes and close these issues.  Please let us know if there
is any objection to closing the three issues listed below after the
corresponding editorial changes have been made.

The resolution to one issue had been previously agreed on the list, but
the edits were not included in the -02 draft, due to an oversight.  The
changes were mentioned in the meeting and recirculated to the list by
Pat Calhoun on March 19th, and there has been no objection to making
them.  So, unless there is any objection before April 9th, the agreed
change will be made by the editors, and the issue will be closed.

For this issue, we agreed that we should be able to handle 8-byte MAC
addresses in the CAPWAP protocol, and that it would be good to be
flexible to other MAC address lengths.  There was general agreement in
the room for a solution that replaced raw MAC addresses with a
type-address pair.  Pat Calhoun proposed text on the list on March 19th
that uses the type-address pair, and Puneet Agarwal raised an objection
indicating that he would prefer a type-length-address triplet.  No one
else has offered support for the type-length-address triplet approach,
so the chairs believe that we have rough consensus to proceed with the
type-address approach, as discussed in Prague.

There was general agreement in Prague that UDP-Lite should be the  
mandatory transport for IPv6, with a checksum coverage length of 8.   
Text to this effect was circulated on the list on March 19th, and there
has been no objection.  There was a question about CAPWAP's use of UDP
ports, and a separate issues (#254) has been opened to clarify that
behavior.  So, seeing no objection, the chairs believe that the group
has consensus to make the changes circulated on March 19th to address
this issue.

There was agreement in Prague that this needed to be fixed.  Proposed
text was sent to the list by Pat Calhoun on March 19th, and no
objections or questions have been raised about that text.  So, the
chairs believe that the WG has consensus to resolve this issue by making
the change proposed on the list.

This was the most contentious issue discussed in Prague, and it was
difficult for us to reach consensus within the room about how to close
this issue.  In the end, we reached consensus that the working group
could accept the following resolution:

This text was circulated on the list by Pat Calhoun on March 19th.   
There has been no objection on the mailing list, so the chairs believe
that the WG has rough consensus to proceed with this change, as
circulated on the list.

Mani, Dorothy & Margaret
The CAPWAP Co-Chairs

---

From: Jim Murphy <[email-masked]>
Date: Fri, 06 Apr 2007 14:16:07 -0700

Here is my feedback on the consensus request:

For the following issues I accept the proposed solutions
as detailed in the attached email:

For the following issue I accept the proposed solution
as further refined on the list by Puneet and Pat:

Thanks,

Jim

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 11 Apr 2007 13:35:15 -0400

Hi All,

Here are the results of the call for consensus confirmation that was  
sent to the list on April 2nd.

> 252 Hearbeat timer is undefined

No one objected to the editors' proposed resolutions to these issues.

> 217 What is frame format with WTP encrypts/decrypts?

No one objected to including the previously-agreed fix in the new  
document.

> 247 MAC Addresses can be larger than 6 octets

There was discussion of this issue, and consensus emerged to adopt  
the editors' proposed resolution with one modification:  the type  
field will be changed to a length field.

> 249 UDP-Lite as optional transport for CAPWAP

There was no disagreement with the editors' proposed resolution.

> 251 Retransmission of control packets is not exponential

There was no disagreement with the editors' proposed resolution.

> 138 Support and negotiation of WTP data encryption in the CAPWAP

There was some discussion of this issue, with two people who were not  
in Prague speaking out against the proposed resolution and two people  
who were not in Prague speaking out in favor of the proposed  
resolution.  There were also messages from some of the people who did  
attend the meeting in Prague, supporting the conclusions that we  
reached at the meeting, even in light of the arguments made on the list.

So, the chairs believe that the group continues to have rough  
consensus to proceed with the proposed resolution to issue #138, as  
reached in Prague.

The editors will now publish documents with the agreed changes, so  
that we can send both documents (the CAPWAP base spec and the IEEE  
802.11 binding) to the IEEE for Review.  The IEEE needs about one  
month to review these documents before their meeting in May, so we  
will be working to get these documents to them as quickly as possible.

We also expect to be starting a Working Group Last Call  on both  
documents fairly soon, once we have determined the status of a few  
remaining issues.

Dorothy, Mani & Margaret
The CAPWAP WG Chairs

---

From: "Sudhanshu" <[email-masked]>
Date: Wed, 11 Apr 2007 12:03:31 -0700

Please see my inline comments.

-----Original Message-----

> 248 Both IPv4 and IPv6 Addresses not required.
[Suds] Reiterate my previous position, sending both addresses IPv4 and IPv6
should not be precluded, especially in the "Discovery Response". 

[Suds] As I said in my previous response, proposed resolution should also
address figure 3. 
	"Protected" field will be edited by both AC/WTP.

[Suds] I disagree with this assessment. As the issues subject says, UDP-lite
should be optional, but the proposed solution does not make it clear. UDP
and UDP-lite both option should be valid for IPv6.

[Suds] I am not very clear behind this timer getting tied with the echo
interval. Editor(s) please comment.

---

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Wed, 11 Apr 2007 12:13:19 -0700

I agree with Sudhanshu on Issue 217. Fig. 3 needs to be made
consistent with the accepted text.

In Fig 3. in the bindings doc, we need to replace

	Protected               AC

with

	Protected               WTP/AC

Here is the updated figure:
------------------------------------------------------------------------
------
           		MAC header field        Location
                   Frame Control:
                           Version                 AC
                           ToDS                    AC
                           FromDS                  AC
                           Type                    AC
                           SubType                 AC
                           MoreFrag                WTP/AC
                           Retry                   WTP
                           Pwr Mgmt                -
                           MoreData                WTP
                           Protected               WTP/AC 
                           Order                   AC
                   Duration:                       WTP
                   Address 1:                      AC
                   Address 2:                      AC
                   Address 3:                      AC
                   Sequence Ctrl:                  WTP
                   Address 4:                      AC
                   QoS Control:                    AC
                   Frame Body:                     AC
                   FCS:                            WTP

       Figure 3: Population of the IEEE 802.11 MAC header Fields for
                              Downlink Frames 

------------------------------------------------------------------------
------

Thanks,
Abhijit

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 12:04 PM
To: 'Margaret Wasserman'; 'capwap'
Subject: Re: [Capwap] Fwd: CONSENSUS CONFIRMATION: #138, #217, #247,
#248,#249, #250, #251 & #252

-----Original Message-----

> 248 Both IPv4 and IPv6 Addresses not required.
[Suds] Reiterate my previous position, sending both addresses IPv4 and
IPv6 should not be precluded, especially in the "Discovery Response". 

[Suds] As I said in my previous response, proposed resolution should
also address figure 3. 
	"Protected" field will be edited by both AC/WTP.

[Suds] I disagree with this assessment. As the issues subject says,
UDP-lite should be optional, but the proposed solution does not make it
clear. UDP and UDP-lite both option should be valid for IPv6.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 11 Apr 2007 17:04:21 -0700

I have made the change in the latest draft as it is necessary to be
consistent with the accepted text.

PatC 

-----Original Message-----
From: Abhijit Choudhury (achoudhu) 
Sent: Wednesday, April 11, 2007 12:13 PM
To: Sudhanshu; Margaret Wasserman; capwap
Subject: [Capwap] Issue 217

I agree with Sudhanshu on Issue 217. Fig. 3 needs to be made consistent
with the accepted text.

	Protected               AC

with

	Protected               WTP/AC

Thanks,
Abhijit

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 12 Apr 2007 11:46:10 -0400

Hi Abhijit,

I'm sorry for not mentioning Sudhanshu's correction in the previous  
message.  This is a necessary correction, as Pat has already indicated.

I view this as a helpful amendment to the text that Pat circulated,  
and not as an objection to the proposed changes.

Thanks to you, and especially to Sudhanshu for noticing this!

Margaret

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 12 Apr 2007 10:17:07 -0700

Currently we have not defined the WTP IPv6 address message element. 

WTP IPv6 address message element is not needed as it is used exclusively for
NAT? Or do we assume that WTP will not be IPv6 host?

If former, "WTP IPv4 address message element" should be optional in join
request. If later, what is rational behind this assumption?

-Suds

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 16 Apr 2007 03:20:53 -0700

I believe the idea is that there will not be any IPv6 NATs out there (or
at least there aren't any v6-v6 NATs). The WTP IPv4 Address message
element MUST be included by the WTP to allow the AC to determine whether
a NAT exists between the two nodes. Having it as optional makes it
impossible for the AC to make this determination, and the WTP would
obviously never know if a NAT is used.

The question is whether the WTP IPv6 Address message element would be
useful in a v4-v6 NAT scenario. I suppose it would be useful if the WTP
was on a v6 network, and the AC was on a v4 network. In such a scenario,
the AC would expect to see the WTP IPv4 Address message element, which
would obviously be absent since the WTP is an IPv6 node. So either the
AC rejects the request, or we add the proposed WTP IPv6 Address message
element to make the protocol handling identical, regardless of the
underlying IP version number.

Thoughts?

PatC 

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 10:17 AM
To: 'capwap'
Subject: [Capwap] WTP IPvX address

WTP IPv6 address message element is not needed as it is used exclusively
for NAT? Or do we assume that WTP will not be IPv6 host?

-Suds

---

From: "Sudhanshu" <[email-masked]>
Date: Tue, 17 Apr 2007 14:35:19 -0700

We should make the protocol behavior identical. It will help in

* Address V6 WTP and V4 AC scenario
* Avoid sending V4 IP address by v6 WTP - a kind of hack

_Suds

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 3:21 AM
To: Sudhanshu; capwap
Subject: RE: [Capwap] WTP IPvX address

Thoughts?

PatC 

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 10:17 AM
To: 'capwap'
Subject: [Capwap] WTP IPvX address

-Suds

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Apr 2007 16:38:33 -0700

Fair enough. Note that the current WTP IPv4 Address is currently a MUST
in the Join Request, which is invalid for IPv6 WTPs - so I changed the
text so that at least one of them MUST be present. 

I have created issue 257, and included the proposed text below.

<proposed text>
4.5.  CAPWAP Protocol Message Elements
[...]
   WTP IPv4 IP Address                                  42
   WTP IPv6 IP Address                                  43

4.5.43.  WTP IPv6 IP Address

   The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to
   IPv6 NAT to help with technology transition).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP IPv6 IP Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP IPv6 IP Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP IPv6 IP Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP IPv6 IP Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   43 for WTP IPv6 IP Address

   Length:   32

   WTP IPv6 IP Address:   The IPv6 address from which the WTP is sending
      packets.  This field is used for NAT detection.

6.1.  Join Request
[...]
   At least one of the following message element MUST be included in the
   Join Request message.

   o  WTP IPv4 IP Address, see Section 4.5.42

   o  WTP IPv6 IP Address, see Section 4.5.43
</proposed text>

PatC
-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 2:35 PM
To: Pat Calhoun (pacalhou); 'capwap'
Subject: RE: [Capwap] WTP IPvX address

_Suds

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Monday, April 16, 2007 3:21 AM
To: Sudhanshu; capwap
Subject: RE: [Capwap] WTP IPvX address

Thoughts?

PatC 

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]]
Sent: Thursday, April 12, 2007 10:17 AM
To: 'capwap'
Subject: [Capwap] WTP IPvX address

-Suds

---

From: "Sudhanshu" <[email-masked]>
Date: Mon, 23 Apr 2007 10:16:33 -0700

Looks good.

_Suds

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 4:39 PM
To: Sudhanshu; capwap
Subject: RE: [Capwap] WTP IPvX address

<proposed text>

      0                   1                   2                   3

   Length:   32

6.1.  Join Request
[...]

PatC
-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 2:35 PM
To: Pat Calhoun (pacalhou); 'capwap'
Subject: RE: [Capwap] WTP IPvX address

_Suds

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Monday, April 16, 2007 3:21 AM
To: Sudhanshu; capwap
Subject: RE: [Capwap] WTP IPvX address

Thoughts?

PatC 

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]]
Sent: Thursday, April 12, 2007 10:17 AM
To: 'capwap'
Subject: [Capwap] WTP IPvX address

-Suds