Barry, Thanks for the detailed review. The editorial comments and security considerations comment will be addressed in a new draft I will be pushing.
On Wed, Sep 11, 2019 at 12:06 PM Barry Leiba <barryle...@computer.org> wrote: > > 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. DONE > > — 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? DONE > > — 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. DONE > > 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 DONE > > 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….” DONE > > — 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 Addressing along with Stephane's response. > > — Section 5 — > > “implementation dependent” needs a hyphen: “implementation-dependent” DONE > > — 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.) DONE > > existing cache state. Some authoritative servers operators have said > > Either “authoritative server operators” or “authoritative servers’ > operators”; I think the former. DONE > > 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. DONE > > — 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? Added wording with suggested text from Stephane. -Puneet > > -- > Barry _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
