Future time zone home

Eliot Lear lear at cisco.com
Tue Oct 26 08:28:15 UTC 2010


Thanks again for the review.  Once again, I will not advance this work
without support from this community.  If you want to see this document
advance, please comment on it.  Now please see below.

On 10/24/10 11:18 AM, SM wrote:
> At 06:11 21-10-10, Olson, Arthur David (NIH/NCI) [E] wrote:
>> In response to the need to find a new time zone home before I'm
>> eligible to retire in 2012, Eliot Lear and Paul Eggert have authored
>> the draft document "IANA Procedures for Maintaining the Timezone
>> Database" now available from the Internet Engineering Task Force
>> (IETF) web site:
> As the intended status of the document is BCP, I'll comment on it from
> that angle.  In Section 1:
>   "Those registries are coordinated by technical experts who are
>    designated by the Internet Engineering Steering Group (IESG)."
> For what it's worth, some of these registries might not fall under the

That is from RFC 5226.

> In Section 2:
>   'This list membership will be transitioned to the IETF mail server.
>    The TZ coordinator will continue to manage the list, in accordance
>    with rules of governance for non-WG mailing lists (including, for
>    example, the commonly used "Note Well" statement).'
> Will the contributions fall under "Note Well" rules?

Yes.  That is, people shouldn't expect to make any intellectual property
claims based on their contributions.

> In Section 4:
>   "From time to time it will be necessary to replace a TZ Coordinator.
>    This could occur for a number of reasons:"
> I suggest "appoint" instead of "replace".
>   "The IESG MUST use rough consensus of the TZ mailing
>    list as their primary guide to further action, when it exists."
> As the document is a BCP, these requirement could be changed in future.

True.  This is what we are saying today.

> In Section 5:
>   "No change shall be made to the license without consultation and rough
>    consensus of the community."
> The document uses "rough consensus" instead of consensus".  The
> barrier is lower for the former.  The above text mentioned
> "community".  Is that the TZ community?

In fact I think this text needs to be reworked.  I don't think we really
CAN or SHOULD change the license terms for something that is either (a)
already licensed by someone else or (b) in the public domain.  Again,
the intent is to maintain the status quo from this regard, but to allow
for some future additions that might require some sort of protection
(tho what I cannot actually fathom).  How about just dropping everything
after "license" and inserting ", should one exist"?

> In Section 6:
>   "It is the understanding of the IESG, ISOC, and IANA that the database
>    itself is public domain."
> I suggest replacing "IESG" with "IETF" as the IESG operates within the

added IETF (should we all agree).
>   "Should claims be made and substantiated against the database,
>    the IANA will act in accordance with all competent court orders."
> I suggest putting code distribution under the IETF so that the legal
> aspect falls under the IETF Trust.  

> The following sentence could then be removed:
>   "Should claims be made and substantiated against the database,
>    the IANA will act in accordance with all competent court orders."

I don't understand your intent.  I do not want to remove text here
without a suggested replacement.
> I suggest removing "further" from the following sentence:
>   "No further ownership claims will be made by IANA, the IETF Trust,
>    or ISOC on the database."

> In Section 7:
>   "The IANA will see that the role of TZ Coordinator is filled, based on
>    the procedures described above."
> According to Section 4, it is the IESG that does that.

Changed to:

The IANA will assist the IESG, as required, in filling of the TZ
Coordinator,, based on the procedures described above.

Read: let the IESG know if the TZ coordinator has resigned, grant
access, revoke access, as required.
> There is a MoU between IANA and the IETF for IETF protocols.  There
> has been various interpretations of that MoU.  An alternative to avoid
> non-technical concerns is to place the distribution of the database
> under the RFC Editor and explore having the material with a status
> similar to the Independent Submission Stream.  I am not suggesting a
> license change.  The following text is an adaption from RFC 4846:
>   To the extent that a TZ Contribution or any portion thereof is
>   protected by copyright and other rights of authorship, the
>   Contributor, and each named co-Contributor, and the organization
>   he or she represents or is sponsored by (if any) grant an
>   irrevocable, non-exclusive, royalty-free, world-wide right and
>   license to the IETF Trust and the IETF under all intellectual
>   property rights in the TZ Contribution in perpetuity, to copy,
>   publish, display, and distribute the TZ Contribution.
>   The Contributor, each named co-Contributor, and the organizations
>   represented above irrevocably and in perpetuity grant the rights
>   listed below to the Internet Community:
>   A.  to prepare or allow the preparation of translations of the
>       TZ database into languages other than English,
>   B    to prepare derivative works (other than translations)
>        that are based on or incorporate all or  part of the
>        TZ Contribution, or comment upon it.  The license to such
>        derivative works shall not grant the IETF Trust, the IETF,
>        or other party preparing a derivative work any more rights
>        than the license to the original TZ Contribution, and
>   C.   to reproduce any trademarks, service marks, or trade names
>        that are included in the TZ Contribution solely in
>        connection with the reproduction, distribution, or
>        publication of the TZ Contribution and derivative
>        works.

That sounds okay, but I would like to hear from others.  Is this
actually required, given the Note Well statement?

> At 09:09 21-10-10, Tony Finch wrote:
>> Apart from three files, the current tzcode distribution is public
>> domain.
>> There is no single BSD licence so this statement is ambiguous. In
>> fact the
>> licence on the three special files is more like a MIT licence.
> Yes.

Dealt with.


More information about the tz mailing list