Proposed liaison presentation to SC6 in relation to the identifier conflict issue

1. Proposed liaison presentation to SC6in relation to the identifier conflict issue • 9 May 2011 Authors:

2. 802.11 WG & SC6 have worked together to define short/long terms solutions to identifier conflict issue 802.11 WG noted identifier conflicts Two SC6 NBs responded with partial solution IEEE provided identifiers for long term solution • The 802.11 WG liaised a document to SC6 in Dec 2010 • N14494 • It noted a conflict between WAPI & 802.11 identifiers • 802.11k IE identifier • 802.11e status codes • Both the Swiss &Chinese NBs responded similarly in early 2011 • N14511 (Swiss NB) • N14544 (China NB) • They suggested of “parameter checking” to distinguish the conflicting IE identifiers • Neither NB suggested a solution for the status code conflicts • The 802.11 WG responded in March 2011 • N14643 • It was agreed “parameter checking” can be used to resolve the IE identifier conflict • The 802.11 WG allocated non conflicting identifiers for long term solution of both IE identifier and status code conflicts • Are these identifiers required by SC6?

3. The conflicts highlighted in N14494 are a problem for WAPI systems, but not 802.11 systems • Summary of N14643 • Two identifier conflicts were highlighted in N14494 in relation to the WAPI draft in N14435 • Conflict with IE identifier in IEEE 802.11k • Conflict with two status codes in IEEE 802.11k • The conflicts are not a problem for 802.11 or 8802-11 systems because they are unlikely to ever support WAPI • The conflicts are a problem for WAPI systems if they make use of advanced features in 802.11-2011 • 8802-11:2005 (same as 802.11-2003) is likely to be replaced by 802.11-2011 very soon • 802.11-2011 incorporates 802.11k and 802.11e.

4. Two SC6 NBs suggested a “parameter checking” mechanism to mitigate the IE identifier conflict • Summary of N14643 • Two SC6 NBs suggested a method by which the IE identifier conflict could be mitigated • Swiss NB in N14511 • Chinese National Body in N14544 • The method suggested by the NBs uses “parameter checking” to differentiate between WAPI and 802.11k IEs • The method relies on the IE length field to differentiate the different uses

5. “Parameter checking” can be used to solve IE identifier conflict but not status code conflicts • Summary of N14643 • The 802.11 WG agrees “parameter checking” is a reasonable short term work around for the IE identifier conflict • This mechanism should be documented in ISO/IEC WD 20011 • There is no need for any equivalent notes to be included in 802.11 or the 802.11 ANA database • A similar method cannot be used to resolve the status code conflict • However, it is suspected the status code conflict will have less impact in practice

6. 802.11 WG requests SC6 to confirm allocation of non conflicting vales for long term solution • Summary of N14643 • In the longer term, maximum flexibility will be attained by WAPI transitioning to use its own non conflicting IE identifier & status codes • There are various methods that could be specified in ISO/IEC WD 20011 to implement such a transition. • The 802.11 ANA has reserved IE = 180 for use in ISO/IEC WD 20011 as part of any transition process • The 802.11 ANA has similarly reserved two status codes (90 and 91) for use by WAPI • The 802.11 WG requests that SC6 confirm whether or not SC6 requires the IE identifier and the status codes to remain reserved

7. The identifier and the status code conflicts were not caused by (in)actions of the 802.11 WG • Summary of N14643 • The 802.11 WG notes that N14544 asserts that “IEEE 802.11k created a conflict with WAPI”, suggesting that the IEEE 802.11 WG was in some way responsible for the conflicts • The 802.11 WG refutes this conclusion because IEEE has always been: • the registration authority for 802.11 • the registration authority, either by explicit agreement or by default, for 8802-11