Robert, I believe we are just going to disagree on the issue you have.
You seem to be saying that the addr arch document (in order to go to Draft) requires that there exist at least 2 implementations that enforce the requirement that IIDs are exactly 64 bits. That is, they MUST NOT allow IIDs of length other than 64 to be used/configured. The actual requirement that IIDs be 64 bits is not an implementation requirement (in the addressing architecture document). It is a principle that is to be followed by other documents that specify usage of the IID. The last part of Section 2.5.1 says: The details of forming interface identifiers are defined in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. All the other IPv6 over foo documents are consistent with addr arch in this regard. I also remain unconvinced that the wording: 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. translates into a requirement that there exist implementations that disallow IIDs of length other than 64. Following this logic, I suspect one could effectively prevent just about any document from being advanced to Draft. Documents typically have a number of principles that are not testable or enforceable, or where no one would bother to actually enforce something because the actual cost is too high. Consider: > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > [...] > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. What implementations prevent a non-globally unique IPv4 address from being used here? By your logic, this requirement would need to be stricken from the document. Or: > All interfaces are required to have at least one link-local unicast > address (see section 2.8 for additional required addresses). By your logic, we have to show that there are implementations that actually enforce that. I.e, it's not enough that implementations in practice assign a LL address to an interface, we need to show that there are implementations that prevent the possibility of the interface ever operating without a LL address. This is unreasonable. As a more general case, consider a protocol that specifies behavior X. For example, protocol X must rate limit messages of type Y. Well, anyone can come along and implement protocol X over raw sockets and have it flood the network with messages of type Y violating the required rate limitingf behavior. By your reasoning, an implementation of a protocol that doesn't also prevent another implementation running over raw sockets from violoating the spec would not be compliant. In general, no implementation can ensure that the spec is not violated when viewed in this light. Popping up a level, the arguments being used are fairly legalistic (on both mine and your side). Based on some of your earlier mail messages to the WG, it would seem that your real goal here is to do away with the requirement that all IIDs be 64 bits long and in particular you would like to remove the 'u' bit from the IID. But this was discussed explicitly within the WG and there appeared to be little support for your position. It is time to advance addr arch to Draft Standard and move on. 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] --------------------------------------------------------------------
