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

[Ladislav Lhotka <[e-mail]>]

On 31 Jan 2014, at 21:50, Juergen Schoenwaelder <[e-mail]> wrote:

> On Fri, Jan 31, 2014 at 09:40:42PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder <[e-mail]> 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.
> 
> The numbers I recall indicate a certain chance it comes out of the
> whole process already outdated. But even if it takes a year, the value
> is rather questionable.

From the network management point of view, it is important to be able to set the behaviour of the system clock properly. I would consider the module to be outdated only if it makes this impossible, and then it should be updated.

> 
>>> 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.
> 
> So what? I believe we will see other leaf where you can't predict for
> 100% that the value will be accepted. If we continue to strive for a
> perfect world, we will never ever achieve anything. I really doubt
> setting the timezone name is the biggest interoperability problem to
> solve.

It certainly isn’t, but we now have the enumeration and the proposal is to dump it for reasons that are not clear to me. We can have strings everywhere and forget about types.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C