I agree MUST is better in section 3.5 Upon rereading section 4 I think it is misleading but in a good way (to a NSEC3 hater like me) , so it can stay as it it. Background: there is a significant benefit to on-line signing in general for large/many zones as it makes it much cheaper and faster to keep servers “in-sync”. If we had on-line signing when we wrote RFC403x series there would be no need for the Opt-out bit.
I approve the document as is with the change in section 3.5 as noted above. Olafur > On Sep 12, 2025, at 08:49, Shumon Huque <shu...@gmail.com> wrote: > > On Fri, Sep 12, 2025 at 5:19 AM Christian Elmerot <elme...@cloudflare.com > <mailto:elme...@cloudflare.com>> wrote: >> >> On Thu, Sep 11, 2025 at 2:47 AM Shumon Huque <shu...@gmail.com >> <mailto:shu...@gmail.com>> wrote: >>> On Wed, Sep 10, 2025 at 12:12 PM Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org >>> <mailto: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
