The IESG has reviewed the appeal by Robert Elz of the IESG decision to
approve for publication the Internet Draft
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard.
The appeal consists of two parts:
A/ Draft-ietf-ipngwg-addr-arch-v3-11.txt says:
"For all unicast addresses, except those that start with binary
value 000, Interface IDs are required to be 64 bits long and
to be constructed in Modified EUI-64 format."
In Robert's opinion, this text means that IPv6 implementations must
enforce the requirement that Interface IDs only be 64-bits long. RFC
2026 requires multiple interoperable implementations of a technology,
including all options, must be shown to exist before a document can
progress to Draft Standard status. Robert takes this to mean that two
or more implementations have to be shown to restrict the ability of the
user to set an Interface ID to a length other than 64-bits in order for
the technology to be approved as a Draft Standard.
B/ Robert says "The requirement that where the 'u' bit (the inverted L
bit from the MAC address) is set, the IID is globally unique."
In Robert's opinion, this means that hosts must ensure that the
Interface ID is globally unique in this case. As above, Robert takes
to also mean that two or more implementations have to be shown to
ensure that the Interface ID is globally unique in order for the
technology to be approved as a Draft Standard.
The IESG notes that there is no wording in
draft-ietf-ipngwg-addr-arch-v3-11.txt requiring that IIDs be globally
unique. On this point, the document says:
> Interface identifiers in IPv6 unicast addresses are used to identify
> interfaces on a link. They are required to be unique within a subnet
> prefix.
With regards to the 'u' bit, the requirement is simply:
> Modified EUI-64 format interface identifiers are formed by inverting
> the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
> forming the interface identifier from IEEE EUI-64 identifiers. In
> the resulting Modified EUI-64 format the "u" bit is set to one (1) to
> indicate global scope, and it is set to zero (0) to indicate local
> scope.
That is, the setting of the 'u' bit indicates whether the IID is
derived from an EUI-64 identifier (in which case it is likely to be
globally unique), but is not a guarantee that the IID is globally
unique.
When considering this appeal, it is clear from the interoperability
reports that there are implementations that generate the interface ID
from the EUI-64 identifier, which makes it be 64 bits long. It is
also clear that the uniqueness properties of EUI-64 based identifiers
will be the same as the EUI-64 identifiers from which they are derived
(which is slightly weaker than a requirement for global uniqueness).
So for at least some implementations, they are capable of acting as
specified in the document being challenged.
The IESG notes that the existing practice when advancing documents on
the standards track has not involved having implementation reports
include detailed verification that implementations enforce every
statement as is implied above, in the absence of explicit text
requiring that an implementation make such checks.
We traditionally require that things interoperate when configured
correctly, not that they interoperate when configured incorrectly, or
that it be impossible to configure them incorrectly.
Implementation reports are used to verify that independent
implementations can succesfully interoperate. This is a quality check
on the clarity of the documents.
Requiring explicit verification on all statements would be a change to
existing practice and one that would likely increase the difficulty in
advancing documents on the standards track.
There are many places in IETF standards where a field is stated to be
a specific length or a value to be within a range. Requiring that the
limits be enforced in software for all of these cases would put a
significant extra burden on the implementers and the documenters of
the implementations for questionable benefit.
If the IETF community believes such a change to our procedures is
beneficial, this should be taken as an explicit decision after due
deliberation by the IETF community.
Thus the IESG rejects the appeal.
