Subject: Re: [netmod] Fwd: Re: Last Call: <draft-ietf-netmod-iana-timezones-03.txt> (IANA Timezone Database YANG Module) to Proposed Standard

From: Benoit Claise <[email-masked]>
Date: Wed, 08 Jan 2014 17:37:17 +0100

Dear all,

Sadly, I have not seen a reply to this one.
So let me start the discussion, copying both the ietf-discussion and the 
netmod WG mailers.
See in-line.
> Dear all,
>
> Here is some feedback from the IETF discussion list.
> I would appreciate if the author and document shepherd could follow 
> up. Ideally on the IETF discussion list.
>
> Regards, Benoit
>
>
> -------- Original Message --------
> Subject: 	Re: Last Call: <draft-ietf-netmod-iana-timezones-03.txt> 
> (IANA Timezone Database YANG Module) to Proposed Standard
> Date: 	Tue, 3 Dec 2013 19:36:31 -0800
> From: 	SM <[email-masked]>
> To: 	<[email-masked]>
>
>
>
> At 12:46 03-12-2013, The IESG wrote:
> >The IESG has received a request from the NETCONF Data Modeling Language
> >WG (netmod) to consider the following document:
> >- 'IANA Timezone Database YANG Module'
> >   <draft-ietf-netmod-iana-timezones-03.txt> as Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to the
> >[email-masked]  mailing lists by 2013-12-17. Exceptionally, comments may be
>
> There is the following question in the document shepherd write-up:
>
>    Why is this the proper type of RFC?
>
> I did not see an answer to that question.
Not sure what you propose here. Proposed Standard seems right to me.
 From http://www.rfc-editor.org/RFCoverview.html

        RFC Categories

    Each RFC has a "category" or "status" designation. The possible
    categories (see *RFC 2026*
    <http://www.rfc-editor.org/rfc/rfc2026.txt> "The Internet Standards
    Process -- Revision 3") are:

      * INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410
        <http://www.rfc-editor.org/rfc/rfc6410.txt>), PROPOSED STANDARD

        These are /Standards Track/ documents, official specifications
        of the Internet protocol suite defined by the Internet
        Engineering Task Force (IETF) <http://www.ietf.org> and its
        steering group the IESG.

      * BEST CURRENT PRACTICE

        These are official guidelines and recommendations, but not
        standards, from the IETF.

      * INFORMATIONAL, EXPERIMENTAL

        These non-standards documents may originate in the IETF or may
        be independent submissions.

      * HISTORIC

        These are former standards that have been actively deprecated.

>
> 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.
>
> In Section 1:
>
>    "The iana-timezones YANG module defines the iana-
>     timezone type, which is a serialization of the existing IANA Time
>     Zone registry [RFC6557] into YANG format."
>
> The terminology in RFC 6557 defines a TZ Database sometimes referred
> to as the "Olson Database".  There isn't any mention of a "IANA Time
> Zone registry".  I suggest using the same name as in RFC 6557.
That makes sense.
>
> >From Section 3:
>
>    'The iana-timezones module is intended to reflect the IANA "timezone
>     database" [RFC6557].  When a timezone location is added to the
>     database, the "iana-timezone" enumeration MUST be updated as defined
>     in RFC 6020 Section 10 to add the newly created timezone location to
>     the enumeration.  The new "enum" statement MUST be added to the
>     "iana-timezone" typedef with the same name as the newly added
>     timezone location.  A new enum value MUST be allocated by IANA and
>     applied to the newly created enum entry.  New entries MAY be placed
>     in any order in the enumeration as long as the previously assigned
>     enumeration values are not changed.
>
>     If a timezone location is removed from the IANA timezone database,
>     the corresponding existing enum statement is kept and a status
>     statement is added to mark the enum entry as 'obsolete'.'
>
> The maintainer of the TZ database is responsible for the TZ
> Database.  The person does not work for IANA.
Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database:
<http://www.iana.org/go/rfc6557>

    The TZ Coordinator is an IANA Designated Expert

Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175?

> I don't think that
> IANA keeps track of the contents of the TZ Database as it was not
> asked to do that work.
I think it does: http://www.iana.org/time-zones
> I don't see the value of using RFC 2119 key
> word for the IANA Considerations.

>
> I suggest not creating the registry proposed in this draft.  The TZ
> database has strived to keep out of political issues.  Adding such a
> registry will pave the way for such issues.
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.

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Jan 2014 09:09:14 -0800

Hi,

By "this one" I assume you mean the question "Why Proposed Standard?"

This YANG module is meant to be imported by other standard YANG modules,
which creates a normative reference in each importing RFC. We try to avoid
standard modules that rely on non-standard modules. At first, (e.g, RFC
5277,
RFC 5717) the YANG modules were not normative. But since 2010,
(RFC 6020) all YANG modules are normative and XSD is no longer used.

Andy

On Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise <[email-masked]> wrote:

> I would appreciate if the author and document shepherd could follow up.
> Ideally on the IETF discussion list.
>
> Regards, Benoit
>
>
> -------- Original Message --------  Subject: Re: Last Call:
> <draft-ietf-netmod-iana-timezones-03.txt> (IANA Timezone Database YANG
> Module) to Proposed Standard  Date: Tue, 3 Dec 2013 19:36:31 -0800  From: SM
> <[email-masked]> <[email-masked]>  To: <[email-masked]> <[email-masked]>
>
> Each RFC has a "category" or "status" designation. The possible categories
> (see *RFC 2026* <http://www.rfc-editor.org/rfc/rfc2026.txt> "The Internet
> Standards Process -- Revision 3") are:
>
>    - INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410<http://www.rfc-editor.org/rfc/rfc6410.txt>),
>    PROPOSED STANDARD
>
>    These are *Standards Track* documents, official specifications of the
>    Internet protocol suite defined by the Internet Engineering Task Force
>    (IETF) <http://www.ietf.org> and its steering group the IESG.
>     - BEST CURRENT PRACTICE
>
>    These are official guidelines and recommendations, but not standards,
>    from the IETF.
>     - INFORMATIONAL, EXPERIMENTAL
>
>    These non-standards documents may originate in the IETF or may be
>    independent submissions.
>     - HISTORIC
>
>  Well, we need to specify the system clock in the following YANG module (
> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/), and
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Jan 2014 08:57:55 +0100

Hi Andy,
> By "this one" I assume you mean the question "Why Proposed Standard?"
I meant the other questions in this email, most importantly.
> standard modules that rely on non-standard modules. At first, (e.g, 
> RFC 5277,
Thanks for your answer.

Regards, Benoit
>
>
> Andy
>
>
> On Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     So let me start the discussion, copying both the ietf-discussion
>     and the netmod WG mailers.
>     See in-line.
>>     Dear all,
>>
>>     I would appreciate if the author and document shepherd could
>>     follow up. Ideally on the IETF discussion list.
>>
>>     Regards, Benoit
>>
>>
>>     Subject: 	Re: Last Call:
>>     <draft-ietf-netmod-iana-timezones-03.txt> (IANA Timezone Database
>>     YANG Module) to Proposed Standard
>>     From: 	SM <[email-masked]> <mailto:[email-masked]>
>>     To: 	<[email-masked]> <mailto:[email-masked]>
>>
>>
>>
>>     >[email-masked]  <mailto:[email-masked]>  mailing lists by 2013-12-17. Exceptionally, comments may be
>>
>         Each RFC has a "category" or "status" designation. The
>         possible categories (see *RFC 2026*
>         <http://www.rfc-editor.org/rfc/rfc2026.txt> "The Internet
>           * INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC
>             6410 <http://www.rfc-editor.org/rfc/rfc6410.txt>),
>             PROPOSED STANDARD
>
>             These are /Standards Track/ documents, official
>             specifications of the Internet protocol suite defined by
>             the Internet Engineering Task Force (IETF)
>             <http://www.ietf.org> and its steering group the IESG.
>
>           * BEST CURRENT PRACTICE
>
>             These non-standards documents may originate in the IETF or
>             may be independent submissions.
>
>           * HISTORIC
>
>     (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),
>     and hence we require a way to represent the TZ in YANG.
>
>     Regards, Benoit
>>     Regards,
>>     -sm
>>
>>     .
>>
>>
>>
>>
>>
>>     [email-masked]  <mailto:[email-masked]>

---

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

Hi Benoit, Andy,
At 08:37 08-01-2014, Benoit Claise wrote:
>categories (see RFC 2026 "The Internet Standards Process -- Revision 3") are:
>INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410), 
>PROPOSED STANDARD
>
>These are Standards Track documents, official specifications of the 
>Internet protocol suite defined by the Internet Engineering Task 
>Force (IETF) and its steering group the IESG.
>BEST CURRENT PRACTICE
>
>INFORMATIONAL, EXPERIMENTAL
>
>HISTORIC

At 09:09 08-01-2014, Andy Bierman wrote:
>standard modules that rely on non-standard modules. At first, (e.g, RFC 5277,

I included the comment from Andy Bierman above as it is also related 
to the document status.

If I understood the argument, it is that this YANG module would be 
referenced by other standard YANG modules and that is why the 
intended status is "Proposed Standard".  The argument from Benoit 
Claise is that the document is on the Standards Track as it is an 
official specification of the Internet protocol suite defined by the 
Internet Engineering Task Force.  I'll consider the question as 
addressed as the matter could be argued that way.

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

>be "TZ Database" according to BCP 175?

I suggested using the same name as in RFC 6557.

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.

>I think it does: http://www.iana.org/time-zones

What I meant was that IANA provides hosting services.  IANA does not 
track the changes.

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

Regards,
-sm

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jan 2014 11:58:05 +0100

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

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

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

---

From: SM <[email-masked]>
Date: Thu, 09 Jan 2014 07:47:46 -0800

Hi Juergen,
>strong concensus on this in the WG.

There was a message about a quick poll [1] to adopt 
draft-lange-netmod-iana-timezones-01 on 2 July, 2012.  Three persons 
expressed their support and the WG Chair expressed his support as a 
technical contributor [2]; there weren't any message objecting to 
adoption.  There were two comments [3][4] on 30 July, 2012.  There 
was a WG Last Call announcement [5] and two reminders [6][7] about 
it. There was a message [8] on 12 November, 2013 from a WG 
participant (I am not taking into account the message from the author 
and one of the WG Chairs).  My comment about the determination of 
consensus being questionable is based on the messages in the NETMOD 
mailing list archive.

>decisions. Perhaps this needs to be stated more explicit.

There is a thread at 
http://mm.icann.org/pipermail/tz/2012-May/017711.html  The problem is 
not changing the way things are done.  I would describe the current 
TZ approach as keeping the TZ information up-to-date by posting a 
(software) release every now and then.  It works for me.

>be available). We simply followed this practice.

If I understood correctly the YANG module defined in the draft 
creates IANA-registered timezones based on public domain [9] 
information about timezones.  IANA is then asked to keep the 
IANA-registered timezones up-to-date.  That sounds okay if the 
politics about time are not taken into consideration [10][11][12].

>coded UTC offsets - the benefits should be obvious.

I agree that there can be benefits to that approach.  I could not 
find the (mailing list) message where that WG decision was taken.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/netmod/current/msg06810.html
2. http://www.ietf.org/mail-archive/web/netmod/current/msg06841.html
3. http://www.ietf.org/mail-archive/web/netmod/current/msg06932.html
4. http://www.ietf.org/mail-archive/web/netmod/current/msg06933.html
5. http://www.ietf.org/mail-archive/web/netmod/current/msg08327.html
6. http://www.ietf.org/mail-archive/web/netmod/current/msg08333.html
7. http://www.ietf.org/mail-archive/web/netmod/current/msg08335.html
8. http://www.ietf.org/mail-archive/web/netmod/current/msg08694.html
9. ftp://ftp.iana.org/tz/tz-link.html
10. 
http://www.theguardian.com/news/datablog/2013/sep/26/spain-countries-wrong-time-zone
11. http://972mag.com/the-worlds-only-ethnic-time-zone/81006/
12. 
http://www.theblaze.com/stories/2013/09/22/just-wait-until-you-see-how-apples-new-operating-system-lists-jerusalem/

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Jan 2014 11:05:13 -0800

Hi,

On Thu, Jan 9, 2014 at 7:47 AM, SM <[email-masked]> wrote:

> technical contributor [2]; there weren't any message objecting to adoption.
>  There were two comments [3][4] on 30 July, 2012.  There was a WG Last Call
> announcement [5] and two reminders [6][7] about it. There was a message [8]
> on 12 November, 2013 from a WG participant (I am not taking into account
> the message from the author and one of the WG Chairs).  My comment about
> the determination of consensus being questionable is based on the messages
> in the NETMOD mailing list archive.
>
> There is a thread at http://mm.icann.org/pipermail/tz/2012-May/017711.html The problem is not changing the way things are done.  I would describe the
> current TZ approach as keeping the TZ information up-to-date by posting a
> If I understood correctly the YANG module defined in the draft creates
> IANA-registered timezones based on public domain [9] information about
> timezones.  IANA is then asked to keep the IANA-registered timezones
> up-to-date.  That sounds okay if the politics about time are not taken into
> consideration [10][11][12].
>
> I agree that there can be benefits to that approach.  I could not find the
> (mailing list) message where that WG decision was taken.
>
>
After reading the IANA Considerations section closer, I have some concerns
about the use of a YANG enumeration. This section does not say who must
update the enumeration typedef and republish the RFC containing the new
YANG module, every time the TZ database is changed.
Is it the NETMOD WG? IANA?

This may not be a practical long-term solution.
The purpose of a YANG enumeration type is to allow a well-constrained
value set that can be machine-validated.  If the data type was a string
instead of an enumeration, there would be no IANA coupling or republishing
(or YANG-based machine validation). The description-stmt can say a leaf
using this data type MUST match a value in the TZ database.

The draft (sec. 3.1) also says to change the status of the old enum to
obsolete
and add a new enum, in order to change the name.  YANG definitions are
supposed to transition from current to deprecated, not current to obsolete.

Andy

> 10. http://www.theguardian.com/news/datablog/2013/sep/26/
> spain-countries-wrong-time-zone
> 12. http://www.theblaze.com/stories/2013/09/22/just-wait-
> until-you-see-how-apples-new-operating-system-lists-jerusalem/
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jan 2014 22:51:29 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> > There is a thread at http://mm.icann.org/pipermail/tz/2012-May/017711.html
> > The problem is not changing the way things are done.  I would describe the

Yes.  The idea is to extract the names from the published TZ database
and list them in a YANG module.  Nothing more.  Entries cannot be
added directly to the YANG module; they will always just mirror what's
in the TZ database.

> Is it the NETMOD WG? IANA?

I think it is clear that the intention is that is IANA.  But of course
it could be clarified.  Maybe it should even say that it is the
responsibility of the TZ Coordinator.  However, this must presumably
be verified with him first.

> using this data type MUST match a value in the TZ database.

If it is not feasible to maintain a YANG "mirror" of the timezone
names from the TZ database, then I guess we can use a string.  I
prefer the formal enumeration though.

> supposed to transition from current to deprecated, not current to obsolete.

RFC 6020, section 10, explicitly allows a definition to go from
current to obsolete:

   o  A "status" statement may be added, or changed from "current" to
      "deprecated" or "obsolete", or from "deprecated" to "obsolete".

/martin

---

From: SM <[email-masked]>
Date: Sat, 11 Jan 2014 00:43:17 -0800

Hi Andy,
>Is it the NETMOD WG? IANA?

That would be IANA.  There is a comment from IANA about what it is 
being asked to do.  There hasn't been any public reply from the 
author of the draft.

The Last Call was announced on December 3, 2013.  The only responses 
have been from the Area Director, one of the working group Chairs, 
Martin Bjorklund and Andy Bierman.  If the document is published as a 
RFC it will be said to represent the consensus of the IETF ...

Regards,
-sm

---

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

> find the (mailing list) message where that WG decision was taken.

SM,

there are no specific concensus calls for every leaf since this won't
scale. I do not recall having seen any issues raised on using timezone
names during the WG last calls. The timezone configuration using
timezone names has been in this document since its very beginning,
even before WG adoption, see draft-bierman-netmod-system-mgmt-00 (June
2, 2011).

/js