Subject: [Tzdist] Stephen Farrell's No Objection on draft-ietf-tzdist-service-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jul 2015 11:17:35 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tzdist-service-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/

----------------------------------------------------------------------
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!

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 14 Jul 2015 15:37:21 -0400

Hi Stephen,
Sorry, only now getting around to replying to this...

> be nice if it were shorter.

The days of 10 page specs are long gone! Examples, formal syntax, 
registration templates, all add to the overall size. Really the key 
descriptive text is only 20 pages long (Sections 1 - 4, & 8 & 9) and the 
reset are details relevant to someone actually doing an implementation 
(i.e., formal syntax).

> to all HTTP authentication uses in the draft.)

Sections 4.2.1.2 and 4.2.1.3 both state:

    To facilitate "context path's" that might differ from user to user,

I think "differing" context paths are very unlikely. The more likely case 
is already described in Section 8:

    Servers MAY require some form of authentication or authorization of
    clients (including secondary servers), as per [RFC7235], to restrict
    which clients are allowed to access their service, or provide better
    identification of problematic clients.

I would be OK with changing the 4.2.1.2 and 4.2.1.3 text to something like:

    As per Section 8, servers MAY require authentication when a client
    tries to access the ".well-known" URI (i.e., the server would return a
    401 status response to the unauthenticated request from the client,
    then return the redirect response after a successful authentication by
    the client).

> and/or say that you can't go from TLS to port 80 via the

OK, I can add text and a reference for that.

> a bad assumption about when it's ok to do this.

Well of course that ultimately depends on the source of the time zone data. 
My current implementation, which uses the IANA tz db, generates about 50KB 
of uncompressed JSON response. I can add a sentence:

    A typical "list" action response size is about 50 KB of "pretty
    printed" JSON data, for a service using the IANA time zone database
    [RFC6557], as of the time of publication of this specification.

> SHOULD use for client-server.

I should point out that Daniel Kahn Gillmor did a thorough security/privacy 
review resulting in a lot of changes to those sections. (And in pointing 
this out I see that I missed listing him in the Ack section so I will fix 
that.)

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 20:42:54 +0100

Hiya,

> Sorry, only now getting around to replying to this...

No problem. And all your responses/suggestions seems fine to
me,

Thanks,
S.

> I think "differing" context paths are very unlikely. The more likely
> case is already described in Section 8:
> 
> Well of course that ultimately depends on the source of the time zone
> data. My current implementation, which uses the IANA tz db, generates
> about 50KB of uncompressed JSON response. I can add a sentence:
> 
> I should point out that Daniel Kahn Gillmor did a thorough
> security/privacy review resulting in a lot of changes to those sections.
> (And in pointing this out I see that I missed listing him in the Ack
> section so I will fix that.)
>