Subject: RE: [dhcwg] Timezones again.

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 11 Apr 2006 15:37:50 -0400

>one issue I've heard from SPs is that they really don't WANT to have to
provide the actual TZ definition, and would rather provide a reference
to something in the OS.

Speaking as a SP. :^)

If I am pushing TZ information to a end user's computer, then I agree; I
would prefer to provide a reference to something in the end user's OS.

If I am pushing TZ information to a SP-managed device such as a cable
modem (or more precisely a cable home gateway device, which enables
parental controls such as time-of-day Internet access as configured by
the customer), then there really isn't a "TZ reference to something in
the OS", so I really need to send an actual TZ definition.

-- Rich

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 1:53 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: [dhcwg] Timezones again.

David,

Thank you for your note.  A few comments.

Regarding your example of a use of option 2, just because someone did
something with with it doesn't make it a good idea.  Quite the contrary
in my mind.  That person demonstrated its flaw.  Clearly POSIX is a far
better option in order to avoid synchronizing DHCP updates to DST
changes.

Having said that I agree with your conclusion that while history is
nice, wall clock time is required.  My point is that the best way for a
client to get wall clock time is for it to receive something as close to
native as possible.  In MOST UNIX implementations the best approach is
the TZ database because that's what nearly all of them use.  This
requires no kernel changes and no tweaks to the environment, a hazardous
approach, always, IMHO.  Again, this makes history a side benefit.   
For Microsoft, I have a query out to the person responsible for
Microsoft DHCP and he has agreed to review the document soon, and so
I'll withhold comment.

As to Australia's problem (and the Brazil papal visit, for that matter),
one issue I've heard from SPs is that they really don't WANT to have to
provide the actual TZ definition, and would rather provide a reference
to something in the OS.  This makes the update "somebody else's
problem".  I personally don't like that approach, but if we split into
three options we get that for free IFF we say only "MUST implement" not
"MUST deploy" which is the line we usually draw, anyway.

This would also solve Ted's problem.

Regards,

Eliot

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

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