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

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Jan 2014 14:53:47 -0500

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
     "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";
  }

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

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 21 Jan 2014 20:25:37 +0000

>back and work on this draft will stop.  The I-D is declared dead.

I support this proposal.

 At some point in the conversation there was also the possibility of
having a config false list of the valid strings that a particular server
supports.  I think this is useful from a usability point of view. This
would be wrapped in a "if-feature timezone-location² clause like the
config true leaf. Was there general interest in this? Or was it more of a
passing comment?

-Jeff

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 09:50:39 +0100

Tom,
> needed in this regard for draft-ietf-netmod-system-mgmt-11.
I'm unclear on what's happening when a timezone name is added, removed, 
modified in the Time Zone Database.
Or maybe the assumption is that the typedef is always up to date with 
the latest version of the Time Zone Database, on the NETCONF client and 
server?
I believe It needs a little bit of explanation.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Jan 2014 08:41:32 +0100

On Wed, Jan 22, 2014 at 09:50:39AM +0100, Benoit Claise wrote:
> I'm unclear on what's happening when a timezone name is added,
> removed, modified in the Time Zone Database.
> Or maybe the assumption is that the typedef is always up to date
> with the latest version of the Time Zone Database, on the NETCONF
> client and server?

Since the typedef does not attempt to define the set of valid timezone
names, the typedef definition is always up-to-date. We are moving from
compile-time validation to run-time validation.

(Implementations that have been coded to 'understand' this typedef may
 still do some validatation based on whatever information source they
 have access to - its up to implementors to figure this out.)

/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: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 11:19:26 +0100

> compile-time validation to run-time validation.
Thanks.
>   have access to - its up to implementors to figure this out.)
This is what needs to be explained in the draft.

Regards, Benoit

---

From: SM <[email-masked]>
Date: Mon, 27 Jan 2014 13:53:56 -0800

Hello,

>to I-D.ietf-netmod-iana-timezones will be removed.

I don't have a strong opinion about the above.  There were some good 
comments (ignoring mine) which might be helpful to the working group 
as it reviews the above.

>needed in this regard for draft-ietf-netmod-system-mgmt-11.

I am okay with the above resolution of the issue.

Regards,
-sm

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Jan 2014 11:44:25 +0100 (CET)

Hi,

> to I-D.ietf-netmod-iana-timezones will be removed.

I support this solution.

However, I think we need to explain in the description text of the
timezone-name typedef that servers will restrict the valid values for
this type to whatever they support, and that how clients can learn
which values are valid is out of scope for this document.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Jan 2014 13:06:57 +0100

> which values are valid is out of scope for this document.

A client also needs to be able to learn the corresponding UTC offsets and DST rules.

I don’t have a strong opinion here but I wonder whether the benefits of the string type outweigh the damage to interoperability. My concern is that a string might be vulnerable not only to political, but also marketing pressures.

Lada

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

---

From: David Spakes <[email-masked]>
Date: Tue, 28 Jan 2014 11:08:15 -0500 (EST)

On Tue, 28 Jan 2014, Ladislav Lhotka wrote:

> I don't have a strong opinion here but I wonder whether the benefits
> of the string type outweigh the damage to interoperability. My concern
> is that a string might be vulnerable not only to political, but also
> marketing pressures.

If the client has a way to view the list of strings recognized by the
server together with their corresponding UTC offsets and DST changes,
then we should be able to lay to rest any and all concerns about how
political and marketing pressures affect the implementation of
individual devices.

I made a proposal a little over a week ago that is relevant.  No one
commented on it at that time, but maybe it should be discussed now.
Here it is again.

On Fri, 17 Jan 2014, David Spakes wrote:

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

Here is basically what I had in mind:

  list known-timezones {
    config false;

    leaf name {
      type timezone-name;
    }
    leaf utc-offset {
      // whatever type is appropriate
    }
    leaf valid-time {
      type uint32 {
        range "0 .. 365";
      }
      description
        "The number of days this advice is expected to remain valid.";
    }
  }

To prepare to configure a device, a client would retrieve the list.
A graphical-based client could use this information to populate a
choice widget from which a human operator could select the desired
value.  A non-interactive client could validate a predetermined
selection or automatically make a choice based on the utc-offset.

The valid-time would be used to set a timer in the client.  When the
timer fires, it's time to review the choice and potentially reconfigure
the device.  The client should retrieve the list again from the device
in order to update the choice.  For countries with a predetermined date
to switch between standard and daylight savings time, the valid-time
would indicate the number of days until the next switch.  If a country
(or state, or other municipality) chooses to modify the DST scheduled
(as the United States did a couple of years ago), the valid-time would
indicate the date when such a schedule change is expected.  If a date
is unknown to the device, it could set the value to zero, which means
"check back often".  In a region where there is no change for DST, the
value would remain 365 every time the information is retrieved.

-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: Andy Bierman <[email-masked]>
Date: Tue, 28 Jan 2014 08:21:33 -0800

> value would remain 365 every time the information is retrieved.

