Hi Med, As AD, please review and approve the following changes. These changes are best viewed in these diff files:
https://www.rfc-editor.org/authors/rfc10001-auth48diff.html (only shows changes made during Final Review) https://www.rfc-editor.org/authors/rfc10001-alt-diff.html (shows all changes) 1) Change from “name space fragmentation” to “name space partitioning” throughout the document Author note: Additional feedback was received that 'fragmentation’ being used for both packet fragmentation and namespace fragmentation is confusing. To address this, name space fragmentation is being changed to name space partitioning throughout the document. 2) Related to above, change from “fragmented” to “partitioned” in second paragraph in Section 3 and changes from “fragment” to “partition” and “fragmentation” to “partitioning” in second paragraph of Section 4 3) Section 3.2 - changes in first paragraph 4) Section 3.2 - changes in fourth paragraph under “DNS-over-TCP packets requiring fragmentation:” heading 5) Section 4.1 - new paragraph added after first paragraph (note that this new paragraph contains the key word “RECOMMENDED”) Author note: This is based on a recommendation to clarify this point, even though it is, technically, obvious. The suggestion itself recommended requiring all NS being dual-stack. However, the below issue can also be mitigated by having the NS RR list a name whose A record points to an authoritative server that is IPv4 only and whose AAAA record points to another authoritative DNS server that is IPv6 only. 6) Section 4.1 - change from “identical” to “equivalent” under “Consistency:” Author note: This change replaces 'identical' with 'equivalent', as DNS responses may (for various reasons) not be fully identical, even when returned by the same NS. Equivalence is closer aligned with the intended meaning of the text. 7) Section 4.3 - changes in last three paragraphs Author note: Based on feedback received and in coordination with the AD, the following clarification is being suggested for the below text. 8) Acknowledgments - addition of Erik Nygren Thank you, Rebecca VanRheenen RFC Production Center > On Jul 15, 2026, at 3:42 PM, Rebecca VanRheenen > <[email protected]> wrote: > > Hi Tobias, > > Thanks for the quick reply! All questions have now been addressed. We have > marked your approval on the Final Review status page for this document (see > https://queue.rfc-editor.org/final-review/rfc10001/). > > We will wait for further updates and/or approval from Momoka, and we’ll send > a separate email to the AD with changes that require approval. > > Best regards, > > Rebecca VanRheenen > RFC Production Center > > > >> On Jul 15, 2026, at 2:55 PM, Tobias Fiebig <[email protected]> wrote: >> >> Hi Rebecca, >>> "Dual-stack name server” still only appears in Section 2. Is this >>> okay, or are further updates needed? >> >> This is okay. >> >>> b) What do you think about the minor updates shown below (i.e., >>> moving “now” and updating “frequent” to “common”)? >>> >>> Original: >>> Yet, while it is observed that the first >>> zones becoming exclusively IPv6 resolvable, there is still a major >>> portion of zones solely relying on IPv4 [V6DNSRDY-23]. >>> >>> Current: >>> Yet, while the first zones that are exclusively IPv6 resolvable >>> can >>> be observed by now, exclusively IPv4 resolvable zones are >>> considerably more frequent [V6DNSRDY-23]. >>> >>> Perhaps: >>> Yet, while the first zones that are exclusively IPv6 resolvable >>> can >>> now be observed, exclusively IPv4 resolvable zones are >>> considerably more common [V6DNSRDY-23]. >> >> Thanks, 'Perhaps:' sounds like a good option. >> >>> c) In the updated text at the end of Section 4.3, should “address >>> family based namespace fragmentation” be revised as follows to align >>> with updates elsewhere in the document? That is, should this phrase >>> be updated to use “name space” (two words), use “partitioning” rather >>> than “fragmentation”, and recast to avoid awkward hyphenation? >>> >>> Current: >>> If this is not done, a client might select a >>> subset of recursive DNS servers that leads to address family based >>> namespace fragmentation. >>> >>> Perhaps: >>> If this is not done, a client might select a >>> subset of recursive DNS servers that leads to name space >>> partitioning due to >>> IP address family support. >> >> Yes, thank you, this one slipped through. >> >>> d) FYI - Once we finalize the questions above, we’ll need to ask the >>> AD to approve some changes that are “above editorial”. >> >> Thanks, and no worries. Please go ahead and reach out to the ADs. >> >> With best regards, >> Tobias >> >> -- >> My working day may not be your working day. Please do not feel obliged >> to reply to my email outside of your normal working hours. >> ----------------------------------------------------------------- >> Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) >> Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken >> E1 4 - Raum 517 mobil: +31 616 80 98 99 > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
