[ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for DHCPv6

[anthony.flavin at bt.com]

That's not really a surprise. A box that is powering up, needs IP
addresses as it may not be able to resolve DNS yet. However DHCP is not
restricted to passing addresses.

Tony 

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org
[mailto:ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org] On Behalf Of
Benoit Lourdelet (blourdel)
Sent: 26 November 2007 17:10
To: Mark Stapp (mjs); David L. Mills
Cc: ntpwg at lists.ntp.org; dhcwg at ietf.org
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for
DHCPv6

Mark and David,

If we consider the already defined DHCPv4 and DHCPv6 Options, IP
services are, in (almost) all cases, passed as an address and not as a
name.  
If we come to the conclusion that FQDN is really mandatory for NTP, I
don't see why we should not retrofit this to all existing IP services
Options.

Honestly, I would like the DHCP veterans to come forward and tell us why
they made so many bad decisions in the past :-;

Benoit

> -----Original Message-----
> From: Mark Stapp (mjs)
> Sent: Wednesday, November 21, 2007 5:10 PM
> To: David L. Mills
> Cc: ntpwg at lists.ntp.org; dhcwg at ietf.org
> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options 
> for DHCPv6
> 
> yes, this is another reason why the DHCP folks have generally used 
> addresses in options. it just removes a dependency among the various 
> clients in the system, and it doesn't usually have any significant 
> drawback.
> 
> there seems to be a concern that delivering addresses via DHCP somehow

> makes them difficult to update over time. just to reiterate: it's 
> often the case that the information at the DHCP server is updated. the

> updated information flows out to clients as they renew. if the lease 
> timers were very long, a client who got NTP addresses and found itself

> having trouble with them all could also use the INFORMATION-REQUEST 
> message to check whether the addresses were still valid, outside of 
> the normal renewal timers.
> 
> -- Mark
> 
> David L. Mills wrote:
> > Brian,
> > 
> > Trying to put out fires when the network is burning is a good 
> > excercise in fault containment. When the DNS is broken and
> the repair
> > party arrives, it's good to know the gateway works even if DNS 
> > doesn't. I'm not sure this exactly applies to NTP, but I sure would 
> > like to see the NTP servers options include hard coded addresses.
> > 
> > Dave
> > 
> > Brian Utterback wrote:
> > 
> >>
> >> Danny Mayer wrote:
> >>
> >>> There is *no* avantage to not sending a FQDN and plenty of 
> >>> disadvantages to not doing so.
> >>> Would you like a list of vendors who have hardcoded IP addresses 
> >>> into their devices without permission of the operator of that NTP 
> >>> server causing headaches for not just the owner of the NTP Server 
> >>> but also for the users of those devices? The NTP reference 
> >>> implementation expects the existence of a resolver so you haven't 
> >>> gained anything.
> >>>
> >>
> >> As already noted, there is an advantage, namely that the
> client does
> >> not have to have a resolver. And even if the reference
> implementation
> >> requires one (Is that really true? Even if no name resolution is
> >> required?) DHCP should remain implementation agnostic.
> >>
> >> As far the "hard coded address" problem goes, I don't see that 
> >> scenario as very likely. DHCP clients don't tend to remain up for 
> >> very long periods. And you don't have the same IP addresses being 
> >> served by thousands of DHCP servers. The thing to be careful of is 
> >> that the DHCP server not be embedded and replicated with
> hard coded
> >> addresses, not that the clients only get IP addresses.
> >>
> >> That having been said, I would like to see a way to pass a
> FQDN as an
> >> option, perhaps passing both. Then you could have logic
> like "Here's
> >> both, use the name if you can, and use the address if you must."
> >>
> > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
_______________________________________________
ntpwg mailing list
ntpwg at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ntpwg