Last Call Review of draft-ietf-tzdist-service-08

Request Review of draft-ietf-tzdist-service
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-06-17
Requested 2015-06-08
Authors Michael Douglass, Cyrus Daboo
Draft last updated 2015-06-11
Completed reviews Genart Last Call review of -08 by Russ Housley (diff)
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)
Assignment Reviewer Qin Wu 
State Completed
Review review-ietf-tzdist-service-08-opsdir-lc-wu-2015-06-11
Reviewed rev. 08 (document currently at 11)
Review result Has Nits
Review completed: 2015-06-11




I have reviewed draft-ietf-tzdist-service-08.txt as part

of the Operational directorate's ongoing effort to review all IETF

documents being processed by the IESG.  These comments were written

with the intent of improving the operational aspects of the IETF

drafts. Comments that are not addressed in last call may be included

in AD reviews during the IESG review.  Document editors and WG chairs

should treat these comments just like any other last call comments.


Short Summary

The document defines an application protocol to distribute a time zone data. I believe this document is ready to be published. 


Operational & management concerns:

Introduction said:


In the case of operating systems,

   often those changes only get propagated to client machines when there

   is an operating system update


How timezone data changes is propagated to client machines? Using manual configuration or CLI? How these timezone data change information
 impact on the system time management within client machine or device?

Besides this, I see no specific operational concern that this document raises.


Editorial(Note that I use datatracker idnits' line numbering in my comments.):

Line 308:

 s/ that use/that uses

Line 449:

Why Server Protocol? I think both Server and Client need to support Time Zone Data Distribution Service protocol, in addition, the client
 also need to support discovery protocol for Time Zone data Service Discovery.

Is section 4.1 focusing on server operation or behavior? But it looks both section 4.1 and section 4.2 describe client behavior.


Line 463 - Line 467:

Is the prefix "{/service-prefix,data-prefix}" referred to prefix template?

If yes, suggest

s/ the prefix "{/service-prefix,data-prefix}/ the prefix template "{/service-prefix,data-prefix}


Line 474:

Is template-URI URI template described in the 2nd paragraph of section 4.1?




 only appear once in the document, So if they are same, please make sure to use consistent terminology.


Line 682 - Line 685:

This document provides two ways for time zone service discovery, one is DNS based approach, the other is HTTP based approach,

I am wondering whether time zone discovery is part of time zone distribution service since time zone distribution protocol defined in this
 document is HTTP based protocol,

In other words, can time zone distribution protocol be used to perform service discovery? I think the answer is no.


Line 2196:

How path=<context path> is used in the timezone Service name registration? Isn


 TXT keys defined in the DNS protocol?

Line 2183:





 a good name for time zone service with TLS support? It looks




 is plura of 





Line 2263:

Is Normative reference to an Informational RFC: RFC
 2818 intentional?