Sorry if this overlaps Bernie's response, I can't remember what he said now. On Mon, Mar 16, 2009 at 02:07:11AM +0200, Jari Arkko wrote: >> The version does keep the ability to provide both addresses and FQDNs for >> the mobility servers, however, using separate options. I personally think >> this issue was far less pressing than the above one; if servers can't deal >> with the encoding that's a serious deployment barrier. If there's multiple >> formats to deliver information, that is an extra implementation burden and >> a potential interoperability issue for nodes that choose to disobey the >> RFC and not implement both. However, folks who want to deploy this could >> overcome these easily. As a result, I'm fine with the document moving >> forward as it is. However, the two WGs need to be OK with them as well, >> and when we talked about this in DHC there were concerns about providing >> both addresses and FQDNs. Can we try to close that issue and move on? One question is which of the two options should the client accept if it receives both? Consider that a simplistic client might attempt to configure both, as though it had two servers. Unless the protocol has a way to detect they're talking to the same device mulitiple times, there might be unintended consequences. So it would be my suggestion based upon this feedback, that only the FQDN-formatted option should be selected, because the address- formatted option becomes seemingly superfluous. >> The arguments for the pure address delivery are that (1) its the common >> way to deliver information in DHCP, so it could be supported as a "base" >> mechanism for networks that do not need any SRV mechanisms and (2) there >> may be networks that do not have DNS names for all entities. The other motivation for raw-address format options I've encoded in my draft is that it reduces the number of packets it takes to finalize the client's configuration (important when you spend battery power to transmit), also reducing the number of 'moving parts' to configure the client...only the DHCP service needs to respond, the DNS service can be overloaded or down. It is my personal advocation to choose raw formats because as a once- operator I know what configuration the client should have at the time I write my dhcpd.conf, and it is "making a mountain out of a molehill" to introduce other mechanisms after DHCP - said another way, if I cannot express a precise, final configuration for the client at DHCP- time, my time as an operator is being wasted. But, I seem to recall that the FQDN->SRV mechanism solves a cross- administrative-domain problem for them, so I think that should be the way to go. I also won't object to two options, but I have a suspicion one will be deprecated over time. >> weak side. But what does the DHC WG think? Is the above analysis correct? >> Are there other means to do this that I missed? I think the main points of deploy/usability are solved, so it's OK to proceed. -- 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
Attachment:
pgpAOEeAJ4w0i.pgp
Description: PGP signature