Submission February 2014 Slide 1 IEEE 802 Response to FDIS comments on IEEE 802.1AR 19 February 2014 Authors: NameCompanyPhone

Submission February 2014 This presentation provides responses to comments on IEEE 802.1AR during FDIS ballot The FDIS voting results on IEEE 802.1AR in N15830 –It passed 15/2/16 (China NB and Switzerland NB voted negative) –Comments were received from China NB and Switzerland NB The FDIS comments have been processed in a timely manner using the mechanisms defined and agreed in 6N15606 This presentation provides the proposed responses from IEEE 802 to all comments by China NB and the Switzerland NB in the FDIS ballot Slide 2

Submission February 2014 China NB comment 1 on IEEE 802.1AR Since the procedural and technical concerns China NB proposed in 6N15627 still haven’t been 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 would have been passing 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. Slide 3

Submission February 2014 China NB comment 1 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CN.1 on IEEE 802.1AR IEEE thanks the China NB for its carefully considered comments on the 802.1AR FDIS ballot We note that the IEEE 802 responded in 6N15659 to all comments submitted by the China NB. Per the agreement in 6N15606, China NB representatives are invited to participate in the IEEE 802 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. Slide 4

Submission February 2014 China NB comment 2 on IEEE 802.1AR The referenced RFC 2986, RFC 3410, RFC 3447, RFC 3647, RFC 4086, RFC 4492, RFC 4949, RFC 5008, RFC 5289 are informational standards. The referenced RFC 3279, RFC 4133, RFC 5280, RFC 5480 are unknown type of standards. All of above listed RFC standards are unqualified for normative references in ISO standards. China NB proposed change 2 on IEEE 802.1AR Delete the referenced RFC and related technology from the document. Slide 5

Submission February 2014 China NB comment 2 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CN.2 on IEEE 802.1AR As part of the normal maintenance process for IEEE 802.1AR, the IEEE WG will review the references to ensure that only required references are included, RFC references are up to date, and normative RFC references have an appropriate status. According to IETF RFC 2026, “Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. An "Informational" specification is published for the general information of the Internet community.” It is appropriate to reference these published specifications in IEEE Standards. Additionally, the IETF has defined a DownRef Registry, RFC 3967 (BCP 97), "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level". Documents added to the Registry are considered Normative by the IETF, and thus are considered as standards by the IETF.RFC 3967 (BCP 97) Slide 6

Submission February 2014 Switzerland comment 1 on IEEE 802.1AR This specification is of very unsatisfactory quality: - It widely duplicates terms and definitions, which are in the scope of other specifications, in a way creating equivocation. - It makes vast reference to specifications which have not been approved by any SDO (INFORMATIONAL RFCs) and/or duplicate International Standards. Specifications submitted for approval as International Standards must respect the International Standardization System and adopt its rules and habits. This specification does not do so and is therefore DISAPPROVED by Switzerland. Switzerland NB proposed change 1 on IEEE 802.1AR Revise the specification using terms and concepts from International Standards. Slide 7

Submission February 2014 Switzerland comment 1 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CH.1 on IEEE 802.1AR IEEE 802 thanks the Switzerland NB for its carefully considered comments on the IEEE 802.AR FDIS ballot, and assures the Switzerland NB that its comments will be processed in a timely manner by the IEEE WG using the mechanisms defined and agreed in 6N Swiss NB representatives are invited to participate in the comment resolution process. The mechanisms defined and agreed in 6N15606 apply. Editing and maintenance will continue to be the responsibility of IEEE 802 and will conform to the IEEE policies and procedures. Slide 8

Submission February 2014 Switzerland comment 2 on IEEE 802.1AR Clause 2 ANSI and NIST aren’t AROs, therefore he references to the cryptography standards do not comply with JTC1 Standing Document N5. Switzerland NB proposed change 2 on IEEE 802.1AR For each of the cryptography standards, chose one of the following alternative actions: - Produce an RER according to JTC1Standing Document N5. - Reference published standards, preferably ISO/IEC standards (ISO/IEC , ISO/IEC and ISO/IEC ). - Incorporate technical requirements into the standard text. Slide 9

Submission February 2014 Switzerland comment 2 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CH.2 on IEEE 802.1AR IEEE 802.1AR has been developed according to the IEEE Standards Association standards development process and IEEE-SA Standards Style Manual. Editing and maintenance will continue to be the responsibility of IEEE 802 and will conform to the IEEE policies and procedures. The mechanisms defined and agreed in 6N15606 will apply. As part of the normal maintenance process for IEEE 802.1AR, the IEEE WG will review the references to ensure that only required references are included, RFC references are up to date, and normative RFC references have an appropriate status. Slide 10

