Subject: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 10:28:25 +0100

Hi,

I like to see whether we can close the technical discussions around
<draft-ietf-netmod-iana-timezones-03>, which is used by
<draft-ietf-netmod-system-mgmt-10>. Let me try to summarize where we
are. Since emails were exchanged between different groups of people, I
think it is necessary to synchronize so that everybody involved is on
the same page. I am trying to summarize where I think we are. I might
get certain details wrong - if so, please correct me. If I left
someone out of the To: line, please let me know as well.

* Overall Goal

  I believe there is agreement that timezone should be configurable
  using the so called Olson database timezone names (e.g.,
  'Europe/London'). This is what the timezone-location leaf in
  <draft-ietf-netmod-system-mgmt-10> tries to achieve.

* Current Solution (<draft-ietf-netmod-iana-timezones-03>)

  The current I-Ds propose to have a YANG enumeration of timezone
  names, essentially a serialization of the so called Olson database
  timezone names into a YANG enumeration. The Olson database is
  currently maintained by Paul Eggert, who serves as the TZ
  Coordinator, an IANA Designated Expert as defined in RFC 6557. The
  enumeration of timezone names in <draft-ietf-netmod-iana-timezones-03>
  resulted in two technical discussion points:

  a) YANG requires that an enumerated string value is always
     associated with a number. If no number is explicitly assigned,
     YANG assigns numbers implicitly but for this to work the order
     of listed enums may not change. Hence, to avoid brittleness when
     YANG modules are revised, it is good practice to assign explicit
     numbers. Unfortunately, the timezone database does not maintain
     such numbers. Options to fix this:

     - Add numeric identifiers to the timezone names as part of the
       timezone database. Increases work for the TZ coordinator and
       they are not needed for any other purpose.
     - Generate likely unique numbers using a hash function. To
       guarantee uniqueness, the TZ coordinator would have to verify
       that hashes do not collide if new timezone names are
       introduced.
     - Generate numbers from the coordinates (second column in the
       zone.tab file), e.g., encoding the coordinates in some way into
       a 32-bit integer. This may lead to issues if coordinates of a
       zone name are updated (not sure this happens).

  b) Timezone names are sometimes (although rarely) added or deleted
     from the timezone database. The timezone database documents the
     current state, it does not track the history by itself. YANG
     modules, however, do version management internally by deprecating
     and obsoleting definitions. This means, whenever timezone names
     are added or deleted, the TZ coordinator would have to do some
     extra work in order to provide that information (either to a tool
     that generates a new version of the YANG module or by maintenance
     of the YANG serialization directly manually).

  A solution to a) and b) is required in order to move forward with
  <draft-ietf-netmod-iana-timezones-03> and the solution must be
  simple enough so that it can be maintained over years with
  potentially different TZ Coordinators involved.

* Alternative Solution

  If we fail to produce a viable solution for a) and b), then an
  obvious fallback solution would be to simply define a YANG type such
  as

    typedef timezone-name {
      type string;
      description
       "A timezone name as used by the Time Zone Database, sometimes
        referred to as the 'Olson Database'.";
      reference
       "RFC 6557: Procedures for Maintaining the Time Zone Database";
    }

  and to use this type in the timezone-location leaf in
  <draft-ietf-netmod-system-mgmt-10>. Generic tools would not have
  knowledge about the set of possible timezone names but tools that
  have been coded to understand this typedef could of course reach out
  to the timezone database to get access to the set of possible
  timezone names. If we were to adopt this solution, we would pull
  back <draft-ietf-netmod-iana-timezones-03> and let it expire.

I think we need to decide in a timely manner whether we can find a
workable solution for the 'Current Solution' addressing a) and b) or
whether we give up on it and instead use a timezone-name typedef as
suggested above in the 'Alternative Solution'.

/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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 10:52:08 +0100 (CET)

Hi,

>        zone name are updated (not sure this happens).

