ietf
[Top] [All Lists]

Re: Gen-ART Review of draft-ietf-tzdist-service-08

2015-06-08 00:53:09
Hi Russ and thanks for the review.

Cyrus is going to answer you on these.  But I have three comments, below:

On 6/5/15 10:09 PM, Russ Housley wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-tzdist-service-08
Reviewer: Russ Housley
Review Date: 2015-06-05
IETF LC End Date: 2015-06-17
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

In section 5.6, it is not clear to me how to distinguish the addition
of a leap second from the removal of a leap second.  The UTC offset
from TAI in seconds is provided.  And, so far, we have never seen a
negative leap second.  Is the assumption that we will never see so
many negative ones that the offset is les than zero?  Please clarify.

Right.  We should allow for this.  A related point: if this ever
happens, however: never mind this protocol, things are likely to break
all over.



Minor Concerns:

Section 4.2.1.3 says: 'The "well-known" URI is always present on the
server, even when a TXT RR (Section 4.2.1.2) is used in the DNS to
specify a "context path".'  I think it would be better to reword this
as a MUST statement.

Section 10.1.1 says: "Decisions made by the designated expert can be
appealed to the IESG Applications Area Director, then to the IESG."
The IESG just merged the Applications Area and the RAI Area, creating
the ART Area.  Is there a way to word this that can avoid confusion
when the IESG makes further organizational changes?

You're right, and I should have caught this.  My suggestion is that the
text be amended to refer to Section 3 of RFC 5226.


Section 10.2 says: "Change controller:  IETF."  Would it be better for
the IESG to be the change controller?  This provides better alignment
with Section 10.3.

If that is the norm, then yes.

Eliot


Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>