Make that 200 %. Hesham
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of > Ralph Droms > Sent: Monday, May 23, 2005 2:47 PM > To: [EMAIL PROTECTED] > Cc: dhcwg@ietf.org; Bob Hinden; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > > Tim - I agree 100% with your message. > > - Ralph > > On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote: > > > > 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 -------------------------------------------------------------------- =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
