Last Call Review of draft-ietf-tzdist-service-08
review-ietf-tzdist-service-08-genart-lc-housley-2015-06-05-00

Request Review of draft-ietf-tzdist-service
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-06-17
Requested 2015-06-04
Other Reviews Genart Telechat review of -09 by Russ Housley (diff)
Secdir Last Call review of -08 by Joseph Salowey (diff)
Opsdir Last Call review of -08 by Qin Wu (diff)
Review State Completed
Reviewer Russ Housley
Review review-ietf-tzdist-service-08-genart-lc-housley-2015-06-05
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg11768.html
Reviewed rev. 08 (document currently at 11)
Review result Almost Ready
Draft last updated 2015-06-05
Review closed: 2015-06-05

Review
review-ietf-tzdist-service-08-genart-lc-housley-2015-06-05

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.


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?

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.

Section 10.2 incudes a heading for "Related information".  Something
needs to go here.  If there is nothing to add, then say "None."


Other Comments:

The are places in the document where there are many blank lies at the
botton of the page.  I'm sure the RFC Editor can fix them, but if you
need to spin a new version, then you might address that too.

Section 4.1.4 says: "If a client only needs data for only one, ..."
There is an extra "only", please drop the first one.

Section 4.2.1.2 says: "... URI approach described next."  However, the
description is a few paragraphs away.  It might be better to say that
the approach is described in the next section, or even give the section
upcoming number.

In the IANA Considerations Section, this document is referenced at least
three ways: RFCXXXX, This RFC, and This Draft.  Please pick one.