Re: Consensus check for Issue 138: encryption/decryption atWTP/AC
From: Bob O'Hara (boohara) (booharacisco.com)
Date: Thu, 1 Mar 2007 17:21:57 -0800 (PST)
Title: Consensus check for Issue 138: encryption/decryption at WTP/AC
I support option 2.  It is sufficient for interoperability of all ACs and WTPs.  It also minimizes the additional work required of WTP vendors, where they are required to implement only one method of supporting 802.11 encryption, rather than both.

 -Bob
 

 


From: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com]
Sent: Friday, February 23, 2007 2:46 PM
To: capwap [at] frascone.com
Cc: margaret [at] thingmagic.com; Dorothy.Gellert [at] nokia.com
Subject: [Capwap] Consensus check for Issue 138: encryption/decryption atWTP/AC

Dear CAPWAP WG,
During the CAPWAP Interim meeting in San Jose last month, we discussed issue 138: Wireless Encryption/Decryption at the WTP/AC, but did not achieve clear consensus. This issue has been discussed at length since IETF 67 in San Diego and on the list over the past few months.

The chairs would like to close this issue  with WG consensus on one of the following proposals that have the most WG support:

1) To provide system component interoperability, the WTP MUST support 802.11 encryption/decryption at the WTP, and the WTP MUST support 802.11 encryption/decryption at the AC. The AC MUST support either 802.11 encryption/decryption at the WTP or 802.11 encryption/decryption at the AC.

The AC MAY support both 802.11 encryption/decryption at the WTP and 802.11 encryption/decryption at the AC.
-OR-
2) 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.

Note the 2 proposals differ with support of 802.11 encryption/decryption at the AC.
As there has been no objections to the optional use of DTLS in the Data Plane, this portion of issue 138 is closed.
Please submit your choice and opinions on this topic to the WG list by March 1st for a final consensus call on this feature.   This is a short consensus call since the last date to submit drafts for IETF 68 is March 5th.   If we cannot agree to come to consensus in the next week, this issue will remain unresolved in the draft targeted for review in IEEE. 

Best Regards,
Dorothy, Mani and Margaret.

Results generated by Tiger Technologies using MHonArc.