Thank you Olafur! Rebecca - with these edits, I think we can move forward.
Parenthetically, on the NSEC3 section, Olafur - we can continue that discussion in a separate venue. But I'll make a quick comment in case you missed the mailing list discussion. Even the NSEC3 lovers were a bit surprised by the inclusion of Section 4. Originally, we had no intention of describing how this technique could be employed with NSEC3, but then a major DNS provider implemented it, so we decided we had to document how to do it (while still pointing out that there appears no compelling reason in favor of an NSEC3 implementation). Shumon. On Fri, Sep 12, 2025 at 11:31 AM Olafur Gudmundsson <o...@ogud.com> wrote: > 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> > 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
