Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 07:31:21 +0200

On Wed, Jun 27, 2012 at 03:37:03PM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : IANA Timezone Database YANG Module
> 	Author(s)       : Jeffrey Lange
> 	Filename        : draft-lange-netmod-iana-timezones-00.txt
> 	Pages           : 40
> 	Date            : 2012-06-27
> 
> Abstract:
>    This document defines the initial version of the iana-timezone YANG
>    module.

Thanks for putting this together. Perhaps the I-D should refer to RFC
6667 and the rules therein under which circumstances new TZ names are
created. In fact, it seems that the maintenance really is in the hands
of the TZ Coordinator and IANA is essentially providing infrastructure
and the framework in which he does his work. So most likely, in
practical terms, the TZ coordinator would have to create the YANG
module as well. Since the database is in a machine readable form, I
guess what he likely need is an advanced version of your script that
automatically generates the YANG module and if it changes, it needs to
be pushed to the IANA place where the YANG modules are published.

In other words, I think some discussion with IANA and the current TZ
coordinator might be needed to come up with a workable procedure how
this would work.

/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: Thu, 28 Jun 2012 10:31:48 +0200 (CEST)

Hi,

> be pushed to the IANA place where the YANG modules are published.

I think the module probably has to be maintained manually by IANA.
The reason for this is the YANG update rule (Section 10 of RFC 6020):

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

The current enum list is sorted in alphabetic order, and it must be
clear to IANA that they need to alloacte a new value for the new
value.  So they can probably not just re-generate the module from
their database - unless they add the value to their db of course.

I just realized that you didn't include the value statement in this
version (it was there in your first proposal).  I suggest you put it
back for the reasons given above.

Some comments on the module:

1. You should probably fix your script to trim empty descriptions:

     enum "Africa/Abidjan" {
       description
         "";
     }

   should be

     enum "Africa/Abidjan" {
       value 1;
     }

2. You should add a description and a reference to the typedef.  The
   reference should point to the IANA registry:
   ("http://www.iana.org/time-zones")

3. And a nit - there's a trailing "<" in the introduction:

   Whenever a new timezone name is added to the IANA "timezone
   database", the iana-timezones module is updated by IANA.<

/martin

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 28 Jun 2012 12:43:54 +0000

>The current enum list is sorted in alphabetic order, and it must be clear to IANA that they need to alloacte a new value for the new value.  So they can probably not just re-generate >the module from their database - unless they add the value to their db of course.

I sorted this alphabetically for readability, the zone.tab file I built it from is sorted as stated in the file:
	# The table is sorted first by country, then an order within the country that
	# (1) makes some geographical sense, and
	# (2) puts the most populous zones first, where that does not contradict (1).

So that also is a bit arbitrary as well.  Should I leave the enums in alphabetical order? Or should it match what the zone.tab file does?

>
>I just realized that you didn't include the value statement in this version (it was there in your first proposal).  I suggest you put it back for the reasons given above.

I pulled those out because they don't map to anything in particular, they were just an incrementing number that I used.  There is no concept of an ID number for entries in the TZ database, just the location string itself...  thoughts?

How does the statement "provided the old  enums's values do not change" apply to YANG enums that don't use values? Does that imply that all enums should have a value tag if they ever want to be considered maintainable?

>1. You should probably fix your script to trim empty descriptions:

Easy enough.

>   ("http://www.iana.org/time-zones")
Can do.

>   database", the iana-timezones module is updated by IANA.<

Typo =)

>/martin

-Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 15:02:30 +0200

> So that also is a bit arbitrary as well.  Should I leave the enums in alphabetical order? Or should it match what the zone.tab file does?

Any order is likely irrelevant over time. See below.
 
> I pulled those out because they don't map to anything in particular, they were just an incrementing number that I used.  There is no concept of an ID number for entries in the TZ database, just the…

Would be nice there were one. Otherwise, the translation needs to
assign one and never change it afterwards.
 
> How does the statement "provided the old  enums's values do not change" apply to YANG enums that don't use values? Does that imply that all enums should have a value tag if they ever want to be con…

If there is no value statement, then the enums are numbered
automatically. This means that the order may never change (and it is
harder to figure out what the 30th enum's value really is unless you
use tools). See RFC 6020 section 9.6.4.2.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2012 15:10:53 +0200 (CEST)

"Lange, Jeffrey K (GE Energy)" <[email-masked]> wrote:
> >value.  So they can probably not just re-generate >the module from
> I sorted this alphabetically for readability, the zone.tab file I
> built it from is sorted as stated in the file:
> 	# The table is sorted first by country, then an order within the
> 	# country that
> 	# (2) puts the most populous zones first, where that does not
> 	# contradict (1).
> 
> So that also is a bit arbitrary as well.  Should I leave the enums in
> alphabetical order? Or should it match what the zone.tab file does?

