Hoffman <<My preference is that there are just two SHOULDs, both in the introduction: SHOULD NOT pollute the zone apex with TXT records, and SHOULD instead use underscore labels as described in the rest of the document. After that, couch every suggestion with reasoning, talk about how different use cases might cause you to do different things, and give more examples.>>
+1. Sent from Workspace ONE Boxer On Mar 7, 2025 16:03, Paul Hoffman <paul.hoff...@icann.org> wrote: Big thanks to the authors of draft-ietf-dnsop-domain-verification-techniques for the massive update in -07 to make it easier to follow. The document remains very important to help applications understand that domain control validation should not be "stuff TXT into the zone apex". Having said that, I would still like to see a major revision throughout the document to take it away from 2119-level SHOULDs and MUSTS for things that really should instead be "if your use case is $x, you should consider doing $y". The current wording makes it hard to implement some use cases, while later saying that those use cases are in fact valid. It makes demands in many places that are only best practices for a subset of the intended readers, and that do not affect interoperability. My preference is that there are just two SHOULDs, both in the introduction: SHOULD NOT pollute the zone apex with TXT records, and SHOULD instead use underscore labels as described in the rest of the document. After that, couch every suggestion with reasoning, talk about how different use cases might cause you to do different things, and give more examples. Many of the current SHOULDs and MUSTs are based on the use case of a certificate authority using ACME. That's a good use case, good enough where it should have its own section near the end (mentioned in the introduction) specifying how each of the options from throughout the document apply to that use case. I recognize that this will take a lot of writing work; I'm happy to assist with such revisions. I sincerely think that changing the tone of the document will cause a lot more adoption for non-CA use cases, and might also increase the adoption of best practices for the many CAs that have or are about to adopt ACME. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
