Re: [dhcwg] Changes in draft-ietf-dhc-option-guidelines-15

[Ted Lemon <[e-mail]>]

Here's my review of the update, AD hat off.

Section 8, paragraph 3, talking about providing lists of IP addresses:

   This problem may be partially addressed by
   providing a list of addresses, rather than just a single one.  That,
   on the other hand, complicates client operation, as some kind of
   failover procedure has to be defined and implemented.

This goes against existing practice—almost no DHCP option returns only a single IP address for a server, nor is this expected behavior.   Furthermore, cycling through a list of addresses is easy, and you'd have to do it with a DNS response as well.   So I don't think this point makes sense.

Next paragraph:

OLD:
   This allows pointing at
   more localized services.  However, such a practice requires violating
   DNS principles ('split horizon'), and hence is not recommended.
NEW:
   This is one way to provide localized addressing.   However, in order
   to do this, it is necessary to violate the DNS convention that a query
   on a particular name should always return the same answer (aside from
   ordering of IP addresses in the response, which is supposed to be varied
   by the name server).   This same locality of reference for configuration
   information can be achieved directly using DHCP, since the DHCP server
   must know the network topology in order to provide IP address or
   prefix configuration.

Next paragraph:

OLD:
   The other type of ambiguity is related to multiple provisioning
   domains (see Section 12), and may get a different answer from the DNS
   depending on which interface or DNS server is used to do the
   resolution.  This is particularly a problem when the normal expected
   use of the option makes sense with private DNS zone(s), as might be
   the case with a corporate VPN.  It may also be the case that the
   client has explicit DNS server configured so may not be using the
   corporate internal DNS server.
NEW:
   The other type of ambiguity is related to multiple provisioning
   domains (see Section 12).   The stub resolver on the DHCP client
   cannot at present be assumed to make the DNS query for a DHCP-
   supplied FQDN on the same interface on which it received its
   DHCP configuration, and may therefore get a different answer from
   the DNS than was intended.

   This is particularly a problem when
   the normal expected use of the option makes sense with private
   DNS zone(s), as might be the case on an enterprise network.  It
   may also be the case that the client has an explicit DNS server
   configured, and may therefore never query the enterprise network's
   internal DNS server.

This advice is simply wrong:

   It may be generalized that the preference for address or FQDN depends	
   on its envisaged usage.  Short lived (immediately consumed) data	
   should be address based, while long timed information is better	
   served with FQDN.

I don't think this is the basis on which the distinction should be made.   E.g., is the DNS server IP address a short-term data item?   I don't think so.   It's reasonable to expect that any data returned by the DHCP server will be used for the duration of the lease, so this distinction provides no guidance.

This paragraph likewise offers no useful guidance:

   Another aspect that should be considered is time required for the	
   clients to notice any configuration changes.  Consider a case where a	
   server configures a service A using address and service B using FQDN.	
   When an administrator decides to update the configuration, he or she	
   can update the DHCP server configuration to change both services.  If	
   the clients do not support reconfigure (which is an optional feature	
   of RFC3315, but in some environments, e.g. cable modems, is	
   mandatory), the configuration will be updated on clients after T1	
   timer elapses.  Depending on the nature of the change (is it a new	
   server added to a cluster of already operating servers or a new	
   server that replaces the only available server that crashed?), this	
   may be an issue.  On the other hand, updating service B may be	
   achieved with DNS record update.  That information may be cached by	
   caching DNS servers for up to TTL.  Depending on the values of T1 and	
   TTL, one update may be faster than another.  Furthermore, depending	
   on the nature of the change (planned modification or unexpected	
   failure), T1 or TTL may be lowered before the change to speed up new	
   configuration adoption.

Since we don't know what the TTL or the T1 time will be, as protocol designers, we simply can't make assumptions about whether a DHCP option will be refreshed more quickly based on T1 or TTL.   Realistically, expectations about sudden network reconfiguration information being quickly propagated to the client are simply not dependable unless reconfigure is in fact available.

Next paragraph:


   Addresses have a benefit of being easier to implemented and handle by	
   the DHCP software.  An address option is simpler to use, its	
   validation is trivial (multiple of 16 constitutes a valid option), is	
   explicit and does not allow any ambiguity.  It is faster (does not	
   require extra round trip time), so it is more efficient, which can be	
   especially important for energy restricted devices.  It also does not	
   require having resolution capability.

If you keep the last sentence, it should say this:
   It also does not require that the client implement DNS resolution.

However, I'm not convinced that this is a compelling argument.

Section 16, paragraph 2:

   If multiple instances are	
   allowed, the document MUST explain how to use them.  Care should be	
   taken to not assume the they will be processed in the other they	
   appear in the message.  See Section 17 for more details.

s/other/order/

In section 22, looks like an editing error:

   On the other hand, if a new document replaces, modifies
   existing behavior, it should be noted that it updates the other
   document.  For example, [RFC6644] clearly updates [RFC3315] as it
   replaces existing with new text.
s/replaces, modifies/replaces or modifies/