Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2013-10-09, at 10:53, Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote:

> Of course there are cases where this doesn't matter, and DHCP is just fine, but I can't think of any other than perhaps a self-setting wall clock.

DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). There is a possible future in which such validation takes place on end hosts, rather than intermediate resolvers. (We may wind up somewhere else, but there are certainly people who think that is the Right Way).

In that sense any device that needs to look up names in the DNS has a potential requirement for time sync.

Of course even the wall clock you imagine might have a vendor who is capable of running their own array of time servers as (e.g.) Apple does, but it seems reasonable to imagine that there will be people who are not in that position, and since I agree with you when you say:

> Of course, if a CPE vendor were to hard-code the FQDN of an NTP server belonging to someone else into their devices, that would be disastrous.

it seems to me that there's a plausible use case for a DHCP client to receive direction on what servers to chime against.


Joe






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]