1. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 1 IEEE 802 JTC1 Standing Committee November 2013 agenda 12 Nov 2013 Authors: NameCompanyPhoneemail Andrew MylesCisco +61 2 84461010 +61 418 656587 amyles@cisco.com

2. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 This presentation will be used to run the IEEE 802 JTC1 SC meetings in Dallas in Nov 2013 This presentation contains a proposed running order for the IEEE 802 JTC1 Standing Committee meeting in Nov 13, including –Proposed agenda –Other supporting material It will be modified during the meeting to include motions, straw polls and other material referred to during the meeting Andrew Myles, CiscoSlide 2

3. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 3 Participants have a duty to inform in relation to patents All participants in this meeting have certain obligations under the IEEE- SA Patent Policy (IEEE-SA SB Bylaws sub-clause 6.2). Participants: –“Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents — “Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents or patent claims –“Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) –The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group Early identification of holders of potential Essential Patent Claims is strongly encouraged; there is no duty to perform a patent search

4. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 4 There are a variety of patent related links All participants should be familiar with their obligations under the IEEE- SA Policies & Procedures for standards development. Patent Policy is stated in these sources: –IEEE-SA Standards Boards Bylaws — http://standards.ieee.org/guides/bylaws/sect6-7.html#6 –IEEE-SA Standards Board Operations Manual — http://standards.ieee.org/guides/opman/sect6.html#6.3 Material about the patent policy is available at –http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat/pat-material.html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.orgpatcom@ieee.org –or visit http://standards.ieee.org/board/pat/index.htmlhttp://standards.ieee.org/board/pat/index.html This slide set is available at http://standards.ieee.org/board/pat/pat- slideset.ppt

5. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 5 A call for potentially essential patents is not required in the IEEE 802 JTC1 SC If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: –Either speak up now or –Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or –Cause an LOA to be submitted

6. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 6 The IEEE 802 JTC1 SC will operate using general guidelines for IEEE-SA Meetings All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. –Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. –Don’t discuss specific license rates, terms, or conditions. — Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. — Technical considerations remain primary focus –Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. –Don’t discuss the status or substance of ongoing or threatened litigation. –Don’t be silent if inappropriate topics are discussed … do formally object. See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details.

7. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 7 Links are available to a variety of other useful resources Link to IEEE Disclosure of Affiliation –http://standards.ieee.org/faqs/affiliationFAQ.htmlhttp://standards.ieee.org/faqs/affiliationFAQ.html Links to IEEE Antitrust Guidelines –http://standards.ieee.org/resources/antitrust-guidelines.pdfhttp://standards.ieee.org/resources/antitrust-guidelines.pdf Link to IEEE Code of Ethics –http://www.ieee.org/web/membership/ethics/code_ethics.htmlhttp://www.ieee.org/web/membership/ethics/code_ethics.html Link to IEEE Patent Policy –http://standards.ieee.org/board/pat/pat-slideset.ppthttp://standards.ieee.org/board/pat/pat-slideset.ppt

8. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 8 The IEEE 802 JTC1 SC will operate using accepted principles of meeting etiquette IEEE 802 is a world-wide professional technical organization Meetings are to be conducted in an orderly and professional manner in accordance with the policies and procedures governed by the organization. Individuals are to address the “technical” content of the subject under consideration and refrain from making “personal” comments to or about the presenter.

9. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Call to Order Select recording secretary <- important! Approve agenda Conduct meeting according to agenda Recess Call to Order Select recording secretary <- important! Conduct meeting according to agenda Recess The IEEE 802 JTC1 SC has three slots at the Dallas plenary meeting Andrew Myles, Cisco Call to Order Select recording secretary <- important! Conduct meeting according to agenda Adjourn Tuesday 12 Nov, PM1 Wednesday 13 Nov, PM1 Thursday 14 Nov, PM1

10. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC has a detailed list of agenda items to be considered In no particular order: Approve minutes –From interim meeting in September 2013 in Nanjing Review extended goals –From IEEE 802 ExCom in Nov 2010 Review status –Review liaisons of drafts to SC6 –Review notifications of projects to SC6 –Review status of FDIS ballots Review comments and next steps on FDIS ballots –802.1X –802.1AE Andrew Myles, CiscoSlide 10

11. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC has a detailed list of agenda items to be considered In no particular order: Review status of security proposals in SC6 –Review meetings between IEEE 802 and Swiss NB –TEPA-AC, TLSec, TAAA, WAPI, TISec Review status of other proposals in SC6 –UHT/EUHT, WLAN Cloud, Optimization technology in WLAN Plan for SC6 meeting in February 2014 –Review agenda –Plan IEEE 802 contributions –Ask for delegation volunteers & empower HoD Discuss role of SC6 Discuss criteria for PSDO submissions Consider any motions Andrew Myles, CiscoSlide 11

12. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 12 The IEEE 802 JTC1 SC will consider approving its agenda Motion to approve agenda The IEEE 802 JTC1 SC approves the agenda for its meeting in Dallas in November 2013, as documented on pages 10-11 of Moved: Seconded: Result:

13. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC will consider approval of previous minutes Motion to approve minutes The IEEE 802 JTC1 SC approves the minutes for its meeting in Nanjing in Sept 2013, as documented in 11-13-1279-r011-13-1279-r0 Moved: Seconded: Result: Andrew Myles, CiscoSlide 13

14. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Andrew Myles, CiscoSlide 14 The IEEE 802 JTC1 SC reaffirmed its general goals in Sept 09, but they were extended in Nov 2010 Agreed (with changes from Nov 2010) goals Provides a forum for 802 members to discuss issues relevant to both: –IEEE 802 –ISO/IEC JTC1/SC6 Recommends positions to ExCom on ISO/IEC JTC1/SC6 actions affecting IEEE 802 –Note that IEEE 802 LMSC holds the liaison to SC6, not the IEEE 802.11 WG Participates in dialog with IEEE staff and 802 ExCom on issues concerning IEEE’s relationship with ISO/IEC Organises IEEE 802 members to contribute to liaisons and other documents relevant to the ISO/IEC JTC1/SC6 members Extensions The extensions to our goals came out of the IEEE 802 ExCom ad hoc held in November 2010 on the Friday evening

15. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 In recent times, IEEE 802 has liaised a variety of drafts to SC6 IEEE 802 has agreed to liaise drafts to SC6 when they are in Sponsor Ballot (and sometimes earlier) The benefit to IEEE 802 is that it might cause SC6 members to participate in or contribute to IEEE 802 activities Since the July plenary in Geneva the IEEE 802 has liaised the following drafts to SC6: –802.11 WG — 22 Aug 2013: 802.11ac D6.0 — 22 Aug 2013: 802.11af D5.0 –802.1 WG — 9 Aug 2013: 802.1Xbx D1.0 — Mick will check if any drafts need to be sent –Need to talk to.3 about what they are going to send Andrew Myles, CiscoSlide 15

16. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 In recent times, IEEE 802 has notified SC6 of various new projects IEEE 802 has agreed to notify SC6 when IEEE 802 starts new projects The benefit to IEEE 802 is that it might cause SC6 members to participate in or contribute to IEEE 802 activities Since the July plenary in Geneva the IEEE 802 has notified SC6 of the approval of the following SGs –In 6N15723 — IEEE 802.3, "Power over Data Lines" SG — IEEE 802.15, “Spectrum Resources Usage in WPANs” SG — IEEE 802.15, “Beam Switchable Wireless Point-to-Point 40/100Gbps links (GbW)” SG –Will be sent after session by John D’Ambrosia Andrew Myles, CiscoSlide 16

17. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 IEEE 802 has submitted ten standards for ratification under the PSDO – with 2 new approvals IEEE 802 standard 60 day pre-balllot 5 month FDIS ballot 802.11Passed in 2012 802.1XPassed in 2013Passed 21 Oct 2013 802.1AEPassed in 2013Passed 21 Oct 2013 802.1ABPassed in May 2013Closes 18 Dec 2013 802.1ARPassed in May 2013Closes 18 Dec 2013 802.1ASPassed in May 2013Closes 18 Dec 2013 802.11aaPassed in Feb 2013Closes 28 Jan 2014 802.11adPassed in Feb 2013Closes 28 Jan 2014 802.11aePassed in Feb 2013Closes 28 Jan 2014 802.3Passed in 2013Closes 16 Feb 2014 Andrew Myles, CiscoSlide 17

18. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 IEEE 802.11-2012 has been ratified as ISO/IEC 8802- 11:2012 Andrew Myles, CiscoSlide 18 60 day pre-ballot: passed in 2012 All comments have been submitted to TGmc for processing Additional comments from Swiss NB in N15623 (a response to the IEEE 802/SC6 collaboration procedure) have also been referred to TGmc The China NB stated in N15591 that they will continue disapproving ISO/IEC 8802-11 until their comments are resolved –It is appears this statement has little real effect — It does not affect any ISO/IEC processes — China is probably required under WTO rules to respect ISO/IEC 8802-11:2012 as an international standard — The reality is that ISO/IEC 8802-11:2012 is being widely used in China today, including 802.11i based security FDIS ballot: passed in 2012

19. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.1X closed in October 2013 Andrew Myles, CiscoSlide 19 60 day pre-ballot: passed in 2013 Submission in N15515 Pre-ballot voting results in N15555 –Comments from China NB replied to by IEEE 802 in N15607 –The China NB stated in Korea that they will reply in detail to the IEEE 802.1 WG response at a later time FDIS voting results in N15771 –Passed 16/1/12 (China negative) –Comments from China and Switzerland FDIS ballot: passed 21 October 2013

20. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.1AE closed in October 2013 Andrew Myles, CiscoSlide 20 60 day pre-ballot: passed in 2013 Submission in N15516 Pre-ballot voting results voting results in N15556 –Comments from China NB replied to by IEEE 802 in N15608 –The China NB stated in Korea that they will reply in detail to the IEEE 802.1 WG response at a later time FDIS voting results in N15770 –Passed 16/1/13 (China negative) –Comments from China and Switzerland FDIS ballot: passed 21 October 2013

21. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.1AB closes in Dec 2013 Andrew Myles, CiscoSlide 21 60 day pre-ballot: passed in Feb 2013 Submission in N15588 Voting results in N15626 –Comments from China replied to in N15659 FDIS ballot: closes 18 December 2013

22. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.1AR closes in Dec 2013 Andrew Myles, CiscoSlide 22 60 day pre-ballot: passed in May 2013 Submission in N15589 Voting results in N15627 –Comments from China replied to in N15659 FDIS ballot: closes 18 December 2013

23. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.1AS closes in Dec 2013 Andrew Myles, CiscoSlide 23 60 day pre-ballot: passed in May 2013 Submission in N15590 Voting results in N15628 –Comments from China replied to in N15659 FDIS ballot: closes 18 December 2013

24. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.11ae closes in Jan 2014 Andrew Myles, CiscoSlide 24 60 day pre-ballot: passed in Feb 2013 Submission in N15552 Voting results in N15599 –Comments from China replied to by IEEE 802 in N15647 — The China NB comments are based on their disapproval of IEEE 802.11-2012 — IEEE 802 referred China NB to disposition of comments on IEEE 802.11-2012 –Comments from Japan in N15664 — These comments expressed a concern about having too many amendments outstanding — Japan NB has informally accepted idea that IEEE 802 should be responsible for all maintenance processes FDIS ballot: closes 28 Jan 2014

25. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.11ad closes in Jan 2014 Andrew Myles, CiscoSlide 25 60 day pre-ballot: passed in Feb 2013 Submission in N15553 Voting results in N15601 –Comments from China replied to by IEEE 802 in N15647 — The China NB comments are based on their disapproval of IEEE 802.11-2012 — IEEE 802 referred China NB to disposition of comments on IEEE 802.11-2012 –Comments from Japan in N15664 — These comments expressed a concern about having too many amendments outstanding — Japan NB has informally accepted idea that IEEE 802 should be responsible for all maintenance processes FDIS ballot: closes 28 Jan 2014

26. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 FDIS on 802.11aa closes in Jan 2014 Andrew Myles, CiscoSlide 26 60 day pre-ballot: passed in Feb 2013 Submission in N15554 Voting results in N15602 –Comments from China replied to by IEEE 802 in N15647 — The China NB comments are based on their disapproval of IEEE 802.11-2012 — IEEE 802 referred China NB to disposition of comments on IEEE 802.11-2012 –Comments from Japan in N15664 — These comments expressed a concern about having too many amendments outstanding — Japan NB has informally accepted idea that IEEE 802 should be responsible for all maintenance processes FDIS ballot: closes 28 Jan 2014

27. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 802.3-2012 passed the pre-ballot, and is awaiting the start to FDIS ballot Andrew Myles, CiscoSlide 27 60 day pre-ballot: passed in May 2013 Submission in N15595 Voting results in N15632 –Comments from China were responded to by the 802.3 Maintenance TF in Geneva – see N15724 FDIS ballot: closes 16 Feb 2014

28. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The SC will review the comments on 802.1X during the FDIS There were comments from two NBs –4 from China NB –16 from Switzerland NB The comments can be summarised as follows: –China — Have technical and procedural concerns — Will not recognise result — Notes normative references to non standards –Switzerland — Wants us to follow processes in N15606 — Notes normative references to non standards — Does not like wording of definitions — Wants authentication to be specified — Wants security goals articulated — Wants security between AS and Authenticator specified — Wants analyse of EAP methods, and only secure methods allowed Andrew Myles, CiscoSlide 28

29. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 1 on 802.1X China 1 comment on 802.1X: Since the procedural and technical concerns China NB proposed in 6N15555 still haven’t reasonably disposed in this FDIS text, and referencing issues mentioned below exist in this text, so China NB has to vote against on this FDIS ballot. If these issues could not be disposed reasonably and this proposal passes the FDIS ballot, it is regretful for China to be obliged to lose the responsibility and obligation of complying with and adopting the standard. Furthermore, China NB wishes to state for the record Andrew Myles, CiscoSlide 29

30. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 1 on 802.1X (continued) Proposed IEEE response: IEEE thanks the China NB for its carefully considered comments on the 802.1X FDIS ballot We note that the IEEE 802 responded in N15607 to the comments by the China NB in N15555. The referencing issues referred to by the China NB in this comment will be addressed in responses specific to each issue using the process defined by N15606. China NB representatives are invited to participate in the comment resolution process. The IEEE 802 is unable to respond to the China NB comment that they are “obliged to lose the responsibility and obligation of complying with and adopting the standard” because this is outside the scope of the responsibilities of IEEE 802 Andrew Myles, CiscoSlide 30

31. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 2 on 802.1X The referenced RFC 2863 is Draft Standard that still requires additional or more widespread field experience described in RFC 2026. China proposed change 2 on 802.1X Delete the referenced RFC and related technology from the document. Proposed IEEE 802.response Andrew Myles, CiscoSlide 31

32. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 3 on 802.1X RFC 2869, 3394, 3410, 3579, 3580 and 4017 are Informational RFC that is defined as a non-standard-track document in RFC 2026. China proposed change 3 on 802.1X Delete the referenced RFC and related technology from the document. Proposed IEEE 802.response Andrew Myles, CiscoSlide 32

33. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 4 on 802.1X RFC 4346, 4675, 5216 and 5247 are Proposed Standards which are treated as immature specifications by implementers required in RFC 2026. China proposed change 4 on 802.1X Delete the referenced RFC and related technology from the document. Proposed IEEE 802.response Andrew Myles, CiscoSlide 33

34. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 1 on 802.1X We welcome and approve the submission of this outstanding global standard to ISO/IEC because we take the view that global standards should be International Standards, i.e. standards approved by ISO, IEC and ITU, respectively. IS approval expresses the international consensus on the value of the standard. While the FDIS fast-track procedure invoked by the PSDO does not foresee a resolution of comments before publication of the IS, the maintenance process of ISO/IEC-approved standards must enable ISO NBs and IEC NCs to make contributions which are duly considered by the maintenance body. Andrew Myles, CiscoSlide 34

35. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 1 on 802.1X (continued) In Graz Resolution 6.1.10, ISO/IEC JTC1/SC6 has allocated responsibility for the revision process of the ISO/IEC 8802-1 standards to the IEEE 802.1 WG under the condition that SC 6 and its NBs have access to an established mechanism to contribute to the revision process in the IEEE 802.1 WG. In 6N15606 the IEEE 802 JTC1 Standing Committee has replied by a proposal for SC6 contributions to IEEE 802.1, 802.3 and 802.11 revision processes, encouraging Sc6 NBs to comments on 802 drafts and standards before or after an IEEE ballot closes. As our comments are submitted after closure of the IEEE ballot, we kindly ask the IEEE 802.1 WG to process them, according to 6N15606, as soon as possible, either during comment resolution on any subsequent draft of during normal maintenance if balloting on the standard has completed.. Andrew Myles, CiscoSlide 35

36. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 1 on 802.1X (continued) Proposed IEEE 802.response IEEE 802 thanks the Switzerland NB for it carefully considered comments on the 802.1X FDIS ballot, and assures the Switzerland NB that its comments will be processed in a timely manner by the IEEE 802.1 WG using the mechanisms defined by N15606. Swiss NB representatives are invited to participate in the comment resolution process. Andrew Myles, CiscoSlide 36

37. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 2 on 802.1X In a conventional DIS or DIS fast-track ballot, the subsequent comments would be issued with a DISAPPROVE vote, which would be turned into APPROVAL if the comments were satisfactorily resolved The FDIS fast- track however postpones, by 2.7 of the ISO/IEC Directives, Part 1, such resolution to the next review of the standard. Furthermore, affirmative votes to an FDIS cannot be made conditional on the resolution of any comments. However, as explained above, we wish ISO/IEC to endorse this standard and to subjugate it under its maintenance procedures as set forth in F.2.4 of the ISO/IEC Directives, Part 1, and Sc6 Graz Resolution 6.1.10. Therefore our vote is APPROVE, unconditionally. Our comments are submitted under the late option of 6N15606 to be processed by the IEEE 802.1 WG as soon as possible, i.e. either during comment resolution on any subsequent draft or during normal maintenance. Proposed IEEE 802.response See response 1 Andrew Myles, CiscoSlide 37

38. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 3 on 802.1X When ISO/IEC/IEEE 8802-1X has been endorsed by ISO/IEC, then the ISO Directives, Part 2, “Rules for the structure and drafting of International Standards” as well as the JTC 1 Supplement and the relevant JTC 1 Standing Documents must be considered. It is desirable that the next revision of the specification be in line with the applicable requirements. This is a major aim of our comments. We will be pleased to find resolutions in fruitful collaboration with the IEEE 802.1 WG. Proposed IEEE 802.response We need to point out that the IEEE rules apply and not the ISO rules for this standard eg on definitions ISO is adopting an IEEE standard Andrew Myles, CiscoSlide 38

39. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 4 on 802.1X Re: clause 2 RFC 4017, 3580, 3579, 3410, 3394 and 2869 have only INFORMATIONAL status. According to RFC 2026 a specification of INFORMATIONAL status is a non-standard-track document which is (cit.) “”not subject to the rules of Internet standardization” and (cit.) “published for the general information of the Internet community and does not represent an Internet community consensus or recommendation. … Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies.” (citation end) Therefore these documents do not qualify for normative referencing. Andrew Myles, CiscoSlide 39

40. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 4 on 802.1X (continued) Switzerland proposed change 4 on 802.1X Resolve the issue by any of the following: –Placing the reference into the Informative References section. –Referencing of published standards, preferably ISO/IEC standards, –Incorporation of technical requirements into the standard text,. Proposed IEEE 802.response Andrew Myles, CiscoSlide 40

41. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 5 on 802.1X Re: clause 2 RFC 2863 has been published in the year 2000 but is still at DRAFT STANDARD status. According to RFC 6410 it will be re-classified as PROPOSED STANDARD in October 2013. Therefore (see CH 6) it does not necessarily qualify for normative referencing. Proposed IEEE 802.response Andrew Myles, CiscoSlide 41

42. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 6 on 802.1X Re: clause 2 RFC 4675, 5216 and 5247 have been published in the year 2006, 2006, 2008 and 2008, respectively, but are still at PROPOSED STANDARD status. According to 4.1.1 of RFC 2026 (cit.) “a Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. … Implementers should treat Proposed Standards as immature specifications.” (citation end). By 2.2 of RFC 6410 (cit.) “An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. Andrew Myles, CiscoSlide 42

43. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 6 on 802.1X (continued) Switzerland comment 6 on 802.1X The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a document advances from Proposed Standard to Internet Standard. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: –(1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. –(2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. –(3) There are no unused features in the specification that greatly increase implementation complexity. –(4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process.” (citation end) Andrew Myles, CiscoSlide 43

44. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 6 on 802.1X (continued) Switzerland comment 6 on 802.1X Specifications will remain at PROPOSED STANDARD level if either no request to reclassify them as INTERNET STANDARD is sent to the IESG or they fail to meet one or more of these requirements. Specifications remaining at PROPOSED STANDARD level for more than four years are either not known to meet the criteria for the INTERNET STANDARD level or known to fail to meet some of them. According the Note in 4.2.4 to RFC 2026 (cit.) “Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies.” (citation end). This principle also applies to ISO/IEC standards and should as well be respected by IEEE standards. Therefore the PROPOSED STANDARD level is not a sufficient qualification for normative referencing. Andrew Myles, CiscoSlide 44

45. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 6 on 802.1X (continued) Switzerland proposed change 6 on 802.1X For each of these RFCs, chose one of the following alternative actions: –Produce an RER according to JTC1 Standing Document N5, explaining whether or not the RFC has been formally evaluated against the criteria for the INTERNET STANDARD level, and if it has been evaluated, which criteria the RFC fails to meet, furthermore why it is needed as a normative reference in the IEEE 802.1X standard and how it is justified to allow a normative reference though IETF does not award it INTERNET STANDARD level. –Reference published standards, preferably ISO/IEC standards, –Incorporate technical requirements into the standard text, –Place the reference into the Informative References section Proposed IEEE 802.response Andrew Myles, CiscoSlide 45

46. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 7 on 802.1X Re: clause 2 RFC 4346 has been obsoleted by RF 5246, which has been published in the year 2008 but is still at PROPOSED STANDARD status. Therefore it does not necessarily qualify for normative referencing Switzerland proposed change 7 on 802.1X Find a resolution for RFC 5246 as indicated in CH6. Proposed IEEE 802.response Andrew Myles, CiscoSlide 46

47. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 8 on 802.1X Re: clause 2 FIPS and NIST do not have ARO status. The related references do not meet the requirements of JTC1 Standing Document N5 Switzerland proposed change 8 on 802.1X Reference ISO/IEC standards where available (e.g. for the AES) or provide RERs as required. Proposed IEEE 802.response Andrew Myles, CiscoSlide 47

48. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 9 on 802.1X Re: clause 3 The definitions are unnumbered and the phrasing of most of them does not conform to the ISO/IEC Directives, Part 2 Switzerland proposed change 9 on 802.1X Number all definitions. Discard articles (“a”, “the”) at the beginning of the definition. Avoid two or more sentences (such as in Authentication Server). Discard Notes. Proposed IEEE 802.response Andrew Myles, CiscoSlide 48

49. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 10 on 802.1X Re: clause 5.22, Table 5-1 This table fails to include the Authentication Server which, by clause 3, can be located in a component separate from the component hosting the Authenticator. See also CH 11. Switzerland proposed change 10 on 802.1X Include the Authentication Server into Table 5-1.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 49

50. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 11 on 802.1X Re: clause 5 This clause specifies requirements and options for the Supplicant and the Authenticator, but none for the Authentication Server, neither explicitly nor through normative references. According to paragraph 3 of 1.3 (cit.) “this standard specifies the use of EAP … to support authentication using a centrally administered Authentication server …”. This wording sketches a configuration with a centralized Authentication Server component providing (by definition) authentication services to a multitude of Authenticator components. To be trusted for the provision of secure authentication services the Authentication Server itself must be secure. The security requirements however are not specified in this standard. See also CH 13 cc. Andrew Myles, CiscoSlide 50

51. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 11 on 802.1X (continued) Switzerland proposed change 11 on 802.1X Specify requirements and options for the Authentication Server.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 51

52. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 12 on 802.1X Re: clause 6.3.1 RFC 3748 is referenced here, but the reference is not listed in clause 2. However, RFC 3748 has been published in the year 2004 but is still at PROPOSED STANDARD status. Therefore it does not necessarily qualify for normative referencing Switzerland proposed change 12 on 802.1X See CH6.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 52

53. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 13.1 on 802.1X Re: clause 6.3.1 The text does not explicitly specify what security goals the authentication exchange claims to achieve. By the definition in clause 3 the Authentication Server performs authentication and access control of the Supplicant. By clause 8.11, EAP methods used by the PAE shall provide mutual authentication. By 5.6.b therefore the Authentication Server is authenticated to the Supplicant. The definition of the Authentication Server indicates the claim that the authentication exchange provides mutual authentication of Authenticator and Supplicant if the MKA option is used, nothing otherwise. However, this can only be guessed but is not explicitly specified. The normative references of this standard do not provide the necessary explicit statements. Any security standard must explicitly state the security goals claimed to be achieved, depending from the options chosen. Andrew Myles, CiscoSlide 53

54. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 13.1 on 802.1X (continued) Switzerland proposed change 13.1 on 802.1X State explicitly all security goals claimed to be achieved by the authentication exchange for each of the three roles and their pairwise relationships.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 54

55. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 13.2 on 802.1X Re: clause 6.3.1 Neither this standard nor its normative references specify normative requirements for the securing of the exchange between Authentication Server and Authenticator. Unless the exchange between Authentication Server and Authenticator is appropriately secured, the mutual authentication of Authentication Server and Supplicant is not transferred the Authenticator and not linked to the 4-way-handshake. The protocol thus fails to provide mutual authentication of Supplicant and Authenticator. See 6N15523 for an analysis. What security mechanisms are appropriate strongly depends on the configuration (centralized AS or collocated with the Authenticator) and the related security assumptions and requires further analysis. As according to 1.3 this standard targets a configuration with a centralized Authentication Server, it must include the security requirements for the centralized configuration.. Andrew Myles, CiscoSlide 55

56. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 13.2 on 802.1X (continued) Switzerland comment 13.2 on 802.1X While it is acceptable to exclude specific security mechanisms and protocols for the exchange between Authentication Server and Authenticator from this standard, the standard must include normative security requirements. Otherwise the standard is incomplete Switzerland proposed change 13.2 on 802.1X Specify the normative security requirements of the exchange between the Authentication Server and the Authenticator if they are not co- located.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 56

57. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 14 on 802.1X Re: clause 8.11 This clause allows for a variety of EAP methods. Neither this standard nor its normative references specify the risks of the allowed EAP methods. 6N15523 and 6N15613 have pointed out attacks possible in case of the use of the strongest EAP methods (mutual authentication based on asymmetric cryptography). It may be the case that other authentication methods allowed by this clause have even more weaknesses. This standard must not allow EAP methods without stating the associated known risks. Andrew Myles, CiscoSlide 57

58. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 14 on 802.1X (continued) Switzerland proposed change 14 on 802.1X Analyse all authentication methods allowed by 8.11 and either discard them from the standard or specify their risks Proposed IEEE 802.response Andrew Myles, CiscoSlide 58

59. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 15 on 802.1X Re: clause 8.11 Neither the specification nor its normative references provide a comprehensive list of the allowed authentication methods. Unless all allowed authentication methods are known and their security is well understood the security of this standard cannot be assessed. Should certain authentication methods fail to meet the security goals of this standard, then the standard would not meet its security goals. Switzerland proposed change 15 on 802.1X List all allowed authentication methods and exclude methods implied by 8.11 and its normative references if they are not sufficiently secure.. Proposed IEEE 802.response Andrew Myles, CiscoSlide 59

60. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The SC will review the comments on 802.1AE during the FDIS There were comments from two NBs –2 from China NB –12 from Switzerland NB The comments can be summarised as follows: –China — Have technical and procedural concerns — Will not recognise result — Notes normative references to non standards –Switzerland — Wants us to follow processes in N15606 — Notes normative references to non standards — Notes normative references to old standards — Does not like wording of definitions — Suggests a couple o technical clarifications Andrew Myles, CiscoSlide 60

61. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 1 on 802.1AE Since the procedural and technical concerns China NB proposed in 6N15556 still haven’t reasonably disposed in this FDIS text, and referencing issues mentioned below exist in this text, so China NB has to vote against on this FDIS ballot. If these issues could not be disposed reasonably and this proposal passes the FDIS ballot, it is regretful for China to be obliged to lose the responsibility and obligation of complying with and adopting the standard. Furthermore, China NB wishes to state for the record. Andrew Myles, CiscoSlide 61

62. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 1 on 802.1AE (continued) Proposed IEEE 802 response IEEE thanks the China NB for its carefully considered comments on the 802.1X FDIS ballot We note that the IEEE 802 responded in N15608 to the comments by the China in N15556. The referencing issues referred to by the China NB in this comment will be addressed in responses specific to each issue using the process defined by N15606. China NB representatives are invited to participate in the comment resolution process. The IEEE 802 is unable to respond to the China NB comment that they are “obliged to lose the responsibility and obligation of complying with and adopting the standard” because the IEEE 802 is not party to any treaty or other obligations of China. Andrew Myles, CiscoSlide 62

63. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 China comment 2 on 802.1AE The referenced RFC 2863 is Draft Standard that still requires additional or more widespread field experience described in RFC 2026. China proposed change 2 on 802.1AE Delete the referenced RFC and related technology from the document Proposed IEEE 802 response Andrew Myles, CiscoSlide 63

64. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 1 on 802.1AE Proposed IEEE 802 response Andrew Myles, CiscoSlide 64

65. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 2 on 802.1AE Proposed IEEE 802 response Andrew Myles, CiscoSlide 65

66. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 3 on 802.1AE Proposed IEEE 802 response Andrew Myles, CiscoSlide 66

67. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 4 on 802.1AE Clause 2 The reference to the publication by McGrew and Viega is not admitted by the ISO Directives Switzerland proposed change 4 on 802.1AE Reference ISO/IEC 19772 and specify the parameters in the standard text Proposed IEEE 802 response Andrew Myles, CiscoSlide 67

68. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 5 on 802.1AE Clause 2 FIPS does not have ARO status. The reference to FIPS 197 does not meet the requirements of JTC1 Standing Document N5 Switzerland proposed change 5 on 802.1AE Reference ISO/IEC 18033-3. Proposed IEEE 802 response Andrew Myles, CiscoSlide 68

69. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 6 on 802.1AE Clause 2 Old versions of IEEE Std. 802.1D, 1Q, 1X, 1ad and 1AB are referenced Switzerland proposed change 6 on 802.1AE Reference the actual versions or use undated references. Proposed IEEE 802 response Andrew Myles, CiscoSlide 69

70. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 7 on 802.1AE Clause 2 IEEE Std 802.11 has been published as ISO/IEC/IEEE 802-11 Switzerland proposed change 7 on 802.1AE Reference the actual versions or use undated references. Proposed IEEE 802 response Andrew Myles, CiscoSlide 70

71. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 8 on 802.1AE IEEE Std 802.11i has been included in the 2012 edition of the 802.11 standard, which is referenced by this standard. The reference to 802.11i is therefore not needed Switzerland proposed change 8 on 802.1AE Delete the reference. Proposed IEEE 802 response Andrew Myles, CiscoSlide 71

72. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 9 on 802.1AE Clause 2 Switzerland proposed change 9 on 802.1AE. Proposed IEEE 802 response Andrew Myles, CiscoSlide 72

73. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 10 on 802.1AE Clause 3 The phrasing of most definitions does not conform to the ISO/IEC Directives, Part 2 Switzerland proposed change 10 on 802.1AE Discard articles (“a”, “the”) at the beginning of the definition. Avoid two or more sentences (such as in 3.13). Discard Notes. Proposed IEEE 802 response Andrew Myles, CiscoSlide 73

74. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 11 on 802.1AE Clause 3.10 While MAC-SEC is not for use by ISO/IEC/IEEE 8802-11, the text makes reference to IEEE STD 802.11 in this definition as well as in several other places. Though there is nothing wrong with these references, they may be misunderstood to assume that MAC-SEC could be used in wireless networks Switzerland proposed change 11 on 802.1AE Add a clarifying footnote to each reference to 802.11.. Proposed IEEE 802 response Andrew Myles, CiscoSlide 74

75. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Switzerland comment 12 on 802.1AE Clause 6.9 MACsec does not support message sequence integrity and thus not provide full connection mode data integrity. More specifically, it does not protect against message removal Switzerland proposed change 12 on 802.1AE Append an exclusion after h). Proposed IEEE 802 response Andrew Myles, CiscoSlide 75

76. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The SC will discuss on next steps for processing the FDIS comments on 802.1X & 802.1AE It is suggested that the 802.1 WG take responsibility for generating responses –Who? <-this is important Possible actions this week –Generate liaison to SC6 noting comments from China and Switzerland, thanking them and committing to process the comments according the agreed process –Inform SC6 of a possible timetable for comment resolution Possible actions for later –Process comments –Liaise responses to SC6 Any objections? Andrew Myles, CiscoSlide 76

77. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 A number of security presentation have been considered by SC6 ProposalEquivalentChinese standard? NP proposal in WG1? Implemented? TEPA-ACSubset of 802.1X Yes (can we get a translation?) Not yetNot known TLSecSubset of 802.1AE Not yet; BWIPS driving Not yetYes, in lab TAAA802.16 security No?Not yetYes, in lab WAPISubset of 802.11i based security YesYes, passed, but withdrawn Yes, required in handsets & SP APs but rarely used TISecSubset/copy of IPSec No?Not yet (in WG7) Not known Andrew Myles, CiscoSlide 77

78. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 A meeting was set up between the IEEE 802.1/11 and Swiss NB security experts about TEPA The Swiss NB has provided significant comment on various 802 standards over the last few years In particular the Swiss NB has had a strong interest in the TEPA based proposals in SC6 from the China NB This has led to significant and important discussions related to the “state of the art” in 802 security standards, but mostly limited to Hans-Rudolf Thomann Hans-Rudolf Thomann has suggested that we might be able to expand discussions with the Swiss NB to other individuals –Josef Schmid has been suggested as another Swiss security expert It was agreed in Geneva that a meeting should be set up between 802.1 and 802.11 security experts and the Swiss NB security experts –The first of a likely series of meetings took place on 27 August 2013 Andrew Myles, CiscoSlide 78

79. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Dan Harkins provided a summary of the TEPA meeting between IEEE 802 & Swiss NB reps Meeting participants were –IEEE 802 — Bruce Kraemer (Marvell), Karen Randall (Randall Consulting), Jodi Haasz (IEEE), Mick Seaman, Dan Harkins (Aruba Networks), Brian Weis (Cisco), Peter Yee (AKAYLA) –Swiss NB — Hans-Rudolf Thomann (Thomann Consulting), Josef Schmid (FITSU), Dan provided a meeting summary in Nanjing (from minutes) –Dan Harkins' interpretation of that teleconference is that the Swiss NB has gone backwards in their understanding of what 802.1X entities and TePA entities do in order to perform authentication. –Thomann has been concentrating on the number of entities involved instead of the functionality of those entities. –Thomann says that he will put together a presentation of how he feels that TePA certificate processing is performed in order to help improve mutual understanding. Dan will produce a similar presentation around 802.1X. Andrew Myles, CiscoSlide 79

80. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Dan Harkins provided a summary of the TEPA meeting between IEEE 802 & Swiss NB reps Dan provided a meeting summary in Nanjing (from minutes) (continued) –Once these two stories are put straight, it should be possible to return to the Swiss presentation from the Seoul JTC1 meeting and clarify the points it attempted to make. –Bruce Kraemer expressed concern that this dialog is dragging on and that we will end up going into the Ottawa meeting (February 2014) of the JTC1 SC6/WG1 with the same distance between the parties. –Josef Schmid has indicated that the Swiss government has been following the progress of TePA in JTC1, although he has not been able to articulate the reason for the particular interest. –Another discussion between the IEEE delegation and the Swiss NB representative would be highly useful before the Ottawa meeting –The timing for this meeting will be dependent on when Thomann's and Harkins' documents are available. Andrew Myles, CiscoSlide 80

81. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 There has been no further meeting between IEEE 802 and the Swiss NB about TEPA It was intended that further meetings be held after Dan Harkins and Hans Rudolf Thoman completed their “homework” –Dan: how certificates are used and validated in 802.1X/EAP-TLS –Hans: how certificates are used and validated in TePA As far as we know, Hans has not completed his homework Dan may discuss his homework, which is complete or close to complete Note that there is no discussion of the TEPA proposals on the WG1 or WG7 agendas in February 2014 Should we continue these meetings? Are they worthwhile? Andrew Myles, CiscoSlide 81

82. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 WAPI has not gone away; it may be re-proposed in SC6 despite uncertainty about the process WAPI was cancelled as an NP proposal in early 2012 There was been little discussion of WAPI in SC6 since that time but there is a possibility it might be re-proposed The process for re-proposing WAPI in SC6 is currently uncertain –There is a claim made at the Korea meeting in June 2013 that the WAPI NP could be un-cancelled by a simple vote of SC6 NBs … –… despite some ambiguity, a case could be made that un-cancelling the WAPI NP requires a new NP ballot WAPI is not on the agenda for the SC6 meeting in February 2014 Andrew Myles, CiscoSlide 82

83. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 There is a claim that the WAPI NP could be un- cancelled by a simple vote of SC6 NBs At the SC6 meeting in Korea it was asserted that ISO staff have asserted the WAPI NP could be un-cancelled by a simple vote of SC6 NBs –Although it was also noted that the comments on the old NP form would still need to be resolved The US NB rep asserted that this was contrary to the JTC1 Directives and a new NP ballot would be required Regardless of the rules, it certainly would seem strange to not completely revise an NP form that was submitted in 2009 –Much of the material in the 2009 NP form is very out of date –It would be even more difficult to resolve comments on the 2009 NP form given the claims about WAPI in the market place have now been proved false by the passage of time –At least three of the five NBs that stated in 2009 they would provide experts never have done so Andrew Myles, CiscoSlide 83

84. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Despite some ambiguity, a case could be made that un-cancelling the WAPI NP requires a new NP ballot The China NB suggested at the time of cancellation they may resubmit WAPI “when a more favorable standardization environment is available” –This assertion was repeated at the SC6 meeting in Korea in June 2013 The JTC1 Directives are not particularly clear on the process for a project to be re-established once it has been cancelled The best hint comes from the latest NP Ballot form, which includes an option for: –“THIS PROPOSAL RELATES TO THE RE-ESTABLISHMENT OF A CANCELLED PROJECT AS AN ACTIVE PROJECT” This form and the latest JTC1 Directives suggest if there was a proposal to re-establish WAPI then: –It would have be sent to a new NP ballot of SC6 NBs –Assuming the ballot passed, any resulting negative comments would have to be resolved and balloted by the JTC1 NBs Andrew Myles, CiscoSlide 84

85. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 WAPI has not gone away; it has ongoing support in China WAPI has been an ongoing failure in the marketplace –It does not exist outside China –In China it is widely implemented in mobile phones but rarely deployed Despite this failure WAPI continues to have support in China –It has been a China National standard since about 2003 –It is required to be implemented in mobile phones in China with Wi-Fi by an (unpublished) regulation –It is required to be implemented in APs used by SPs in China an (unpublished) regulation –It was supported by new government funding as recently as late 2012 –The WAPI Alliance is now leveraging the Snowden affair to promote mandatory use of WAPIpromote Andrew Myles, CiscoSlide 85

86. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 WAPI has not gone away; but WPA2 is being embraced by Chinse SPs anyway It appears the Chinese SPs are embracing HS2.0/Passpoint based on 802.11i/WPA2-Enterprise Andrew Myles, CiscoSlide 86 China Mobile Beijing

87. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 WAPI will have ample government funding for the foreseeable future WAPI has had support from some parts of the Chinese Government for a long time It appears this support is continuing with the opening of a National Engineering Laboratory in Xi’an in late 2012 –See http://tech.sina.com.cn/t/2012-12-10/01357870879.shtmlhttp://tech.sina.com.cn/t/2012-12-10/01357870879.shtml The focus of the lab (Google Translate) is to “fight for more international standards to adopt China's WAPI security technologies” The attendance at the opening of the lab indicated support for its work from: –“National Information Security Management research institutions” –“industry experts” –“China's electric power, petroleum, finance, transportation” industries Andrew Myles, CiscoSlide 87

88. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The status of TISec is unknown in WG7, as are ISOC plans ISOC (Sean Turner) sent a representative to the SC6 meeting in Korea in June 2013 He participated in discussions about TISec and observed other discussions in WG7 relating to their plan to redesign the Internet It is not yet known if ISOC will be sending a rep to the next meeting TISec is currently not on the WG7 agenda Andrew Myles, CiscoSlide 88

89. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 A number of other relevant proposals are being considered by SC6 ProposalEquivalentChinese standard? NP proposal in WG1? Implemented? UHT802.11n extensionYesNoNot known EUHT802.11ac competitor – really a LTE lite in unlicensed spectrum solution YesNoPrototype WLAN CloudNone obvious; functionality could be achieved in different ways with existing standards NoPWI proposalNot known Optimization technology in WLAN None obvious;NoPWI proposalNot known Andrew Myles, CiscoSlide 89

90. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 There is no news on EUHT standardisation in ISO/IEC but some activity in IEEE 802.11 WG There is no further news on standardisation of EUHT in ISO/IEC: –it was not discussed at the SC6 meeting in Korea in June 2013 –It is not on the agenda for the next SC6 meeting in Feb 2014 Nufront presented to the IEEE 802.11 WG and conducted a Q&A in Hawaii in May 2013 –See 595r0 & 595r1 for presentation595r0595r1 –See 640r0 for Q&A minutes640r0 Nufront presented to IEEE 802.11 WG and this SC in relation to EUHT, and more explicitly coexistence with IEEE 802.11 –1147 - EUHT Status Description1147 –1148 - EUHT Technology Document1148 –1149 - Interference and Co-existence Issues of EUHT network1149 –1150 - Process Recommendations on Coexistence Interference Analysis1150 It is hoped that Nufront return (maybe in March 2014?) to participate in HEW Andrew Myles, CiscoSlide 90

91. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 SC6/WG7 decided to delay decisions on two PWI proposals related to WLAN SC6/WG7 discussed two proposals for PWIs related to WLAN –N15692: WLAN Cloud — Allows sharing of APs by SPs –N15691: Optimization technology in WLAN — Defines protocol for sending WLAN sniffing data to central database It appears the IEEE 802 delegation was not in attendance when the items were initially discussed However, later in the week the US NB rep successfully argued that PWIs should not be started in WG7 because the items maybe within the scope of WG1 Andrew Myles, CiscoSlide 91

92. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 SC6/WG7 decided to delay decisions on two PWI proposals related to WLAN It was decided that the items should be discussed in a joint meeting between WG1 and WG7 in Ottawa in February 2014 The approved SC6 resolution was –SC 6 instructs its Secretariat to circulate the documents below for study and comment prior to the interim WG 7 meeting in October 2013. –Due to the nature of the topic, the scope should be clarified between WG 1 and WG 7. –SC 6 Secretariat is instructed to arrange a joint session between WG 1 and WG 7 at the next SC 6 meeting in Canada to discuss these topics in more detail and particularly the question of scope. –SC 6 encourages China NB to submit additional documents regarding the details of the proposals and the scope. These items are on the SC6/WG7 agenda in February 2014 Andrew Myles, CiscoSlide 92

93. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Does IEEE 802 have a view on two PWI proposals related to WLAN N15692: WLAN Cloud –Allows sharing of APs by SPs –Isn’t the same thing effectively achieved with HS2.0? –What is the market need? –Is there any harm in allowing a PWI? It might show there is no interest –Should it be in WG1 or WG7? –Do we care? N15691: Optimization technology in WLAN –Defines protocol for sending WLAN sniffing data to central database –Is a standard actually required for this? Is there an market need for interoperability? –Is there any harm in allowing a PWI? It might show there is no interest –Should it be in WG1 or WG7? –Do we care? Andrew Myles, CiscoSlide 93

94. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The next SC6 meeting will be held in Canada in February 2014 Meeting ISO/IEC JTC1/SC6 Host Standards Council of Canada Date Week of 17 February 2014 Location Offices of Ericsson in Ottawa Andrew Myles, CiscoSlide 94

95. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Agendas has been issued for WG1 and WG7 and are not exactly inspiring … yet! WG1 agenda is very sparse with little of interest … yet –Enough material for a few hours only –IEEE 802 items are status only –No WAPI, TEPA-AC, TLSec, TAAA, UHT, EUHT discussions WG7 agenda is very sparse with little of interest … yet –Optimization technology in WLAN and WLAN cloud scope discussion –IEEE 1888 discussion –No TISec discussion The agenda could expand closer to the meeting –New work items must be available by 3 January 2014 –Comments are allowed up until 31 January 2014 –We will be able to develop responses during our January meeting Andrew Myles, CiscoSlide 95

96. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Technically, TEPA topics and WAPI cannot be discussed at the SC6 meeting in Canada SC6 has been discussing various possible NPs for periods up to years over many meetings –eg TePA based proposals and WAPI This wastes everyone’s time, with endless discussion and no conclusions The SC6 Chair made a statement in Korea limiting discussion on topics in the future; this statement will be included in the minutes –The SC6 Chair recommended that items of the same subject should not be discussed more than two times at SC6 meetings before an NP Proposal is submitted to SC6. –The SC 6 Chair strongly requested to the WG 1 Convenor to see to it that this practice be strictly exercised –The SC6 Chair also noted that contributions should not be in the form of stepping on standards of other SDOs. –Technically TEPA topics and WAPI cannot be discussed! Andrew Myles, CiscoSlide 96

97. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 What do we want to put on the agenda for February SC6 meeting? Possibilities include: Overview of 802.1/3/11/15? –Including summary of liaisons/new projects Disposition matrix of old 802 documents Responses to any agenda items –None needed so far Security experts discussion –Discuss again in January? Summary of comment responses –FDIS responses on 802.11-2012 – are there any more –FDIS responses on 802.1X/AE – discussed earlier Andrew Myles, CiscoSlide 97

98. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 IEEE 802 needs to generate updated overviews of 802.1/3/11 and maybe 802.15? In Korea in June 2013 IEEE 802 gave status updates on 802 and 802.1/3/11 Note: the 802 document includes matrix of old 8802 documents We need to updates these documents for Canada? –Due by 3 Jan –Generated for or by WG Chairs: Tony Jefree, David Law, Bruce Kraemer Does 802.15 want to provide an update? –Ask Bob Hiele - NO These documents will not be ready this week and will need to be approved by the HoD Andrew Myles, CiscoSlide 98

99. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 There appears to be no change required to the disposition matrix of old 802 documents Andrew Myles, CiscoSlide 99 ProjectNumberYearNameRecommendation 05.01.008802-12011SPECIFIC LANS OverviewRetain. IEEE 802 will provide a replacement based upon the revision of 802 O&A (anticipated in 2014) 05.01.018802-1-SPECIFIC LANS Cooperative agreement with IEEE 802 Cancel project. Delete the draft. 05.02.008802-21998SPECIFIC LANS Logical Link Control 90.93 Retain in stabilized state 05.03.008802-32000SPECIFIC LANS CSMA/CD Edn. 6Retain. Will be superseded as soon the next revision of IEEE 802.3 is ratified by ISO/IEC. The ballot process on 802.3-2012 in ISO/IEC JTC1 has started 05.05.008802-51998SPECIFIC LANS Token Ring. Edn.3Retain in stabilized state 05.11.008802-112005LANS. Wireless MAC/PHY specifications Edn. 2 Withdraw. Has been superseded by ISO/IEC 802-11:2012 05.21.0111802-12005LAN GUIDELINES LLC AddressesWithdraw standard. This has been transferred to the IEEE Registration Authority. The registry will be referenced in the revision of 8802-1 05.22.0111802-22005LAN GUIDELINES Standard group MAC addresses Withdraw standard. This has been transferred to the IEEE Registration Authority. The registry will be referenced in the revision of 8802-1 05.25.0011802-51997Media Access Control (MAC) Bridging of Ethernet v2.0 in Local Area Network Retain in stabilized state. 05.31.0015802-11995COMMON LANS MAC serviceRetain. IEEE 802 will provide a replacement based upon 802.1AC (anticipated in 2014) 05.33.0015802-31998COMMON LANS MAC bridgesRetain. IEEE 802 will provide a replacement based upon the revision of 802.1Q (anticipated in 2014)

100. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Who is planning to attend the SC6 meeting in Canada in February 2014? IEEE 802 delegation will likely include –Bruce Kraemer (IEEE 802.11 WG Chair & probably HoD) –Jodi Haasz (IEEE staff) –Dan Harkins –Maybe (Brian Weis, Paul Nikolich, David Law, Bill Carney) It is believed others will be attending –US NB (Andrew Myles), China NB, Swiss NB, Korea NB, Canada NB (Glenn Parsons, host) It is believed others could be attending –ISOC, UK NB, Austria NB, Japan NB Andrew Myles, CiscoSlide 100

101. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC will empower the IEEE 802 HoD to the SC6 meeting in February 14 Motion The IEEE 802 JTC1 SC recommends that Bruce Kraemer be appointed as HoD of the IEEE 802 delegation to the SC6 meeting in February 2014 and be authorised to: –Appoint the IEEE 802 delegation –Approve any necessary submissions –Call any necessary preparation teleconferences Moved: Seconded: Result: Andrew Myles, CiscoSlide 101

102. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 With this little on the agenda, are future F2F meetings justified? Should IEEE 802 suggest that SC6 meetings be held less frequently? Andrew Myles, CiscoSlide 102

103. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Is it appropriate for the IEEE 802 to participate in a discussion about the future role of SC6? SC6 participants have noted views privately about the role of SC6 A summary of a view from a number of participants is –Having an SC under JTC1 focusing on networking is more than justifiable –However, with IETF and IEEE 802 dominating in the networking field, there's little room for SC6 to make itself relevant –In addition, some NBs are misusing SC6 to bypass proper review processes by all stakeholders As a stakeholder in the networking industry, does IEEE 802 have a view on the role of SC6? –Maybe as an “upper house” that reviews standards for possible international standardisation but does not develop standards – this is sort of its role now …and is it appropriate to share any views with SC6? Andrew Myles, CiscoSlide 103

104. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 IEEE 1888 will be discussed in SC6/WG7 in Canada for possible submission to SC6 under the PSDO IEEE 1888 is a ratified standard for “UGCCNet: Ubiquitous Green Community Control Network Protocol)” An IEEE 1888 WG delegation proposed the submission of IEEE 1888 to SC6 under the PSDO agreement There was significant discussion in SC6/WG7 comparing IEEE 1888 to ISO/IEC 17811-x (DCM: Device Control and Management) It was agreed that there should be further discussions, and it is on the WG7 agenda in February 2014 Andrew Myles, CiscoSlide 104

105. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The proposed submission of IEEE 1888 raises meta questions for IEEE-SA that were discussed in Geneva Meta questions Under what conditions should IEEE-SA WGs be allowed to make use of the PSDO? –Overuse risks diminishing the reputation of IEEE-SA –Particularly if the submitted standards are of insufficient quality to be “International standards” –But also because submission of many standards makes it easier to make the claim that IEEE is not an international SDO Should IEEE 802 request IEEE-SA to develop a set of criteria for IEEE standards before they are submitted to ISO/IEC –Is the standard appropriate as an ISO/IEC “international” standard? –It is in IEEE-SA’s interest to submit the standard to ISO.IEC under the PSDO? Andrew Myles, CiscoSlide 105

106. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The SC discussed in Geneva possible criteria for submission of IEEE standards under the PSDO Possible criteria for submission under PDSO Does it meet the needs of a significant or important set of stakeholders? –ie useful Does it meets the needs of stakeholders situated in multiple countries –ie international scope Is it known to be able achieve its goals in real implementations –Ie viable Has it undergone sufficient development and review by all stakeholders –ie maturity Is it likely be used –ie relevant Is its submission in the interest of IEEE-SA? Andrew Myles, CiscoSlide 106

107. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 There were no conclusion to the discussion in Geneva about use of the PSDO Geneva discussion Reviewed IEEE 1888 situation Reviewed questions Questions/comments –If there are criteria for the use of the PSDO, who is the arbiter for submissions? –If any change is to be made, such a policy decision will be made by the IEEE Standards Board. –The concern is over sending “lesser” standards to JTC1/SC6 and exposing IEEE to accusations that might bleed over to IEEE 802 submissions. There was no conclusion to this discussion Andrew Myles, CiscoSlide 107

108. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The SC may have further discussion on the general topic of when should the PSDO be used Is anyone proposing to make a proposal? What might a proposal look like? –Maybe a WG should be at least be required to document their reasons for using the PSDO, against a minimal set of criteria? –Enforcement/approval is an open question at this time Andrew Myles, CiscoSlide 108

109. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 ISO and IEEE will renegotiate the PSDO, and requested comments in Nov 2012 – no update The ISO and IEEE will renegotiating the PSDO in 2014 IEEE 802 may want to provide comments to IEEE staff Does this group have any comments? From Nov 2012 –IEEE should ensure only groups with an established track record may propose use of PSDO; 802.1/3/11 would all qualify –The default state should be that all revisions are undertaken by the source IEEE group, but that group must provide a way for NB reps to participate and contribute –Revisions should be better defined to include any activity that ultimately leads to the next edition of a standard, including amendments and corrections –A revision should also include any work that relies on an IEEE standard ratified under the PSDO and yet adds to, changes or replaces its functions, particularly if it does so in a way that effectively generates independent and incompatible standards There has been no further news on this topic since Nov 2012 Andrew Myles, CiscoSlide 109

110. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 IEEE 802 JTC1 SC will consider any motions The motions will be constructed during the week Andrew Myles, CiscoSlide 110

111. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC will at the January 2014 interim meeting The agenda for January will be constructed during the week Andrew Myles, CiscoSlide 111

112. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 Are there any other matters for consideration by IEEE 802 JTC1 SC? Matters will be added during the week Andrew Myles, CiscoSlide 112

113. doc.: IEEE 802.11-13/1342r1 Submission Nov 2013 The IEEE 802 JTC1 SC will for the week Motion: The IEEE 802 JTC1 SC, having completed its business in Dallas in November 2013, adjourns Moved: Seconded: Result: Andrew Myles, CiscoSlide 113