On Sat, Aug 11, 2007 at 05:51:09PM +0900, JINMEI Tatuya / 神明達哉 wrote: > In any event, I hear that some DHCPv6 guys are planning to make a new > draft that covers this topic. So I think it's better to hold off for > now and wait for the document, rather than continue this thread > with keeping possible misunderstanding or confusing about the base > protocol principles.
I agree with everything Jinmei said, but this in particular. Any conclusions from these threads have a tendency to get forgotten - it's better that we argue the position of a draft that an editor can follow consensus. But - before I hold my own tongue - I'd like to say that I think Tammy has given us a kind of horse-sense wisdom that we don't often see at the IETF; http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07421.html If I may expand on what I took away from that; - RTADV and DHCPv6 do 'kind of' the same thing. They configure knobs related to the network to which the host is attached. From the host's point of view, it is not "on the network" until both vehicles succeed. To get "on the network" reliably, both vehicles must succeed reliably. The number of corner cases to manage is staggering. - It doesn't make a lick of difference to a host which vehicle gives them the configuration information. Machines can't taste, they just consume the config. Corrolaries; A host's user is going to call the systems admin, not the router operator, if one, the other, or both vehicles fail. Neither will a host's user appreciate the difference between configuring its prefix/router and its address/assist-servers. - It doesn't really appear to make any difference at all to the network which vehicle gives them the configuration information. Clarifications; Ostensibly, the RTADV may be colocated on the router whereas DHCPv6 may be remote. But just as there's no reason why RTADV can't be colocated on a server (such as where there is no router), there is also no reason why DHCPv6 can't be colocated on a router (such as, in the home, where there is no server). So the "fate sharing" principle is bankrupt here: you can share whatever fate you want either way. The existence of two separate protocols doesn't create fate. So one thing we should consider and measure is wether or not this is an example of "throwing spaghetti at the wall to see what sticks," and if so wether or not it is worthwhile to make an attempt to clean up. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpjKNL7lAFTl.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
