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

[Jim Murphy (jmurphy]

Here is my feedback on the consensus request:

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

248 Both IPv4 and IPv6 Addresses not required.
250 Clarification onDTLSRehandshake/DTLSPeerAuthorize/
    DTLSIncomingSession
252 Hearbeat timer is undefined
217 What is frame format with WTP encrypts/decrypts?
249 UDP-Lite as optional transport for CAPWAP
251 Retransmission of control packets is not exponential
138 Support and negotiation of WTP data encryption in the CAPWAP
    protocol

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

247 MAC Addresses can be larger than 6 octets

Thanks,

Jim

Margaret Wasserman wrote:
> 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