Submission February 2014 Switzerland comment 3 on IEEE 802.1AR Clause 2 The reference to FIPS 140 does not comply with JTC1 Standing Document N5. Same as Switzerland comment 2 on IEEE 802.1AR Switzerland NB proposed change 3 on IEEE 802.1AR Choose one of the following alternative actions: - Produce an RER according to JTC1 Standing Document N5. - Reference ISO/IEC and incorporate a generic PP (Protection Profile) into the standard text. Proposed IEEE 802 response to CH.3 on IEEE 802.1AR See response 2 Slide 11

Submission February 2014 Switzerland comment 4 on IEEE 802.1AR Clause 2 RFC 2986, 3410, 3447, 3647, 4492, 4949, 5008 and 5289 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. Slide 12

Submission February 2014 Switzerland comment 4 on IEEE 802.1AR (continued) Switzerland proposed change 4 on IEEE 802.1AR Resolve the issue by any combination 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. Slide 13

Submission February 2014 Switzerland comment 4 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CH.4 on IEEE 802.1AR As part of the normal maintenance process for IEEE 802.1AR, the IEEE WG will review the references to ensure that only required references are included, RFC references are up to date, and normative RFC references have an appropriate status. According to IETF RFC 2026, “Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. An "Informational" specification is published for the general information of the Internet community.” It is appropriate to reference these published specifications in IEEE Standards. Additionally, the IETF has defined a DownRef Registry, RFC 3967 (BCP 97), "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level". Documents added to the Registry are considered Normative by the IETF, and thus are considered as standards by the IETF.RFC 3967 (BCP 97) Slide 14

Submission February 2014 Switzerland comment 5 on IEEE 802.1AR Clause 2 While expressing a standardized IETF practice, BCP 4086 is not a standards-track document Switzerland proposed change 5 on IEEE 802.1AR Move the reference to the informative references section and insert a normative reference to ISO/IEC Slide 15

Submission February 2014 Switzerland comment 5 on IEEE 802.1AR (continued) Proposed IEEE 802 response to CH.5 on IEEE 802.1AR As part of the normal maintenance process for IEEE 802.1AR, the IEEE WG will review the references to ensure that only required references are included, RFC references are up to date, and normative RFC references have an appropriate status. IEEE 802.1AR has been developed according to the IEEE Standards Association standards development process and IEEE-SA Standards Style Manual. Editing and maintenance will continue to be the responsibility of IEEE 802 and will conform to the IEEE policies and procedures. The mechanisms defined and agreed in 6N15606 will apply. Slide 16

Submission February 2014 Switzerland comment 6 on IEEE 802.1AR RFC 3279, 4133, 5280 and 5480 have been published between the year 2000 and 2008, respectively, but are still at PROPOSED STANDARD status. According to 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. Slide 17

Submission February 2014 Switzerland comment 6 on IEEE 802.1AR (continued) 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) Slide 18

Submission February 2014 Switzerland comment 6 on IEEE 802.1AR (continued) 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 to RFC 2026 (cit.) “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. Slide 19

Submission February 2014 Switzerland comment 6 on IEEE 802.1AR (continued) Switzerland proposed change 6 on IEEE 802.1AR 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. Slide 20

Submission February 2014 Switzerland NB comment CH. 6 on IEEE 802.1AR (continued) IEEE 802 response to comment CH.6 on IEEE 802.1AR IEEE 802.1AR does not and cannot specify normative references in IEEE 802.1X. The proposed change to justify a normative reference in IEEE 802.1X is improper. RFC 7127, Characterization of Proposed Standards, clarifies that an IETF Proposed Standard is mature, has no technical omissions, and are such quality that implementations can be deployed on the Internet. Thus, a Proposed Standard RFC is suitable for as a Reference Specification of the IETF. Additionally, as part of the normal maintenance process for IEEE 802.1AR, the IEEE WG will review the references to ensure that only required references are included, RFC references are up to date, and normative RFC references have an appropriate status. Slide 21

Submission February 2014 Switzerland comment 7 on IEEE 802.1AR Clause 3 The phrasing of most definitions does not conform to the ISO/IEC Directives, Part 2 Switzerland proposed change 7 on IEEE 802.1AR 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 to CH.7 on IEEE 802.1AR IEEE 802.1AR has been developed according to the IEEE Standards Association standards development process and IEEE-SA Standards Style Manual. Editing and maintenance will continue to be the responsibility of IEEE 802 and will conform to the IEEE policies and procedures. The mechanisms defined and agreed in 6N15606 will apply. Slide 22