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

["Benoit Lourdelet (blourdel)" <[e-mail]>]

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: [e-mail]; [e-mail]
> 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg