On Fri, Sep 12, 2025 at 5:19 AM Christian Elmerot <elme...@cloudflare.com> wrote:
> > On Thu, Sep 11, 2025 at 2:47 AM Shumon Huque <shu...@gmail.com> wrote: > >> On Wed, Sep 10, 2025 at 12:12 PM Rebecca VanRheenen < >> rvanrhee...@staff.rfc-editor.org> 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. > Ok, sold :) Olafur - do you have any comments on this point? Or if not, can you note your approval for publication? Thanks! Shumon.
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