Another option is to let the numbers live only in the YANG module.
I.e., use the previous version of the YANG module ("the IANA
resgitry") as input when new timezone locations are added.

>      from the timezone database.

I did a quick check, and it seems 3 were deleted and 3 added during
2012 and 2013.

>      The timezone database documents the

The current document explains what has to be done.  It is fairly
trivial to write a program that takes as input the current YANG module
and the new zone.tab file, and generate an updated YANG module if
needed.

So when the TZ coordinator publishes a new version of the database, he
would first run this program, and send a new YANG module to IANA, if
needed.

/martin

---

From: Per Hedeland <[email-masked]>
Date: Thu, 16 Jan 2014 11:16:13 +0100

> resgitry") as input when new timezone locations are added.

+1. This option seems both simpler to implement and more robust than the
others.

--Per Hedeland

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Jan 2014 14:31:29 +0100

Juergen, Martin,

Thanks for starting the discussion.
Including Michelle Cotton, from IANA, in the discussion.
>    potentially different TZ Coordinators involved.
And we must have an easy and repeatable procedure for IANA.
>    <draft-ietf-netmod-system-mgmt-10>.
This document is currently in IETF LC, and on the IESG telechat on Jan 23rd.
I guess I should remove it from the telechat?

Regards, Benoit
> Generic tools would not have

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Jan 2014 14:34:19 +0100

A question for Michelle in line.
> would first run this program, and send a new YANG module to IANA, if
Michelle, would this procedure work for IANA?
Alternatively, does IANA work with such a program/script?

Regards, Benoit
> .

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jan 2014 07:10:03 -0800

Hi,

I do not have any concerns about this draft if IANA has a reliable tool
to generate the YANG module.  IMO it should be very clear at
the start of the document that the YANG module in the RFC  may
not be current.  The URL of the official IANA YANG module must be
very prominent as well.

Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Thu, 16 Jan 2014 15:31:46 +0000

Sorry for not jumping in earlier but here is my $0.02..

>>        zone name are updated (not sure this happens).

The auto generation of numbers (by whatever means) only helps on the
creation of new zones.  It doesn¹t address the removal (and obsoleting) of
zones.

>and the new zone.tab file, and generate an updated YANG module if

I like this idea, but who will write such a program? The initial version
of this yang model was created with a simple awk script, but taking in the
zone.tab file and a yang file and intelligently comparing them would be a
bit more work (perhaps a pyang extension?).

For posterity, the following awk script was used for the initial zone.tab
-> yang conversion:

#!/usr/bin/awk -f
BEGIN {
  FS="\t";
  line=0;
  print "typedef iana-timezone {"
  print "  description"
  print "    \"A timezone location as defined by the IANA timezone"
  print "     database (http://www.iana.org/time-zones)";
  print "  type enumeration {"
}
{
  print "    enum \"" $3 "\" {";
  print "      value " line ";"
  if ($4 != "") {
    print "      description";
    print "        \""$4"\";";
  }
  print "    }";
  line++;
}
END {
  print "  }";
  print "}";
}

- Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 17:02:22 +0100 (CET)

Paul Eggert <[email-masked]> wrote:
> Juergen Schoenwaelder wrote:
> 
> >    The enumeration of timezone names in <draft-ietf-netmod-iana-timezones-03>
> A third technical discussion point was raised:
> 
>   c) There is no canonical list of TZ time zone names.
> 
> This is deliberate, because coming up with a "canonical"
> list raises political issues, and we'd rather leave
> those sleeping dogs lie.
> 
> In particular, the zone.tab file is *not* a canonical
> list of TZ values.  It's merely a list intended to be
> used by programs like tzselect.  It contains many duplicate
> aliases, and it omits some entries.
> 
> The four solutions you proposed (including the Alternative
> Solution) all suffer from this issue.

So why is this a problem?  Can't we let the YANG model just reflect
the zone.tab?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 18:42:49 +0100 (CET)

Paul Eggert <[email-masked]> wrote:
> Martin Bjorklund wrote:
> 
> > why is this a problem?
> 
> Because people often use names that are not in zone.tab.

Can you explain how this relates to having a YANG version of zone.tab?
In which situation does this become problematic?

The YANG module is intended to reflect zone.tab, so if there is a
problem with a location not being in the YANG module I would assume
the problem exist with zone.tab?

> Just today, for example, someone asked on the tz mailing
> about Asia/Calcutta, a name that's not in zone.tab but which
> does work.  Although Asia/Calcutta was formerly in zone.tab
> and so could presumably rely on a proleptic application of
> whatever deprecation procedure the YANG maintainers want to
> establish, some commonly-used names have never been in
> zone.tab -- US/Pacific is one example.
> 
> More generally, there is a political burden in coming up
> with a "canonical" list of names.  This is a long story, one
> that's connected to conflicts between Israelis and
> Palestinians, between the Serbs and the Croats, etc.  If the
> YANG maintainers, whoever they are, want to address this
> problem, more power to them; but it's not a burden the TZ
> coordinator should have to take up.

I am pretty sure noone wants to address this problem.  Again, we just
want a version of zone.tab expressed in YANG.

/martin

---

From: SM <[email-masked]>
Date: Thu, 16 Jan 2014 10:17:09 -0800

>want a version of zone.tab expressed in YANG.

I agree with what Paul Eggert wrote (see message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg85386.html for 
the political aspect).  The NETMOD Working Group could choose YANG 
maintainers to do the work instead of pushing the political burden to 
the TZ coordinator.

