Skip to main content

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 revision 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
I-D 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 A. Salowey (diff)
Opsdir Last Call review of -08 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Request Last Call review on draft-ietf-tzdist-service by Ops Directorate Assigned
Reviewed revision 08 (document currently at 11)
Result Has nits
Completed 2015-06-11
review-ietf-tzdist-service-08-opsdir-lc-wu-2015-06-11-00

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