I think you should keep them in the same order as in the zone.tab
file.  Anyone can easily sort them alphabetically if they want to, but
it is harder the other way around.

> I pulled those out because they don't map to anything in particular,
> they were just an incrementing number that I used.  There is no
> concept of an ID number for entries in the TZ database, just the
> location string itself...  thoughts?
> 
> How does the statement "provided the old enums's values do not change"
> apply to YANG enums that don't use values? Does that imply that all
> enums should have a value tag if they ever want to be considered
> maintainable?

No, but the update procedure must be clear.  With explicit values the
instructions to IANA would be:

   1.  allocate a new value for the new timezone
   2.  add a new enum statement in the proper order (as defined in the
       zone.tab)

Without explicit values you would have to always add entries at the
end (or use values for the new entries, but that would be even
worse...)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 15:12:13 +0200

> Any order is likely irrelevant over time. See below.

Well, I realize this statement is not really helpful / correct. You
can keept the enums defined in the order they are defined in the TZ
database but then the value statements MUST be used and the numbers
over time won't be assigned in a strictly increasing order. This means
that YANG tools can use the definition order (if they are able to
access it) or they might end up using the numeric value order, which
will over time be increasingly meaningless.

/js

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 28 Jun 2012 13:49:53 +0000

I have a general question about the description text.  I took the text directly from the iana-if-type module, but it has the text

 This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";

Now from the conversations yesterday, am I correct in saying that this will NOT map to a particular RFC due to how iana controls their documents?  If this is true, the description text in the iana-if-type module should also be updated to reflect this.

Also the email is listed as iana&iana.org  I assume that this is a typo and should also be changed in the iana-if-type document.

-Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 16:23:48 +0200

> Now from the conversations yesterday, am I correct in saying that this will NOT map to a particular RFC due to how iana controls their documents?  If this is true, the description text in the iana-…

The initial version is an RFC and hence the statement is correct. The
question whether the legal framework then also applies to subsequently
IANA maintained modules likely leads to a major discussion if we ask
it...
 
> Also the email is listed as iana&iana.org  I assume that this is a typo and should also be changed in the iana-if-type document.

I recently had a discussion about this with IANA and it seems right
now they prefer this style because they believe it helps them fighting
spam. (I think they are likely confused about this but I decided not
to try to convince them otherwise, at least not via email.)

/js

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 15:58:15 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder
[mailto:[email-masked]]
> Sent: 28 June 2012 14:12
> To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; [email-masked]
> Subject: Re: [netmod] I-D Action:
draft-lange-netmod-iana-timezones-00.txt
> will over time be increasingly meaningless.

Still learning here, but RFC6087 states:

If extensibility of enumerated values is required, then the
'identityref' data type SHOULD be used instead of an enumeration or
other built-in type.

So why are enums being considered over identityrefs?

> /js

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2012 17:03:10 +0200 (CEST)

> So why are enums being considered over identityrefs?

In this case, you really do not want the kind of extensibility that
identities give you - with an identity you get decentralized
extensibility; anyone can add their own new value.  That's probably
not what you need for timezones...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Jun 2012 08:07:15 -0700

> So why are enums being considered over identityrefs?
That text should be clarified.  If a centralized naming authority
is used, then enumeration is OK, and less complex than identityref.
For distributed naming authority, an identityref is needed.
(Identityref is a QName -- module-prefix:identity-name).

Also, enums are allowed to have many chars in them that
would be invalid in a YANG identifier. (e.g. '/' would make every
timezone location invalid)

> > /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 17:08:23 +0200

> So why are enums being considered over identityrefs?

Because that was proposed on the list. ;-)

/js

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 16:16:59 +0100

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: 28 June 2012 16:03
> To: Jonathan Hansford
> Cc: [email-masked]; [email-masked];
> [email-masked]
> > > > > So that also is a bit arbitrary as well.  Should I leave the
enums
> > in

Some might want to add military timezones
(http://www.worldtimezone.com/wtz-map-military.html).

Jonathan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Jun 2012 08:20:49 -0700

On Thu, Jun 28, 2012 at 8:08 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> On Thu, Jun 28, 2012 at 03:58:15PM +0100,
> [email-masked] wrote:

Wonder who proposed it?  :-)

I can't change ietf-system.yang to import this typedef until
the document is accepted as a WG document, so the new
version about to be published will not use it yet --
unless the WG can adopt this document via the mailing list.

I haven't seen any objections, and all issues have been addressed
(within scope of this WG).

Andy

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 28 Jun 2012 15:26:21 +0000

>(within scope of this WG).

I have just submitted version -01 of  draft-lange-netmod-iana-timezones that hopefully should address most of the issues raised on the list.

-Jeff