Re: [Tzdist] AD review of draft-ietf-tzdist-service-07 - Sections 3 - 4

[Barry Leiba <[e-mail]>]

> Note: one area that needs more WG discussion here is the suggestion that
> there be a push mechanism for primary servers to notify secondary servers of
> changes, rather than require secondaries to poll once an hour.

I'm happy to see such a discussion; I'm also happy to accept Ken's
suggestion that it'd be OK to see, first, if it's a problem in
practice, and add an extension later if it is.  The only problem with
that is if we think that once deployed, servers aren't likely to be
changed to add such extensions, in which case it'd be better to have
it in the base.  Y'all's judgment works for me here.

> Inclusive start/exclusive end, is consistent with the DTSTART/DTEND property
> behavior used in iCalendar VEVENTs, and I felt it was better to maintain
> that consistency.

OK.  As I said, it's fine either way and I'm only curious.  I sort of
think of these as different things: DTEND is how it is because of how
we think about meetings: a meeting from 1 to 2 means the next meeting
can start at 2.  (Actually, a meeting from 1 to 2 probably ends
between 2:05 and 2:10, when those waiting for the 2:00 meeting
irritatedly throw us out of the conference room, but never mind.)
Whereas this is a protocol precision thing.  Anyway, happy to leave it
as it is.

>> -- Section 4.1.4 --
>> I find the lengthy discussion confusing, as it doesn't seem to get to
>> the point(s) it's making directly.  As I understand it, they key
>> points are these:
...
> A fair bit of work did go into that section, but a more "procedural"
> description might be clearer. I'll see what I can do and others can review
> it.

Thanks; please do what you can to keep it organised.

Polling frequency:
I agree that using heuristics to guess how often to poll based on how
often a particular TZ was updated in the past... is not a particular
good or robust mechanism.

I also see that the polling will mostly be fairly lightweight:
discovery will mostly be cached, the "list" will mostly be empty, OK.

>> *** I do find the combination of mechanisms interesting, though: I
>> MUST do an extra query for a TXT RR, which might or might not be
>> there.  If it's not there, I've wasted a query, and then I use an HTTP
>> request to .well-known, which I *know* will always work.  Clearly, the
>> query for TXT RR is lighter weight.  But if RTT is my concern...
>
> TXT RR was added in RFC6764 after quite some debate with various IETF DNS
> experts who were quite insistent that it was not appropriate to rely on
> .well-known alone.

Really?  I should check the list archive on that, because I don't see
why.  It's an HTTP-based protocol, so it's perfectly sensible for its
anchor to come from .well-known.  Hm.

> As regards RTTs - typically the DNS server will send the matching TXT as
> additional data in the response to the SRV query, so the TXT will be in the
> clients cache avoiding the need for another DNS query.

My point -- for what it's worth: another hill I won't die on -- is
that there doesn't have to be a matching TXT record at all.  If there
isn't, is its absence in the SRV query definitive?  Or will the client
still have to do a TXT query to make sure, before falling back to
.well-known?

Barry