Hi Rebecca, thanks for the edits.
See my comments in line
On Wednesday, 20 August, 2025 20:53, "Rebecca VanRheenen"
<rvanrhee...@staff.rfc-editor.org> said:
> 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.
Blank is what I prefer
>
>
> 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.
"not be set" is better than what I wrote.
>
> 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.
>
Ack, I will wait for their response
thanks
Olafur
>
> — 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
