Re: [netmod] Fwd: Re: Last Call: <draft-ietf-netmod-iana-timezones-03

Andy Bierman <andy@yumaworks.com> Thu, 09 January 2014 19:05 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1AF1AE4C5 for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 11:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRQEg_QF_uyX for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 11:05:26 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5061AE4C1 for <ietf@ietf.org>; Thu, 9 Jan 2014 11:05:23 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id i13so3124449qae.21 for <ietf@ietf.org>; Thu, 09 Jan 2014 11:05:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9jqPM8SiHHWIyMZcwRJkrKbpOakxR7MFy9C5p092R/8=; b=cPvm/8GXt8k7Di96WTn5Gazzz7xNFEGmK7SQzFL6JhG290lEYiSP70NVYNSVxNa3FZ dipb9zHWfmG+Kvph5JGqAdvgcd3AOXuzSv98BeGKpyOZLRi6kyPGvGXv1rK1Nb4T6CyT /rwMrOLa2BMHoTmfvF4VF9yF+tYk/ddKbBWYYlxTLzOM1DYSp63Yei+dpRTLQ8GgsMER Sw6Rfy2U9XK6LSQX0zABG+mgpZeOvwfS1vGUBteLatDqQ1zdvvt9CKaWRZgaj5WA491D 1l4vdkvOAo0DFUBuOBxDIZizxuPP/xFqBzZ32WsfTQtbahCGhNqhVwYK9Vr9p7eyANKb QCAw==
X-Gm-Message-State: ALoCoQmkCZgVMR8M8vOSGR+ZEa/802usb+wiU8z+DTnxntQrMlGmv5QWnrKlMamEDVRk0XZe5FtU
MIME-Version: 1.0
X-Received: by 10.49.84.105 with SMTP id x9mr10557787qey.65.1389294313332; Thu, 09 Jan 2014 11:05:13 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 9 Jan 2014 11:05:13 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20140109051548.0a951040@resistor.net>
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> <CABCOCHQp+04OwEZ2rMZt6mvfboX-cnqSmhAE9rxFqd0NjmYdAg@mail.gmail.com> <6.2.5.6.2.20140108233958.0a849e58@resistor.net> <20140109105804.GA44893@elstar.local> <6.2.5.6.2.20140109051548.0a951040@resistor.net>
Date: Thu, 09 Jan 2014 11:05:13 -0800
Message-ID: <CABCOCHTF4=zhwd25TWxh1pM8h_Tw2==WehDHuJaPPYMm3XWVUg@mail.gmail.com>
Subject: Re: [netmod] Fwd: Re: Last Call: <draft-ietf-netmod-iana-timezones-03
From: Andy Bierman <andy@yumaworks.com>
To: SM <sm@resistor.net>
Content-Type: multipart/alternative; boundary="047d7bdc0ef00910c904ef8e4a86"
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, IETF discussion list <ietf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 19:05:29 -0000

Hi,

On Thu, Jan 9, 2014 at 7:47 AM, SM <sm@resistor.net> wrote:

> Hi Juergen,
> At 02:58 09-01-2014, Juergen Schoenwaelder wrote:
>
>> People want to be able to configure timezones using the timezone
>> naming scheme commonly supported by operating systems (e.g.,
>> Europe/Paris). This document defines a serialization of the timezone
>> names into YANG format for this purpose. I believe there was indeed
>> strong concensus on this in the WG.
>>
>
> There was a message about a quick poll [1] to adopt
> draft-lange-netmod-iana-timezones-01 on 2 July, 2012.  Three persons
> expressed their support and the WG Chair expressed his support as a
> technical contributor [2]; there weren't any message objecting to adoption.
>  There were two comments [3][4] on 30 July, 2012.  There was a WG Last Call
> announcement [5] and two reminders [6][7] about it. There was a message [8]
> on 12 November, 2013 from a WG participant (I am not taking into account
> the message from the author and one of the WG Chairs).  My comment about
> the determination of consensus being questionable is based on the messages
> in the NETMOD mailing list archive.
>
>  This document aims at establishing an IANA maintained serialization of
>> whatever list of names the timezone database contains. It does not
>> change the way the TZ coordinator, an IANA Designated Expert, takes
>> decisions. Perhaps this needs to be stated more explicit.
>>
>
> There is a thread at http://mm.icann.org/pipermail/tz/2012-May/017711.html The problem is not changing the way things are done.  I would describe the
> current TZ approach as keeping the TZ information up-to-date by posting a
> (software) release every now and then.  It works for me.
>
>  So far (in the MIB world), the initial versions of IANA maintained
>> modules were published as Proposed Standards on the standards track
>> (although the only thing that really remains valid over time are the
>> IANA considerations, which however often require the initial module to
>> be available). We simply followed this practice.
>>
>
> If I understood correctly the YANG module defined in the draft creates
> IANA-registered timezones based on public domain [9] information about
> timezones.  IANA is then asked to keep the IANA-registered timezones
> up-to-date.  That sounds okay if the politics about time are not taken into
> consideration [10][11][12].
>
>  There was concensus in the WG that it is desirable to configure
>> timezones by name (e.g., Europe/Paris) instead of having only hard
>> coded UTC offsets - the benefits should be obvious.
>>
>
> I agree that there can be benefits to that approach.  I could not find the
> (mailing list) message where that WG decision was taken.
>
>
After reading the IANA Considerations section closer, I have some concerns
about the use of a YANG enumeration. This section does not say who must
update the enumeration typedef and republish the RFC containing the new
YANG module, every time the TZ database is changed.
Is it the NETMOD WG? IANA?

This may not be a practical long-term solution.
The purpose of a YANG enumeration type is to allow a well-constrained
value set that can be machine-validated.  If the data type was a string
instead of an enumeration, there would be no IANA coupling or republishing
(or YANG-based machine validation). The description-stmt can say a leaf
using this data type MUST match a value in the TZ database.

The draft (sec. 3.1) also says to change the status of the old enum to
obsolete
and add a new enum, in order to change the name.  YANG definitions are
supposed to transition from current to deprecated, not current to obsolete.



> Regards,
> -sm
>


Andy


>
> 1. http://www.ietf.org/mail-archive/web/netmod/current/msg06810.html
> 2. http://www.ietf.org/mail-archive/web/netmod/current/msg06841.html
> 3. http://www.ietf.org/mail-archive/web/netmod/current/msg06932.html
> 4. http://www.ietf.org/mail-archive/web/netmod/current/msg06933.html
> 5. http://www.ietf.org/mail-archive/web/netmod/current/msg08327.html
> 6. http://www.ietf.org/mail-archive/web/netmod/current/msg08333.html
> 7. http://www.ietf.org/mail-archive/web/netmod/current/msg08335.html
> 8. http://www.ietf.org/mail-archive/web/netmod/current/msg08694.html
> 9. ftp://ftp.iana.org/tz/tz-link.html
> 10. http://www.theguardian.com/news/datablog/2013/sep/26/
> spain-countries-wrong-time-zone
> 11. http://972mag.com/the-worlds-only-ethnic-time-zone/81006/
> 12. http://www.theblaze.com/stories/2013/09/22/just-wait-
> until-you-see-how-apples-new-operating-system-lists-jerusalem/
>