In order to justify all this extra work on the client and server, it would
help to understand the impact that timezone interoperability problems
are having on real deployments.

IMO the real TZ database is going to match the server values for
over 99.5% of the string values.  A few corner-cases are not worth
worrying about.

> -dss
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Jan 2014 18:43:27 +0100

> commented on it at that time, but maybe it should be discussed now.

I don’t get why it is preferable to have the poor server send all this info (which can be quite bulky) instead of letting the client to simply *configure* the timezone, perhaps using the POSIX format or any other means involving UTC offset and DST rules, provided the client knows the geographical location of the device.

> value would remain 365 every time the information is retrieved.

I think the DST rules have to be specified exactly, pretty much as in the POSIX format, so that both local time and UTC offset never get out of sync.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Jan 2014 18:57:00 +0100

> over 99.5% of the string values.  A few corner-cases are not worth

I agree. To this end, it would IMO be sufficient to publish the existing timezones module (the enumeration), and just get IANA out of the loop.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jan 2014 10:25:58 -0800

On Tue, Jan 28, 2014 at 9:57 AM, Ladislav Lhotka <[email-masked]> wrote:

> I agree. To this end, it would IMO be sufficient to publish the existing
> timezones module (the enumeration), and just get IANA out of the loop.
>
>
I don't agree with using a snapshot as an enumeration.
New values added over time will get incorrectly rejected by the server.
Since the YANG module needs to be generated from the TZ database,
the client (and server) can just use that directly for validation.

If the double-validation that the YANG module provides is not correct
for any reason, then it just gets in the way.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Jan 2014 19:41:21 +0100

> New values added over time will get incorrectly rejected by the server.

Unless and until the module changes, there is nothing new between the server and client that can be rejected. A problem might be with deleted timezones but I wonder whether this falls among the 0.05% you mentioned.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jan 2014 10:59:26 -0800

On Tue, Jan 28, 2014 at 10:41 AM, Ladislav Lhotka <[email-masked]> wrote:

> ....
> Unless and until the module changes, there is nothing new between the
> server and client that can be rejected. A problem might be with deleted
> timezones but I wonder whether this falls among the 0.05% you mentioned.
>
>

Martin posted an email showing there were 3 additions/year over
the last 2 years. I did not count the enums.
I guessed this rate was 0.5%

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Jan 2014 21:16:59 +0100

> I guessed this rate was 0.5% 

New additions won’t be available to NETCONF clients until the module gets updated, but this IMO presents very few practical problems, so the module needn’t be changed with every tzdata database update.

Lada

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 31 Jan 2014 10:02:34 -0500

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Jan 2014 16:20:40 +0100

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.

Lada

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

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 31 Jan 2014 10:28:23 -0500

Fair enough.  Point taken. 

	--Tom

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jan 2014 17:45:32 +0100 (CET)

Ladislav Lhotka <[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 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?

/martin

> 
> Lada
> 
> >  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:
> >>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jan 2014 08:55:11 -0800

On Fri, Jan 31, 2014 at 8:45 AM, Martin Bjorklund <[email-masked]> wrote:

> > You must have missed my comments, so let me say I don't like the
> proposal. I
The YANG enumeration is supposed to reflect the TZ database
and IANA is the naming authority for that database.  This YANG
module cannot be the authoritative source of TZ names.
A "snapshot" removes IANA as the naming authority,
and that was never the intent.

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Jan 2014 18:18:41 +0100

> IANA-maintained db differs?

Paul Eggert suggested in his messages from 16 January that the political issues can be avoided by not claiming that the YANG enumeration is authoritative/canonical or that it always mirrors the current Olson database names.

I was trying to figure out what typical changes have been applied to the database recently but I don’t know how to get this information. I reckon a typical scenario might be that a new timezone is added, say "Pacific/Bora-Bora”. Until the YANG module gets updated, all NETCONF servers on Bora Bora will not allow this setting but the clients can continue to use “Pacific/Tahiti” as before - mostly not a big deal IMO.

I am convinced that Benoit’s proposal from

http://www.ietf.org/mail-archive/web/netmod/current/msg08983.html

is perfectly viable.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Jan 2014 21:26:20 +0100

> IANA-maintained db differs?

I completely fail to understand which value an RFC with an almost
immediately outdated list of TZ names has. I would then rather prefer
to code my manager to use my local list and be prepared that names can
be rejected.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jan 2014 21:40:42 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> immediately outdated list of TZ names has.

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

> I would then rather prefer

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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Jan 2014 21:50:59 +0100

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

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

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jan 2014 12:53:21 -0800

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

3 a year may be rare but IMO that is too often for a standard YANG module.

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

You mean you don't know from analyzing the YANG module.
Code today must already use some other validation mechanism.
IMO they will still use some other validation mechanism.

Eventually (4 months or so) the YANG module will start rejecting
requests that are valid in the TZ database.  I agree with Juergen
about not seeing the value in this sort of YANG module.
I am not buying that this a feature instead of a bug (i.e., declare that
the YANG module is a new standard, not related to the TZ database)

Andy