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

[David Hankins <[e-mail]>]

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

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


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


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.


>
> Regards,
>
> - Bernie
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Bernie Volz (volz)
> Sent: Tuesday, April 09, 2013 11:06 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>



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