IETF Logo Mail Archive

Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03

Andy Bierman <andy@yumaworks.com> Fri, 31 January 2014 20:53 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BC01A0456 for <netmod@ietfa.amsl.com>; Fri, 31 Jan 2014 12:53:27 -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 QbadlP6e84Cw for <netmod@ietfa.amsl.com>; Fri, 31 Jan 2014 12:53:25 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id A17151A0451 for <netmod@ietf.org>; Fri, 31 Jan 2014 12:53:25 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j5so7037056qaq.34 for <netmod@ietf.org>; Fri, 31 Jan 2014 12:53:21 -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=cphHA0qyOYxTV9O5MFIQovEivCIAob4QRCpEGXRyRIk=; b=cIjiJQctCqjy1EJJx/+c6VNwA4aGhw876bzESrzeLAyq8XmCcp6nJQyBJo28s1HK9g JGTeJU18+o25AIxd13yBjYk5q2fS8sXibawjXaTsJrdWr7DMTyB/VMzWyQx9hlwa0iMs Ql4oNiOBH4DoNGsMF9IJ4v6+hGwaNfPuvxVyxrt3u/+hEx1IEFYdlXJWx878U/kzXLQo Xb/DwivvCF4/m9BH0oVi00/DlXXuy9IB5fan/qo3NlXuV65A4N7mswnbmMSGPP3oqfwE ILfX3wABW4f6zBYCgt2+67msNlPf3CO650PxTiKQcJxVMBU8MKpL6A3npgC3BlHWhKYW T/2A==
X-Gm-Message-State: ALoCoQmCLXbuCDdEcE1Pjw3Qjwodwje7pKF0n2gJWxDme907o2J+aO4QmRpEc9Hth8YocN0FuDvn
MIME-Version: 1.0
X-Received: by 10.140.92.65 with SMTP id a59mr32955144qge.34.1391201601853; Fri, 31 Jan 2014 12:53:21 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Fri, 31 Jan 2014 12:53:21 -0800 (PST)
In-Reply-To: <20140131.214042.353989959.mbj@tail-f.com>
References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 12:53:21 -0800
Message-ID: <CABCOCHTOkaC863qQ=1hcyahLRUfrYL9xoUUfybnHkmCX3dV0hQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="001a113ab29e4a47e604f14a5db8"
Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 31 Jan 2014 20:53:28 -0000

On Fri, Jan 31, 2014 at 12:40 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
> > >
> > > I think you do have a valid point.  It is probably be better to have
> > > one fixed version of the enumeration standardized.  But the problem is
> > > how this module would be maintained.  Apparently the database changes
> > > too often for being maintained in RFCs.  And there also seems to be
> > > a political dimension to it that I don't think we are prepared to
> > > handle.  And if we simply publish an RFC with the current version of
> > > the names from the database, what does it mean that the
> > > IANA-maintained db differs?
> > >
> >
> > I completely fail to understand which value an RFC with an almost
> > immediately outdated list of TZ names has.
>
> I don't think it is "immediately outdated".  Locations are rarely added and
> removed.
>

3 a year may be rare but IMO that is too often for a standard YANG module.


>
> > I would then rather prefer
> > to code my manager to use my local list and be prepared that names can
> > be rejected.
>
> I expect this to work reasonably well in practice.  But the point is
> that you don't know if a value will be accepted or not.
>

You mean you don't know from analyzing the YANG module.
Code today must already use some other validation mechanism.
IMO they will still use some other validation mechanism.

Eventually (4 months or so) the YANG module will start rejecting
requests that are valid in the TZ database.  I agree with Juergen
about not seeing the value in this sort of YANG module.
I am not buying that this a feature instead of a bug (i.e., declare that
the YANG module is a new standard, not related to the TZ database)




>
>
> /martin
>


Andy


>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

v2.23.0 | Report a Bug | By Email