Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 1 Feb 2014 10:56:54 +0100

On 31 Jan 2014, at 21:50, Juergen Schoenwaelder <[email-masked]> wrote:

> On Fri, Jan 31, 2014 at 09:40:42PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder <[email-masked]> wrote:
>>> On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
>>>> 
>>>> I think you do have a valid point.  It is probably be better to have
>>>> one fixed version of the enumeration standardized.  But the problem is
>>>> how this module would be maintained.  Apparently the database changes
>>>> too often for being maintained in RFCs.  And there also seems to be
>>>> a political dimension to it that I don't think we are prepared to
>>>> handle.  And if we simply publish an RFC with the current version of
>>>> the names from the database, what does it mean that the
>>>> IANA-maintained db differs?
>>>> 
>>> 
>>> I completely fail to understand which value an RFC with an almost
>>> immediately outdated list of TZ names has.
>> 
>> I don't think it is "immediately outdated".  Locations are rarely added and
>> removed.
> 
> The numbers I recall indicate a certain chance it comes out of the
> whole process already outdated. But even if it takes a year, the value
> is rather questionable.

From the network management point of view, it is important to be able to set the behaviour of the system clock properly. I would consider the module to be outdated only if it makes this impossible, and then it should be updated.

> 
>>> I would then rather prefer
>>> to code my manager to use my local list and be prepared that names can
>>> be rejected.
>> 
>> I expect this to work reasonably well in practice.  But the point is
>> that you don't know if a value will be accepted or not.
> 
> So what? I believe we will see other leaf where you can't predict for
> 100% that the value will be accepted. If we continue to strive for a
> perfect world, we will never ever achieve anything. I really doubt
> setting the timezone name is the biggest interoperability problem to
> solve.

It certainly isn’t, but we now have the enumeration and the proposal is to dump it for reasons that are not clear to me. We can have strings everywhere and forget about types.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 1 Feb 2014 11:01:56 +0100

> I don't think it is "immediately outdated".  Locations are rarely added and

Yes.

> that you don't know if a value will be accepted or not.

You know it, at least from the NETCONF point of view - that’s what the module is for. You wouldn't know it if it was a string, unless there is another mechanism to learn it (which is out of scope though).

Lada

> /martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Feb 2014 14:06:18 +0100

> From the network management point of view, it is important to be able to set the behaviour of the system clock properly. I would consider the module to be outdated only if it makes this impossible,…

Having two definitions of timezone names that are not synced is the
worst of all solutions. I want 3rd party NETCONF implementations to
function on open systems where the packaging and maintenance of the
timezone database is separate from the packaging and maintenance of
the NETCONF implementation.

We started with the idealistic idea there could be a maintained
enumeration and it turns out this is not realistic to establish and
likely also difficult to implement on open systems. So we are going
with a string which I believe will work just fine for a large part of
the world. If we find out later that this is not workable, we can add
additional objects to report which time zone names are available. At
this point in time, we have to ship things.

I leave it to Tom to determine concensus. But I note that concensus
can be rough.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 01 Feb 2014 14:46:39 +0100 (CET)

> I leave it to Tom to determine concensus. But I note that concensus

Just to make it clear; I do (still) believe that the string approach
is the only realistic alternative at this point.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Feb 2014 14:50:48 +0100

> is the only realistic alternative at this point.

Thanks. So it seems only Lada is unhappy with the resolution.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 1 Feb 2014 16:00:16 +0100

> the NETCONF implementation.

Even if the tzdata package is upgraded and the module isn’t, I fail to see the reason why it should stop functioning, except in really singular cases.

> I leave it to Tom to determine concensus. But I note that concensus

Sure, if everybody else is happy with the string type, then go ahead with it.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Feb 2014 07:25:59 -0800

> ....
> Even if the tzdata package is upgraded and the module isn't, I fail to see
> the reason why it should stop functioning, except in really singular cases.
>
>

It is important that the data type be correct 100% of the time.
The failure mode will always be singular cases here.  We would
like to use enumeration, but it doesn't work for this particular typedef.
Identity names cannot have forward slashes or whitespace.
The only base type that will work 100% is string.

> Sure, if everybody else is happy with the string type, then go ahead with

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Feb 2014 12:54:47 -0800

On Fri, Jan 31, 2014 at 7:20 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> On 31 Jan 2014, at 16:02, Thomas Nadeau <[email-masked]> wrote:
>
> >
> >       I would like to call consensus on this matter. I've received %100
> supporting comments for the proposal from the WG with no one not liking the
> proposal. The only comments received were from Martin and
>
> You must have missed my comments, so let me say I don't like the proposal.
> I think we are throwing out the baby with the bath water.
>
>
I think I have a compromise solution that saves the baby :-)

typedef timezone-enum {
  // TZ snapshot we have now
}

typedef timezone-name {
   type union {
      type timezone-enum;
      type string;
   }
}

