Well stated and with this can we please stop there is no other point to discuss. For those that don't like stateful don't use it. For those that don't like stateless your stuck with it by default set the m and/or o bits.
thanks /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tim Hartrick > Sent: Monday, May 23, 2005 1:09 PM > To: Bob Hinden > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > > > Bob, > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > > > 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. > > > > > tim > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
