Re: [dhcwg] draft-ietf-ntp-dhcpv6-ntp-opt-00

["Richard Gayraud (rgayraud)" <rgayraud at cisco.com>]

Ted, 
 
We do understand your point, and we are aware this is not 
the usual format of options. We have been discussing this 
with several people in the DHCP and NTP working groups, and 
we have to accomodate 2 opposite goals:
 
  - by nature, NTP can have several NTP servers. Hence the
    possibility to have several instances of the option.
    
  - Each server can be identified by different ways (FQDN, 
    address, ...) and will have to contain some additional
    parameters shortly. Hence the use of sub-options.
    
We tried other formats, and there were always some objections
to the formats we proposed, each implementor having its own
problems.
 
Finally, we choosed this one as a compromise. And, if we think
about it, what we ask DHCP is not too difficult: we need the
ability to encode a "list of records". There are chances that 
this will be of some use for others.
 
Richard. 

> -----Original Message-----
> From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 
> On Behalf Of Ted Lemon
> Sent: jeudi 18 septembre 2008 08:04
> To: DHC WG
> Subject: Re: [dhcwg] draft-ietf-ntp-dhcpv6-ntp-opt-00
> 
> On Sep 17, 2008, at 10:44 PM, John Jason Brzozowski wrote:
> > During the WG meeting I believe some questions were raised 
> about the  
> > packing
> > and or structure of the option.  Shortly after Dublin some 
> additional
> > questions were also posted to the WG mailing list regarding possible
> > sub-options.
> 
> The point I attempted to raise, which I think wasn't entirely  
> understood, is that this draft proposes doing something novel with  
> DHCP options.   It proposes defining suboptions to an option.   It  
> then proposes that the option can appear more than once, and 
> that each  
> instance of that option is an informational unit, in which each  
> suboption of that instance of the option is related.
> 
> The reason I brought this up as a concern is that I suspect 
> that this  
> will create problems for implementors both of servers and of 
> clients,  
> since no other DHCP option works this way.   We do have options with  
> suboptions, but we have never before used this grouping technique.
> 
> Because this is a DHCPv6 option, there is no option 
> aggregation, so we  
> don't have to worry about that.   But the configuration language for  
> various DHCP servers may not be capable of representing options of  
> this type.
> 
> I'm not objecting as a server implementor - I'm pretty sure that the  
> Nominum server can implement this option with relatively minor  
> tweaks.   However, on the client end, I'm aware of at least 
> one client  
> implementation that may require some nontrivial work to support  
> delivering this option to the host in a usable form.
> 
> So if the authors are hoping for wide adoption of this option, this  
> should be a consideration.   Given that the choice of how the option  
> would be represented is largely based on a desire for 
> future-proofing,  
> and not required by the current set of needs for this option, 
> I'm not  
> sure this is a good idea.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> 
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg