1. July 2010
doc.: IEEE /0xxxr0
Proposed liaison presentation to SC6 in relation to the identifier conflict issue
9 May 2011
Authors:
Andrew Myles, Cisco

2. July 2010
doc.: IEEE /0xxxr0
WG & SC6 have worked together to define short/long terms solutions to identifier conflict issue
WG noted identifier conflicts
Two SC6 NBs responded with partial solution
IEEE provided identifiers for long term solution
The WG liaised a document to SC6 in Dec 2010
N14494
It noted a conflict between WAPI & 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 WG responded in March 2011
N14643
It was agreed “parameter checking” can be used to resolve the IE identifier conflict
The WG allocated non conflicting identifiers for long term solution of both IE identifier and status code conflicts
Are these identifiers required by SC6?
Andrew Myles, Cisco

3. July 2010
doc.: IEEE /0xxxr0
The conflicts highlighted in N14494 are a problem for WAPI systems, but not 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 k
Conflict with two status codes in IEEE k
The conflicts are not a problem for or 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
:2005 (same as ) is likely to be replaced by very soon
incorporates k and e.
Andrew Myles, Cisco

4. July 2010
doc.: IEEE /0xxxr0
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 k IEs
The method relies on the IE length field to differentiate the different uses
Andrew Myles, Cisco

5. July 2010
doc.: IEEE /0xxxr0
“Parameter checking” can be used to solve IE identifier conflict but not status code conflicts
Summary of N14643
The 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 or the 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
Andrew Myles, Cisco

6. July 2010
doc.: IEEE /0xxxr0
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 to implement such a transition.
The ANA has reserved IE = 180 for use in ISO/IEC WD as part of any transition process
The ANA has similarly reserved two status codes (90 and 91) for use by WAPI
The WG requests that SC6 confirm whether or not SC6 requires the IE identifier and the status codes to remain reserved
Andrew Myles, Cisco

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