Subject: [dhcwg] WGLC request for draft-ietf-dhc-option-guidelines-11

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Apr 2013 14:49:32 +0200

<chair hat off>
Bernie, authors of draft-ietf-dhc-option-guidelines-11 believe that this
work is ready and would like to ask for WGLC. Can you announce one, please?

Thanks,
Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Apr 2013 15:06:15 +0000

Folks, the authors of draft-ietf-dhc-option-guidelines-11,
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11, feel it's
ready for a WGLC.  There's been discussion and comment already, but more
eyes on and a "final" review of this work are required to advance it.

This document is critical as it provides guidance to others in the IETF
that may not be DHCP "experts" when they need to write a DHCP option
internet-draft.

At the time of this writing, there is no IPR reported against this draft.

Please review the draft and indicate whether or not you feel it is ready
to be published. Your response matters to the process, so please do
respond.

As Tomek is an author, I will evaluate consensus after April 24, 2013.

Thanks!

-	Bernie

---

From: Bud Millwood <[email-masked]>
Date: Wed, 10 Apr 2013 00:11:03 +0200

I'm so glad to see all this knowledge and experience finally codified in
one place! Great work.

- Figure 7 should say "variable", not "variale".

- Section 10: "Introducing additional timers make deployment unnecessarily
complex and should be avoided."

* Change "make" to "makes"

- Section 11

* I think the whole section is poorly written and poorly justified. How
about:

----
11. Configuration changes occur at fixed times

In general, DHCPv6 clients only refresh configuration data from the DHCP
server when the T1 timer expires.
Although there is a RECONFIGURE mechanism that allows a DHCP server to
request that clients initiate
reconfiguration, support for this mechanism is optional and cannot be
relied upon.

In light of the above, when designing an option you should take into
consideration the fact that your option
may hold stale data that will only be updated at an arbitrary time in the
future.
----

- Bud

On Tue, Apr 9, 2013 at 5:06 PM, Bernie Volz (volz) <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: <[email-masked]>
Date: Fri, 12 Apr 2013 14:12:04 +0200

Dear all,

I read this version. Thanks for the work.

IMHO, http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-8 does not reflect the consensus of the WG on these matters. Especially, it does not reflect what has been discussed during the call for adoption for http://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding/. 

Saying IP Address is superior to FQDN is just not that trivial to say. It is not a universal statement and it makes deployment assumptions. I don't want to reiterate what have been discussed for draft-boucadair-dhc-address-name-encoding, archives are there to extract the exact position of the wg. 

The text in Section 8 still assume DNS is the only available name resolution library; this is not anymore true. Section 2 of draft-boucadair-dhc-address-name-encoding provides a much more balanced comparison. 