Regards,
-sm

---

From: Paul Eggert <[email-masked]>
Date: Thu, 16 Jan 2014 07:55:29 -0800

One way around this issue would be to have the
maintainers of the YANG module (who would be separate
from the TZ maintainers) assume the burden of
dealing with this political issue.  The TZ
database would be upstream from the YANG module
and would continue its current maintenance practices,
and the YANG maintainers could track it using whatever
procedures and software that they like.

This is the approach taken by the Unicode CLDR project,
so there's precedent for it.  See:

http://cldr.unicode.org/

http://www.unicode.org/cldr/charts/latest/by_type/timezones.timezone_cities.html

> This may lead to issues if coordinates of a

Yes, it does happen; errors are corrected and precision
is added.

---

From: Paul Eggert <[email-masked]>
Date: Thu, 16 Jan 2014 08:21:52 -0800

---

From: Paul Eggert <[email-masked]>
Date: Thu, 16 Jan 2014 10:16:59 -0800

> Can you explain how this relates to having a YANG version of zone.tab?

If the goal is merely to have a YANG version of zone.tab,
then there is no problem.  But if the goal is, as Juergen
put it, that timezones "should be configurable using the so
called Olson database timezone names", then there is a
problem, because zone.tab is not a list of all the Olson
database timezone names.

> In which situation does this become problematic?

When the user wants to specify a TZ setting that
is not in zone.tab.

> the problem exist with zone.tab?

No, there's no problem in zone.tab; as mentioned above,
zone.tab is not intended to be a list of all the TZ values.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jan 2014 20:15:19 +0100 (CET)

> problem, because zone.tab is not a list of all the Olson

Let me see if I understand the names involved.

RFC 6557 defines the term the "TZ Database".  It also says that this
database sometimes is 'referred to as the "Olson database"'.

Are you saying that the zone.tab does not list the timezone names in
the TZ Database?  Or are you saying that the Olson database is
actually something else than the TZ database?

> When the user wants to specify a TZ setting that

The end goal of the YANG model is to allow systems that use the TZ
Database to advertise this, and let clients configure the timezone on
these systems.  The system will advertise the revision of the YANG
module that corresponds to the TZ database in use on that system.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jan 2014 11:38:01 -0800

> module that corresponds to the TZ database in use on that system.

It comes down to how much coupling we want between the
IANA TZ database and the YANG typedef.

IMO:

Enumeration Pros:
   - client knows in advance the values supported by server
   - YANG driven applications like AJAX auto-completion can use
     enumerations but not strings

Enumeration Cons:
   - release-specific YANG module must be maintained
     and kept in sync with the TZ database and the server code
   - values not yet in the TZ database (or will never be in
     the TZ database) cannot be supported

String Pros:
   - Publish once and be done forever with this typedef
   - Double validation avoided (server implementation
     still needs to look up GMT offset, etc. so name validation
     is probably done twice)

String Cons:
   - NOT(enumeration pros)

I am leaning slightly towards string over enumeration, but either is OK.

Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Thu, 16 Jan 2014 19:49:08 +0000

From:  Andy Bierman <[email-masked]>
Date:  Thursday, January 16, 2014 at 2:38 PM
To:  "[email-masked]" <[email-masked]>
Cc:  Paul Eggert <[email-masked]>, Jeffrey Lange
<[email-masked]>, Eliot Lear <[email-masked]>, Benoit Claise
<[email-masked]>, SM <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: technical discussion around
draft-ietf-netmod-iana-timezones-03

>I am leaning slightly towards string over enumeration, but either is OK.

My feeling here is that I (Obviously) would like to see this done as an
enum.  But if this proves to be logistically/politically impossible, I¹m
open to doing this as a typedef¹d string as Martin previously suggested.
It¹s not great, but at least provides a small level of context as to what
the valid values are.

-Jeff

---

From: Paul Eggert <[email-masked]>
Date: Thu, 16 Jan 2014 12:09:56 -0800

On 01/16/2014 11:15 AM, Martin Bjorklund wrote:
> the TZ Database?

That's correct, in the sense that zone.tab is not an
exhaustive list.  Also, depending on what one means by "the
timezone names", some of zone.tab's names are duplicates or
aliases of each other, so zone.tab is not intended to give
unique names for zones either.

> Or are you saying that the Olson database is

No, they're the same thing.

> these systems.

OK, but the problem is that the YANG model seems to require
that names be numbered and advertised and standardized, even
though in practice there is no standard or canonical set of
names, and the set of supported names is often
astronomically large.

