Subject: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 03 Dec 2019 15:50:43 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-serve-stale-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-dnsop-serve-stale/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* I agree with Mirja, Section 8 is more informative than what is alluded to the
paragraph starting with “Several recursive resolvers …” in Section 3, and IMO
is worth keeping.  I struck me as odd to call out the operation practice of a
particular vendor (Akamai).  We might want to check if this reference is ok –
Ben?

* A few reference nits:
- Section 6.  Per the mention to DNS-OARC, please provide a citation.
- Section 6 and 9.  The text references “during discussions in the IETF”.  What
is that specifically – WG deliberation?

* Thanks for covering the attacker use cases of stale data in Section 10.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Dec 2019 16:39:26 -0800

To some extent the operational practices of operators equate to
implementation status, for those that develop/run their own
implementations.  So I wasn't particularly struck by the text in Section 8
-- I was more struck by the text in Section 3 that left the "some way"
rather vague, and had opened an internal discussion about it (as-yet
unresolved).  But Adam's proposal to drop the vendor name entirely is
likely to be satisfactory.

-Ben

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 5 Dec 2019 14:19:07 -0500

Thank you for the review, Roman.

Roman Danyliw via Datatracker writes:
> * I agree with Mirja, Section 8 is more informative than what is
> alluded to the paragraph starting with “Several recursive resolvers
> …” in Section 3, and IMO is worth keeping.

I've already updated the GitHub copy in response to Mirja's review to
drop the request for the RFC Editor to remove the section.

> I struck me as odd to call out the operation practice of a
> particular vendor (Akamai).  We might want to check if this
> reference is ok – Ben?

I had also removed this reference from Section 3.  It was important
background material when I first introduced the draft, before the
technique became more widely available, but I agree that Akamai
specifically need ongoing highlighting there.

> - Section 6.  Per the mention to DNS-OARC, please provide a citation.

This was my own personal research on DITL data, not published as a
special report.  How should I cite?

> - Section 6 and 9.  The text references “during discussions in the
> IETF”.  What is that specifically – WG deliberation?

Yes, in dnsop (mostly at the mic, as I recall).  It used to say dnsop
specifically (version -05) but a couple of people had stronger
feelings than I that the language there should use the more expansive
IETF umbrella.  Me personally, my only strong feeling on the matter is
that, though someone else has suggested that it just be excluded
entirely, I want to see it included as historically relevant because
we did spend time on the EDNS option issue only to have it ultimately
be decided that it wasn't wanted.