Instead of picking a winner (IP Address vs. FQDN), it is more valuable to investigates ways to accommodates operational needs rather than imposing a deployment choice for entities deploying servers and making use of a given option.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Bernie Volz (volz)
>Envoyé : mardi 9 avril 2013 17:06
>À : [email-masked]
>Objet : [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by
>April 24
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 22 Apr 2013 14:35:36 +0000

I'm in favor of advancing it. Thank the authors for writing this great document!

Just one minor comment, I'm not sure, but just throwing out my idea:
We have 22 sections in one document, it might be a little fragmented, so would it be better to aggregate the specific guidelines into less number of principles or aspects? So that it might be easier for the readers to understand and remember in mind.

Cheers,
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bernie Volz (volz)
> Sent: Tuesday, April 09, 2013 11:06 PM
> To: [email-masked]
> Subject: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by
> April 24
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 25 Apr 2013 15:29:32 +0200

> that may not be DHCP "experts" when they need to write a DHCP option
I strongly support this work. Having such a set of guidelines published
will make any review much easier. That will be especially handy for
drafts that are written outside of DHC WG.

I'm surprised that there's somewhat weak response to this last call so
far. Please, read this draft (it is easy read) and state you opinion on it.

Disclaimer: Although I'm listed as co-author, I merely joined in around
a year ago. This document was created and developed by David Hankins,
who unfortunately is no longer active in DHC WG.

Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 26 Apr 2013 01:32:02 +0000

As one of the late-join coauthor, I personally find such document is very useful for any readers who may create new DHC options. That's why I volunteered to wake this draft up and complete it. The current version has done a lot more work based on the previous version. It is real easy-read and good guidelines for readers. I support to move it forward.

Best regards,

Sheng

>Of Tomek Mrugalski
>Sent: Thursday, April 25, 2013 9:30 PM
>To: [email-masked]
>Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by
>April 24
>

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Fri, 26 Apr 2013 02:00:10 +0000

I have read and strongly support this work too. I find it very useful
especially when designing new DHCP options.

Shwetha 

On 4/26/13 7:02 AM, "Sheng Jiang" <[email-masked]> wrote:

>As one of the late-join coauthor, I personally find such document is very
>useful for any readers who may create new DHC options. That's why I
>volunteered to wake this draft up and complete it. The current version
>has done a lot more work based on the previous version. It is real
>easy-read and good guidelines for readers. I support to move it forward.
>
>Best regards,
>
>Sheng
>

---

From: GangChen <[email-masked]>
Date: Fri, 26 Apr 2013 10:32:06 +0800

I support this WGLC. The draft already has stable and useful contents.

BRs

Gang

---

From: Marcin Siodelski <[email-masked]>
Date: Fri, 26 Apr 2013 10:21:20 +0200

I am one of the late joint co-authors of this draft. I also find this
very important to have such a guideline document. I strongly support
advancing this document.

Marcin

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 26 Apr 2013 09:58:55 -0400

I am also late, though not a co-author of this draft -- I'm just late.

I have read this document and support advancing it beyond last call.

Regards -- Kim

---

From: Qi Sun <[email-masked]>
Date: Sun, 28 Apr 2013 16:29:28 +0800

Dear all,

I think this guideline is very useful. I support the WGLC on the document.

Best Regards,
Qi Sun

---

From: David Hankins <[email-masked]>
Date: Mon, 29 Apr 2013 11:28:08 -0700

Med, I believe the draft as written is consistent with the publishing of
RFC 6334, and summarizes most of the points you make in
dhc-address-name-encoding.

But your point in section 2.2.2 is hard to understand.  It's equivalent to
configure the regionalized FQDN in the DHCP server or client; the same name
will be resolved from the same (separate administrative domain) DNS server
which is authoritative.  That is to say, whereas Client A and Client B will
resolve separate names if given separate names, Server A will resolve
separate names for Client A and Client B and deliver to them the results of
those specific resolutions.  The only differences are that 1) regional
teams do not get a DNS packet with a source address specific to the client
which they can use to inform load balancing decisions, so this reduces to
be the same as your point in 2.2.3 and 2) the name can not be overloaded
(where e.g. "foo-server.orange.com." is resolved differently depending on
which recursive resolver is used - depending on something similar to what
BIND calls "views") - but this again reduces to your point in 2.2.3 as it
is simply a second level of domain name load balancing.

I can only guess one possible misunderstanding on your part; RFC 3315 FQDN
format options convey Fully Qualified Domain Names.  This is a name
including an explicit zero length label indicating the DNS Root.  DNS
search paths are not applied to names conveyed by RFC 3315 format names,
except as a non-standard extension of the protocol (or by this detail
simply being overlooked by implementers).

So one does not gain any additional ability to handoff between
administrative domains by the ability to configure a "foo-server" server
name in an DHCP option and "thoseguys.orange.com" in domain search path
separately.  There is no significant DHCP server configuration complexity
reduction since all servers I'm familiar with (excepting "embedded device"
/ zeroconf servers etc.) provide a means to concatenate names
hierarchically.

And one of the points you missed in your draft is that the server
performing the recursive resolution to populate an IP address option for
the client most likely locally caches the lookup internally (as opposed to
externally).  This changes the game from a zero-sum latency movement into a
latency net win, obeying DNS TTL semantics.

So in my opinion it remains superior to use a raw IP address format when
there's no compelling reason to promote the option under consideration to a
FQDN.  I believe, after some effort, the participants of the softwires wg,
yourself included, eventually justified that promotion for the publication
of RFC 6334.  Undertaking that effort to extract such requirements is
important; we need to produce the lightest and fastest protocols we can.

"Use What You Need."

It's my opinion that the current text conveys that message.  At some points
in the text, we also underscore that these are guidelines, and it is not
intended for the document to constrain future protocol development.

