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
> <[email protected]> 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
>> <[email protected]> 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 <[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]
