Robert Elz <[EMAIL PROTECTED]> writes: > I believe that the IESG is considering publishing > draft-ietf-ipngwg-addr-arch-v3-09.txt > as a Draft Standard.
> Before that happens, you should be aware that RFC2026 requires > 4.1.2 Draft Standard > 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. > The IPv6 address architecture contains 2 features for which the > interoperability report (as currently published on the IETF web page) > does not comment at all, let alone show two independent and interoperable > implementations from different code bases. > Those two are the requirement that all interfaces use /64 subnets, As you have pointed out on the mailing list yourself, all link-layer types will need to support 64-bit interface identifiers for stateless address autoconfiguration. And we have Ethernet, FDDI, ATM, etc. that do that just that. So there is ample evidence (and implementations) that interfaces support the use of /64 subnets. What you seem to be saying above, however, is subtly different. Namely, that all interfaces must "use" /64 subnets. Presumably you mean "implement", as implementation reports don't necessarily indicate actual "use". But if this is your argument, I disagree with it. It is not possible (nor does it make sense) that when a spec says X, the implementation report somehow needs to show that no implementations do *not* do X. This line of reasoning would effectively prevent *any* specification from ever advancing to Draft, as one can never be sure that some implementation (or future implementation) does not do X. If it were the case that there was evidence that there were implementations that did not do X, that would be useful input, but would certainly not by itself prevent a spec from going to Draft. > and the requirement that when the 'u' bit is set, the address has been > derived from a globally unique MAC address. I'm not exactly sure what you think needs to be shown here. The addrarch document describes how one creates EUI-64 identifiers and how one sets the corresponding 'u' bit. We have a number of other documents (e.g., IP over Ether) that actually require that implementations do this. There seems to be wide agreement that implementations do in fact do this (in fact, this is indicated in the implementation report up at http://www.ietf.org/IESG/Implementations/address-architecture.txt). Again, your words seem to suggest an even stronger requirement, namely, that there be some way to show that implementations that set the 'u' bit have actually derived their IIDs from an IEEE identifier. I know of no way of doing this. However, I also don't see that as a problem. I suspect that it would be easy to find in many specifications some implementation recommendations where it is not immediately possible to demonstrate that an implementation that sets bits in a certain way has actually been "authorized" to do so. (How does one verify that an implementation is authorized to set the 'u' bit?) What 2026 requires, is that the words describing how to implement something are clear enough to get interoperable implementations from. 2026 does not require that an implementation that sets the bits in a field in a certain way has actually satisfied all the assumptions/requirements for setting the bits in that way. This would be an unrealistic requirement. > Further, all experience suggests that implementors are widely ignoring > those two requirements - which makes them exactly the kinds of fluff > that this part of 2026 is demanding be removed. What is your evidence that *implementors* are widely ignoring these requirements? I am aware of none. > Or, or course, the doc can be republished as a PS, while awaiting > implementation of the features. > In any case, the document, as it is, with the interoperability report > that exists, clearly do not satisfy the requirements of 2026 that would > allow the document to be published as a draft standard. I disagree, as explained above. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
