On Thu, Jan 09, 2014 at 02:16:38AM -0800, SM wrote:
The WGLC was from 5 July to 22 July. There wasn't any comments
during the WGLC. The only comment I found was one posted on 9 August.
According to the write-up, the "document has strong consensus". In
my opinion that determination is questionable.
People want to be able to configure timezones using the timezone
naming scheme commonly supported by operating systems (e.g.,
Europe/Paris). This document defines a serialization of the timezone
names into YANG format for this purpose. I believe there was indeed
strong concensus on this in the WG.
TZ locations can be controversial every now and then. There have
been discussions about having a (TZ) location for an island
inhabited by penguins. :-) There have been arguments about
changing a location as a matter of national pride. There has been
an attempt to take up a TZ mailing list disagreement with IANA.
IETF standardization of this information makes it look official and
paves the way for governance questions.
This document aims at establishing an IANA maintained serialization of
whatever list of names the timezone database contains. It does not
change the way the TZ coordinator, an IANA Designated Expert, takes
decisions. Perhaps this needs to be stated more explicit.
So far (in the MIB world), the initial versions of IANA maintained
modules were published as Proposed Standards on the standards track
(although the only thing that really remains valid over time are the
IANA considerations, which however often require the initial module to
be available). We simply followed this practice.
Well, we need to specify the system clock in the following YANG
module
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),
and hence we require a way to represent the TZ in YANG.
Would it be possible to use "timezone-utc-offset" only and not have
"timezone-location"? RFC 5277 references RFC 3339 for time zones.
There was concensus in the WG that it is desirable to configure
timezones by name (e.g., Europe/Paris) instead of having only hard
coded UTC offsets - the benefits should be obvious.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>