[DNSOP] Re: [Ext] [DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis

[Tim Wicinski <[e-mail]>]

Paul


On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman <[e-mail]> 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 <[e-mail]> 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
>
>