Hello, Thomas. Inline comments are continued below.
2008/10/15 Thomas Narten <[EMAIL PROTECTED]>: > 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. > To fix problem caused by misconfigured flags, there are two options. i) to fix misconfiguration of routers and ii) to change running policy of DHPCv6 client in user node. I think that in most cases, the first way is feasible. I agree that grandma can not configure a CPE router box in her home. Then, where is DHCPv6 server for the client in her node and who is responsible for the configuration of it? If the server is provisioned by service provider, it is very likely that CPE router box has DHCPv6 relay installed and configured to be enabled. Then, I think that your concern is not big because box can be implemented for M&O bits to be TRUE automatically if DHCPv6 server or relay agent is turned on. Even if relay/server is not collocated with the CPE router, it is not such a big task to change M&O bits in RA for whoever is responsible for the configration of server/relay. I also believe that the second option might be necessay with whatever reasons. This might not be feasible for grandma. However, it depends on UI in implementations and users. In short, I am ok if failure is easily detactable and there are obvious ways to solve the failure. >> 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.) > I am not sure that there is consensus that it is ok not to define a way to "revoke" invocation of DHCPv6 client and the current wording in the RFCs is clear on that issue. I believe that unless M&O bits are deprecated, a way to "revoke" invocation of DHCPv6 client is required. > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
