Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:05:31 +0000

I've updated the iana timezone typedef to reflect the latest version of the IANA timezone database.  However in doing this I think I've found a larger issue.  One of the changes was the removal of the timezone "Antarctica/South_Pole" This leads to a problem if we are trying to reflect this as an enumeration (with an auto incrementing value). Would this not make more sense to convert this to an identity so that changes to the IANA timezone database would not be as intrusive?

-Jeff

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 10:50 AM
> To: Lange, Jeffrey K (GE Energy Management)
> Subject: New Version Notification for draft-ietf-netmod-iana-timezones-
> 01.txt
> 
> 
> A new version of I-D, draft-ietf-netmod-iana-timezones-01.txt
> has been successfully submitted by Jeffrey Lange and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-netmod-iana-timezones
> Revision:	 01
> Title:		 IANA Timezone Database YANG Module
> Creation date:	 2013-11-12
> Group:		 netmod
> Number of pages: 39
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-netmod-
> iana-timezones-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-
> timezones
> Htmlized:        http://tools.ietf.org/html/draft-ietf-netmod-iana-
> timezones-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-
> timezones-01
> 
> Abstract:
>    This document defines the iana-timezones YANG module for timezone
>    configuration.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 17:28:20 +0100

> I've updated the iana timezone typedef to reflect the latest version of the IANA timezone database.  However in doing this I think I've found a larger issue.  One of the changes was the removal of…

Thanks for looking into the update.

Concerning the removal, I think the proper YANG way would be to mark
the status of the enum obsolete. This should actually be discussed in
the IANA guidelines. I am not sure how choosing identities instead of
enums makes a difference here - perhaps I am missing something?

/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: Tue, 12 Nov 2013 17:31:16 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > I've updated the iana timezone typedef to reflect the latest version
> > of the IANA timezone database.  However in doing this I think I've
> > found a larger issue.  One of the changes was the removal of the
> > timezone "Antarctica/South_Pole" This leads to a problem if we are
> > trying to reflect this as an enumeration (with an auto incrementing
> > value). Would this not make more sense to convert this to an identity
> > so that changes to the IANA timezone database would not be as
> > intrusive?
> 
> the IANA guidelines.

+1

> I am not sure how choosing identities instead of

In fact, using identities give the impression that this is a
"decentralized extensible enumeration", which I believe it is not.  It
is a centralized enumeration.

/martin

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:40:57 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 11:31 AM
> To: [email-masked]
> Cc: Lange, Jeffrey K (GE Energy Management); [email-masked]
> Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-
> timezones-01.txt
> 

I agree, perhaps it should stay an enumeration, currently the IANA considerations talks about adding a new entry, but not removing them:

   The iana-timezones module is intended to reflect the IANA "timezone
   database".  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.

How about in addition:
   If a timezone location is removed or renamed in the IANA timezone
   database, the exiting enum statement MUST NOT be removed from the
   enumeration. The status of the existing enum statement MUST be
   changed to "obsolete".

-Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 17:47:20 +0100

>    enumeration. The status of the existing enum statement MUST be

I suggest to discuss remove and renaming separately for clarity,
e.g. something like this:

  If a timezone location is removed in the IANA timezone database, the
  corresponding existing enum statement is kept and a status statement
  is added to mark the enum 'obsolete'.

  If a timezone location is renamed in the IANA timezone database, a
  new enum is added with the new timezone name (as described above)
  and the enum representing the old timezone name is kept but marked
  with a status statement declaring the enum 'obsolete'.

Since IANA is not having YANG expertise, we may want to add concrete
examples they can work with (e.g. using the south pole case).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Nov 2013 16:11:27 +0100

Jeffrey,

I took a look at the revised documents and this is where I think we
are in terms of pending updates:

- Leave only one revision statement since we do not track revisions of
  I-Ds with revision statements (I-Ds are not published documents but
  just temporary drafts documenting work-in-progress).

- Is the IANA description of Europe/Berlin really "most locations"?

- Text should be added to the IANA considerations that explains how
  IANA has to deal with removals and renamings.

Can we get this worked out and a revised I-D posted in a few days? I
would like to put this together with the system configuration document
on Benoit's desk.

/js