On Thu, Jul 4, 2019 at 1:08 PM Warren Kumari <war...@kumari.net> wrote:
>
> On Thu, Jul 4, 2019 at 12:22 PM Dave Lawrence <t...@dd.org> wrote:
> >
> > 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.
> >
> > > Could be:
> > >       Values SHOULD
> > >       be capped to 604,800 seconds, and implementations SHOULD allow
> > >       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?
>
> I see benefit in doing so, and no harm, so LTGM. Will integrate.

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

>
> >
> > > 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.
> >
> > This one looks useful, suggesting a reasonable cap on the order of
> > minutes rather than much longer.  I'm happy to make the change.
>
> Thank you. If you don't get to it, I will.

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


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

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

>
> W
>
>
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > 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



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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to