Suppose servers and clients are POSIX-compatible, and
support both TZ database names (e.g., 'America/New_York',
'Asia/Kabul') and TZ settings as specified by POSIX (e.g.,
'UTC0', 'EST+5EDT,M3.2.0/2,M11.1.0/2').  This is a fairly
common situation: how does the YANG model represent it?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Jan 2014 07:06:31 +0100

Paul,

> common situation: how does the YANG model represent it?

It is possible to traipse through each of the files and grep for "Zone"
and "Link".  The IETF doesn't have to be consistent with everyone else's
use.  We just have to be self-consistent.  The question is whether that
raises any political issue, and I don't think it does.  It does,
however, raise a maintenance issue with IANA.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Thu, 16 Jan 2014 23:20:52 -0800

Eliot Lear wrote:
> and "Link".

Sure, one could do that, and that would sidestep many
of the political problems.  This would generate a longer list,
one that I expect doesn't match up to CLDR or with
any other widely-used time zone resource.  And the list
would omit commonly-used names like 'UTC0'.  But these
issues may well not matter to users of the YANG module.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Jan 2014 11:04:13 +0100 (CET)

> issues may well not matter to users of the YANG module.

We want the YANG module to match what the underlying system is
actually using, provided they support the TZ Database available from
IANA.

Due to my ignorance I thought that zone.tab provided this list.  But
the underlying idea doesn't change: the YANG module should list all
timezone names in the TZ Database, including the links.

I did the grep excerice and found 579 names marked as Zone or Link,
and 415 in zone.tab.  UTC0 is not in the list, but UTC is.  I think it
is ok that the system actually would internally accept e.g. UTC0, even
if it is not available in the YANG module.

This puts a heavier burden on IANA I guess.  It is of course still
trivial to write the program that takes as input the current YANG
module and the new tzdata<vsn>.tar.gz file and produces a new YANG
module.  If this is what we want to do, I can write that program.  But
the question is if this procedure is ok for IANA?

Also, you asked previously about the POSIX TZ format.  The YANG
module does not support that, but it would be trivial to add, if we
believe that it would be useful.  Currently the module support a
choice of a location string or utc-offset.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Jan 2014 12:44:04 +0100

>      of listed enums may not change. Hence, to avoid brittleness when

RFC 6020 says:

"The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors."

This makes me wonder why it is that important to standardize the numeric values. They only have local meaning, they are not carried in NETCONF messages, and everything should work fine even if different servers or clients used different values.

Lada 

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: David Spakes <[email-masked]>
Date: Fri, 17 Jan 2014 11:03:41 -0500 (EST)

On Thu, 16 Jan 2014, Juergen Schoenwaelder wrote:

>   timezone names.

On Thu, 16 Jan 2014, Lange, Jeffrey K (GE Energy Management) wrote:

> enum.
> ...

> module that corresponds to the TZ database in use on that system.
...

> I am leaning slightly towards string over enumeration, but either is OK.

I am only casually following this thread, but I wanted to say that I
would also choose the string over enumeration.

The TZ Database seems too volatile to be the basis for enums.  Compound
that with developers making their own additions (e.g., US/Pacific, for
user convenience/preference) and subtractions (e.g., because of political
bias).  Would implementations even advertise their deviations for changes
based on politics?  Probably not.  And on a personal level, whenever I am
contemplating the decision to make work for someone else (i.e., IANA), I
try to be discriminating to ensure that the task is truly worthy of their
effort.  In this case, it feels too much like "busy work".

If the client needs to be able to see the list of strings that the
server is actually using, then the client should not reach out to the
TZ Database; it should consult the server.  In addition to the typedef,
the document should define a config false list of strings that the server
actually supports.

I would also suggest adding another leaf that is an optional descriptor
for the contents of the list of strings.  So if a developer grabs the
TZ Database on a particular date, makes a couple of changes, and drops it
into their server instrumentation, the descriptor could summarize
``based on TZ Database dated xx-xx-xxxx''.

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Paul Eggert <[email-masked]>
Date: Fri, 17 Jan 2014 15:39:20 -0800

Martin Bjorklund wrote:

> We want the YANG module to match what the underlying system is actually using, provided they support the TZ Database available from IANA.

OK, but the typical case is that if the underlying system supports the TZ database, it also supports POSIX TZ strings such as UTC0.  So if we want the YANG module to match what the underlying system is actually using ...

> I think it is ok that the system actually would internally accept e.g. UTC0, even if it is not available in the YANG module.

... then we might want to rethink this.

> It is of course still trivial to write the program that takes as input the current YANG module and the new tzdata<vsn>.tar.gz file and produces a new YANG module.  If this is what we want to do, I can write that program.  But the question is if this procedure is ok for IANA?

