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
