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

From: The IESG <[email-masked]>
Date: Tue, 03 Dec 2013 12:46:04 -0800

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
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the initial version of the iana-timezones YANG
   module.  The iana-timezones YANG module defines the iana-timezone
   type, which is a serialization of the existing IANA Time Zone
   registry into YANG format.  The document provides instructions to
   IANA how to maintain the iana-timezones YANG module when the
   underlying Time Zone registry is updated.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Dec 2013 11:54:39 +0100

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

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

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.

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

Regards,
-sm

.