On Jan 31, 2024, at 11:38, Warren Kumari <war...@kumari.net> wrote: > > 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….
Sure. > > 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. Nope. The tone is because some root server operators want the ability to continue to not set the TC bit due to root server operational independence. We have to be honest about what is happening, and what the rules are. > RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will > survive at least that long. Yep, if not longer. > I don't know how we address my concern, but it feels like, in e.g 6 years, > this text will have aged poorly... Or it might still be accurate. We cannot tell ahead of time. > Can you see about some more massaging of this text? Not without suggestions from you or the WG about how to massage while being honest. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
