[ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6

[TS Glassey]

BLU  :-)

----- Original Message ----- 
From: "Brian Utterback" <Brian.Utterback at Sun.COM>
To: "Ted Lemon" <mellon at fugue.com>
Cc: <ntpwg at lists.ntp.org>; "Danny Mayer" <mayer at ntp.org>; "Richard Gayraud 
(rgayraud)" <rgayraud at cisco.com>; <dhcwg at ietf.org>
Sent: Sunday, November 25, 2007 5:28 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6


>I think we are all arguing at cross purposes. We have people reasoning
> about what will be,
> some about what is, some about what could be and some about what should 
> be.
>
> The question on the floor is very simple. Is it sufficient for the DHCP
> option to follow convention
> and serve an IP address or is it necessary to instead serve a string
> that represents a FQDN that should
> be used for a DNS lookup and periodically re-resolved.

I would san "NO" if it is also to be required to present stateful info on 
the status of the TS system...

>
> It has been suggested that if you are going to serve up a string, a URL
> that points to a configuration
> file to be used would offer the most general mechanism for
> configuration, but this is highly problematic
> since there is no implementation agnostic configuration language it it
> is way, way out of scope to think
> about making one. This this idea is rejected.

Agreed

>
> So, the advantage of serving a FQDN is that the client is forced to
> resolve the host and get the IP
> addresses from DNS and removal of an IP from the DNS name system will
> cause all the traffic
> to that IP to eventually disappear.

But not the surious traffic to the name servers; The issues before  were not 
just the NTP traffic but the DNS traffic to resolve those names as well. I 
can speak to that first hand too.

>
> The disadvantage is that it forces client to run and configure a
> resolver and potentially adds a lot
> of overhead to the DHCP protocol.
>
> Ted maintains that as a practical matter, the same effect is achieved
> with the IP address.
> We can specify in the DHCP protocol that when the DHCP lease is renewed,
> that the
> NTP client must accept a new IP address and if different from the old
> one, cease using
> the old one.  We can specify that the DHCP client may only serve site
> local addresses
> unless the IP addresses served are themselves the result of periodic DNS
> lookup if
> FQDN's. We can specify that the FQDN used may not be hard coded and must 
> be
> configurable.
>
> Not all of these "can"s and "must"s may be necessary or perhaps they are 
> not
> sufficient. If we decide on using the IP address, then we must also
> decide on the
> musts and shoulds and mays.
>
> Ted Lemon wrote:
>> On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote:
>>> I would think that this should be a push operation from the dhcp
>>> client rather than a pull operation.
>>
>> Sure, but it amounts to the same thing.   This is trivial to do with
>> the ISC DHCP client (which I presume is the one you use).   It's also
>> trivial to do on Linux with dbus.   Mac OS X and Windows handle it
>> differently still, but they already have mechanisms in place for doing
>> this.   So the point is that if the will exists to make it happen,
>> it's trivial to make it happen.
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg