Paul
On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman <paul.hoff...@icann.org> wrote: > 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 I am guilty as charged. But our comment on we would like people to review the changes. > > > 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. > Thank you for incorporating those changes. However, I do have one small nit: ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) thanks tim > --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
