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

[Cyrus Daboo <[e-mail]>]

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

--On July 8, 2015 at 11:17:35 AM -0700 Stephen Farrell 
<[e-mail]> wrote:

> - 62 pages! urgh;-) But it's actually a pretty good spec, just
> 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).

> - 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.)

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).



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

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

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

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.

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

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