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
