1 / 113

IEEE 802 JTC1 Standing Committee November 2013 agenda

IEEE 802 JTC1 Standing Committee November 2013 agenda. 12 Nov 2013. Authors:. This presentation will be used to run the IEEE 802 JTC1 SC meetings in Nanjing in Sept 2013.

sonja
Télécharger la présentation

IEEE 802 JTC1 Standing Committee November 2013 agenda

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE 802 JTC1 Standing CommitteeNovember 2013 agenda • 12 Nov 2013 Authors: Andrew Myles, Cisco

  2. This presentation will be used to run the IEEE 802 JTC1 SC meetings in Nanjing in Sept 2013 • This presentation contains a proposed running order for the IEEE 802 JTC1 Standing Committee meeting in Sept 2013, 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, Cisco

  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 Andrew Myles, Cisco

  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.html • If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org • or visit http://standards.ieee.org/board/pat/index.html • This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt Andrew Myles, Cisco

  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 Andrew Myles, Cisco

  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. Andrew Myles, Cisco

  7. Links are available to a variety of other useful resources • Link to IEEE Disclosure of Affiliation • http://standards.ieee.org/faqs/affiliationFAQ.html • Links to IEEE Antitrust Guidelines • http://standards.ieee.org/resources/antitrust-guidelines.pdf • Link to IEEE Code of Ethics • http://www.ieee.org/web/membership/ethics/code_ethics.html • Link to IEEE Patent Policy • http://standards.ieee.org/board/pat/pat-slideset.ppt Andrew Myles, Cisco

  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. Andrew Myles, Cisco

  9. The IEEE 802 JTC1 SC has three slots at the Dallas plenary meeting Tuesday 12 Nov, PM1 Wednesday13 Nov, PM1 Thursday 14 Nov, PM1 • 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 • Call to Order • Select recording secretary <- important! • Conduct meeting according to agenda • Adjourn Andrew Myles, Cisco

  10. 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, Cisco

  11. 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 & mmpowerHoD • Discuss role of SC6 • Discuss criteria for PSDO submissions • Consider any motions Andrew Myles, Cisco

  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-11of <this slide deck> • Moved: • Seconded: • Result: Andrew Myles, Cisco

  13. 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-r10 • Moved: • Seconded: • Result: Andrew Myles, Cisco

  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 Andrew Myles, Cisco

  15. 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 Andrew Myles, Cisco

  16. 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 Andrew Myles, Cisco

  17. IEEE 802 has submitted ten standards for ratification under the PSDO – with 2 new approvals Andrew Myles, Cisco

  18. IEEE 802.11-2012 has been ratified as ISO/IEC 8802-11:2012 • 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 Andrew Myles, Cisco

  19. FDIS on 802.1X closes in October 2013 • 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 Andrew Myles, Cisco

  20. FDIS on 802.1AE closes in October 2013 • 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 Andrew Myles, Cisco

  21. FDIS on 802.1AB closes in Dec 2013 • 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 Andrew Myles, Cisco

  22. FDIS on 802.1AR closes in Dec 2013 • 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 Andrew Myles, Cisco

  23. FDIS on 802.1AS closes in Dec 2013 • 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 Andrew Myles, Cisco

  24. FDIS on 802.11ae closes in Jan 2014 • 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 Andrew Myles, Cisco

  25. FDIS on 802.11ad closes in Jan 2014 • 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 Andrew Myles, Cisco

  26. FDIS on 802.11aa closes in Jan 2014 • 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 Andrew Myles, Cisco

  27. 802.3-2012 passed the pre-ballot, and is awaiting the start to FDIS ballot • 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 Andrew Myles, Cisco

  28. 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, Cisco

  29. 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, Cisco

  30. 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 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 the IEEE 802 is not party to any treaty or other obligations of China. Andrew Myles, Cisco

  31. China comment 2 on 802.1X • 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 • <refer to 802.1 WG for processing> Andrew Myles, Cisco

  32. China comment 3 on 802.1X • 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 • <refer to 802.1 WG for processing > Andrew Myles, Cisco

  33. China comment 4 on 802.1X • 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 • <refer to 802.1 WG for processing> Andrew Myles, Cisco

  34. Switzerland comment 1on 802.1X • 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, Cisco

  35. Switzerland comment 1on 802.1X (continued) • 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, Cisco

  36. Switzerland comment 1on 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, Cisco

  37. Switzerland comment 2 on 802.1X • 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, Cisco

  38. Switzerland comment 3 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  39. Switzerland comment 4 on 802.1X • 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, Cisco

  40. 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  41. Switzerland comment 5 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  42. Switzerland comment 6 on 802.1X • 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, Cisco

  43. 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, Cisco

  44. 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, Cisco

  45. 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  46. Switzerland comment 7 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  47. Switzerland comment 8 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  48. Switzerland comment 9 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  49. Switzerland comment 10 on 802.1X • 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 • <refer to IEEE 802.1 WG> Andrew Myles, Cisco

  50. Switzerland comment 11 on 802.1X • 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, Cisco

More Related