Subject: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 02 Dec 2019 08:26:42 -0800

Mirja Kühlewind 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:
----------------------------------------------------------------------

Two comments:

1) It seems to me that this sentence in section 7 should/could actually be
phrased as a normative requirement in this document: "it is not necessary that
every client request needs to
   trigger a new lookup flow in the presence of stale data, but rather
   that a good-faith effort has been recently made to refresh the stale
   data before it is delivered to any client."
Maybe worth considering...

2) I find the Implementation Status section (8) actually quite interesting for
this document and maybe it should be considered to keep it in the document for
final publication.

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 2 Dec 2019 17:42:23 -0500

Thank you very much for your review, Mirja.

> 1) It seems to me that this sentence in section 7 should/could
> actually be phrased as a normative requirement in this document: "it
> is not necessary that every client request needs to trigger a new
> lookup flow in the presence of stale data, [...]"

I agree.  We had a lot of back-and-forth in the working group about
normative language in this document, and but for the Standards Action
section.  I'm personally in support of more of it, but ended up having
to strip out existing instances of normative language based on working
group consensus.

> 2) I find the Implementation Status section (8) actually quite
> interesting for this document and maybe it should be considered to
> keep it in the document for final publication.

I personally am in favor of this, not just for this document but for
all RFCs.   RFC 6982 recommends that the section be removed, but I'd
be happy to help evolve that recommendation.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 3 Dec 2019 19:28:41 +0100

Hi Dave,

Just on this point:

> On 2. Dec 2019, at 23:42, Dave Lawrence <[email-masked]> wrote:
> 

RFC6982 recommends this because usually it's more important to have this information during the life-time of a draft (to understand the maturity of the protocol) but then it might quickly get out-dated after publication. However, we had also drafts were we retained the section for final publication because e.g. the whole draft was based on one specific implementation. I think that is also the case here and there is nothing in RFC6982 that permits keeping this information in the draft (if it seen as still useful in future).

Mirja

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 3 Dec 2019 13:34:47 -0500

Dave Lawrence writes:
> We had a lot of back-and-forth in the working group about
> section.

Huh, I clearly had a slipping brain clutch in the middle of that
sentence when it came to the final phrase.  I think I had intended to
finish the sentence something like "... determined it was best to not
use normative keywords."  Apologies for my failure to proofread before
sending.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Dec 2019 15:22:20 -0500

> RFC6982 recommends this because usually it's more important to have this information during the life-time of a draft (to understand the maturity of the protocol) but then it might quickly get out-d…

Note: Author hat only.

I'm not 100% sure, but I suspect you meant: "I think that is also the
case here and there is nothing in RFC6982 that **prevents** keeping
this ..."?
I'm personally in favor of keeping the information - even if it ends
up out of date, it still seems useful to me.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf