Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

[Michael StJohns <[e-mail]>]

On 7/12/2022 9:54 AM, Tim Wicinski wrote:
>
> This starts a Call for Adoption for Negative Caching of DNS Resolution 
> Failures
>
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 26 July 2022
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
Hi -

I think this draft SHOULDN'T be adopted on a cost/benefit basis.  My 
main issue is that it's not really clear who the audience for this might 
be.   It's clearly not the developers.   I doubt it's the customers as 
any customer is going to have to follow the guidance laid down by their 
provider.  That leaves the providers as a possible target, but they've 
already implemented their solutions (as evidenced by the content of this 
document) and really aren't going to change things unless it saves or 
makes them money.   So I question putting WG (or reviewer) time in on 
this document.  Instead, see if ICANN might stand up a wiki page to 
memorialize this - at least that wiki might not be obsolete upon 
publication.

Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for 
oh so many reasons.  So that may also not be a correct approach.

If this does proceed, I'd revise it to not use the RFC 2119 constructs 
in section 4.  Basically, use lower case, and avoid the "its is 
RECOMMENDED" passive structure.  Most of these are targeted at people, 
not at implementations and people are not protocol elements.  Instead, 
explain why doing it the way being suggested makes sense and leave it 
for the operator to do what works for them.

Mike