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

Martin Bjorklund <mbj@tail-f.com> Thu, 28 June 2012 13:10 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22A321F8496 for <netmod@ietfa.amsl.com>; Thu, 28 Jun 2012 06:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.746
X-Spam-Level:
X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXU94o+gXiww for <netmod@ietfa.amsl.com>; Thu, 28 Jun 2012 06:10:55 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3502821F85AF for <netmod@ietf.org>; Thu, 28 Jun 2012 06:10:55 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 244F91200AE5; Thu, 28 Jun 2012 15:10:54 +0200 (CEST)
Date: Thu, 28 Jun 2012 15:10:53 +0200
Message-Id: <20120628.151053.917190434192028680.mbj@tail-f.com>
To: jeffrey.K.lange@ge.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <B0FB1FAC2C7B234D87DCEBF309F703C51BAA6B7D@CINMBCNA02.e2k.ad.ge.com>
References: <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <B0FB1FAC2C7B234D87DCEBF309F703C51BAA6B7D@CINMBCNA02.e2k.ad.ge.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 13:10:55 -0000

"Lange, Jeffrey K (GE Energy)" <jeffrey.K.lange@ge.com> 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?

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

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