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

[Michael StJohns <[e-mail]>]

Disregard this - it was targeted for a different adoption call.

Thanks to Paul H for noticing.

Mike


On 7/12/2022 12:51 PM, Michael StJohns wrote:
> 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
>
>
>