(Dear OPs ADs, please read … ) I disagree with the advice in section 8. Cisco IP phones have been deployed with DHCP options that use FQDN and with options that use IP addresses. For this type of use case the FQDM turned out to be much better from an operational and administration point of view. IT departments are used to making sure that changes of IP addresses on servers are well coordinated with changes to the DNS - they are good at doing that and that and have good tools for it. Conversely, they are not used to coordinating server changes with DHCP changes and do not have good tools for that. Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. For nearly every case in the real world, the power and RTT and reliability issues are simply not relevant - regardless of which way you do it, the application is unlikely to work if DNS is down, the extra RTT make no speed difference the user can percieve and the power difference over a day of use of the application is so small it is not measurable. FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for v6 transition, and make it easier to get things to geographically close servers. I don't think it should come a a shock to anyone that the level of indirection that FQDNs provides turns out to be a really useful tool. Lets use that indirection tool where appropriate. Related to this, the advice in section 12 seems a bit off to me. I understand the issues - but keep in mind that many modern applications (browsers and SIP phones for example) do the DNS inside the application instead of using the OS resolvers. Part of the reason for this is asynchronous resolution but part of it is also control of which interface is used for DNS and if multiple interfaces are used, being able to keep the applications traffic on the the appropriate interface for the DNS server that returned the address. So while I agree that "Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source;" Equally true is you can't assume the converse of that. So I think the statement that As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multi- homed client. Is just plain wrong. I think it would be more accurate to say in these cases the results are not always predictable. The issue is the DHCP server may get an DNS answer that contains and server that can not even be reached by the DHCP client. As a general rule of thumb, using FQDN in the configuration of a DHCP server is a really bad idea because IT admins assume that if they change the the DNS information, the clients will get the new information. But they don't. Cullen On Sep 19, 2013, at 3:54 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from the Dynamic Host Configuration WG > (dhc) to consider the following document: > - 'Guidelines for Creating New DHCPv6 Options' > <draft-ietf-dhc-option-guidelines-14.txt> as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2013-10-03. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document provides guidance to prospective DHCPv6 Option > developers to help them creating option formats that are easily > adoptable by existing DHCPv6 software. This document updates > RFC3315. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > >