Hi Rebecca, all,
> 1) Section 2 (penultimate paragraph): change from “required” to
> “mandated"
>
OK.
> 2) Sections 3.1 and 3.4: change from “3600” to “300”
>
The TTL change in two occurrences is OK. Anyway, these are examples.
> 3) Section 3.5 (1st and 2nd paragraphs): change from “should not”
> to "SHOULD NOT”
The use of normative language is justified here, so OK with both changes.
One note though, the second "SHOULD NOT" does not have an exception called out:
CURRENT:
A resolver SHOULD NOT forward these queries upstream or attempt iterative
resolution
Absent a valid exception, this smells more "MUST NOT".
>
> 4) Section 4 (4th paragraph): change from “should” to “SHOULD"
>
OK.
> 5) Section 7.1: change from “must be clear” to “not be set” in the
> note
The OLD is OK.
Given that RFC4034 uses "set" in opposition to "clear" (see, e.g., last para of
4034#4.1.2), the new would work as well. OK to proceed with that change if this
is the authors preference.
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>
> Envoyé : lundi 8 septembre 2025 23:15
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
> Cc : Shumon Huque <shu...@gmail.com>; Christian Elmerot
> <elme...@cloudflare.com>; Olafur Gudmundsson <o...@ogud.com>; RFC
> Editor <rfc-edi...@rfc-editor.org>; dnsop-...@ietf.org; dnsop-
> cha...@ietf.org; suzworldw...@gmail.com; Warren Kumari
> <war...@kumari.net>; auth48archive@rfc-editor.org
> Objet : [AD] Re: AUTH48: RFC-to-be 9824 <draft-ietf-dnsop-compact-
> denial-of-existence-07> for your review
>
>
> Hi Med,
>
> As AD, please review the following changes made during AUTH48 and
> let us know if you approve. These changes are best viewed in these
> diff files:
>
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9824-
> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1a
> 1745819148461b286308ddef1ce258%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C638929629525806875%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BSqKjEzzlPRFHOY8MmfnYe3PzddcIiB
> Z3Iei%2FbJCWuY%3D&reserved=0
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9824-
> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7
> C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638929629525827453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rCr%2FLTazRhi1bRnMbrMDTCYtl%2F
> %2BBX3XsvlVfPnLcafk%3D&reserved=0 (side by side)
>
>
> 1) Section 2 (penultimate paragraph): change from “required” to
> “mandated"
>
> 2) Sections 3.1 and 3.4: change from “3600” to “300”
>
> 3) Section 3.5 (1st and 2nd paragraphs): change from “should not”
> to "SHOULD NOT”
>
> 4) Section 4 (4th paragraph): change from “should” to “SHOULD"
>
> 5) Section 7.1: change from “must be clear” to “not be set” in the
> note
>
>
> Thank you,
>
> Rebecca VanRheenen
> RFC Production Center
>
>
> > On Sep 8, 2025, at 2:12 PM, Rebecca VanRheenen
> <rvanrhee...@staff.rfc-editor.org> wrote:
> >
> > Hi Olafur and Shumon,
> >
> > Thank you for your replies and for resolving this final issue.
> We’ve updated the note in Section 7.1 accordingly.
> >
> > Olafur, please let us know if you now approve the document in
> its current form. The other authors have already sent their
> approvals (see
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauth48%2Frfc9824&data=05%7C02%7Cmohamed.boucadair%40o
> range.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C638929629525844640%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fM8L5sZC2%2Bi5p1tUu
> 1xHLlKy5qCWuNI%2BsWYZMEwrfl8%3D&reserved=0).
> >
> > In a separate email, I will ask the AD to review and approve the
> changes that are “above editorial” (e.g., changes to values and
> 2119 key words).
> >
> > Once we receive approval from Olafur and the AD, we can move
> this document forward in the publication process. We are getting
> close!
> >
> > The most recent files are available here (please make sure to
> refresh):
> >
> > Updated XML file:
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-
> editor.org%2Fauthors%2Frfc9824.xml&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40
> bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638929629525860653%7CUnknown%7CTWFpbGZsb3
> d8ey
> >
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFp
> >
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5oy3k7F6lziE03wYbEjyTnlqga
> 6nXi
> > Q6RTOlhN0hdLM%3D&reserved=0
> >
> > Updated output files:
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-
> editor.org%2Fauthors%2Frfc9824.txt&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40
> bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638929629525873889%7CUnknown%7CTWFpbGZsb3
> d8ey
> >
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFp
> >
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fkCMpgukB65JUloJmJ45QMaCAk
> BGea
> > WLq60PkJ94TyI%3D&reserved=0
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-
> editor.org%2Fauthors%2Frfc9824.pdf&data=05%7C02%7Cmohamed.boucadai
> >
> r%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40
> bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638929629525887553%7CUnknown%7CTWFpbGZsb3
> d8ey
> >
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFp
> >
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lShmoIKoqwXqh67SDdHn%2FZ0o
> TbPj
> > osKuYGSLF%2F5lt5w%3D&reserved=0
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-
> editor.org%2Fauthors%2Frfc9824.html&data=05%7C02%7Cmohamed.boucada
> >
> ir%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b4
> 0bfb
> >
> c48b9253b6f5d20%7C0%7C0%7C638929629525900948%7CUnknown%7CTWFpbGZsb
> 3d8e
> >
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWF
> >
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ckvj%2B5s6tDigTm2S2GMO0t3
> MhzL
> > U810xfxw8xKRUSfc%3D&reserved=0
> >
> > Diff files showing all changes made during AUTH48:
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-editor.org%2Fauthors%2Frfc9824-
> auth48diff.html&data=05%7C02%7Cmoha
> >
> med.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90
> c7a2
> >
> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525914234%7CUnknown%
> 7CTW
> >
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIs
> >
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hU9hHqzHFfIEb4
> jb3S
> > DVFuAoiBpJXmAz2xLW0LEKUhw%3D&reserved=0
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-editor.org%2Fauthors%2Frfc9824-
> auth48rfcdiff.html&data=05%7C02%7Cm
> >
> ohamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7
> C90c
> >
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525927665%7CUnkno
> wn%7
> >
> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
> W4zM
> >
> iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x0ae%2B3%2F
> NGWw
> > BgX30PO%2FCc%2BnD6gxn%2Bo4ZHQWWBuekDks%3D&reserved=0 (side by
> side)
> >
> > Diff files showing all changes:
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-editor.org%2Fauthors%2Frfc9824-
> diff.html&data=05%7C02%7Cmohamed.bo
> >
> ucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20a
> f34b
> >
> 40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525941548%7CUnknown%7CTWFp
> bGZs
> >
> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
> FOIj
> >
> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F0ySTnFObJw5dr5lg1
> jsMP
> > 0zWTt3HMa7%2FcVD5B8RloE%3D&reserved=0
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-editor.org%2Fauthors%2Frfc9824-
> rfcdiff.html&data=05%7C02%7Cmohamed
> >
> .boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a
> 20af
> >
> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525954635%7CUnknown%7CT
> WFpb
> >
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkF
> >
> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=33eNweMRz%2BL%2Bw
> JhZ8
> > hBoZSojbuWHseOQeLytYQD63T0%3D&reserved=0 (side by side)
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-editor.org%2Fauthors%2Frfc9824-alt-
> diff.html&data=05%7C02%7Cmohame
> >
> d.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7
> a20a
> >
> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525967915%7CUnknown%7C
> TWFp
> >
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> IsIk
> >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T6jDJyHLchxBUYKS
> RIRJ
> > 6WCiEyZRVLnuPgfViY6vpGw%3D&reserved=0 (diff showing changes
> where text
> > is moved or deleted)
> >
> > For the AUTH48 status of this document, please see:
> >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > rfc-
> editor.org%2Fauth48%2Frfc9824&data=05%7C02%7Cmohamed.boucadair%40o
> >
> range.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40bfbc4
> 8b92
> >
> 53b6f5d20%7C0%7C0%7C638929629525981511%7CUnknown%7CTWFpbGZsb3d8eyJ
> FbXB
> >
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> CIsI
> >
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zIAdfYNmIvoEUPCZMtEndpQkgO9Y7bJ
> 1u5s
> > glYJw2TA%3D&reserved=0
> >
> > Thank you,
> >
> > Rebecca VanRheenen
> > RFC Production Center
> >
> >
> >
> >> On Sep 8, 2025, at 1:05 PM, Shumon Huque <shu...@gmail.com>
> wrote:
> >>
> >> Rebecca,
> >>
> >> So, let's go with "are not set" then for the text in this
> paragraph.
> >>
> >> For the other upper-case RFC2119 changes Olafur is suggesting,
> I believe we were waiting for you to get AD sign-off (from Med?).
> Is that already in progress?
> >>
> >> Shumon.
> >>
> >> On Mon, Sep 8, 2025 at 3:43 PM Olafur Gudmundsson
> <o...@ogud.com> wrote:
> >>
> >> 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
> <rvanrhee...@staff.rfc-editor.org> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-
> editor.org%2Fauthors%2Frfc9824.xml&data=05%7C02%7Cmohamed.bouc
> >>>
> adair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af3
> 4b
> >>>
> 40bfbc48b9253b6f5d20%7C0%7C0%7C638929629525995216%7CUnknown%7CTWFp
> bG
> >>>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> Ik
> >>>
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=30a3zFwi6%2Ftf1m
> sf
> >>> IoeHJphODb1t%2BEHuNM40EMm9uyM%3D&reserved=0
> >>>
> >>> Updated output files:
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-
> editor.org%2Fauthors%2Frfc9824.txt&data=05%7C02%7Cmohamed.bouc
> >>>
> adair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af3
> 4b
> >>>
> 40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526014886%7CUnknown%7CTWFp
> bG
> >>>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> Ik
> >>>
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HAM6%2Fdz2ETLZZI
> DI
> >>> FLeRGwxbdQoV25gtlvwyig%2B1iqQ%3D&reserved=0
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-
> editor.org%2Fauthors%2Frfc9824.pdf&data=05%7C02%7Cmohamed.bouc
> >>>
> adair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af3
> 4b
> >>>
> 40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526029479%7CUnknown%7CTWFp
> bG
> >>>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> Ik
> >>>
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LW0iecynLTAo9U9u
> an
> >>> rshcjD%2BI22Bh8q%2FpxXxUebCcY%3D&reserved=0
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-
> editor.org%2Fauthors%2Frfc9824.html&data=05%7C02%7Cmohamed.bou
> >>>
> cadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af
> 34
> >>>
> b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526043894%7CUnknown%7CTWF
> pb
> >>>
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sI
> >>>
> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IcV5Txph2z%2F%2
> F5
> >>> 4TfYLcqtbuOql%2BdMXKWv6a%2BremV9tI%3D&reserved=0
> >>>
> >>> Diff files showing all changes made during AUTH48:
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> auth48diff.html&data=05%7C02%7C
> >>>
> mohamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%
> 7C
> >>>
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526057893%7CUn
> kn
> >>>
> own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> Oi
> >>>
> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BAMq
> Hm
> >>> tRu1ydyt75MV3flGXmksRMMF5KuRyxUPCkirQ%3D&reserved=0
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> auth48rfcdiff.html&data=05%7C02
> >>>
> %7Cmohamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce2
> 58
> >>>
> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526071451%7
> CU
> >>>
> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> lA
> >>>
> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M
> n0
> >>> iu6bFZLxSGRKFlOQ4UpGZylIzOPtIUGu48hmVnD4%3D&reserved=0 (side
> by
> >>> side)
> >>>
> >>> Diff files showing the last round of changes made during
> AUTH48 (sent by Olafur):
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> lastdiff.html&data=05%7C02%7Cmo
> >>>
> hamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C
> 90
> >>>
> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526084880%7CUnkn
> ow
> >>>
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
> JX
> >>>
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=B26ewm
> pk
> >>> jqeMRnwoydOwcnQNId4zQQs9h7i31vlfIF8%3D&reserved=0
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> lastrfcdiff.html&data=05%7C02%7
> >>>
> Cmohamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258
> %7
> >>>
> C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526098553%7CU
> nk
> >>>
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> iO
> >>>
> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ycm
> 2X
> >>> g4SwzdWmjP8tWtXdmVsQ6Vz5w27RYIS7Ec8MfQ%3D&reserved=0 (side by
> side)
> >>>
> >>> Diff files showing all changes:
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> diff.html&data=05%7C02%7Cmohame
> >>>
> d.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7
> a2
> >>>
> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526111685%7CUnknown%
> 7C
> >>>
> TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
> 4z
> >>>
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xWG1mRtG5K
> O9
> >>> l89R7uO87EYYYRc3VnRPbd5l4vHl%2BbA%3D&reserved=0
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-
> rfcdiff.html&data=05%7C02%7Cmoh
> >>>
> amed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C9
> 0c
> >>>
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526124864%7CUnkno
> wn
> >>>
> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
> Xa
> >>>
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zruhRA3
> OA
> >>> RE9wE3BjLNFUYsuIdCuCKeEjOPqtRVgqro%3D&reserved=0 (side by
> side)
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-editor.org%2Fauthors%2Frfc9824-alt-
> diff.html&data=05%7C02%7Cmo
> >>>
> hamed.boucadair%40orange.com%7C1a1745819148461b286308ddef1ce258%7C
> 90
> >>>
> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638929629526138143%7CUnkn
> ow
> >>>
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
> JX
> >>>
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HlefGr
> Nj
> >>> DLTgYgIrZhZcjZPfxYLeWd3dRLRbteHIssY%3D&reserved=0 (diff
> showing
> >>> changes where text is moved or deleted)
> >>>
> >>> For the AUTH48 status of this document, please see:
> >>>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> ww
> >>> w.rfc-
> editor.org%2Fauth48%2Frfc9824&data=05%7C02%7Cmohamed.boucadair
> >>>
> %40orange.com%7C1a1745819148461b286308ddef1ce258%7C90c7a20af34b40b
> fb
> >>>
> c48b9253b6f5d20%7C0%7C0%7C638929629526151583%7CUnknown%7CTWFpbGZsb
> 3d
> >>>
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> jo
> >>>
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vnKq00eUR5ATVnfu7fLZf
> El
> >>> b49U0RTpNtQur4d3ItDk%3D&reserved=0
> >>>
> >>> 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.
> >>>>>
> >>>>
> >>>
> >>
> >
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
