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

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 18 Sep 2008 01:44:38 -0400

Folks,

In Dublin one of the authors (Benoit) of the
draft-ietf-ntp-dhcpv6-ntp-opt-00 presented an update on this work.

http://www3.ietf.org/proceedings/08jul/slides/dhc-9.pdf

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.

I do not recall seeing activity on the WG mailing list related to either of
the above.

Are there any outstanding comments, questions, or concerns?

These need to be address before we can move this work forward.

Thanks,

John

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 23:03:39 -0700

> questions were also posted to the WG mailing list regarding possible

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.

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Fri, 19 Sep 2008 14:30:29 +0200

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: [email-masked] [mailto:[email-masked]] 
> 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
> 
> > During the WG meeting I believe some questions were raised 
> about the  
> > packing