Hi Med, As AD, please review the following changes made during AUTH48 and let us know if you approve. These changes are best viewed in these diff files:
https://www.rfc-editor.org/authors/rfc9824-auth48diff.html https://www.rfc-editor.org/authors/rfc9824-auth48rfcdiff.html (side by side) 1) Section 2 (penultimate paragraph): change from “required” to “mandated" 2) Sections 3.1 and 3.4: change from “3600” to “300” 3) Section 3.5 (1st and 2nd paragraphs): change from “should not” to "SHOULD NOT” 4) Section 4 (4th paragraph): change from “should” to “SHOULD" 5) Section 7.1: change from “must be clear” to “not be set” in the note Thank you, Rebecca VanRheenen RFC Production Center > On Sep 8, 2025, at 2:12 PM, Rebecca VanRheenen > <[email protected]> wrote: > > Hi Olafur and Shumon, > > Thank you for your replies and for resolving this final issue. We’ve updated > the note in Section 7.1 accordingly. > > Olafur, please let us know if you now approve the document in its current > form. The other authors have already sent their approvals (see > https://www.rfc-editor.org/auth48/rfc9824). > > In a separate email, I will ask the AD to review and approve the changes that > are “above editorial” (e.g., changes to values and 2119 key words). > > Once we receive approval from Olafur and the AD, we can move this document > forward in the publication process. We are getting close! > > The most recent files are available here (please make sure to refresh): > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9824.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9824.txt > https://www.rfc-editor.org/authors/rfc9824.pdf > https://www.rfc-editor.org/authors/rfc9824.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9824-auth48diff.html > https://www.rfc-editor.org/authors/rfc9824-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9824-diff.html > https://www.rfc-editor.org/authors/rfc9824-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9824-alt-diff.html (diff showing > changes where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9824 > > Thank you, > > Rebecca VanRheenen > RFC Production Center > > > >> On Sep 8, 2025, at 1:05 PM, Shumon Huque <[email protected]> wrote: >> >> Rebecca, >> >> So, let's go with "are not set" then for the text in this paragraph. >> >> For the other upper-case RFC2119 changes Olafur is suggesting, I believe we >> were waiting for you to get AD sign-off (from Med?). Is that already in >> progress? >> >> Shumon. >> >> On Mon, Sep 8, 2025 at 3:43 PM Olafur Gudmundsson <[email protected]> wrote: >> >> Here is what I said on August 21’th >> on the topic of Upper and lower case 2119 words >> >> The text originates in a pre-RFC2119 RFC. >> In my experience with industry people many of them do not grasp the >> difference between MUST and must >> in an RFC they have been handed to implement, thus they treat them as the >> same. >> For that reason I have tried to minimize any use of lower case 2119 words in >> drafts. >> >> Thus I prefer my proposed text “are not set” >> If the OLD text is kept then “MUST be clear” is the change >> >> Olafur >> >> . >>> >>> >>> On Sep 5, 2025, at 14:57, Rebecca VanRheenen >>> <[email protected]> wrote: >>> >>> Hi Olafur, >>> >>> This is a friendly reminder that we are waiting for your input on the last >>> open question (see details below) as well as your approval of the document. >>> >>> You proposed this change (see full sentence below for context if needed): >>> >>>> Section 7.1 >>>> OLD: >>>> insists that pseudo-types must be clear >>>> NEW: >>>> insists that pseudo-types are not set >>> >>> Shumon noted a preference to leave this text as is (with the rationale >>> below) but does not feel extremely strongly about it: >>> >>>> the "must be clear" phrase is a commentary on the paragraph from RFC >>>> 4034's quoted text, specifically "Bits representing pseudo-types MUST be >>>> clear", so this seems appropriate to me. >>>> >>>> But I don't feel extremely strongly about it. If Olafur prefers another >>>> equivalent phrase like "are not set", then I can go along with that. >>> >>> >>> Current: >>> Note: As a practical matter, no known resolver insists that pseudo- >>> types are not set in the NSEC Type Bit Maps field, so this >>> restriction (prior to its revision) has posed no problem for the >>> deployment of this mechanism. >>> >>> >>> The most recent files are available here (please make sure to refresh): >>> >>> Updated XML file: >>> https://www.rfc-editor.org/authors/rfc9824.xml >>> >>> Updated output files: >>> https://www.rfc-editor.org/authors/rfc9824.txt >>> https://www.rfc-editor.org/authors/rfc9824.pdf >>> https://www.rfc-editor.org/authors/rfc9824.html >>> >>> Diff files showing all changes made during AUTH48: >>> https://www.rfc-editor.org/authors/rfc9824-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9824-auth48rfcdiff.html (side by side) >>> >>> Diff files showing the last round of changes made during AUTH48 (sent by >>> Olafur): >>> https://www.rfc-editor.org/authors/rfc9824-lastdiff.html >>> https://www.rfc-editor.org/authors/rfc9824-lastrfcdiff.html (side by side) >>> >>> Diff files showing all changes: >>> https://www.rfc-editor.org/authors/rfc9824-diff.html >>> https://www.rfc-editor.org/authors/rfc9824-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc9824-alt-diff.html (diff showing >>> changes where text is moved or deleted) >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9824 >>> >>> Thank you, >>> >>> Rebecca VanRheenen >>> RFC Production Center >>> >>> >>> >>>> On Aug 29, 2025, at 5:41 PM, Rebecca VanRheenen >>>> <[email protected]> wrote: >>>> >>>> Hi Shumon, >>>> >>>> Thank you for letting us know your position on this! We will wait to hear >>>> from Olafur. If Olafur prefers the change, we’ll apply it. >>>> >>>> Best regards, >>>> Rebecca >>>> >>>> >>>> >>>>> On Aug 28, 2025, at 7:26 AM, Shumon Huque <[email protected]> wrote: >>>>> >>>>> Rebecca, >>>>> >>>>> My preference is to leave the text as is. >>>>> >>>>> As I've noted, and you've reiterated, the "must be clear" phrase is a >>>>> commentary on the paragraph from RFC 4034's quoted text, specifically >>>>> "Bits representing pseudo-types MUST be clear", so this seems appropriate >>>>> to me. >>>>> >>>>> But I don't feel extremely strongly about it. If Olafur prefers another >>>>> equivalent phrase like "are not set", then I can go along with that. >>>>> >>>>> Shumon. >>>>> >>>>> On Fri, Aug 22, 2025 at 12:47 PM Rebecca VanRheenen >>>>> <[email protected]> wrote: >>>>> Hi Olafur and Shumon, >>>>> >>>>> We have one open issue: >>>>> >>>>> Olafur proposed this change (see full sentence below for context if >>>>> needed): >>>>>> >>>>>> >>>>>> Section 7.1 >>>>>> OLD: >>>>>> insists that pseudo-types must be clear >>>>>> NEW: >>>>>> insists that pseudo-types are not set >>>>> >>>>> Shumon notes that "must be clear” is phrasing from another RFC and is >>>>> clear as is. Shumon’s comment: >>>>> >>>>>> I'm happy with the text as currently written. (And for the reason cited >>>>>> -- that it re-uses a phrase from the cited RFC). >>>>>> I also don't think there is any lack of clarity here. A bit being clear >>>>>> means that it is not set. >>>>>> Olafur - if you feel strongly about the change, please elaborate on your >>>>>> reasoning. >>>>> >>>>> >>>>> Please discuss and let us know if we can leave “must be clear” as is or >>>>> if it should be updated to “not be set”. >>>>> >>>>> Current: >>>>> Note: As a practical matter, no known resolver insists that pseudo- >>>>> types are not set in the NSEC Type Bit Maps field, so this >>>>> restriction (prior to its revision) has posed no problem for the >>>>> deployment of this mechanism. >>>>> >>>>> Perhaps (’not be set’): >>>>> Note: As a practical matter, no known resolver insists that pseudo- >>>>> types not be set in the NSEC Type Bit Maps field, so this >>>>> restriction (prior to its revision) has posed no problem for the >>>>> deployment of this mechanism. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Rebecca VanRheenen >>>>> RFC Production Center >>>>> >>>>> >>>>> >>>>>> On Aug 21, 2025, at 5:57 AM, Olafur Gudmundsson <[email protected]> wrote: >>>>>> >>>>>> On Wednesday, 20 August, 2025 22:34, "Shumon Huque" <[email protected]> >>>>>> said: >>>>>> >>>>>> On Wed, Aug 20, 2025 at 8:53 PM Rebecca VanRheenen >>>>>> <[email protected]> wrote: >>>>>> Hi Olafur and Shumon, >>>>>> >>>>>> Thank you for your review and comments. We have updated the document >>>>>> accordingly and have a few followup questions/notes: >>>>>> >>>>>> b) >>>>>> >>>>>>> Section 7.1 >>>>>>> OLD: >>>>>>> insists that pseudo-types must be clear >>>>>>> NEW: >>>>>>> insists that pseudo-types are not set >>>>>> >>>>>> We have not updated as indicated above. Would “not be set” be better >>>>>> than “are not set”? Shumon also notes that 'The "must be clear" phrasing >>>>>> came from re-using the phrasing in the original RFC text. But I'm not >>>>>> attached to it.’ >>>>>> >>>>>> Please discuss and let us know if any updates are needed. I'm happy with >>>>>> the text as currently written. (And for the reason cited -- that it >>>>>> re-uses a phrase from the cited RFC). >>>>>> I also don't think there is any lack of clarity here. A bit being clear >>>>>> means that it is not set. >>>>>> Olafur - if you feel strongly about the change, please elaborate on your >>>>>> reasoning. >>>>>> [OG] >>>>>> The text originates in a pre-RFC2119 RFC. >>>>>> In my experience with industry people many of them do not grasp the >>>>>> difference between MUST and must >>>>>> in an RFC they have been handed to implement, thus they treat them as >>>>>> the same. >>>>>> For that reason I have tried to minimize any use of lower case 2119 >>>>>> words in drafts. >>>>>> [OG] >>>>>> c) Note that we will ask AD approval for all changes that are “above >>>>>> editorial”. This includes changes to values and 2119 key words. We will >>>>>> send that request in a separate email once the questions above are >>>>>> addressed. Okay, we'll await the AD's response/approval. >>>>>> Thank you, >>>>>> Shumon. >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
