On Saturday, January 4th 2003, Robert Elz filed an appeal with the
Internet Architecture Board (IAB). The appeal concerned the IESG
decision to publish draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft
Standard and the subsequent IESG consideration of an appeal to the
IETF chair on this matter.
1. Background
The appeal asked the IAB to consider whether the Internet Engineering
Steering Group's (IESG's) decision to approve the publication of
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard met the
process and technical standards of the IETF. The appeal contained the
following claims:
1) That the IESG failed to verify interoperability of 2
independent implementations for the Internet Protocol
version 6 (IPv6) unicast address format defined in the
above Internet-Draft.
2) That the IESG failed to verify that 2 independent implementations
exist that prohibit the configuration of any IPv6 unicast
address (not including those that start with binary 000)
that does not have a 64-bit Interface-Identifier (Interface-ID).
3) That the document draft-ietf-ipngwg-addr-arch-v3-11.txt fails
to clearly indicate (e.g. using customary MAY, SHOULD, MUST
language) which parts of the document are mandatory or
optional to implement or which parts of the document are
interoperability requirements.
4) That the document uses the phrase "global scope" in a way that
is materially confusing and causes a typical reader to
incorrectly assume that "global scope" means "globally
unique".
5) That the IESG has failed to verify that at least two interoperable
implementations exist that prohibit the configuration of
an interface-ID with the 'u' bit when the basis of the
interface-ID is not a "globally unique token (MAC address
or similar)".
6) That the document is materially unclear with respect to the
language on when the 'u' bit of an Interface-ID is
permitted to be set (or not set).
In its rejection of Robert Elz's original appeal to the IESG,
the IESG stated:
A) That there is no traditional requirement that implementation reports
"include detailed verification that implementations enforce
every statement...in the absence of explicit text requiring
that an implementation make such checks."
B) That the requirement is that implementations operate when
correctly configured, not that they interoperate when
incorrectly configured.
C) That there is no traditional requirement that an implementation
disallow an operator from misconfiguring a protocol.
D) That the Internet-Draft in question does not require that
the Interface-ID be globally unique when the 'u' bit
is set; it merely requires that the Interface-ID comply
with the EUI-64 specification when the 'u' bit is set.
E) That Elz's appeal is rejected by the IESG.
2. IAB Conclusion
Some of the issues raised in this appeal represent instances in which
the process or technical standards of the IETF were not met. On that
basis, the IAB has determined that the IESG decision to advance this
specification on the IETF standards-track as a Draft Standard in its
current form, and the IESG's subsequent response to Elz's appeal, were
incorrect.
On that basis, the draft in its current form must not be published as a
IETF Draft Standard, and may be published as an IETF Proposed Standard.
The IAB response to this appeal is in three parts. The first part
contains particular facts determined by the IAB that relate to the
claims made in the appeal. The second part contains related
observations of the IAB arising from its review of documents germane to
the appeal. The third part contains recommendations to the IESG as to
possible actions on how to remedy the matters raised here.
2.1 Salient Facts
The IAB has determined the following facts regarding the Elz appeal:
I) An IP Address Architecture specification will always need to have
some implementation requirements and interoperability
requirements. Addressing and routing are inextricably
linked. Decisions about an address architecture necessarily
have impacts on the forwarding of IP packets and on
the routing protocols. If there were no requirements
in an IP Address Architecture, it is very unlikely that
global interoperability could result in practice. We
further find that an IPv6 Address Architecture document
belongs on the standards-track.
II) The IETF standards process does NOT require that a tested
implementation prohibit misconfiguration of a protocol
parameter, unless there is a specific written statement
requiring such in the applicable specification document.
The IAB makes the additional comment that to interpret
the standards process requirements otherwise would be to
make it nearly impossible for any IETF standards-track
specification to advance and would be a new and undue
process burden on the IETF.
III) The IETF standards process does require that the default settings
for each protocol parameter are valid and interoperable
when tested as part of an interoperability report. It
is not required that each protocol parameter's default
setting be individually documented in an interoperability
report. The IETF requires interoperability testing, not
conformance testing, as part of advancement beyond Proposed
Standard according to RFC-2026.
2.2 IAB Considerations
In the course of reviewing the appeal and studying the facts
germane to the appeal, the IAB also reached consensus on the
following points:
IV) The Internet-Draft in question is not sufficiently clear
in specifying the implementation requirements and/or
interoperability requirements for the IPv6 Address
Architecture.
V) This lack of clarity on the part of the draft document violates
criteria as specified in RFC-2026 and RFC-2119, by not
containing clear documentation of the implementation
requirements and interoperability requirements. On this
basis, the draft cannot be published in its current form on
the IETF standards-track as a Draft Standard.
VI) The questions of whether the IESG properly verified
implementation report details regarding this I-D are moot,
due to the consideration that the I-D itself was in violation
of RFC-2026 and RFC-2119.
VII) The phrase 'global scope' does not mean 'globally unique'. There
remains, however, some scope for confusion as to the precise
meaning of the term 'global scope' for the average reader.
VIII) The existing specification of how the 'u' bit is used in
an IPv6 unicast Interface-ID is clear, but the current
version of the I-D under appeal is unclear regarding the
implementation or interoperability requirements, if any,
that are related to the 'u' bit
IX) The IAB considers that the separation of the Interface-ID from
the Subnet Identifier in IPv6 unicast addresses not starting
with binary 000 is a fundamental property of the IPv6
addressing and routing architecture and should be retained.
X) The IAB notes that RFC-2461 Section 4.6.2 permits an IPv6
router to advertise an IPv6 unicast prefix-length of
more than 64 bits while simultaneously setting the
'autonomous configuration' flag to true. Further,
the RFC-2462 Section 5.5.3d does not explicitly require
that the IPv6 prefix length not exceed 64 bits, as
the IPv6 Address Architecture draft requires. Hence,
we find a material conflict between the specifications
in the IPv6 Address Architecture draft, in RFC-2461, and
in RFC-2462.
XI) We believe that the conflicts noted in (X) occurred primarily
because of the failure of the I-D under appeal to comply
with the requirement for clearly specified implementation
and interoperability requirements as per RFC-2119 and
RFC-2026.
XII) We concur with IESG statements paraphrased above as (A), (B),
(C), and (D). However, we reject the IESG conclusion (E) on
the basis that the IESG's reply to Elz ignored the question
of whether the current language regarding implementation
requirements and interoperability requirements in draft-ietf-
ipngwg-addr-arch-v3-11.txt is sufficiently clear and fully
compliant with RFC-2026 and RFC-2119.
2.3 IAB Recommendations
The IAB makes the following recommendations with regard to draft-ietf-
ipngwg-addr-arch-v3-11.txt. An organizing theme behind these
recommendations is a desire on the part of the IAB to see the IPv6
addressing architecture stabilized as quickly as possible, with
interoperability requirements clearly specified, in an aid to
facilitating the more rapid implementation and deployment of IPv6 in the
Internet infrastructure.
As noted in Section 2, the IAB has determined that the draft in its
current form must not be published as an IETF Draft Standard.
a) We recommend to the IESG that the current version of the I-D draft
be published as a Proposed Standard.
b) we recommend that the IESG consider the publication of subsequent
updates to this document as per recommendations c) and d).
c) We recommend that, as an update to this document, and via a
recommendation to the IESG, that the IPv6 Working
Group create clear, specific, and concise implementation and
interoperability requirements as per RFC-2026 and RFC-2119 in
any revised version of the IPv6 Addressing Architecture
document. This includes, but is not limited to, the
specification of any implementation or interoperability
requirements relating to the use of the 'u' bit in an IPv6
unicast Interface-ID.
d) We recommend that, as an update to this document, and via a
recommendation to the IESG, that the IPv6 Working Group uses
clearer specification language as per RFC-2026 and RFC-2119 to
describe the requirement for a 64-bit Interface-ID in IPv6
unicast addresses not starting with binary 000.
e) We recommend that, via a recommendation to the IESG, that the IPv6
Working Group expeditiously revise RFC-2461 to:
- specifically note that it is not valid to configure an IPv6
router such that the 'autonomous configuration' bit is set
to TRUE AND the advertised IPv6 prefix length exceeds 64
bits AND the advertised IPv6 prefix does not start with
binary 000,
and also expeditiously revise RFC-2462 to:
- specifically require that a host ignore a Prefix
Advertisement Option when the first three bits of the
advertised IPv6 prefix do not start with binary 000 AND the
advertised IPv6 prefix-length exceeds 64-bits.
Leslie Daigle,
for the IAB.
