Time Zone Data Distribution Service
draft-ietf-tzdist-service-11

[Ballot comment]
I support Stephen's comments and do not have any additional ones to add.  Thanks for your work on this draft and the security & privacy considerations.

[Ballot comment]

- 62 pages! urgh;-) But it's actually a pretty good spec, just
be nice if it were shorter.

- 4.2.1.2 - I don't get why HTTP authentication (401 etc) is
being used here. Is it that you want personalisation but you're
hacking that via HTTP authentication? I'd argue that not trying
for that via the TXT RR scheme would be better, that is, to say
that you don't get personalisation when you use a TXT RR to get
the path. Or just say the server can try set a cookie if it
wants personalisation. I can't see that clients here will
sensibly handle HTTP authentication in any case (well, not
unless you adopt something like RFC7486:-) - for example, how
would a HTTP UA pick a username here? (The same comment applies
to all HTTP authentication uses in the draft.)

- 4.2.1.3 - maybe useful to point forward to section 8 here
and/or say that you can't go from TLS to port 80 via the
.well_known 3xx.

- 4.2.2.1 - it'd have been nice to indicate the amount of data
that'd be downloaded here just so's some developer doesn't make
a bad assumption about when it's ok to do this.

- section 8, 2ndary-primary MUST use TLS - thanks! And for the
SHOULD use for client-server.

- section 9: thanks!

[Ballot comment]
A detail, really.

  "Discussion of this document has taken place on the tzdist working
  group mailing list ."

is this a new practice for WG document?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tzdist-service-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has some questions about some of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

First, a new top level registry will be created at the IANA Matrix (http://www.iana.org/protocol).
This new top level registry will be called "Time Zone Distribution Service (TZDIST) Parameters"
and will have a reference of [ RFC-to-be ].

Second, a new registry will be created called TZDIST Service Actions and located in the top level regirsty created in step one above. The reference for this registry will be set to [ RFC-to-be ]. The registry will be maintained via Specification Required as defined in RFC 5226. There are initial registrations in the new registry as follows:

+---------------+----------+-----------------------------+
| Action Name | Status | Reference |
+---------------+----------+-----------------------------+
| capabilities | Current | [ RFC-to-be ], Section 5.1 |
| list | Current | [ RFC-to-be ], Section 5.2 |
| get | Current | [ RFC-to-be ], Section 5.3 |
| expand | Current | [ RFC-to-be ], Section 5.4 |
| find | Current | [ RFC-to-be ], Section 5.5 |
| leapseconds | Current | [ RFC-to-be ], Section 5.6 |
+---------------+----------+-----------------------------+

QUESTION: The above table does not contain the inputs defined in section 10.1.2.
of this draft.  We also do not see "Status" as one of the inputs in section 10.1.2 for
"Registration Template for Actions".  Is it correct that "Description", "Parameters",
etc. do not need to be listed in the Actions registry?

Third, in the Well-Known URI registry located in:

http://www.iana.org/assignments/well-known-uris/

a new URI is to be registered as follows:

URI suffix: timezone
Change controller: IETF.
Specification document(s): [ RFC-to-be ]
Related information:

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, the authors request two service name assignments, for TCP only for timezone and timezones.
The authors can submit a template for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1:

IANA MAY accept early assignment [RFC4020] requests (known as "early allocation" therein) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC.

Fifth, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers in the Uniform Resource Name (URN) Namespace for IETF Use registry located at:

http://www.iana.org/assignments/params/

a new sub-namespace will be registered as follows:

Registered Parameter Identifier: tzdist
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-registration ]

QUESTION: Is the repository "Time Distribution Service protocol elements registry"
in section 10.4 of this draft created in step two above?  The word "Zone" is missing
from the name.  Further the name does not match those names in section 10.1,
"Time Zone Distribution Service (TZDIST) Parameters" and "TZDIST Service Actions". 


Sixth, in the Properties subregistry of the iCalendar Element Registries located at:

http://www.iana.org/assignments/icalendar/

two new properties will be registered as follows:

Property: TZUNTIL
Status: Current
Reference: [ RFC-to-be ], Section 7.1

Property: TZID-ALIAS-OF
Status: Current
Reference: [ RFC-to-be ], Section 7.2

These are also registrations in an Expert Review or Specification Required (see RFC 5226) registry, and IANA will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these six actions are te only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Time Zone Data Distribution Service) to Proposed Standard


The IESG has received a request from the Time Zone Data Distribution
Service WG (tzdist) to consider the following document:
- 'Time Zone Data Distribution Service'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a time zone data distribution service that
  allows reliable, secure and fast delivery of time zone data and leap
  second rules to client systems such as calendaring and scheduling
  applications or operating systems.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document is "Time Zone Data Distribution Service" [1] from M. Douglass and C. Daboo. The Working Group is TZDIST. The document shepherd is Daniel Migault. The responsible Area Director is Barry Leiba.

This document defines the protocol for time zone and leap second distribution.

2. Review and Consensus


a) Addressed Issues

In my opinion, all issues have been addressed, and there are no remaining open issues. Issues have been tracked in the data tracker, and all issues have been closed. The WG has been notified of the last version of the draft no issues have been raised so far.

Issues have been methodologically tracked and addressed. The individual draft came through 11 revisions and once adopted as WG document, the WG draft came through 7 additional revisions. They were among 22 open issues. All these issues have reached the WG consensus on the mailing list. In addition, the document was also approved on the saag, app-discuss, int-area, ops-area and ietf-privacy Mailing lists.

b) Strong consensus

In my opinion, I believe a strong consensus has been reached, and the last version results in global agreement from the WG as well as from the person raising the issue. As far as I know none believes the current version does not address one issue it has raised.

Consensus was reached as we spent a significant amount of time to expose and address the different issues. The WG was pretty much active, with around 80 discussion threads and 15 active participants. There were no face to face meeting during IETF regular meetings, but two phone conference meetings have been set on 2014/10/24 and 2014/12/18.

As a result to the numerous addressed issues with a strong consensus, the initial proposal has significantly changed from its initial version. Among the changes are 1) leap seconds, 2) redesign of the API, 3) historical data management has been considered, 4) security and privacy both in design and considerations section.


3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other points

I-D nits shows a downref: Normative reference to an Informational RFC: RFC 2818.  This is a very common reference and is already in the downref registry.

[1] https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/
[2] http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
[3] http://datatracker.ietf.org/doc/rfc2818/referencedby/