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 <o...@ogud.com> 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 < > rvanrhee...@staff.rfc-editor.org> 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 < > rvanrhee...@staff.rfc-editor.org> 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 <shu...@gmail.com> 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 < > rvanrhee...@staff.rfc-editor.org> 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 <o...@ogud.com> wrote: > > On Wednesday, 20 August, 2025 22:34, "Shumon Huque" <shu...@gmail.com> > said: > > On Wed, Aug 20, 2025 at 8:53 PM Rebecca VanRheenen < > rvanrhee...@staff.rfc-editor.org> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
