Hi Olafur and Shumon,
Thank you for your review and comments. We have updated the document
accordingly and have a few followup questions/notes:
a)
> Affiliation: do I really need one ?
> OLD:
> Retired/Unaffiliated
>
> NEW:
> Retired/formerly Cloudflare
> or
> NEW:
An affiliation is not required per Section 4.1.2 of RFC 7322 ("RFC Style
Guide”), which states:
If an author cannot or will not provide an affiliation for any
reason, "Independent", "Individual Contributor", "Retired", or some
other term that appropriately describes the author's affiliation may
be used. Alternatively, a blank line may be included in the document
header when no affiliation is provided.
We have left your affiliation blank as that seems to be your preference. Please
let us know if that is not correct.
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.
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.
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.
— FILES (please 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 19, 2025, at 5:53 PM, Shumon Huque <shu...@gmail.com> wrote:
>
> My quick comments on Olafur's ...
>
> On Tue, Aug 19, 2025 at 12:56 PM Olafur Gudmundsson <o...@ogud.com> wrote:
>
> I’m reviewing the html document as I have forgot how to read XML bloat,
>
> Affiliation: do I really need one ?
> OLD:
> Retired/Unaffiliated
>
>
> NEW:
> Retired/formerly Cloudflare
> or
> NEW:
>
> I'll defer to the RFC Editor about whether an affiliation is needed.
>
> If one is, then your proposed "Retired/formerly Cloudflare" sounds fine to me.
>
> Comment:
> I hate reading RFC’s where lower case of RFC2119 words appears in a section
> that has RFC2119 words, see the 3 used of should in section 3.5 that
> reads like a specification section not as guidance section
> Section 3.5 paragraph 1
> OLD:
> that should not appear
> NEW:
> that SHOULD NOT appear
>
>
> Section 3.5 paragraph 1
> OLD:
> response should be.
> NEW:
> response ought to be.
>
>
> Section 3.5 paragraph 2
> OLD:
> resolver should not forward
> NEW:
> resolver SHOULD NOT forward
>
>
> Section 3.5 paragraph 3
> OLD:
> type that should not appear
>
>
> NEW:
> type that ought not appear
>
>
> Section 4. paragraph 3
> OLD:
> The NSEC3 parameters should be set to algorithm 1
> NEW:
> The NSEC3 parameters SHOULD be set to algorithm 1
>
> All of the above upper-casing of RFC 2119 keywords sound good to me.
> Section 7.1
> OLD:
> insists that pseudo-types must be clear
> NEW:
> insists that pseudo-types are not set
>
> Ok.
>
> The "must be clear" phrasing came from re-using the phrasing in the original
> RFC text. But I'm not attached to it.
>
> Section: 2 paragraph 3
> OLD:
> in addition to the required RRSIG
> NEW:
> in addition to the mandated RRSIG
>
> Ok.
> Other points:
> Section 4: redundant word confuses message
> OLD:
> This protection is already better provided
> NEW:
> This protection is better provided
>
> Ok.
>
> Section 3.1 bad guidance on TTL value
> OLD:
> a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
>
>
>
> NEW:
> a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
>
>
>
> Section 3.4 (bad TTL guidance)
> OLD:
> sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC
>
>
> NEW:
> sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC
>
>
>
>
>
> I'm fine with changing the TTL value from 3600 to 300 in these examples.
>
> But as you might suspect, I don't agree with your assertion that 3600 is
> "bad TTL guidance". In fact I don't believe there is any general agreement in
> the DNS operator or protocol engineering community about longer TTLs being
> bad (or good). There are strong opinions in either direction. In my own
> organization, TTLs we select are situation dependent. Some configurations
> benefit from lower TTLs (load balancers etc), others benefit from longer. As
> a counterpoint to your assertion, there are many technical papers and
> diatribes out there, for example this one:
> https://00f.net/2019/11/03/stop-using-low-dns-ttls/
>
> At any rate, this RFC does not intend to express an opinion on the topic of
> what TTL values are good or bad, nor should it. So we don't not need to
> belabor the point. I'm good with your suggestion of changing the TTL in the
> example to 300.
>
> I will wait for others to comment on those suggested changes before giving my
> approval
>
> Olafur
>
>
> Done!
>
> Please approve and let's ship this doc!
>
> Shumon.
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
