On Thu, Sep 11, 2025 at 2:47 AM Shumon Huque <[email protected]> wrote:
> On Wed, Sep 10, 2025 at 12:12 PM Rebecca VanRheenen < > [email protected]> wrote: > >> Hi Med and authors, >> >> Med - Thank you for reviewing these. We have noted your approval on the >> AUTH48 status page for this document (see >> https://www.rfc-editor.org/auth48/rfc9824). >> >> All - Note that we have not changed “SHOULD NOT” to “MUST NOT” per Med's >> note below. Please discuss and let us know how to proceed. >> >> >> 3) Section 3.5 (1st and 2nd paragraphs): change from “should not” >> >> to "SHOULD NOT” >> > >> > The use of normative language is justified here, so OK with both >> changes. >> > >> > One note though, the second "SHOULD NOT" does not have an exception >> called out: >> > >> > CURRENT: >> > A resolver SHOULD NOT forward these queries upstream or attempt >> iterative resolution >> > >> > Absent a valid exception, this smells more "MUST NOT". >> >> >> Once Med’s comment is resolved and we receive Olafur’s approval on the >> document, we can move this document forward in the publication process. > > > Ideally, I agree this should be a MUST. > > The softer SHOULD NOT language here was to take into account the > pre-existing base of DNS resolvers, some which today do not treat unknown > meta-types this way and do actually forward such queries upstream (although > most competent DNS resolver implementations do have the correct behavior). > My thinking was that publication of this document with a "MUST NOT" here > would immediately put those other implementations out of compliance with a > standards track document, so I was hesitant to do that. > > Christian/Olafur - what are your thoughts? > I agree that this should be a MUST. There is no enforcing function, nor would pre-existing resolvers etc, stop functioning in any new way if they keep breaking this new MUST. Making the language clear and unambiguous has in my view only upsides here. /Christian
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