1) The NETMOD WG would maintain this module, not IANA.
2) The snapshot would be updated at long-term intervals, such as every 2
years

This forces the server to support a set of values the client can predict
and also supports extra strings not in the snapshot.  This prevents false
negatives
wrt/ YANG validation, but not false positives (i.e., values have been
removed
from the snapshot).

Do timezone names get removed from the database? IMO, this seems rare
enough not to worry about until the next YANG snapshot RFC is published
with the now obsolete enums.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Feb 2014 14:02:47 -0800

Hi,

This does not address the political problems that seem to be
associated with the mere existence of a YANG snapshot
of the TZ database, so it is OK if we just use a string.
Since Lada is OK with a string, and that is already seems
to be the consensus, I will withdraw this union typedef idea
so we can finish this draft.

Andy

On Sat, Feb 1, 2014 at 12:54 PM, Andy Bierman <[email-masked]> wrote:

>> You must have missed my comments, so let me say I don't like the
>> proposal. I think we are throwing out the baby with the bath water.
>>
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 01 Feb 2014 23:19:17 +0100 (CET)

Hi,

As suggested by Tom, here's a proposal for the new typedef, which will
go into the ietf-system module:

  typedef timezone-name {
    type string;
    description
      "A timezone name as used by the Time Zone Database, sometimes
       referred to as the 'Olson Database'.

       The exact set of valid values is an implementation-specific
       matter.  Client discovery of the exact set of time zone names
       for a particular server is out of scope.";
    reference
      "RFC 6557: Procedures for Maintaining the Time Zone Database";
   }

We also realized that we were calling the feature and the leaf
"timezone-location", and this is not correct.  So we propose we rename
the feature and leaf to "timezone-name".   (The timezone has a name in
the database, and the name is often a location; but some names like
"Etc/GMT-1" are not locations.)

So with these changes, this the new definition:

OLD:

        case timezone-location {
          if-feature timezone-location;
          leaf timezone-location {
            type ianatz:iana-timezone;
            description
              "The TZ database location identifier string
               to use for the system, such as 'Europe/Stockholm'.";
          }
        }

NEW:
        case timezone-name {
          if-feature timezone-name;
          leaf timezone-name {
            type timezone-name;
            description
              "The TZ database name to use for the system, such
               as 'Europe/Stockholm'.";
          }
        }

/martin & andy

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 13 Feb 2014 14:08:14 -0500

Hi all,

	Apologies for not following up on this until now. I started my new gig about a week ago and have been going full tilt.  Anyways, I'd like to make a final consensus call on this matter so that we can move the draft forward. 

	After some decent discussion around the matter at hand, there appears to be sufficient consensus to move forward with the proposal below. I also see that Martin just posted an updated that aligns with this, so I think we are all set to move forward.

	--Tom

> 
> 	I would like to call consensus on this matter. I've received %100 supporting comments for the proposal from the WG with no one not liking the proposal. The only comments received were from Martin and Benoit with regard to enhancing the description around the timezone-name typedef.  Document editors, please take those two comments into account and make the changes necessary. You might want to propose the text on the list before publishing as it should be a fairly minor change, but just to make sure it covers the comments received.
> 
> 	--Tom
> 
> 
>> 
>> 	Netmod WG:
>> 
>> 	The working group chairs have considered the discussion concerning 
>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>> like to call consensus on the matter regarding that surfaced during
>> the IETF last call with regard to the the practicability of maintaining a 
>> YANG module with an enumeration of timezone names. We believe there is
>> consensus in the working group to move forward with the following 
>> resolution:
>> 
>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>> extended to introduce a new typedef for timezone names, e.g.
>> something that looks like:
>> 
>> typedef timezone-name {
>>  type string;
>>  description
>>    referred to as the 'Olson Database'.";
>>  reference
>> The timezone-location leaf will be changed to use this type,
>> the import of iana-timezones will be removed and the references
>> to I-D.ietf-netmod-iana-timezones will be removed.
>> 
>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>> back and work on this draft will stop.  The I-D is declared dead.
>> 
>> - Since there is nothing to do for IANA, there will be no IANA request 
>> needed in this regard for draft-ietf-netmod-system-mgmt-11. 
>> 
>> 	We note that further alternatives can be added to the timezone
>> choice in the future should the two mechanisms currently in place
>> turn out to be insufficient in practice.
>> 
>> 	We would like to give the WG sufficient time to raise any additional concerns or 
>> issues with regard to this issue and our path for resolving the issue at hand, and so we 
>> will accept comments/discussion on this matter until 8AM EDT on Tuesday, January 28, 2014.
>> As Juergen has been closely involved with the matter, I will adjudicate any issues
>> arising from this comment period.
>> 
>> 	Thanks,
>> 
>> 	Tom
>> 
>> 
>> 
>> 
>