liaison-ieee802response-ARFDIScmts-0314-V01.pptx

Download Report

Transcript liaison-ieee802response-ARFDIScmts-0314-V01.pptx

February 2014
IEEE 802 Response to FDIS comments
on IEEE 802.1AR
20 March 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 CN1 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 CN1 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.
• 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.
Submission
Slide 4
February 2014
China NB comment 2 on IEEE 802.1AR
China NB comment CN2 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 CN2 on IEEE 802.1AR
• Delete the referenced RFC and related technology from the document.
Submission
Slide 5
February 2014
China NB comment CN2 on IEEE 802.1AR
(continued)
Proposed IEEE 802 response to CN2 on IEEE 802.1AR
• 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.
Submission
Slide 6
February 2014
Switzerland comment CH1 on IEEE 802.1AR
Switzerland comment CH1 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 CH1 on IEEE 802.1AR
•
Revise the specification using terms and concepts from International Standards.
Submission
Slide 7
February 2014
Switzerland comment CH1 on IEEE 802.1AR
(continued)
Proposed IEEE 802 response to CH1 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.
• 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.
Submission
Slide 8
February 2014
Switzerland comment CH2 on IEEE 802.1AR
Switzerland comment CH2 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 CH2 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 CH2 on IEEE 802.1AR
(continued)
Proposed IEEE 802 response to CH2 on IEEE 802.1AR
• 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.
Submission
Slide 10
February 2014
Switzerland comment CH3 on IEEE 802.1AR
Switzerland comment CH3 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 CH3 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 CH3 on IEEE 802.1AR
• See response CH2 on slide 10
Submission
Slide 11
February 2014
Switzerland comment CH4 on IEEE 802.1AR
Switzerland comment CH4 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 CH4 on IEEE 802.1AR
(continued)
Switzerland proposed change CH4 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 CH4 on IEEE 802.1AR
(continued)
Proposed IEEE 802 response to CH4 on IEEE 802.1AR
• 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.
Submission
Slide 14
February 2014
Switzerland comment CH5 on IEEE 802.1AR
Switzerland comment CH5 on IEEE 802.1AR
• Clause 2
• While expressing a standardized IETF practice, BCP 4086 is not a
standards-track document
Switzerland proposed change CH5 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 CH5 on IEEE 802.1AR
(continued)
Proposed IEEE 802 response to CH5 on IEEE 802.1AR
• 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.
Submission
Slide 16
February 2014
Switzerland comment CH6 on IEEE 802.1AR
Switzerland comment CH6 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 CH6 on IEEE 802.1AR
(continued)
Switzerland comment CH6 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 CH6 on IEEE 802.1AR
(continued)
Switzerland comment CH6 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 CH6 on IEEE 802.1AR
(continued)
Switzerland proposed change CH6 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 CH6 on IEEE 802.1AR
(continued)
IEEE 802 response to comment CH6 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.
• 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.
Submission
Slide 21
February 2014
Switzerland comment CH7 on IEEE 802.1AR
Switzerland comment CH7 on IEEE 802.1AR
• Clause 3
• The phrasing of most definitions does not conform to the ISO/IEC
Directives, Part 2
Switzerland proposed change CH7 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 CH7 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