It's also my opinion that RFC's 3361, and 3319 are casualties of the
organizational failure to clearly communicate the constraints and
requirements.  I'm not familiar with the other RFC numbers, but I'm
guessing a similar problem prevailed.

On Fri, Apr 12, 2013 at 5:12 AM, <[email-masked]> wrote:

> IMHO,
> http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-8does not reflect the consensus of the WG on these matters. Especially, it
> does not reflect what has been discussed during the call for adoption for
> http://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding/
> .
>
> Saying IP Address is superior to FQDN is just not that trivial to say. It
> is not a universal statement and it makes deployment assumptions. I don't
> want to reiterate what have been discussed for
> draft-boucadair-dhc-address-name-encoding, archives are there to extract
> the exact position of the wg.
>
> The text in Section 8 still assume DNS is the only available name
> resolution library; this is not anymore true. Section 2 of
> draft-boucadair-dhc-address-name-encoding provides a much more balanced
> comparison.
>
> Instead of picking a winner (IP Address vs. FQDN), it is more valuable to
> investigates ways to accommodates operational needs rather than imposing a
> deployment choice for entities deploying servers and making use of a given
> option.
>
> Cheers,
> Med
>

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Apr 2013 02:58:08 +0000

I support this document, and would like to see it advance quickly, but I also have some suggestions for it.   Most of these suggestions are made with my AD hat off; however the suggestions for changes to section 13 are specifically with my AD hat on, because I think this stuff needs to be said, and I wouldn't have known to say it before I started thinking about chartering from the perspective of an AD.

But even with my AD hat on, I'm not saying you have to add that text—just that as your AD, I think it would be beneficial to the working group in the long run.   Obviously, that text is substantial enough to require a new WGLC.

First, I've suggested before that the document ought to be BCP rather than standards track.   I suspect that it's been kept at Standards Track because it updates RFC 3315, but Dave Hankins says it doesn't.   The reason to call it a BCP is because it's something we can point to when people are writing DHCP extensions, whether they be trivial extensions or more serious ones.   I don't think you can call it Standards Track because there's nothing to implement, and no way to evaluate interoperability.  But we want it to be a BCP so that it's a consensus document, which carries more weight than an Informational document.

In section 2, I would suggest adding a fourth bullet item:

 o If the option would work well in the particular deployment
   environment the proponents currently envision, but has
   equally valid uses in some other environment where the
   proposed option format would fail or produce inconsistent
   results.

At the end of section 3, this text is a bit unclear:

   Note that the client still reserves the right to ignore values
   received via DHCPv6

Might be better to say:

   Note that the client is not required to configure any of these values
   via DHCPv6

Section 4:

   The primary guiding principle to follow in order to enhance an
   option's adoptability is simplification.  More specifically, the
   option should be created in such a way that does not require any new
   or special case software to support.  If old software currently
   deployed and in the field can adopt the option through supplied
   configuration facilities then it's fairly certain that new software
   can easily formally adopt it.

how about:

   The primary guiding principle to follow in order to enhance an
   option's adoptability is reuse.  The
   option should be created in such a way that does not require any new
   or special case software to support.  If old software currently
   deployed and in the field can adopt the option through supplied
   configuration facilities then it's fairly certain that new software
   can easily formally adopt it.

Here, why "bulk"?

   There are at least two classes of DHCPv6 options: A bulk class of
   options which are provided explicitly to carry data from one side of
   the DHCPv6 exchange to the other (such as nameservers, domain names,
   or time servers), and a protocol class of options

How about:

   There are at least two classes of DHCPv6 options: simple
   options which are provided explicitly to carry data from one side of
   the DHCPv6 exchange to the other (such as nameservers, domain names,
   or time servers), and a protocol class of options

Section 5 introduces the term "fragment" to mean a data field within an option.   This term is never clearly defined.   I think it means "data field of a particular type," but think about how someone who isn't a DHC working group regular is going to read this text.   I think the text needs to be really clear and formal about what is being described here—this is a key part of the document.   I don't think this is a major change, but it feels like a lack to me at the moment.

Another problem with this term is that it's used in the introduction to section 5, and then not again until section 13.   In section 14, we see the term used in its more usual sense—talking about IP packet fragmentation.   It might be better to use a different word, like "data element" or something.

5.3, the equation is problematic:

	expressed using the following equation: >prefix6-len<+7/8

How about:

	expressed using the following equation: (prefix6_len + 7) / 8

