Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-15.txt

From: [email-masked]
Date: Mon, 09 Dec 2013 10:26:29 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Guidelines for Creating New DHCPv6 Options
	Author(s)       : David W. Hankins
                          Tomek Mrugalski
                          Marcin Siodelski
                          Sheng Jiang
                          Suresh Krishnan
	Filename        : draft-ietf-dhc-option-guidelines-15.txt
	Pages           : 33
	Date            : 2013-12-09

Abstract:
   This document provides guidance to prospective DHCPv6 Option
   developers to help them creating option formats that are easily
   adoptable by existing DHCPv6 software.  It also provides guidelines
   for expert reviewers to evaluate new registrations.  This document
   updates RFC3315.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-option-guidelines-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 09 Dec 2013 19:37:18 +0100

Hi all,

After a long time, we finally managed to address (hopefully) all the
issues raised during IESG review. There's surprisingly large number of
changes:
- FQDN vs addresses section rewritten
  (addresses 2 or 3 DISCUSSes)
- Privacy considerations section added
  (Stephen Farrell requested it)
- Added clarification that the doc can be used during experts review
  (addressed Benoit Claise's positive DISCUSS)
- the wording about RFC5908 (NTP option) ugliness was eased. The text
  simply states that it should not be used as a template for new
  options. (Brian Haberman was unhappy about old text)
- added references to RFC5986, RFC5223
  (Richard Barnes' comment)
- added clarification to text if the draft updates 3315 or not
  (result of latest discussions about unknown-msg draft)
- many smaller clarifications and explanations
  (other nits from IESG)

Most of them could be considered clarification changes, except the one
about address vs FQDN. -14 text strongly suggested using address, unless
there are compelling reasons to use FQDN. The new text tries to make
more balanced approach and explores benefits and flaws of each
approach. This updated text has been agreed with IESG members that
raised DISCUSSes about its previous version.

Since this changes what WG agreed to, I'd like ask Bernie to run a short
WGLC on this to confirm that WG does not have strong objections in that
matter.

Tomek

On 09.12.2013 19:26, [email-masked] wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2013 14:17:25 -0500

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/