1 / 22

IEEE 802 Response to FDIS comments on IEEE 802.1AB

IEEE 802 Response to FDIS comments on IEEE 802.1AB. 20 March 2014. Authors:. This presentation provides responses to comments on IEEE 802.1AB during FDIS ballot. The FDIS voting results on IEEE 802.1AB in N15829 It passed 16/1/16 ( China NB voted negative)

brody
Download Presentation

IEEE 802 Response to FDIS comments on IEEE 802.1AB

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 Response to FDIS comments on IEEE 802.1AB • 20 March 2014 Authors:

  2. This presentation provides responses to comments on IEEE 802.1AB during FDIS ballot • The FDIS voting results on IEEE 802.1AB in N15829 • It passed 16/1/16 (China 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

  3. China NB comment CN1 on IEEE 802.1AB • China NB comment CN1 on IEEE 802.1AB • Since the procedural and technical concerns China NB proposed in 6N15626 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.

  4. China NB comment CN1 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CN1 on IEEE 802.1AB • IEEE 802 thanks the China NB for its carefully considered comments on the 802.1AB FDIS ballot • We note that 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. • We have noted the comment that the China NB is “obliged to lose the responsibility and obligation of complying with and adopting the standard”. It is out of scope for IEEE 802 and therefore we will forward it to ISO Central Secretariat.

  5. China NB comment CN2 on IEEE 802.1AB • China NB comment CN2 on IEEE 802.1AB • The referenced RFC 2863, RFC 2108, RFC 2863, RFC 3629, RFC 4502 are draft standards. The referenced RFC 3232, RFC 3410 are informational standards. The referenced RFC 1812, RFC 4293 are proposed standards. The referenced RFC 3046, RFC 3621, RFC 4133, RFC 4363, RFC 4546, RFC 4639, RFC 4789, RFC 4836 are unknown type of standards. All of above listed RFC standards are unqualified for normative references in ISO standards. China NB proposed change CN2 on IEEE 802.1AB • Delete the referenced RFC and related technology from the document.

  6. China NB comment CN2 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CN2 on IEEE 802.1AB • We note that ISO and JTC1 referencing rules allow references to informational, proposed standard and draft standard IETF RFCs • IEEE 802 standards are developed according to the IEEE SA standards development process and IEEE-SA Standards Style Manual, and the PSDO agreement accepts the formatting and referencing rules of the IEEE-SA. The IEEE-SA referencing rules also allow references to informational, proposed standard and draft standard IETF RFCs • As part of the normal maintenance process for IEEE 802 standards, the relevant 802 WG reviews the references to ensure that only required RFC references are included, RFC references are up to date, and normative RFC references have an appropriate status.

  7. Switzerland comment CH1 on IEEE 802.1AB • Switzerland comment CH1 on IEEE 802.1AB • 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, 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.

  8. Switzerland comment CH1 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CH1 on IEEE 802.1AB • IEEE 802 thanks the Switzerland NB for its carefully considered comments on the IEEE 802.AB 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 and agreed in 6N15606. 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.

  9. Switzerland comment CH2 on IEEE 802.1AB • Switzerland comment CH2 on IEEE 802.1AB • When the ISO/IEC/IEEE 8802-1AB standard 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.

  10. Switzerland comment CH2 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CH.2 on IEEE 802.1AB • IEEE 802.1AB 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. • We look forward to collaboration with the Swiss NB in the future.

  11. Switzerland comment CH3 on IEEE 802.1AB • Switzerland comment CH3 on IEEE 802.1AB • Since the year 2002, ISO/IEC 8824-1 and ITU-T Rec. X.680 have been revised. • Switzerland NB proposed change CH3 on IEEE 802.1AB • Use an undated reference or a dated reference to the most recent edition. • Proposed IEEE 802 response to CH3 on IEEE 802.1AB • This comment will be submitted to the IEEE 802.1 maintenance process and considered by the IEEE 802.1 Maintenance Task Group for potential inclusion in a future revision or corrigendum to the standard.

  12. Switzerland comment CH4 on IEEE 802.1AB • Switzerland comment CH4 on IEEE 802.1AB • IEEE Std 802.1 has been submitted for publication as ISO/IEC/IEEE 8802-1X. • Switzerland proposed change CH4 on IEEE 802.1AB • Reference ISO/IEC/IEEE 8802-1X. • Proposed IEEE 802 response to CH4 on IEEE 802.1AB • This comment will be submitted to the IEEE 802.1 maintenance process and considered by the IEEE 802.1 Maintenance Task Group for potential inclusion in a future revision or corrigendum to the standard.

  13. Switzerland comment CH5 on IEEE 802.1AB • Switzerland comment CH5 on IEEE 802.1AB • RFC 3232 and 3410 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. • Switzerland proposed change CH5 on IEEE 802.1AB • 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 to CH5 on IEEE 802.1AB • See Proposed IEEE 802 response to CN2 on IEEE 802.1AB in slide 6.

  14. Switzerland comment CH6 on IEEE 802.1AB • Switzerland comment CH6 on IEEE 802.1AB • RFC 2863 and 4502 have been published in the year 2000 and 2006, respectively, but are still at DRAFT STANDARD status. According to RFC 6410 they will be reclassified as PROPOSED STANDARD in October 2013. • 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. • 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.

  15. Switzerland comment CH6 on IEEE 802.1AB (continued) • Switzerland comment CH6 on IEEE 802.1AB (continued) • (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) • 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.

  16. Switzerland comment CH6 on IEEE 802.1AB (continued) • Switzerland proposed change CH6 on IEEE 802.1AB • 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.1AE 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.

  17. Switzerland comment CH6 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CH6 on IEEE 802.1AB • IEEE 802.1AB does not and cannot specify normative references in IEEE 802.1AE. The proposed change to justify a normative reference in IEEE 802.1AE is improper. • We note that ISO and JTC1 referencing rules allow references to informational, proposed standard and draft standard IETF RFCs • IEEE 802 standards are developed according to the IEEE SA standards development process and IEEE-SA Standards Style Manual, and the PSDO agreement accepts the formatting and referencing rules of the IEEE-SA. The IEEE-SA referencing rules also allow references to informational, proposed standard and draft standard IETF RFCs • As part of the normal maintenance process for IEEE 802 standards, the relevant 802 WG reviews the references to ensure that only required RFC references are included, RFC references are up to date, and normative RFC references have an appropriate status.

  18. Switzerland comment CH7 on IEEE 802.1AB • Switzerland comment CH7 on IEEE 802.1AB • RFC 1812, 2108, 3046, 3621, 4133, 4293, 4363, 4546, 4639, 4789 and 4836 have been published between the year 1995 and 2007, 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. • 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.

  19. Switzerland comment CH7 on IEEE 802.1AB (continued) • Switzerland comment CH7 on IEEE 802.1AB (continued) • (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) • 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.

  20. Switzerland comment CH7 on IEEE 802.1AB (continued) • Switzerland proposed change CH7 on IEEE 802.1AB • 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.1AB 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.

  21. Switzerland comment CH7 on IEEE 802.1AB (continued) • Proposed IEEE 802 response to CH7 on IEEE 802.1AB • We note that ISO and JTC1 referencing rules allow references to informational, proposed standard and draft standard IETF RFCs • IEEE 802 standards are developed according to the IEEE SA standards development process and IEEE-SA Standards Style Manual, and the PSDO agreement accepts the formatting and referencing rules of the IEEE-SA. The IEEE-SA referencing rules also allow references to informational, proposed standard and draft standard IETF RFCs • As part of the normal maintenance process for IEEE 802 standards, the relevant 802 WG reviews the references to ensure that only required RFC references are included, RFC references are up to date, and normative RFC references have an appropriate status.

  22. Switzerland comment CH8 on IEEE 802.1AB • Switzerland comment CH8 on IEEE 802.1AB • The phrasing of most definitions does not conform to the ISO/IEC Directives, Part 2 • Switzerland proposed change CH87 on IEEE 802.1AB • Discard articles (“a”, “the”) at the beginning of the definition. Avoid two or more sentences. Discard Notes. Do not re-define terms (such as OID) in the scope of existing standards, but include them by normative reference. • Proposed IEEE 802 response to CH8 on IEEE 802.1AB • IEEE 802.1AB 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.

More Related