IESG response to Appeal Against moving draft-ietf-ipngwg-addr-arch-v3 to Draft Standard

[Harald Tveit Alvestrand <[e-mail]>]

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.