Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[Robert Edmonds <[e-mail]>]

tjw ietf wrote:
> August is over and my self-imposed holiday is over, so it's time to get
> busy again. We have this document marked as a candidate for adoption.
> 
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
> 
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> *If You have already stated your position for or against adoption, we are
> counting those so you do not need to repeat yourself. *
> 
> This call for adoption ends: 19 September 2017
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

Hi,

I support the adoption of this document.

Comments:

This document is marked as updating 1034 and 1035 but it's not clear
what text from those documents is being updated. E.g. compare to
"NXDOMAIN: There Really Is Nothing Underneath" (RFC 8020) which
explicitly documents its revisions in its Section 3.

I think the claim in the introduction, "Notably, the original DNS
specification does not say that data past its expiration cannot be used"
should either be justified further or removed. The "should again be
consulted" text from STD 13 could be read in isolation as permitting
serve stale, but it's the weakest text out of these three TTL
definitions given in STD 13:

RFC 1034 §3.6:

    "The TTL describes how long a RR can be cached before it should be
    discarded. […] The meaning of the TTL field is a time limit on how
    long an RR can be kept in a cache."

RFC 1035 §3.2.1:

    "a 32 bit […] integer that specifies the time interval that the
    resource record may be cached before the source of the information
    should again be consulted."

RFC 1035 §4.1.3:

    "a 32 bit […] integer that specifies the time interval (in seconds)
    that the resource record may be cached before it should be
    discarded."

That is, if "the original DNS specification does not say that data past
its expiration cannot be used" is true, then this document doesn't need
to update STD 13, and maybe it should only be an informational document.
But if it's not true (and I don't think it is, based on the other two
TTL definitions in STD 13), then a new TTL definition should be given
that permits the serve stale mechanism.

Also, just for fun, this text from RFC 882 exists (p.28 "Resolvers with
cache management") and is even stronger than the text in STD 13:

    "When a resolver caches a returned resource record it must also
    remember the TTL field.  The resolver must discard the record when
    the equivalent amount of time has passed."

-- 
Robert Edmonds