Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?

[Mark Nottingham <[e-mail]>]

Sorry, I had a weekend.

I'm OK with the text that Patrick incorporated, it's not worth getting too far into the weeds here. But, to answer a question / explain where I'm coming from:

> On 9 May 2018, at 2:25 am, Patrick McManus <[e-mail]> wrote:
> 
>> > Is there another aspect to the question I'm missing?
>> 
>> It looks like you're using RFC2119 requirements to bring attention to important parts of the specification ("we really mean that this could trip you up"), rather than stating actual requirements for interoperability. These MUSTs aren't testable, and they may be too confining in some deployments. This stuff really is advice, of the "if it hurts, don't do that" sort -- not requirements.
> 
> I must be misunderstanding what you mean by not testable - the alignment of expiration information seems pretty observable. And there is an operational impact to terminal clients without caches (either DNS or HTTP) which simply want to lookup a record and use it having to retry to get non-expired info (and the rather large risk of them not trying and using old data instead).

I don't understand how the location of the cache has anything to do with this. If a client gets a stale response -- as I said, this is very possible today despite the language in the draft -- they need to be able to deal with it. If the client wants to act like that's not a possibility, they're going to have a bad time.

> So I guess you can argue that without 2119 language the DOH client and server can communicate, but without normative provisions constraining the server you can't interop well with the Internet.. seems 2119 in scope to me.

The style of requirements used doesn't tell consumers what to do when they're violated, and -- as we've seen many times -- implementers tend to read too much into them, e.g., refusing messages which violate them, even though no such thing is specified. 

In other words, specifying in terms of ideal requirements (e.g., "the message MUST look like foo") hurts interop. It's much more effective to specify requirements in terms of producer and consumer behaviours, and to use those requirements sparingly. 

E.g., in the previous text, it said:

"""
The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response.
"""

This is better stated as something like:

"""
The DNS API server MUST NOT generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

That said, another reason to avoid requirements here is that, as discussed, there might be future uses for stale responses, but now they'll be forbidden by something that doesn't really need to be a requirement, and so the document will have to be updated -- creating friction against these uses. This is why I prefer something like:

"""
The DNS API server should typically generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

The current text isn't bad, but the SHOULDs are unqualified, and IME SHOULDs like that just confuse people.

Cheers,

--
Mark Nottingham   https://www.mnot.net/