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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Jun 28, 2012 at 12:43:54PM +0000, Lange, Jeffrey K (GE Energy) wrote:
> >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 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?

Any order is likely irrelevant over time. See below.
 
> >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?

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 considered maintainable?

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>