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
