Last Call Review of draft-ietf-tzdist-service-08
review-ietf-tzdist-service-08-opsdir-lc-wu-2015-06-11-00

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

Review
review-ietf-tzdist-service-08-opsdir-lc-wu-2015-06-11






Hi,




 




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?


“

template-URI

”

 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

’

t
 TXT keys defined in the DNS protocol?




Line 2183:




Is


“

timezones

”

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


‘

timezones

’

 is plura of 


‘

timezone

’

.




Line 2263:

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




 




-Qin