Subject: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2019 23:02:45 +0000

Greetings again. draft-ietf-dnsop-serve-stale has a few places where it suggest ranges for values, but these suggestions are vague. I propose that the suggestions be made stronger so that resolver implementers know what to do while giving operators choices.

Section 4:
      Values SHOULD
      be capped on the orders of days to weeks, with a recommended cap
      of 604,800 seconds.
Could be:
      Values SHOULD
      be capped to 604,800 seconds, and implementations SHOULD allow
      lower values to be configured by operators.

Section 4:
   When returning a response containing stale records, the recursive
   resolver MUST set the TTL of each expired record in the message to a
   value greater than 0, with 30 seconds RECOMMENDED.
Could be:
   When returning a response containing stale records, the recursive
   resolver MUST set the TTL of each expired record in the message to a
   value greater than 0, with 30 seconds RECOMMENDED. Implementations
   SHOULD allow values above 0, but SHOULD NOT allow values greater
   than 600 seconds.

Section 5:
   The maximum stale timer should be
   configurable, and defines the length of time after a record expires
   that it should be retained in the cache.  The suggested value is
   between 1 and 3 days.
Could be:
   The maximum stale timer should be
   configurable, and defines the length of time after a record expires
   that it should be retained in the cache.  The value SHOULD be
   one day, and SHOULD NOT be longer than 3 days.

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 4 Jul 2019 15:21:52 -0400

Paul Hoffman writes:
> Greetings again. draft-ietf-dnsop-serve-stale has a few places where
> it suggest ranges for values, but these suggestions are vague.

"Vague"?  They give hard numbers with the intended flexibility for the
considerations that might go into them.

>       lower values to be configured by operators.

Do we really have to suggest to implementers that this be
configurable, especially when all of the major packages already have
such a knob, afaik?

>    SHOULD allow values above 0, but SHOULD NOT allow values greater

This one looks useful, suggesting a reasonable cap on the order of
minutes rather than much longer.  I'm happy to make the change.

>    one day, and SHOULD NOT be longer than 3 days.

All 2119 normative language was removed from that section.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 4 Jul 2019 13:08:05 -0700

> configurable, especially when all of the major packages already have

I see benefit in doing so, and no harm, so LTGM. Will integrate.

> minutes rather than much longer.  I'm happy to make the change.

Thank you. If you don't get to it, I will.

> All 2119 normative language was removed from that section.

Indeed it was. WG, would you like us to revisit this?
Please clearly state if you'd like us to make the change to put back
2119 stuff here (it is trivial to do)

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 4 Jul 2019 20:37:15 -0700

> I see benefit in doing so, and no harm, so LTGM. Will integrate.

Done (in editor / github source), thank you.

> Thank you. If you don't get to it, I will.

Done (in editor / github source), and thank you.

> 2119 stuff here (it is trivial to do)

As we had removed the RFC2119 language from this section at the WG's
request, I'm not integrating this unless the WG expresses a clear
desire that we change it again.

Thank you for your review, and even more so for providing suggested text.

W