[DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

[Barry Leiba <[e-mail]>]

I am handling this document as responsible AD, as Warren is a
co-author and so must recuse himself.  I’m not sure how I missed the
publication request, but miss it I did, and thanks to Warren for
pinging me.

Thanks for a very well-written and clear document.  I have only some
minor editorial comments and a couple of questions, all of which can
be addressed along with any last-call comments that come along.  I’ll
request last call right after I send this message.

— Abstract —

   data can be kept in the cache beyond the TTL expiry, and also updates
   RFC 2181 by interpreting values with the high order bit set as being
   positive, rather than 0, and also suggests a cap of 7 days.

The chain of “and also”s feels awkward; I would remove the first one,
so “…TTL expiry, updates RFC 2181…”.  (I might remove the second
“also” as well, as “and suggests” is fine without it.)  This text is
also in the Introduction, so whatever change is made in the Abstract
should be made in the Introduction too.

— Introduction —

   This document proposes that the definition of the TTL be explicitly
   expanded to allow for expired data to be used in the exceptional

This isn’t wrong, but for a standards-track document we would usually
say, “This document expands the definition of the TTL to explicitly
allow for…”.  It will be published as a Proposed Standard, so I guess
the “proposed” part can just come from there, yes?

— Section 3 —

   This is again not [RFC2119]-normative
   language, but does convey the natural language connotation that data

In my ongoing effort to disabuse people of the idea that language has
to have BCP 14 key words in order to be normative, I would prefer that
this say, “This wording again does not contain BCP 14 key words,
but…,” because I do believe the quoted text is normative.

   Several recursive resolver operators currently use stale data for
   answers in some way, including Akamai.

Misplaced modifier:
NEW
   Several recursive resolver operators, including Akamai, currently
   use stale data for answers in some way.
END

   collective operational experience is that it provides significant
   benefit with minimal downside.

The antecedent to “it” is unclear (it could refer to Apple MacOS or
the Happy Eyeballs algorithm or mDNSResponder).  Better to say, “…is
that using stale data can provide….”

— Section 4 —

      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired.

I wonder if it makes sense to be more explicit here that one isn’t
meant to keep using expired data forever, but is expected to keep
trying to refresh it.  So, maybe?:

NEW
      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired until an authoritative refresh is
      successful.
END

— Section 5 —

“implementation dependent” needs a hyphen: “implementation-dependent”

— Section 6 —

   fact that no other RCODEs which a resolver normally encounters makes
   any assertions regarding the name in the question

Number agreement: “make any assertions”  (I would also change “which”
to “that”, but I’m picky about using “that” to introduce restrictive
clauses.)

   existing cache state.  Some authoritative servers operators have said

Either “authoritative server operators” or “authoritative servers’
operators”; I think the former.

   their servers are responding with errors like ServFail instead of
   giving true authoritative answers.  Implementers MAY decide to return
   stale answers in this situation.

It might be good for the last paragraph in Section 4, with the
“SHOULD”, to have a forward reference to this explanation.

— Section 10 —

Is another possible new security consideration that bad actors could
DDoS authoritative servers with the explicit intent of having stale
cached information used for longer, perhaps to extend the life of a
cache-poisoning attack or some such?

-- 
Barry