Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines

[David Hankins <[e-mail]>]

I believe the only text that refers to the preference of FQDN or binary IP
address is in Section 9 ("Option Size"):

   So in either protocol, it is advantageous to prefer option formats
   which contain the desired information in the smallest form factor
   that solves the requirements.  One example is to use a 4-octet IPv4
   address rather than a fully qualified domain name, because many DHCP
   servers will perform DNS resolution on configured FQDN's (so the DNS
   recursive lookup is performed anyway).  There may be motivations to
   use the fully qualified domain name anyway, such as if the intended
   RRSET is not an address, or if the client must refresh the name more
   frequently than common lease renewal periods.


If anyone thinks this is overzealously leaning towards FQDN over binary
addresses, or could use different exceptional examples, please suggest text.
 I considered, but was unable to find a language that seemed polite (not
condescending) to cover the recent use-cases of FQDN in DHCPv6 we have seen;
namely, to use DNS as a protocol to negotiate configuration between separate
administrative domains.

There is a very hard limit on DHCPv4 option space available.  Pointing out
the level of protocol waste that would be required to support the use of DNS
as a administrative-domain-bridge is hopefully poignant and helpful to those
embroiled in such debates.  With DHCPv6, I feel like there's not much more
to say than "Try for the best."

-- 
David W. Hankins
SRE - Systems Engineer
Google, Inc.