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

[Stephen Farrell <[e-mail]>]

Hiya,

On 14/07/15 20:37, Cyrus Daboo wrote:
> Hi Stephen,
> Sorry, only now getting around to replying to this...

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

Thanks,
S.

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