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]
