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

[Ladislav Lhotka <[e-mail]>]

On 31 Jan 2014, at 17:45, Martin Bjorklund <[e-mail]> wrote:

> Ladislav Lhotka <[e-mail]> wrote:
>> 
>> On 31 Jan 2014, at 16:02, Thomas Nadeau <[e-mail]> wrote:
>> 
>>> 
>>> 	I would like to call consensus on this matter. I've received %100
>>> 	supporting comments for the proposal from the WG with no one not liking
>>> 	the proposal. The only comments received were from Martin and
>> 
>> You must have missed my comments, so let me say I don’t like the proposal. I
>> think we are throwing out the baby with the bath water.
> 
> 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?

Paul Eggert suggested in his messages from 16 January that the political issues can be avoided by not claiming that the YANG enumeration is authoritative/canonical or that it always mirrors the current Olson database names.

I was trying to figure out what typical changes have been applied to the database recently but I don’t know how to get this information. I reckon a typical scenario might be that a new timezone is added, say "Pacific/Bora-Bora”. Until the YANG module gets updated, all NETCONF servers on Bora Bora will not allow this setting but the clients can continue to use “Pacific/Tahiti” as before - mostly not a big deal IMO.

I am convinced that Benoit’s proposal from

http://www.ietf.org/mail-archive/web/netmod/current/msg08983.html

is perfectly viable.

Lada

> 
> 
> /martin
> 
> 
> 
>> 
>> Lada
>> 
>>> Benoit with regard to enhancing the description around the timezone-name
>>> typedef.  Document editors, please take those two comments into account and
>>> make the changes necessary. You might want to propose the text on the list
>>> before publishing as it should be a fairly minor change, but just to make
>>> sure it covers the comments received.
>>> 
>>> 	--Tom
>>> 
>>> 
>>>> 
>>>> 	Netmod WG:
>>>> 
>>>> 	The working group chairs have considered the discussion concerning 
>>>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>>>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>>>> like to call consensus on the matter regarding that surfaced during
>>>> the IETF last call with regard to the the practicability of maintaining a 
>>>> YANG module with an enumeration of timezone names. We believe there is
>>>> consensus in the working group to move forward with the following 
>>>> resolution:
>>>> 
>>>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>>>> extended to introduce a new typedef for timezone names, e.g.
>>>> something that looks like:
>>>> 
>>>> typedef timezone-name {
>>>>  type string;
>>>>  description
>>>>   "A timezone name as used by the Time Zone Database, sometimes
>>>>    referred to as the 'Olson Database'.";
>>>>  reference
>>>>   "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>>> }
>>>> 
>>>> The timezone-location leaf will be changed to use this type,
>>>> the import of iana-timezones will be removed and the references
>>>> to I-D.ietf-netmod-iana-timezones will be removed.
>>>> 
>>>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>>>> back and work on this draft will stop.  The I-D is declared dead.
>>>> 
>>>> - Since there is nothing to do for IANA, there will be no IANA request 
>>>> needed in this regard for draft-ietf-netmod-system-mgmt-11. 
>>>> 
>>>> 	We note that further alternatives can be added to the timezone
>>>> choice in the future should the two mechanisms currently in place
>>>> turn out to be insufficient in practice.
>>>> 
>>>> 	We would like to give the WG sufficient time to raise any additional
>>>> 	concerns or
>>>> issues with regard to this issue and our path for resolving the issue at
>>>> hand, and so we
>>>> will accept comments/discussion on this matter until 8AM EDT on Tuesday,
>>>> January 28, 2014.
>>>> As Juergen has been closely involved with the matter, I will adjudicate any
>>>> issues
>>>> arising from this comment period.
>>>> 
>>>> 	Thanks,
>>>> 
>>>> 	Tom
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

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