>>>>> On 23 May 2005 10:09:20 -0700, >>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
>> Part of me is starting to think that we might be better off waiting for >> there to be more operational experience with deployments of DHCPv6 to see >> how much confusion there really is. I agree it is good for vendors to >> implement similar knobs, but I wonder how much of a problem there really is. > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What happens if the M > and/or O bits are set and the client doesn't want to run DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol specifications. > This is impossible. We should stop trying. First of all, as a part of the authors of the "infantile" document, I'd like to emphasize once again that it's not our goal to *enforce* system configuration issues through a protocol document. Perhaps the current text is overacting, but the goal is to "clarify" (as the title of the document shows) confusing points about the M/O flags. (You seem to agree that there *is* confusion, but are saying that clarifying those points is not IETF's work, correct?) Anyway, regarding Bob's point, I can live with that. In fact, my position of these bits has always been we don't have much experience with these flags to be more specific about their usage. And that's why I hesitated to describe more details about those flags in rfc2462bis. On top of this fact, I can live with the approach of leaving the current confusion as is and waiting until we get enough operational experience (then we may or may not need a separate document). Before actually taking this approach, however, I'd like to make a couple of additional notes beforehand: - we removed from rfc2462bis some statements regarding the M/O flags and the "stateful" protocol (=DHCPv6), such as this one: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. or one even with an RFC2119 keyword: In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating with the intention of clarifying these points in the ipv6-ra-mo-flags document. If we stop this work, it means these statements will simply disappear. - rfc2461bis will also need to remove the last sentence from the description of the M/O flags: M 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is further described in [ADDRCONF]. (this comment already applies regardless of the future of ra-mo-flags, since [ADDRCONF](=rfc2462bis) does not talk about these flags anymore) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------