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

["Stephen Farrell" <[e-mail]>]

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!