Hi there, authors (and WG), Thank you for this document — I have some questions / comments before I can progress it.
Firstly, the (presumably) easy one: The document says: "This document, when published, obsoletes RFC 8109." - can you add something along the lines of "Section 1.1 contains a list of changes from RFC 8109" or similar…. Now the harder one… Sec 4.2: "If some root server addresses are omitted from the Additional section, there is no expectation that the TC bit in the response will be set to 1. At the time that this document is written, many of the root servers are not setting the TC bit when omitting addresses from the Additional section. Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. It says "If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response." " IMO, this text is confusing…. It sounds like it is saying "RFC9471 says you must set TC if you truncate the glue. The root server folk are ignoring RFC9471, bad root server folk…" I have read the discussion in the WGLC ( inc https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/ and am assuming it was rewritten as "If some root server addresses are omitted from the Additional section…".), but I don't really think that really addresses my concern — it's easy to miss the subtleties and the "all glue records" vs "some addresses" bit is tricky. It's also true that "At the time that this document is written, many of the root servers are not setting the TC bit when omitting addresses from the Additional section." — RFC9471 was only published at the end of September, there is an open BIND bug to update this behavior (I think! - https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned to change in 9.19.x (I think!) So, while what it written is all technically correct[0], the tone feels weird. I think that some of this is because ot the timing of when this and RFC9471 were written. RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will survive at least that long. I don't know how we address my concern, but it feels like, in e.g 6 years, this text will have aged poorly... Can you see about some more massaging of this text? W [0]: The best kind of correct….
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