That would require that the TZ coordinator maintain the YANG module.  I think it's better to have YANG-only stuff maintained by the YANG maintainers.  TZ database maintenance is a pain enough already, and its maintenance procedure won't scale to also maintaining YANG timezone data, CLDR timezone data, etc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Jan 2014 11:33:31 +0100

>      the TZ database) cannot be supported

I think Andy makes a strong point here. This coupling will be a major
issue for any NETCONF implementation that is not shiped shrink wrapped
with a product. If I run a third party NETCONF server on my say Debian
system, the TZ database changes when the Debian packages are updated,
which happens pretty much independent of the NETCONF server update. So
it is likely that the IANA module shipped with the NETCONF server gets
out of sync with the underlying systems' database.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 19 Jan 2014 13:55:21 +0100

> out of sync with the underlying systems' database.

On the other hand, for a management application configuring a large and heterogeneous network of devices, it would be beneficial to have a uniform interface.

For an operator, the main point of having timezones properly configured is the ability to compare times reported from different sources. I think the POSIX format could serve this purpose quite well, and it would be up to NETCONF server implementations to translate the POSIX specification to the local system's conventions.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Jan 2014 07:35:12 -0800

On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka <[email-masked]> wrote:

> On the other hand, for a management application configuring a large and
> heterogeneous network of devices, it would be beneficial to have a uniform
> interface.
>
>

The client needs to be using the module version reported by each server that
it is managing.  The problem with generating a new official YANG module  ~3
times a year
is that there most assuredly will be servers using different versions of
this YANG module.
The client must keep in synch with each server, based on the server
revisions.

The problem that I raised and Juergen commented on is for each individual
server staying
in synch with itself.  On an embedded system, the server vendor must ensure
that the
correct YANG module and TZ database are loaded on the device.  But what
about
a NETCONF server on an open system?  When the OS updates the tzdata package,
the YANG module (or maybe just the module revision date within the server
<hello>) will not
magically update to the new version as well.

An enumeration typedef must be updated ASAP. A string typedef never needs
to be updated.
Never mind the burden on IANA, what about the burden this update
requirement places
on server vendors and operators?

For an operator, the main point of having timezones properly configured is
> the ability to compare times reported from different sources. I think the
> POSIX format could serve this purpose quite well, and it would be up to
> NETCONF server implementations to translate the POSIX specification to the
> local system's conventions.
>
> Lada
>
> >
> > /js
>

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 19 Jan 2014 17:19:55 +0100

On 19 Jan 2014, at 16:35, Andy Bierman <[email-masked]> wrote:

> it is managing.  The problem with generating a new official YANG module  ~3 times a year
> is that there most assuredly will be servers using different versions of this YANG module.
> The client must keep in synch with each server, based on the server revisions.
> 
> The problem that I raised and Juergen commented on is for each individual server staying
> in synch with itself.  On an embedded system, the server vendor must ensure that the
> correct YANG module and TZ database are loaded on the device.  But what about
> the YANG module (or maybe just the module revision date within the server <hello>) will not
> An enumeration typedef must be updated ASAP. A string typedef never needs to be updated.
> Never mind the burden on IANA, what about the burden this update requirement places

From what I have read about the POSIX format, the client would essentially specify the offset from UTC and rules for DST shifts. So there would be no enumeration and no module updates, and the server will just have to apply the received data correctly.

The POSIX format is more cryptic than the Olson names but this can be handled on the client’s side if necessary. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Jan 2014 09:27:11 -0800

On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka <[email-masked]> wrote:

> From what I have read about the POSIX format, the client would essentially
> specify the offset from UTC and rules for DST shifts. So there would be no
> enumeration and no module updates, and the server will just have to apply
> the received data correctly.
>
> The POSIX format is more cryptic than the Olson names but this can be
> handled on the client’s side if necessary.
>
>
This is a lot of complicated work for no gain.
I strongly oppose changing the format from Olson to POSIX.
POSIX is not user-friendly at all.

This debate is about encoding the Olson format with an enumeration
or with a string typedef, not starting over.

The value of a string timezone type is the same as the xpath1.0 typedef.
It lets tools know how to treat a special string type, without introducing
YANG language extensions to flag the string type as special.

Andy

>
> >
> >
> >
> > For an operator, the main point of having timezones properly configured
> is the ability to compare times reported from different sources. I think
> the POSIX format could serve this purpose quite well, and it would be up to

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 19 Jan 2014 19:09:19 +0100 (CET)

> or with a string typedef, not starting over.

