Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

["Bernie Volz (volz)" <[e-mail]>]

BTW: One nice thing to consider for the DHCPv6 multiple option instances design is that at least for the single PCP instance case, it would work immediately (on all DHCPv6 clients and servers).

I don't know how common it will be for there to be multiple PCP servers that clients need to contact.

(The downside with this is of course that few may implement the multiple PCP servers support unless it is widely required?)

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Thursday, March 20, 2014 9:30 AM
To: 'Ted Lemon'; [e-mail]
Cc: [e-mail]
Subject: RE: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

FYI - Adding back dhcwg as I think this is important to keep there.

The only issue with DHCPv6 multiple options is the ordering - if ordering is important, you should not use them. In the PCP case, I don't see that ordering matters as the draft requires using each of them.

DHCPv6 clients and servers already have to deal with multiple instances of the same option so I don't think there are any significant issues here. (Whereas in DHCPv4, that has not been the case to date, so that's why there is more significant concern.)

The guidelines are:

   DHCPv6 does allow for multiple instances of a given option, and they
   are treated as distinct values following the defined format, however
   this feature is generally preferred to be restricted to protocol
   class features (such as the IA_* series of options).  In such cases,
   it is better to define an option as an array if it is possible.  It
   is recommended to clarify (with normative language) whether a given
   DHCPv6 option may appear once or multiple times.  The default
   assumption is only once.

...

16.  Singleton options

   Although [RFC3315] states that each option type MAY appear more than
   once, the original idea was that multiple instances are reserved for
   stateful options, like IA_NA or IA_PD.  For most other options it is
   usually expected that they will appear at most once.  Such options
   are called singleton options.  Sadly, RFCs have often failed to
   clearly specify whether a given option can appear more than once or
   not.

   Documents that define new options SHOULD state whether these options
   are singletons or not.  Unless otherwise specified, newly defined
   options are considered to be singletons.  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 order they
   appear in the message.  See Section 17 for more details.

(There's more in section 17.)

I don't really care that much which we go as I think either will require code changes in some (or most) clients and servers (servers may readily support configuring multiple instances of the options and probably don't support the <sub-length><address(es)> encoding either).

Personally, I don't see a problem with multiple instances of the options as that is the way DHCPv6 was designed. Again, the only issue is ordering (since this would require specialized handling on the server configuration to allow you to define the order). For clients, order might also be an issues in how they store the data (i.e., if lists are maintained, is a new instances inserted at start or end of list).

I WOULD like to see multiple instances of options used in the way PCP proposed - i.e., where there really are more than one thing a client needs to do RATHER than alternative values (i.e., list of addresses to contact for an instance). This is in keeping how we currently handle things like the DNS server address list and domain search list.

While we could encode this as proposed for DHCPv4, I also see no need to encode it that way for this particular usage.

I guess we need to get some rough consensus here as to what the DHC WG would prefer as this will set a precedence. So it would be great for others to chime in. (Note that my comments on this entire thread are to be taken as an individual with WG co-chair hat off.)

Again, my feeling is that when order is required or when there are a list of 'equal' values (i.e., try one or more of these addresses to reach a service), we should use a single option. When there are possibly multiple items that ALL must be used (simultaneously and there is no order importance), multiple options would be fine. This is exactly how IA_* and IAADDR/IAPREFIX and the multiple vendor options instances all work.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Thursday, March 20, 2014 9:07 AM
To: [e-mail]
Cc: Bernie Volz (volz)
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

On Mar 20, 2014, at 8:49 AM, <[e-mail]> <[e-mail]> wrote:
> Changing the format of the dhcpv4 option to be complaint with 3396 would lead to a dhcpv4 option and a dhcpv6 option that are not similar. Are you fine with that? Should we update only the dhcpv4 part of the document?

FWIW, I don't really see much value in the semantics of multiple options, and would rather see the DHCPv6 and DHCPv4 options done the same way.   It's not something that would stop me approving the document, but we did discuss this when the option guidelines draft was done, and it seemed that there was strong skepticism, which I _think_ was expressed in the draft, about giving semantic meaning to the presence of multiple options.