Capwap Mailing List: CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

[Margaret Wasserman (margaret]

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