Gen-art review of draft-lear-iana-timezone-database-01

[Elwyn Davies]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-lear-iana-timezone-database-01.txt
Reviewer: Elwyn Davies
Review Date: 11 January 2010
IETF LC End Date: 11 January 2011
IESG Telechat date: (if known)

Summary:
This document is not quite ready for the IESG.  The appeals process (if
there is to be one) needs to clarified as it currently points indirectly
to a hole in RFC 5226. As explained below, I have a feeling that it
would be wise to avoid tying the processes in this document to the
Designated Expert processes in RFC 5226 despite the similarities.
Making it clear what does apply and what doesn't is probably more work
than doing it from scratch in this document, especially given the hole
in RFC 5226.

Major(ish) issue:
s4: 
> As RFC-5226 states, the IESG is not a
>normal avenue for appeals of specific decisions of the coordinator,
>but rather a last resort when a coordinator is thought not to be
>functioning in an appropriate way.

I think the draft should make it explicit that it is referring to the
'Designated Expert' sections in RFC 5226 here if it continues to
reference RFC 5226 - although there is a clear relationship with
Designated Experts, the differences between the selection process and
the operations of the TZ Coordinator and generic Deisgnated Experts may
mean that citing RFC 5226 might lead to legalistic disputes about which
set of rules applies.  Also, I am unable to find statements in RFC 5226
backing up the sentence above.  Regrettably, RFC 5226 appears
effectively to have a 'dsngling reference' in this area. Section 3.2,
para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses
'disputes and appeals in more detail'.  However s5.2 is titled 'Updating
Registrations' and says nothing about appeals and disputes.  Section 7
of RFC 5226 covers appeals of IANA decisions but says nothing specific
about appealing designated expert rulings.  I think this area may need a
little more work.  Overall, my inclination would be to make this a
standalone document that does not try to partially modify the RFC 5226
Designated Expert process and operations.  Appeals... >*sigh*<.  

Minor Issue:
s3, para 3: Is it intended that that the supporting info should also be
signed?  If so the order of the phrases should be reversed.


Nits/Editorial:
s3:  'tar files' is jargon. s/tar files/archive files/ maybe adding "in
the format used by the 'tar' program".

s4, last para: s/may/MAY/
s4, last para: 'OR MORE' - this isn't RFC 2119 language - is there any
real need for capitalization?

s5: The three instances of 'shall' ought to to be RFC 2119 terms:
s/No change shall be made to licenses, where they exist./Licenses, where
they exist SHALL NOT be changed./
s/IANA shall allow for the downloading of this reference code.  The
reference implementation shall be distributed/IANA SHALL allow for the
downloading of this reference code.  The reference implementation SHALL
be distributed.../

s7: Arguably the various 'will's and 'may' in the later part of the
section (from 'The IANA will provide' onwards) should be capitalised as
RFC 2119 requirements: s/will/SHALL/ (5 places) and s/may/MAY/.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-art review of draft-lear-iana-timezone-database-01

[SM]

Hi Elwyn,
At 09:10 12-01-11, Elwyn Davies wrote:

This document is not quite ready for the IESG.  The appeals process (if
there is to be one) needs to clarified as it currently points indirectly
to a hole in RFC 5226. As explained below, I have a feeling that it
would be wise to avoid tying the processes in this document to the
Designated Expert processes in RFC 5226 despite the similarities.
Making it clear what does apply and what doesn't is probably more work
than doing it from scratch in this document, especially given the hole
in RFC 5226.


[snip]


I think the draft should make it explicit that it is referring to the
'Designated Expert' sections in RFC 5226 here if it continues to
reference RFC 5226 - although there is a clear relationship with
Designated Experts, the differences between the selection process and
the operations of the TZ Coordinator and generic Deisgnated Experts may


Yes, there are significant differences.  According to RFC 5226:

  "The designated expert is responsible for initiating and coordinating
   the appropriate review of an assignment request."

It might be helpful to get some feedback from IANA and the IETF Trust 
on this draft before it is evaluated by the IESG.



mean that citing RFC 5226 might lead to legalistic disputes about which
set of rules applies.  Also, I am unable to find statements in RFC 5226
backing up the sentence above.  Regrettably, RFC 5226 appears
effectively to have a 'dsngling reference' in this area. Section 3.2,
para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses
'disputes and appeals in more detail'.  However s5.2 is titled 'Updating
Registrations' and says nothing about appeals and disputes.  Section 7
of RFC 5226 covers appeals of IANA decisions but says nothing specific
about appealing designated expert rulings.  I think this area may need a
little more work.  Overall, my inclination would be to make this a
standalone document that does not try to partially modify the RFC 5226
Designated Expert process and operations.  Appeals... >*sigh*<.


Section 7 of RFC 5226 states that:

  "Appeals of registration decisions made by IANA can be made using the
   normal IETF appeals process as described in Section 6.5 of
   [IETF-PROCESS]."

Section 4 of mentions that:

  "In keeping with [RFC5226], the IESG selects the TZ
   coordinator(s).  The IESG will use rough consensus of the TZ mailing
   list as their primary guide to further action, when it exists, and
   whatever other means they have at their disposal, when rough
   consensus cannot be found.  As RFC-5226 states, the IESG is not a
   normal avenue for appeals of specific decisions of the coordinator,
   but rather a last resort when a coordinator is thought not to be
   functioning in an appropriate way."

