Time Zone Data Distribution Service
draft-ietf-tzdist-service-11
Yes
(Barry Leiba)
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Terry Manderson)
Note: This ballot was opened for revision 09 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -09)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2015-07-07 for -09)
Unknown
Thank you for the privacy considerations.
Spencer Dawkins Former IESG member
Yes
Yes
(for -09)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-07-08 for -09)
Unknown
Well-written spec. And some info about defeating traffic analysis, what a novelty!
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-07-06 for -09)
Unknown
A detail, really. "Discussion of this document has taken place on the tzdist working group mailing list <tzdist@ietf.org>." is this a new practice for WG document?
Brian Haberman Former IESG member
No Objection
No Objection
(for -09)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-07-08 for -09)
Unknown
Qin Wu performed the opsdir review it looks like change have been incorporated into -10
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-07-08 for -09)
Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2015-07-09 for -09)
Unknown
Thank you for the elaborated security and privacy considerations!
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-07-08 for -09)
Unknown
- 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!
Terry Manderson Former IESG member
No Objection
No Objection
(for -09)
Unknown