The problem with a string as the timezone is that it is
non-interoperable.  A common use case is that a set of devices from
different vendors are installed at some site, and the operator wants
to set the same timezone on all of them.  How will the operator know
what to set on each device?  Even if the dveice reports its supported
values as operational state, it doesn't help much.

But from the discussion so far it seems this problem is too difficult
to solve, simply b/c there is no such thing as a standard set of
timezone locations.  We thought we could use the IANA-maintained TZ
Database for this, but since it changes too often it won't work.

I suspect though that if we create this as a string, it will work as
intended in most practical situations.  I.e., if the operator chooses
a "common" location, it will work "most of the time".  This might be
good enough.

So, my conclusion after this discussion, is that we should remove the
enum (and that document), and use a string in the ietf-system module.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Jan 2014 19:31:30 +0100

On Sun, Jan 19, 2014 at 07:09:19PM +0100, Martin Bjorklund wrote:

[...]
 
> enum (and that document), and use a string in the ietf-system module.

This is also my conclusion. So, anybody opposing this move forward?
Speak up now. I will read silence as agreement.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Jan 2014 10:33:31 -0800

On Sun, Jan 19, 2014 at 10:09 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > The client needs to be using the module version reported by each
> server
> > > that
> > > > it is managing.  The problem with generating a new official YANG
> module
> > >  ~3 times a year
+1

The worst that happens if the client sends an unsupported string,
it gets back an invalid-value error.  Since the CLI or WEBui (if present)
also needs the timezone set, NETCONF does not make the problem
any worse.  Advertising a YANG enumeration that did not exactly match
the server implementation would be worse.

Andy

---

From: SM <[email-masked]>
Date: Sun, 19 Jan 2014 10:44:12 -0800

Hi Juergen,
>Speak up now. I will read silence as agreement.

I gather that "document" in the above refers to not moving forward 
with draft-ietf-netmod-iana-timezones-03.

Regards,
-sm

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 19 Jan 2014 22:02:25 +0100 (CET)

SM <[email-masked]> wrote:
> I gather that "document" in the above refers to not moving forward with
> draft-ietf-netmod-iana-timezones-03.

Yes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 07:54:35 +0100

> POSIX is not user-friendly at all.

User-friendliness is nice, but only as long as it allows for setting the timezone correctly and reliably.

And as I wrote, a friendly interface to human users can be added by a client application.

> or with a string typedef, not starting over.

IMO, the debate is about how to do the right thing wrt timezone setting.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 08:16:44 +0100

> values as operational state, it doesn't help much.

Right.

> Database for this, but since it changes too often it won't work.

Moving to the string type does not improve the database in any way, it only shifts the responsibility for resolving possible mismatches from the server to the client. 

> a "common" location, it will work "most of the time".  This might be

Probably. I suspect though that the same is true for the current Olson format enumeration, even if it was updated only every five years or so.

> enum (and that document), and use a string in the ietf-system module.

This is fine for a human user configuring a small number of devices but not so much for an automated application and large networks.

Lada

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2014 09:46:14 +0100

Hi everyone,

I'm sorry this is so complex, but there are still a number of options,
none of which are perfect.  Maybe perfection isn't the right target here.

1.  Assume self-consistency from an IETF part.  We can't control what
others do.  We don't write code, and we can expect at least some
localization.  An example of this localization may be adding other
names.  This is my suggested approach, and it means grepping for Link
and Zone lines, or better simply requiring that the name be listed in
the TZ database.  Details of that latter option to be worked out by
yourselves.  The drawback is that localization differs between vendors.

2.  Go with a string and assume absolutely no semantics associated with
it.  I have no idea if this serves your purposes, other than to say,
well if the two systems have a configured TZ then the chances are they
will to some extent agree on what time it is. (N.B., database version
skew means they may disagree).

3.  Go with a POSIX string.  It is possible to some reasonable degree
generate a POSIX string from an Olson database entry, although there are
MANY corner cases, and you have periodically to recompute the string.

Just some thoughts.

Eliot

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 10:04:43 +0100

Dear all,

Taking into account
- that there is no canonical list of TZ time zone names (political 
reasons were mentioned)
- that the generate number solutions (from hash or coordinates) don't 
address the removal (and obsoleting) of zones.
- that I'm not too clear if IANA would support a program to generate 
this YANG module
- Lada's feedback: "The value is unused by YANG and the XML encoding, 
but is carried as a convenience to implementors."
I'm wondering if it doesn't make sense to:
- not ask IANA to maintain this YANG module (so removing the IANA 
considerations)
- express: "this document is generated from *Time Zone Data v. 2013i* 
(Released 2013-12-17) tzdata2013i.tar.gz 
<http://www.iana.org/time-zones/repository/releases/tzdata2013i.tar.gz> 
(213.7kb)"
- see how the situation evolves in the couple of years.
     maybe wait for a canonical list of TZ names
     maybe update this YANG module with a new RFC in a couple of years 
