Tim jumped the gun by about an hour: we just submitted the -05. It incorporates the suggested text from below; you can see the diff at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05
FWIW, this new text is somewhat based on the findings from NLnetLabs and SIDN on a project supported by ICANN. You can see the report, and an earlier report on a related topic, at: https://www.icann.org/resources/pages/octo-commissioned-documents-2020-11-05-en Please let us know if you have any issues with the changed text in the new version. --Paul Hoffman On Jun 5, 2024, at 08:25, Tim Wicinski <tjw.i...@gmail.com> wrote: > > All > > The chairs are requesting some final comments on draft-ietf-dnsop-rfc8109bis. > As you might recall, this document has already been through WGLC and had > consensus to advance, but our AD reviewed it and raised some additional > questions. (Warren Kumari, “AD Review of draft-ietf-dnsop-rfc8109bis,” email > to the list on 31 January.) > > Here are specific things we particularly want feedback on: > > > -Discussion on the list suggested a change regarding the use of the TC bit in > the context of a priming response, which appears in the -04 (current) version > of the document but hasn’t been reviewed by the full WG: > > OLD: > 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." Note, however, > the root server addresses are not glue records, so setting the TC bit in > truncated responses from the root servers is not required by [RFC9471]. > > NEW: > 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." Because the > priming response is not a referral, root server addresses in the priming > response are not considered glue records. Thus, [RFC9471] does not apply to > the priming response and root servers are not required to set the TC bit if > not all root server addresses fit within message size constraints. There are > no requirements on the number of root server addresses that a root server > must include in a priming response. > > Willem's email to the list which suggests changes to section 3.3 to better > explain what is signed when; the chairs feel that these changes should be > incorporated into the draft as well > https://mailarchive.ietf.org/arch/msg/dnsop/D2Ha-Hk2lpvvkcXx7k4RILpgaPQ/ > [mailarchive.ietf.org] > The addition of a reference to RSSAC 0028 > (https://www.icann.org/en/system/files/files/rssac-028-03aug17-en.pdf, > “Technical Analysis of the Naming Scheme Used For Individual Root Servers,” > as an informative reference; it discusses the rationale for not signing > root-servers.net [root-servers.net]. > > > We liked to hear from the WG on this by Friday June 14, 2024. > > Thanks > tim, et al _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
