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]