That could be rewritten as:

   The IESG selects the TZ coordinator(s).  The IESG will use the rough
   consensus of the TZ mailing list as their primary guide for any action,
   when it exists, and whatever other means they have at their disposal,
   when rough consensus cannot be found.

   The IESG is not an avenue for appeals of specific decisions of the
   coordinator, but rather a last resort when a coordinator is thought not
   to be functioning in an appropriate way.  An appeal can be made in such
   a case by using the normal IETF appeals process as described in Section
   6.5 of RFC 2606.

The following sentence in Section 1.1 might have to be removed then:

  "The TZ coordinatior is a Designated Expert, as defined in [RFC5226]"

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-art review of draft-lear-iana-timezone-database-01

[Eliot Lear]

Elwyn, SM,

Thank you for your reviews.  Here is my current thinking:

1.  There was probably some confusion in that we probably meant section
5.2 and not 5.3 in RFC 5226.  Nevertheless, I find RFC 5226 difficult to
apply here because of the way it is worded.  Specifically, it is
designed for assignment purposes and not for change purposes.  Hence,
I've removed most references to 5226.  To be clear, the TZ coordinator
should be given great deference, but that in limited circumstances
appeals to the IESG must be allowed (one could imagine a designated
expert who went crazy and took sides in a political fight, for instance).

2.  Clearly there is a need for criteria for updating the database. 
We're going to take a swing at that.

3.  The licensing terms listed in the current draft seem to satisfy
almost nobody.  Therefore they have to be redone.  I have asked for
opinions on this very subject from one or two knowledgeable people, and
hope to have a new proposal before the draft cut-off date.

4.  I've accepted your minor point and your nits.

Eliot

On 1/13/11 2:13 AM, SM wrote:
> Hi Elwyn,
> At 09:10 12-01-11, Elwyn Davies wrote:
>> This document is not quite ready for the IESG.  The appeals process (if
>> there is to be one) needs to clarified as it currently points indirectly
>> to a hole in RFC 5226. As explained below, I have a feeling that it
>> would be wise to avoid tying the processes in this document to the
>> Designated Expert processes in RFC 5226 despite the similarities.
>> Making it clear what does apply and what doesn't is probably more work
>> than doing it from scratch in this document, especially given the hole
>> in RFC 5226.
>
> [snip]
>
>> I think the draft should make it explicit that it is referring to the
>> 'Designated Expert' sections in RFC 5226 here if it continues to
>> reference RFC 5226 - although there is a clear relationship with
>> Designated Experts, the differences between the selection process and
>> the operations of the TZ Coordinator and generic Deisgnated Experts may
>
> Yes, there are significant differences.  According to RFC 5226:
>
>   "The designated expert is responsible for initiating and coordinating
>the appropriate review of an assignment request."
>
> It might be helpful to get some feedback from IANA and the IETF Trust
> on this draft before it is evaluated by the IESG.
>
>> mean that citing RFC 5226 might lead to legalistic disputes about which
>> set of rules applies.  Also, I am unable to find statements in RFC 5226
>> backing up the sentence above.  Regrettably, RFC 5226 appears
>> effectively to have a 'dsngling reference' in this area. Section 3.2,
>> para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses
>> 'disputes and appeals in more detail'.  However s5.2 is titled 'Updating
>> Registrations' and says nothing about appeals and disputes.  Section 7
>> of RFC 5226 covers appeals of IANA decisions but says nothing specific
>> about appealing designated expert rulings.  I think this area may need a
>> little more work.  Overall, my inclination would be to make this a
>> standalone document that does not try to partially modify the RFC 5226
>> Designated Expert process and operations.  Appeals... >*sigh*<.
>
> Section 7 of RFC 5226 states that:
>
>   "Appeals of registration decisions made by IANA can be made using the
>normal IETF appeals process as described in Section 6.5 of
>[IETF-PROCESS]."
>
> Section 4 of mentions that:
>
>   "In keeping with [RFC5226], the IESG selects the TZ
>coordinator(s).  The IESG will use rough consensus of the TZ mailing
>list as their primary guide to further action, when it exists, and
>whatever other means they have at their disposal, when rough
>consensus cannot be found.  As RFC-5226 states, the IESG is not a
>normal avenue for appeals of specific decisions of the coordinator,
>but rather a last resort when a coordinator is thought not to be
>functioning in an appropriate way."
>
> That could be rewritten as:
>
>The IESG selects the TZ coordinator(s).  The IESG will use the rough
>consensus of the TZ mailing list as their primary guide for any
> action,
>when it exists, and whatever other means they have at their disposal,
>when rough consensus cannot be found.
>
>The IESG is not an avenue for appeals of specific decisions of the
>coordinator, but rather a last resort when a coordinator is thought
> not
>to be functioning in an appropriate way.  An appeal can be made in
> such
>a case by using the normal IETF appeals process as described in
> Section
>6.5 of RFC 2606.
>
> The following sentence in Section 1.1 might have to be removed then:
>
>   "The TZ coordinatior is a Designated Expert, as defined in [RFC5226]"
>
> Regards,
> -sm
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf