Subject: Re: [dhcwg] WGLC - draft-ietf-dhc-option-guidelines-11 - Respond by April 24

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 14 Apr 2013 20:13:16 +0000

NOTE: WG co-chair hat OFF ... these are my comments as an individual "member" of the WG.

I fully support this work and would like to see it advance. And I have done a somewhat careful review with the comments below.

1. I think the "updates RFC 3315" in the header and also in the Abstract is wrong and should be removed. There is nothing in this document that specifically changes anything in RFC 3315.

2.  In section 3 - add text in brackets:

   accessing the external Internet via local assist services that [the]
   network must also provide (such as domain name servers, or routers).

...

   this is one [of the] main reason[s] for the use of DHCPv6 in corporate
   enterprises.

3. In section 5 - replace/add text in brackets:

   This [means] that implementations will [likely] be able to reuse code paths
   designed to support the other options.

Another choice would be "This assumes that implementations will be able ...".

Drop the last sentence as it is not true: "It is only a list of option format fragments which are used in two or more options."

4. Section 5.1:

For:
   o  DHCPv6 server unicast address [RFC3315]
You need to also add "(a single address only)".

5. Section 5.3: 

   Sometimes there is a need to convey [a/an] IPv6 prefix.  The information to
   be carried by [such] an option includes the 128-bit IPv6 prefix together

Wonder whether the equation should be:
	(<prefix6-len> + 7) /8
As written, it may be misevaluated as division has higher preference than addition (usually). We could further clarify the integer portion is used, but I think that is clear as you can't have 6.5 octets.

In the example, prefix-len should be prefix6-len:

   For example, the prefix 2001:db8::/60 would be encoded with an
   option-length of 9, prefix6-len would be set to 60, the ipv6-prefix
   would be 8 octets and would contains octets 20 01 0d b8 00 00 00 00.

And replace the last sentence paragraph with:

   It should be noted that the IAPREFIX option defined by [RFC3633]
   uses a constant length prefix.  The concern about option length was
   not well understood at the time of its publication.

6. Section 5.7 - I wonder whether it is worth to remind future writers they MUST document the allowed encoding for this data.

7. Section 5.8 - I wonder whether it is worth to point out that this really is a specific encoding instances of section 5.7, and in this case the encode can also support multiple instances as the DNS wire encoded format allows on to determine the end of a FQDN (because of the 0 "." field).

8. Section 6:

The following is a bit odd ...

  Therefore the conditional formatting requires new code to
   be written, as well as introduces an implementation problem; as it
   requires that all speakers implement all current and future
   conditional formats.

   Conditional formatting is not recommended, except in cases where the
   DHCPv6 option has already been deployed experimentally, and all but
   one conditional format is deprecated.

Can we replace this with:

  Conditional formatting requires new code to be written and complicates
  future interoperability should new conditional formats be added; and
  existing code has to ignore conditional formats that it does not support.

Do we even want to suggest that "deployed experimentally" is useful? It is an experiment so why would the 'official' IETF option use it? I would just suggest not to go there - I don't want someone arguing 'well, I experimented in my network using option 55555 with this conditional format and this document lets me keep that conditional format."

9. Section 8.

Reword:

   Section 7), so one of them must be chosen.  This section is intended
   as a help to make an informed decision in that regard.

To:

   Section 7), so one of them must be chosen.  This section is intended
   to help make an informed decision in that regard.

And also:

   FQDN imposes [a] number of additional failure modes and issues that
   should be dealt with:

And I still have concerns about #4 and #7 in this list. They don't really make that much sense as written.

Perhaps for 4 the intent was:

  4. The client has to determine for which address families DNS is queried? A or AAAA records or both? And if both, which is preferred? Client implementations are encouraged to follow [RFC 6555] if both address families are possible.

For 7, I think this issue refers to encoding that is not DNS wire format - as I don't understand what the issue is for IDNs for DNS wire encoding? But this goes back to my issue with #6 for Section 5.7 that documenting the encoding is important.

I suspect this issue 7 goes back to when UTF-8 or ASCII was intended as a possible 'string' encoding (as then addresses in string format could be sent). The text in Section 8 never really discussed 'FQDN' encoding, but there really is the question as to what does "FQDN" mean? I don't think we generally mean it to be an ASCII representation of a v4 or v6 address.

So perhaps this means that 'FQDN' is a bad term used in this section or that we need additional text to discuss this alternate form for a "string" encoding of an ASCII representation for a v4/v6 address or a FQDN. (The 2nd paragraph in this section 8 starts out with "On the specific subject of desiring to configure a value using a FQDN instead of a binary IP address" - yet Med's original proposal wasn't a choice between the two but an ENCODING that allowed an FQDN or "ascii" address. So perhaps we have not really answered his quest for that? (Which may be why he sent his response to this WGLC.)

Perhaps for 7 in the list, remove it and add a new paragraph to end of the section (feel free to edit and extend):

Some may be tempted to use a "string" encoding which would allow the string representation of an address or a domain name. However, this MUST be avoided as it has many potential security and implementation issues, some of which are:
1. How is this data encoded? Especially consider International Domain Names and non-ASCII characters in domain names.
2. How is this data validated? While it is easy to determine whether the string representation of an IPv6 (or IPv4) address is specified, it is more difficult to validate domain names as valid FQDNs. And, is a terminal "dot" assumed for the domain name or are relative names allowed (if so, this of course raises the question of the search list being used by the client).

10. Section 9:

   From the implementation perspective, it is easier to implement
   encapsulated option rather than sub-option, as the implementer[s] do not
...
   Such encapsulation is not limited to one level.  There is

For this 3rd paragraph "sub-option" has returned. I really would like to see this replaced by encapsulated and not to use sub-option as this is encapsulation!

   Such encapsulation is not limited to one level.  There is
   at least one defined option that is encapsulated twice: Identity
   Association for Prefix Delegation (IA_PD, defined in [RFC3633],
   section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section
   10).  Such delegated prefix may contain an excluded prefix range that
   is represented by PD_EXCLUDE option that is conveyed as encapsulated
   inside the IAPREFIX option (PD_EXCLUDE, defined in [RFC6603]).  It seems awkward
   to refer to such an option as a doubly encapsulated
   option, therefore "encapsulated option" term is typically used,
   regardless of the nesting level.

11. Section 10:

Can we replace "nodes" and "node" with "clients" and "client"? This section starts out with "DHCP is a protocol designed for provisioning nodes." ... This should be "DHCP is a protocol designed for provisioning clients.".

Also:

   generate [client]-specific information.  Such [a] solution does not introduce
   any additional state for the server and therefore scales better.

...

   For renewing other parameters, please use [the] Information Refresh Time
   Option (defined in [RFC4242]).  Introducing additional timers make
   deployment unnecessarily complex and [SHOULD] be avoided.

One note here is that RFC 4242 states "It is only used in Reply messages in response to Information-Request messages." - so a "Renew" messages cannot use it (the text says "For renewing" which doesn't necessarily imply a Renew message.).

12. Section 11:

   nonce.  That means that [the] provisioning server is the only one that can
   initiate reconfiguration.  Other servers do not know [the nonce] and [therefore] cannot
   trigger reconfiguration.  Therefore the only reliable way for clients
   to refresh their configuration is to wait until T1 [or Information Refresh Time] expires.

13. Section 12:

   example of such [a] case is a home network with a connection to two
   independent ISPs.

14. Section 14:

   DHCPv6 [RFC3315] allows for packet sizes up to 64KB.  First, through
   its use of link-local addresses, it [avoids] many of the

   requirements.  [C]ommon sense still applies here.  It is better to
   split distinct values into separate [octets] rather than propose
   overly complex bit shifting operations to save [] several bits (or

   is recommended to clarify (with normative language) whether a given
   DHCPv6 option may appear once or multiple times. [The default assumption
   is only once.]

15. Section 15:

   Such [] text is discouraged as there are several issues with it.
   First, it assumes that client implementation that supports a given
   option will always want to use it.  This is not true.  The second and
   more important reason is that such [] text essentially duplicates

Either at the end of this section (or possibly section 14), do we want to provide any guidance about whether the ordering of multiple instances of any option can be assumed to have significance? I don't think RFC 3315 clarified this and in many cases it doesn't matter (such as IA_NA/IA_PD ordering). But, while we didn't do it and probably don't recommend doing so, but the DNS Servers (addresses) option could have only allowed a single address and we could have allowed multiple instances. In this case, order would likely be significant.

I think this goes back to saying - if order is important to you, do it in your option(s) - have a list of items rather than a single item.

And, we should simply say that the order of options, even multiple instances of the same option, is NOT significant and MUST NOT be assumed.

16. Section 17:

I'd move the requestor text from the first paragraph into the start of the 2nd. The reason is that you start with three major entities, then add the fourth, but the say "those three major components". So, I think the following makes more sense:

   There are three major entities in DHCPv6 protocol: server, relay
   agent, and client.   It is very helpful for
   [implementers] to include separate sections that describe operation for
   those three major [entities].  Even when a given entity does not
   participate, it is useful to have a very short section stating that
   it must not send a given option and must ignore it when received.

   There is also a separate entity called requestor, which is a special
   client-like type that participates in leasequery protocol [RFC5007]
   and [RFC5460]. [A] similar section for [the] requestor is not required,
   unless the new option has anything to do with requestor (or it is likely
   that the reader may think that is has).  It should be noted that while in
   [the] majority of

Later, replace be with by:

   appear in certain message or being sent [by] certain entities.

And:

   Typically new options are requested by clients and assigned by [the]
   server, so there is no specific relay behavior.  Nevertheless it is
   good to include a section for relay agent [behavior] and simply state

17. Section 17.1

How about naming this section "Sample DHCPv6 Client Behavior Text"?

And:

   Client[s] MAY request option foo, as defined in [RFC3315], sections

And:

   Optional text (if the option contains FQDN): If the client request[s] an
   option that conveys [an] FQDN, it is expected that [the] content[s] of that option
   will be resolved using DNS.  Hence the following text may be useful:
   Client that requests option foo SHOULD also request option
   OPTION_DNS_SERVERS specified in [RFC3646].

   Client[s] MUST discard option foo if it is invalid (i.e.  did not pass
   validation steps defined in Section X.Y).

18. Section 17.2

How about naming this section "Sample DHCPv6 Server Behavior Text"?

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

   Optional text (if server is never supposed to receive option foo):
   Server[s] MUST ignore incoming foo option.

19. Section 18

   Authors often ask themselves a question whether their proposal
   updates exist RFCs, especially [[RFC3315]].  [In April 2013] 
   there were [about 80] options defined.

(I think it best not to be that specific, as the count will continue to change and the 'time of writing' may move.)

   changes something in already defined behavior, e.g.  servers must
   discard incoming messages if option foo is invalid or missing, then
   the "updates" phrase is warranted.

I don't think this is really a good example. I think it should be when existing behavior (as documented in RFC 3315) is replaced by new behavior (such as the stateful -issues draft does). Adding new options or messages that may have different behavior still just extends. Only when text is replaced or modified is updates appropriate. For example, RFC 6644 and draft-ietf-dhc-dhcpv6-solmaxrt-update clearly updates RFC 3315 - they replace existing with new text. Perhaps these are better examples?

20. Section 19:

   endpoints and men in the middle.  Other authentication mechanisms may
...
   least to man-in-the-middle attacks from within the network, even

Should be consistent and use "man-in-the-middle" in both places? (That's at least what Wikipedia uses - http://en.wikipedia.org/wiki/Man-in-the-middle_attack).

And in the following replace supporting with support:

   without requiring symmetric key pairs or [support] from any key

And in v6 we have no broadcast so best to replace broadcast with multicast (may also want to drop 'local'?)

   security.  An IP address field might be made to carry a loopback
   address, or local [multicast] address, and depending on the protocol

21. Section 22:

Usually 2119 and 3115 would be Normative References? But this is sometimes a judgment call.

22. What might be missing?

I wonder whether more might be said about Relay options and that they too use the same number space as client/server options? Perhaps this is already clear enough in RFC 3315.

23. Summary:

A great job on this document and I'm glad it hopefully will be finished soon! Thanks much Tomek for taking it over and working to get it this far. Much of what I have commented on is minor and would be addressed by RFC-Editor anyway (there is likely a lot more they will do too!). But, I do have a few significant comments that I hope can be addressed in a -12 and will not require another WGLC.

I do hope that for those that have read this far that you also look over the document as it is important work!!

Regards,

- Bernie

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

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

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

---

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

On Sun, Apr 14, 2013 at 1:13 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I fully support this work and would like to see it advance. And I have
> done a somewhat careful review with the comments below.
>
> 1. I think the "updates RFC 3315" in the header and also in the Abstract
> is wrong and should be removed. There is nothing in this document that
> specifically changes anything in RFC 3315.
>
>
I think an earlier version of the draft had some text that proposed to
clarify some point.  I suspect instead I was absolved of my own
misunderstanding on the point, but this wasn't removed.

> Drop the last sentence as it is not true: "It is only a list of option
> format fragments which are used in two or more options."
>
> 4. Section 5.1:
>
> For:
> As written, it may be misevaluated as division has higher preference than
> addition (usually). We could further clarify the integer portion is used,
> but I think that is clear as you can't have 6.5 octets.
>
> 6. Section 5.7 - I wonder whether it is worth to remind future writers
> they MUST document the allowed encoding for this data.
>
> 7. Section 5.8 - I wonder whether it is worth to point out that this
> really is a specific encoding instances of section 5.7, and in this case
> the encode can also support multiple instances as the DNS wire encoded
> format allows on to determine the end of a FQDN (because of the 0 "."
> field).
>
> 8. Section 6:
>
> Do we even want to suggest that "deployed experimentally" is useful? It is
> an experiment so why would the 'official' IETF option use it? I would just
> suggest not to go there - I don't want someone arguing 'well, I
> experimented in my network using option 55555 with this conditional format
> and this document lets me keep that conditional format."
>
> 9. Section 8.
>
> Reword:
>
>   4. The client has to determine for which address families DNS is
> queried? A or AAAA records or both? And if both, which is preferred? Client
> implementations are encouraged to follow [RFC 6555] if both address
> families are possible.
>
> For 7, I think this issue refers to encoding that is not DNS wire format -
> as I don't understand what the issue is for IDNs for DNS wire encoding? But
> this goes back to my issue with #6 for Section 5.7 that documenting the
> encoding is important.
>
> I suspect this issue 7 goes back to when UTF-8 or ASCII was intended as a
> possible 'string' encoding (as then addresses in string format could be
> sent). The text in Section 8 never really discussed 'FQDN' encoding, but
> there really is the question as to what does "FQDN" mean? I don't think we
> generally mean it to be an ASCII representation of a v4 or v6 address.
>
> So perhaps this means that 'FQDN' is a bad term used in this section or
> that we need additional text to discuss this alternate form for a "string"
> encoding of an ASCII representation for a v4/v6 address or a FQDN. (The 2nd
> paragraph in this section 8 starts out with "On the specific subject of
> desiring to configure a value using a FQDN instead of a binary IP address"
> - yet Med's original proposal wasn't a choice between the two but an
> ENCODING that allowed an FQDN or "ascii" address. So perhaps we have not
> really answered his quest for that? (Which may be why he sent his response
> to this WGLC.)
>
> Some may be tempted to use a "string" encoding which would allow the
> string representation of an address or a domain name. However, this MUST be
> avoided as it has many potential security and implementation issues, some
> of which are:
> 1. How is this data encoded? Especially consider International Domain
> Names and non-ASCII characters in domain names.
> 2. How is this data validated? While it is easy to determine whether the
> string representation of an IPv6 (or IPv4) address is specified, it is more
> difficult to validate domain names as valid FQDNs. And, is a terminal "dot"
> assumed for the domain name or are relative names allowed (if so, this of
> course raises the question of the search list being used by the client).
>
> 10. Section 9:
>
> For this 3rd paragraph "sub-option" has returned. I really would like to
> see this replaced by encapsulated and not to use sub-option as this is
> encapsulation!
>
> Can we replace "nodes" and "node" with "clients" and "client"? This
> section starts out with "DHCP is a protocol designed for provisioning
> nodes." ... This should be "DHCP is a protocol designed for provisioning
> clients.".
>
> Also:
>
> One note here is that RFC 4242 states "It is only used in Reply messages
> in response to Information-Request messages." - so a "Renew" messages
> cannot use it (the text says "For renewing" which doesn't necessarily imply
> a Renew message.).
>
> 12. Section 11:
>
> Either at the end of this section (or possibly section 14), do we want to
> provide any guidance about whether the ordering of multiple instances of
> any option can be assumed to have significance? I don't think RFC 3315
> clarified this and in many cases it doesn't matter (such as IA_NA/IA_PD
> ordering). But, while we didn't do it and probably don't recommend doing
> so, but the DNS Servers (addresses) option could have only allowed a single
> address and we could have allowed multiple instances. In this case, order
> would likely be significant.
>
> I think this goes back to saying - if order is important to you, do it in
> your option(s) - have a list of items rather than a single item.
>
> And, we should simply say that the order of options, even multiple
> instances of the same option, is NOT significant and MUST NOT be assumed.
>
> 16. Section 17:
>
> I'd move the requestor text from the first paragraph into the start of the
> 2nd. The reason is that you start with three major entities, then add the
> fourth, but the say "those three major components". So, I think the
> following makes more sense:
>
> (I think it best not to be that specific, as the count will continue to
> change and the 'time of writing' may move.)
>
> I don't think this is really a good example. I think it should be when
> existing behavior (as documented in RFC 3315) is replaced by new behavior
> (such as the stateful -issues draft does). Adding new options or messages
> that may have different behavior still just extends. Only when text is
> replaced or modified is updates appropriate. For example, RFC 6644 and
> draft-ietf-dhc-dhcpv6-solmaxrt-update clearly updates RFC 3315 - they
> replace existing with new text. Perhaps these are better examples?
>
> 20. Section 19:
>
> Should be consistent and use "man-in-the-middle" in both places? (That's
> at least what Wikipedia uses -
> http://en.wikipedia.org/wiki/Man-in-the-middle_attack).
>
> I wonder whether more might be said about Relay options and that they too
> use the same number space as client/server options? Perhaps this is already
> clear enough in RFC 3315.
>
> 23. Summary:
>
> A great job on this document and I'm glad it hopefully will be finished
> soon! Thanks much Tomek for taking it over and working to get it this far.
> Much of what I have commented on is minor and would be addressed by
> RFC-Editor anyway (there is likely a lot more they will do too!). But, I do
> have a few significant comments that I hope can be addressed in a -12 and
> will not require another WGLC.
>

Thanks to Tomek for pushing this forward, I have very little time of late
for pursuits here.  Provided the other authors agree on Bernie's edits, I'm
also of the opinion we should move this document forward, although for
form's sake we should maybe plan to do WGLC on -12.

> 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.
>
> 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.
>

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 29 Apr 2013 20:41:10 +0000

Thanks David for reviewing and support it! Good to hear from you!

Just to make sure it wasn't missed (as it is near the end), you support this:

Thanks to Tomek for pushing this forward, I have very little time of late for pursuits here.  Provided the other authors agree on Bernie's edits, I'm also of the opinion we should move this document forward, although for form's sake we should maybe plan to do WGLC on -12.

I will discuss with Tomek as to whether another WGLC will be needed; if so it may be a short one just to confirm that everyone is happy with all of the edits.

-          Bernie