I recommend against using angle brackets to delimit the variable name because they look like comparison operators.   I think it's better to just use an underscore and make it C-code: people will know what you mean.   Alternatively, I would enthusiastically support using LISP code:

	expressed using the following equation: (/ (+ prefix6-len 7) 8)

But I'm guessing you'll prefer the first suggestion... :)

RFC 6603 uses the format you guys are recommending; might be a better reference than the as-yet-unpublished MAP document.

5.7: I think you should call URLs out as a separate data type.   Yes, they are represented as a hunk of variable-length data, but the semantics are different, and this is important in UIs.   Also, use "URI," not "URL."   URIs are ASCII text, not UTF8, and are defined in RFC 3986.

Section 5 doesn't seem to define text strings.   This is an important data type, and it's not the same as raw data.   It appears differently in the UI, and it has encoding implications.   You need to add a section that defines this fragment format.   It should talk about the problem of canonical and non-canonical representations.   It should also say that strings have no semantics; they are simply strings.   If a data format has semantics other than just being text, it is not a string.  E.g., an option carrying a presentation-format FQDN is not a string, and an option containing a URI is also not a string, because they have different semantics.

You should also point out that bit fields should be composed using 8-, 16- or 32-bit numbers, and that bit fields can't cross those boundaries.   I think there are some examples of bit fields in options either existing or coming down the pike.

8: You should mention that the use of FQDN options is discouraged for options intended to configure hosts, because hosts may have multiple provisioning domains, and may get a different answer from the DNS depending on the provisioning domain.   This is particularly a problem when the normal expected use of the option makes sense with private DNS zone, as might be the case with a corporate VPN.   You touch on this in point 6, but I think it's a really key point, and should be emphasized more heavily.

This is something that only occurred to me a couple of days ago, although it obviously occurred to the authors earlier, but I think it's actually a really good reason _not_ to use FQDNs in DHCP options unless the use case for the DHCP option is really constrained—for example, the recipient of the option is expected to always be a HG, and never a host.

Section 9: I have a bit of a quibble with using the term encapsulated here.   I tend to think of encapsulation as what relay agents to do DHCP messages.   I actually think that the term "nested" is better, even though RFC3315 doesn't use it.   I leave it to the authors to decide what to do, but my personal advice would be to change to using "nested" rather than "encapsulated."

Also, I would change this:

   Those options are sometimes called
   sub-options, but this term is not precise and thus discouraged.

to this:

   Those options are sometimes called
   sub-options, but this term actually means something else, and
   therefore should never be used to describe nested options.

You should specifically say that RFC5908 never got proper review from the DHC working group and contains many errors, and should not under any circumstances be used as a template for future DHCP option definitions.

You also use the term "sub-options" several times when I think you mean nested options.   Probably somebody else already caught this, but I mention it just in case. :)

Section 10 isn't very clear.   It's not the case that stateful options (if that is what you are referring to) place additional load on the server.   Rather it is that they require new extensions, new implementation complexity, and additional database state on the server.

In section 11 you might additionally want to mention that even when DHCP clients refresh their configuration information, not all consumers of DHCP-sourced configuration data notice these changes.   For instance, if a server is started using parameters received in an early DHCP transaction, but does not check for updates from DHCP, it may well continue to use the same parameter indefinitely.   Modern notification systems take care of reconfiguring services when the client moves to a new network, but it's worth bearing in mind that a renew may not actually result in the client taking up new configuration information that it receives.

In section 12, you should refer back to the bit about multiple provisioning domains with respect to the FQDN option.   It might be worth considering if there are other options that have the same problem.

In section 13, you seem to be muddling formats and fragments.   I propose the following replacement text:

When defining a new option, it is best to synthesize the option format using fragment types already in use.   However, in some cases there may be no fragment type that accomplishes the intended purpose.

Adding a simple DHCP option is straightforward, and generally something that any working group can do, perhaps with some help from designated DHCP experts.   However, when new fragment types need to be devised, this requires the attention of DHCP experts, and should not be done in a working group that doesn't have a quorum of such experts.   This is true whether the new fragment type has the same structure as an existing fragment type, but has different semantics.   It is equally true when the new format has a new structure.

