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

From: Russ Housley <[email-masked]>
Date: Fri, 5 Jun 2015 16:09:26 -0400

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.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 7 Jun 2015 23:01:22 +0300

Thank you for this Russ. I think these are good questions and comments.
Authors, any thoughts?

Jari

---

From: Eliot Lear <[email-masked]>
Date: Mon, 08 Jun 2015 07:52:53 +0200

Hi Russ and thanks for the review.

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

> 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.

> 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.

> the IESG to be the change controller?  This provides better alignment

If that is the norm, then yes.

Eliot

---

From: Daniel Migault <[email-masked]>
Date: Mon, 8 Jun 2015 13:40:37 +0000

Hi Russ,

Thank you for the comments, these will be addressed with the necessary clarifications shortly.
BR,
Daniel

From: Cyrus Daboo [mailto:[email-masked]]
Sent: Sunday, June 07, 2015 8:26 PM
To: Daniel Migault
Cc: Eliot Lear
Subject: Re: Gen-ART Review of draft-ietf-tzdist-service-08

I have time set aside Monday morning to work on that.

--
Cyrus Daboo
(Tapped out on my iPad)

On Jun 7, 2015, at 2:36 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi Cyrus,
Can you confirm you have received Russ' comments, and please address them. I think it would be good to have a new version this week. BTW it looks we are getting closer and closer to the finish state.
BR,
Daniel.

---------- Forwarded message ----------
From: Russ Housley <[email-masked]<mailto:[email-masked]>>
Date: Fri, Jun 5, 2015 at 4:09 PM
Subject: Gen-ART Review of draft-ietf-tzdist-service-08
To: [email-masked]<mailto:[email-masked]>
Cc: IETF <[email-masked]<mailto:[email-masked]>>, IETF Gen-ART <[email-masked]<mailto:[email-masked]>>

Summary: Almost Ready

Major Concerns:

Minor Concerns:

Other Comments:

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 08 Jun 2015 11:12:23 -0400

Hi Russ,
Thanks for your review. My comments are in line below. I have updated my 
working copy with the changes listed below, but I will hold off posting the 
update until the IETF last call finishes in about 5 days.

> many negative ones that the offset is les than zero?  Please clarify.

The proposed format covers both addition and removal of leap seconds. In 
the case of an addition of a leap second, the "utc-offset" value in the 
JSON response will increment by one (as shown in the example in Section 
5.6.1). In the case of a removal, the "utc-offset" would decrement by one. 
For example, let's assume a fictitious negative leap second at the end of 
this year, this is what the 5.6.1 example response would look like (note 
how the "utc-offset" value is reduced from 36 to 35:

{
  "expires": "2016-06-28",
  "publisher": "Example.com",
  "version": "2015d",
  "leapseconds": [
    {
      "utc-offset": 10,
      "onset": "1972-01-01",
    },
    {
      "utc-offset": 11,
      "onset": "1972-07-01",
    },
    ...
    {
      "utc-offset": 35,
      "onset": "2012-07-01",
    },
    {
      "utc-offset": 36,
      "onset": "2015-07-01",
    },
    {
      "utc-offset": 35,
      "onset": "2016-01-01",
    }
  ]
}

I will add the following sentence to the end of the "Response:" text in 
Section 5.6 to help clarify this:

    When a leap second is added, the "utc-offset" value will be incremented
    by one, when a leap second is removed, the "utc-offset" value will be
    decremented by one.

I also spotted that a leap second is due to be added at the end of this 
month, so I adjusted the example in 5.6.1 to include that.

> specify a "context path".'  I think it would be better to reword this

Fixed.

> when the IESG makes further organizational changes?

Eliot suggested referencing RFC 5226, but I see that there is an update to 
that (draft-leiba-cotton-iana-5226bis-11) that is currently in IESG review, 
and it seems appropriate to reference the update (and update the existing 
5226 references to that as well). It looks like the right part to point to 
is Section 10 
(<https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11#section-10>). 
I will make that change.

> the IESG to be the change controller?  This provides better alignment

That seems appropriate based on what I read in 5226bis.

> needs to go here.  If there is nothing to add, then say "None."

Fixed.

> need to spin a new version, then you might address that too.

I think that is an artifact of the xml2rfc tool. I am using the latest 
version of that and what I think are the normal defaults for the <?rfc ...> 
directives. I would rather not try and "manually" adjust the pagination as 
that will need to be tweaked for each update and will likely have to be 
removed by the RFC editor when they get to process it.

> There is an extra "only", please drop the first one.

Fixed.

> the approach is described in the next section, or even give the section

Fixed.

> three ways: RFCXXXX, This RFC, and This Draft.  Please pick one.

Fixed.

-- 
Cyrus Daboo