Joseph Hyunwook Cha <[EMAIL PROTECTED]> writes: > Hello, Thomas.
> Thank you for your analysis and suggestions. > IMO, as long as M&O flags are configured correctly, there is no > reason to ignore the bits. So, I do not think that one of two > options should be selected and specified exclusively. What I am > saying is that it will be ok if there is an option (configurable > policy) in client side for user to run DHCPv6 client irrespecive of > the flags because user can swith its policy to ignorance of flags > in case that running client fails by misconfigured flags. (You can > refer to the draft-ietf-ipv6-ra-mo-flags-01.txt ) One thing I think we need to keep in mind is that we are long past the time where it makes sense (generally) to "make something configurable by the end user" as a way to try to have it both ways. We are past (or rapidly getting past) the day where the standard Internet device is a PC that has a nice GUI that users can configure things with. Think cell phones, iPhones, SlimServers, etc. Also, think typical end users (grandma) who doesn't have a clue about what DHCP is and what it would mean to enable or disable it. We really need to make things work out of the box, by default, for everyone with no configuration. That sort of simplicity is far more important than saving a few multicast messages in certain environments. > As I discussed 71st and 72nd meetings, I do not think that RFC > 2461/2462 are clear enough for implementors to be guieded. ; > Specifically speaking, there are no considerations regarding how to > revoke clients and handle with conflict flags from different > routers. In my note, I specifically did not address this issue. This is completely separate from the basic question of when to invoke DHCP in the first place. I agree we need to have a clear answer on this one too, but my take is that we have consensus that the current text (that does not define a way to "revoke" invocation of DHCP service) is adequate and the current wording in the RFCs is clear about that. (But I'm open to other views on this.) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
