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
DNSOP@ietf.org
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
