Transcript liaison-ieee802response-ARFDIScmts-0314.pptx

February 2014
IEEE 802 Response to FDIS comments
on IEEE 802.1AR
19 February 2014
Authors:
Name
Submission
Company
Phone
Slide 1
email
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
Submission
Slide 2
February 2014
China NB comment 1 on IEEE 802.1AR
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.
Submission
Slide 3
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.
Submission
Slide 4
February 2014
China NB comment 2 on IEEE 802.1AR
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.
Submission
Slide 5
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 802.1
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.
Submission
Slide 6
February 2014
Switzerland comment 1 on IEEE 802.1AR
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.
Submission
Slide 7
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
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.
Submission
Slide 8
February 2014
Switzerland comment 2 on IEEE 802.1AR
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 15946-2, ISO/IEC 10118-3 and ISO/IEC 14888-3).
- Incorporate technical requirements into the standard text.
Submission
Slide 9
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
802.1 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.
Submission
Slide 10
February 2014
Switzerland comment 3 on IEEE 802.1AR
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 15408 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
Submission
Slide 11
February 2014
Switzerland comment 4 on IEEE 802.1AR
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 nonstandard-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.
Submission
Slide 12
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.
Submission
Slide 13
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 802.1
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.
Submission
Slide 14
February 2014
Switzerland comment 5 on IEEE 802.1AR
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 18031.
Submission
Slide 15
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
802.1 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.
Submission
Slide 16
February 2014
Switzerland comment 6 on IEEE 802.1AR
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 4.1.1 of RFC 2026 (cit.) “a Proposed Standard specification is
generally stable, has resolved known design choices, is believed to be wellunderstood, 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.
Submission
Slide 17
February 2014
Switzerland comment 6 on IEEE 802.1AR
(continued)
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)
Submission
Slide 18
February 2014
Switzerland comment 6 on IEEE 802.1AR
(continued)
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 4.2.4 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.
Submission
Slide 19
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.
Submission
Slide 20
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 802.1 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.
Submission
Slide 21
February 2014
Switzerland comment 7 on IEEE 802.1AR
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.
Submission
Slide 22