Re: Appeal against IESG decision
Robert, all, Here is the IAB's response to this appeal, as it is queued to be announced on [EMAIL PROTECTED] Regards, Leslie. 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 a
Appeal against IESG decision
This is an appeal to the IAB against the IESG decision to reject my appeal against their earlier decision to approve the publication of draft-ietf-ipngwg-addr-arch-v3-11.txt as a Draft Standard. The issues here are very simple, and no lengthy examination of mailing list archives, taking of evidence, hearing opinions, ... should be necessary in this case. I believe that none of the facts are in any kind of dispute. Those facts are 1) RFC2026 says, in section 4.1.2 ... A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. [...] The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. 2) draft-ietf-ipngwg-addr-arch-v3-11.txt contains at least one (and perhaps two) features for which there are not two interoperable implementations. The one is: 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. There's no dispute that there are no interoperable implementations of this - there are no implementations of it at all (or no documented ones anyway). Note that the spec actually gives no option here, other than the exceptions (the 000 addresses, and multicast), interface IDs are required to be 64 bits long.While all implementations I'm aware of allow 64 bit IDs, none have been presented that require it. The draft *requires* it. Any reasonable reading of 2026 would require that that feature of the specification be removed from the draft before the draft is permitted to be published as a draft standard. Of course, as an alternative, the WG or IESG could have the draft, as it is, published as a Proposed Standard, and await the necessary two implementations of the feature before requesting advancement. The IESG's opinion of this seems to be that the "two implementations of every feature" applies only where they consider it important enough to bother checking. I have no problems with drafts advancing when no-one brings to the attention of the IESG that there is a problem in this area. But when a problem is pointed out, the clear words of 2026 really must be enforced. The rationale for this requirement in 2026 is simple (as the IESG should know, as the author of 2026 is a member of the IESG). First, it ensures that the text in the document is clear enough that it can be implemented in an interoperable way. And second, it helps make sure that the document doesn't get cluttered with requirements in practice no-one bothers to implement - that is, that the document is a proper specification, and anyone reading the document can implement from it, with the expectation that their implementation will interoperate with others. The quoted text from the draft fails both of those tests. We have no implementations so we don't know that the text is clear enough to be implemented correctly. It may seem obvious that the text is clear to any reader - but the IETF has always ignored "seem obvious" and required actual implementation experience as a demonstration. Second, an implementation which did faithfully follow the words of the draft would fail to interoperate correctly with every other known implementation of it. It may be claimed that it is the other implementations, or the way they are configured, that is at fault here, but that's not relevant - the aim is to get interoperability, and if we have operators configuring /112, /226, /227 and similar prefix lengths (that is, interface ID's that are 16, 2, or 1, and other, numbers of bits long) - and we do - then an implementation that enforced the 64 bit IID requirement (allowed only /64 prefix on an interface) would fail to interoperate with other implementations (with all other existing implementations). This seems to be a "placeholder" fluff feature, being maintained to perhaps allow some future design to allow applications to simply "know" what is the prefix, and what is the interface-ID. The requirement for existing implementations in 2026 is a specific requirement that such fluff be removed from docs before they're allowed to advance to DS status. The extra requirement should be removed from the document, and then, if the WG so desires, published as a PS (or Experimental) RFC of its own. If it then becomes accepted and implemented, it could be merged back with the main document in a later revision. The second issue in the appeal to the IESG concerned the 'u' bit,