Responsible Area Directors for working groups that wish to add a work item to a working group charter to define a new DHCP option should get clarity from the working group as to whether the new option is a simple DHCP option with no new fragment type or new fragment semantics, or whether it in fact will require new fragment types.   A working group charter item should explicitly state which of these two types is required; if it is not known at the time of chartering, the charter should state that the working group will study the question and recharter or seek help elsewhere if a new fragment type is to be defined.

If a working group needs a new fragment type, it is preferable to seek out a working group whose members already have sufficient expertise to evaluate the new work and try to come up with a new format that generalizes well and can be reused, rather than a single-use fragment type.   If such a working group is available, the work should be chartered in that working group as a separate draft that documents the new fragment type.   The working group that needs the new fragment type can then define their new option referencing the new fragment type document.   This work can generally be done in parallel so as not to delay the process significantly.

In the event that there is no working group with DHCP expertise that can define the new fragment type, the responsible AD should seek out help from known DHCP experts within the IETF to provide advice and frequent early review as the working group defines the new fragment type.   The new fragment type should still be done in a separate document, even if it's done in the same working group, so as to foster reuse of the new fragment type.   The responsible AD should work with the working group chairs and designated DHCP experts to ensure that new fragment type document has in fact been carefully reviewed by the experts and appears satisfactory.

Responsible area directors for working groups that are considering defining options that actually update the DHCP protocol, as opposed to simple options, should go through a process similar to that described above when trying to determine where to do the work.   Under no circumstances should a working group be given a charter deliverable to define a new DHCP option, and then on the basis of that charter item actually make updates to the DHCP protocol.

[this is left over from section 13, and doesn't relate to the text as I've rewritten it, but is still important and maybe should be folded in somewhere else, or maybe you should just title the above section "chartering requirements and advice for responsible ADs" and leave the following under the existing head for section 13:

When defining new options, one specific consideration to evaluate is whether or not options of a similar format would need to have multiple or single values encoded (whatever differs from the current option), and how that might be accomplished in a similar format.

The matter of size considerations is further discussed in Section 14.]

In the Option Size section, you should point out that relay agents have to do fragment reassembly and refragment on transmission—the relay can't simply relay the fragments.   So while fragmentation is allowed, if a new option requires significant fragmentation, it probably isn't a good choice for DHCP configuration; instead DHCP should simply point to a URI where the configuration information can be obtained.

In section 15, creators of DHCP options are not protocol implementations, and hence not appropriate targets for normative languages.   Also, options in encapsulations are not ordered any more than top-level options are, so that doesn't work.   If order is important, the things being ordered should be fields in an option, not separate options.   You might also want to point out that options values are never aligned within the DHCP packet: even the option code and option length may appear on odd byte boundaries.

In section 16, you should get rid of the "disappointing pace" language.   That's inappropriate.   Section 16 also recapitulates draft-rajtar-dhc-v4configuration, I think.   It might be worth referencing the document; I realize that this will probably delay publication, but it'll give you an incentive to get that document finished quickly as well.

In 17.3, WTF:

   Optional text: Server MUST NOT send more than one instance of foo
   option.

This is totally wrong.   Documents that define new simple options can't place _any_ special requirements on servers.   A document with language like the above is a DHCP protocol extension, not a simple option document.

In 17.3, you should say "in the relay-forward message."   You can't put any normative text here either, but this bit is worth saying.   It's never appropriate for a relay agent to add options to a message heading toward the client, of course, and relay agents don't actually make relay-reply messages anyway.

In section 19, I would say "it is necessary to assume" rather than "it is prudent to assume."   And "actual production use of the software may be vulnerable..."   I think the second point is debatable, but I prefer "you should be aware of this possibility" over "there is a 35% possibility that", and "will probably be vulnerable" sounds like the latter.

Suggest changing this:

   So it behooves an option's definition to contain any validation
   measures as can reasonably be made.

To this:

   Authors of drafts defining new DHCP options are therefore
   strongly advised  to explicitly define validation measures
   that recipients of such options are required to do before
   processing such options.   However, validation measures
   are already required by RFC3315 or other specifications
   referenced by the new option document are redundant, and
   can introduce errors, so authors are equally strongly
   advised to refer to the base specification for any such
   validation language rather than copying it into the new
   specification.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Apr 2013 03:01:12 +0000

>   are already required by RFC3315 or other specifications

Validation measures THAT are already defined—sorry for the confusing omission.