if there are many entry additions/deletions
     ...

Note: without a quick resolution on this issue (max tomorrow morning), I 
will have to remove draft-ietf-netmod-system-mgmt 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/> from 
the telechat this Thursday.

Regards, Benoit
> OK, but the typical case is that if the underlying system supports the 
> TZ database, it also supports POSIX TZ strings such as UTC0. So if we 
> want the YANG module to match what the underlying system is actually 
> using ...
>
>> I think it is ok that the system actually would internally accept 
>> e.g. UTC0, even if it is not available in the YANG module.
>
>> It is of course still trivial to write the program that takes as 
>> input the current YANG module and the new tzdata<vsn>.tar.gz file and 
>> produces a new YANG module. If this is what we want to do, I can 
>> write that program.  But the question is if this procedure is ok for 
>> IANA?
>
> That would require that the TZ coordinator maintain the YANG module.  
> I think it's better to have YANG-only stuff maintained by the YANG 
> maintainers.  TZ database maintenance is a pain enough already, and 
> its maintenance procedure won't scale to also maintaining YANG 
> timezone data, CLDR timezone data, etc.
> .
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 10:19:27 +0100

On 20 Jan 2014, at 10:04, Benoit Claise <[email-masked]> wrote:

> Dear all,
> 
> Taking into account 
> - that there is no canonical list of TZ time zone names (political reasons were mentioned)
> - that the generate number solutions (from hash or coordinates) don't address the removal (and obsoleting) of zones.
> - that I'm not too clear if IANA would support a program to generate this YANG module
> - Lada's feedback: "The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.”

In other words, I think the “value” substatements can be safely removed from the enums, they seem to be more of a nuisance than convenience.

> - not ask IANA to maintain this YANG module (so removing the IANA considerations)

+1

> - express: "this document is generated from Time Zone Data v. 2013i (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)”

+1

>     maybe update this YANG module with a new RFC in a couple of years if there are many entry additions/deletions

+1

Lada

>     ...
> 
> Note: without a quick resolution on this issue (max tomorrow morning), I will have to remove draft-ietf-netmod-system-mgmt from the telechat this Thursday.
> 
> Regards, Benoit
>> Martin Bjorklund wrote: 
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jan 2014 10:35:42 +0100

> In other words, I think the “value” substatements can be safely removed from the enums, they seem to be more of a nuisance than convenience.

RFC 6020 section 9.6.4.2:

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value.

This essentially means any change of order will cause different
numbers to be assigned. Lets not get into a debate whether this
is a feature or but - it is just how Yang 1.0 is defined.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jan 2014 10:39:46 +0100

> And as I wrote, a friendly interface to human users can be added by a client application.

Our goal is to 'fix' the definition of the timezone-location leaf at
this point in time.  Other options can be added to the timezone choice
in the future once we have gained experience that this is needed.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Jan 2014 10:39:58 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> > - reasons were mentioned)
> > - address the removal (and obsoleting) of zones.
> > - this YANG module
> > - but is carried as a convenience to implementors.”
> 
> In other words, I think the “value” substatements can be safely
> removed from the enums, they seem to be more of a nuisance than
> convenience.

Whether the "value" statement is there or nor doesn't matter - if it
is not there explicitly, the enum gets an implict value, and this
value must not change on updates.

But in either case, I don't see the problem with the value.

> > - considerations)
> > - express: "this document is generated from Time Zone Data v. 2013i
> > - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)”
> 
> +1
> 

But doesn't this effectively mean that we standardize a snapshot of
the (timezone names from the) TZ Database?  I assume that entries get
added or removed for some good reason, and we are saying that we
ignore that?

This also doesn't solve the issue of mismatch between the YANG module
and the underlying system, for installations on "open" systems.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 10:51:32 +0100

> is a feature or but - it is just how Yang 1.0 is defined.

But it is the name that counts, and that is sent between the client and server (or vice versa).

If an implementation decides to map internally the Olson names to integers (which is IMO by no means necessary), it should be completely transparent to other parties. The numbers are no issue in terms of interoperability.

Lada

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 10:54:10 +0100

> In other words, I think the “value” substatements can be safely removed from the enums, they seem to be more of a nuisance than convenience.
I was simply thinking that, if there is a new YANG revision (posted 
after a couple of years) with a different set of values, then it doesn't 
matter to implementation.

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jan 2014 10:55:53 +0100

> If an implementation decides to map internally the Olson names to integers (which is IMO by no means necessary), it should be completely transparent to other parties. The numbers are no issue in te…

As I said, I am quoting how Yang 1.0 is defined. Whether that is
useful or not is not the point of this discussion - we are not going
to change RFC 6020 in order to define the timezone-location leaf.

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 10:59:26 +0100

A question for IANA in line.

> and the underlying system, for installations on "open" systems.
Let me see if I get the situation right.
I understand that we can't do a perfect job (*), so should we do an OK job?

(*) except with a program that IANA would maintain, if I'm not mistaken.
Michelle, is this a viable solution for you?

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 11:18:47 +0100

> value must not change on updates.

Must not change - where? As far as I can tell, the value is completely local to each client or server. Will anything break if an implementation uses a different internal numbering, or no numbering at all?

> But in either case, I don't see the problem with the value.

I agree.

> added or removed for some good reason, and we are saying that we

If a server advertizes a timezones module, the client knows exactly the available options. Even if it doesn’t reflect the most recent version of the database, the client should in most cases be able to configure the timezone properly. That is, the client may not be able to use “Europe/Budweis”, which is a shame, but “Europe/Prague” will work as well. 

> and the underlying system, for installations on "open" systems.

The NETCONF server should correctly handle the advertised revision. If it doesn’t, it’s broken.

It is an illusion to assume that one can freely run “apt-get upgrade” without checking the impact on the NETCONF subsystem. Other things can easily break, too, and the implementation must take care of it.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 11:22:50 +0100

> to change RFC 6020 in order to define the timezone-location leaf.

Nothing needs to be changed, the values just seem to be irrelevant from the interoperability point of view.
And they are optional in YANG.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jan 2014 11:29:08 +0100

> And they are optional in YANG.

Yang 1.0 says (RFC 6020 section 10):

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 11:33:31 +0100

>      enums's values do not change.

Right, so if no enum’s values are present, they cannot change. 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Jan 2014 12:11:29 +0100 (CET)

> Right, so if no enum’s values are present, they cannot change. 

From 6020:

   The "value" statement, which is optional, is used to associate an
   integer value with the assigned name for the enum.

   [...]

I.e., every enum *always* has a value.  This value must not change
during upgrade.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jan 2014 13:45:10 +0100

> Right, so if no enum’s values are present, they cannot change.

Oh, I see, the misunderstanding is due to the vague formulation in sec. 9.6.4.2:

"If a value is not specified, then one will be automatically assigned.”

My interpretation is, because “The value is unused by YANG and [only] a convenience to implementors”, that it is an implementor that assigns the missing values.

Your and Martin’s interpretation seems to be “If a value is not specified, the enum entry must be treated as if a value of X was defined for it.” Then the constraint you cited from sec. 10 of course means that the value *is* used by YANG!

Lada

---

From: Paul Eggert <[email-masked]>
Date: Mon, 20 Jan 2014 08:42:10 -0800

> <http://www.iana.org/time-zones/repository/releases/tzdata2013i.tar.gz>

If this option is taken (and I'm not saying it's a good idea), it should 
state the generation method, and state that this isn't all the names 
supported by the TZ code and data.  Something like this, say:

"The time zone names of this document were taken from the third column 
of the TZ data's zone.tab file, in the same order as the zone.tab file. 
This is a proper subset of the time zone names supported by the TZ code 
and data."

If the generation method is changed to be something along the lines that 
Eliot Lear suggested, then the above text should be changed to match.

Also, it would be helpful to state what should or will happen with 
future releases of the tz data, particularly if the enum values must be 
stable, since the above method does not generate stable enums.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jan 2014 09:17:40 -0800

On Mon, Jan 20, 2014 at 8:42 AM, Paul Eggert <[email-masked]> wrote:

> "The time zone names of this document were taken from the third column of
> the TZ data's zone.tab file, in the same order as the zone.tab file. This
> is a proper subset of the time zone names supported by the TZ code and
> data."
>
> Also, it would be helpful to state what should or will happen with future
> releases of the tz data, particularly if the enum values must be stable,
> since the above method does not generate stable enums.
>

I don't see how a snapshot helps.  That seems to just ignore the problem
of YANG enums out of synch with the operating system. I was surprised that
the TZ database changes as often as 3 times a year.  YANG enumerations
are best suited for static classification.

Andy

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 21 Jan 2014 09:00:27 -0800

I am reviewing the question below to IANA.  Hope to get you an answer
today.

--Michelle

On 1/20/14 1:59 AM, "Benoit Claise" <[email-masked]> wrote:

>>>> - but is carried as a convenience to implementors.²
>>> In other words, I think the ³value² substatements can be safely
>>>> - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)²
>>> +1
>>>