Hi Med, Tobias, and Momoka, Med, we have updated the document with the changes listed in your last email. We have also marked your approval on the Final Review status page for this document (see https://queue.rfc-editor.org/final-review/rfc10001/).
Tobias, we have marked your approval as well. Thank you for your responsiveness! Momoka, once we receive your approval, we will move this document forward in the publication process. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc10001.xml Updated output files: https://www.rfc-editor.org/authors/rfc10001.txt https://www.rfc-editor.org/authors/rfc10001.pdf https://www.rfc-editor.org/authors/rfc10001.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc10001-auth48diff.html https://www.rfc-editor.org/authors/rfc10001-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc10001-diff.html https://www.rfc-editor.org/authors/rfc10001-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc10001-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://queue.rfc-editor.org/final-review/rfc10001/ Thank you, Rebecca VanRheenen RFC Production Center > On Jul 16, 2026, at 1:02 AM, Tobias Fiebig <[email protected]> wrote: > > Hello Rebecca, Hello Med, > > @Med: Thanks! I also really appreciate the nits. > > @Rebecca: As an author, I do approve of the nits and suggested > resolutions Med has pointed out. Please feel free to implement them. > > With that in place, as an author, I approve of publication of the > document as RFC10001. > > With best regards, > Tobias > > On Thu, 2026-07-16 at 06:15 +0000, [email protected] wrote: >> Hi Rebecca, all, >> >> I approve the changes [1], but I suggest to make the following edits: >> >> # nit/simplify >> >> OLD: In fact, this overhead could even lead to DNS requests timing >> out >> >> NEW: This overhead could even lead to DNS requests timing out >> >> # IPs has no meaning >> >> OLD: >> 1. all supplied recursive server IPs are from the same address >> family, based on knowledge as to clients being IPv4-only or >> IPv6-mostly; or >> 2. exactly two IPs are from one address family (IPv4 or IPv6) and >> exactly one is from the other address family. >> >> NEW: >> 1. all supplied recursive server IP addresses are from the same >> address >> family, based on knowledge as to clients being IPv4-only or >> IPv6-mostly; or >> 2. exactly two IP addresses are from one address family (IPv4 or >> IPv6) and >> exactly one is from the other address family. >> >> # nit >> >> OLD: >> Furthermore, all suppled resolvers SHOULD be able to perform dual- >> >> NEW: >> Furthermore, all supplied resolvers SHOULD be able to perform >> dual- >> >> >> # Not used terminology >> >> CURRENT: >> Dual-stack name server: >> A name server that is both an "IPv4-reachable name server" and >> an >> "IPv6-reachable name server". >> >> That term is not used exactly as such in the document (although we >> have variants out there). >> >> Maybe consider making this change: >> >> NEW: >> Dual-stack name server (or resolver): >> A name server (or resolver) that is both IPv4-reachable and >> IPv6-reachable. >> >> Cheers, >> Med >> >> [1] For the record, the discussion that triggered the changes made by >> Tobias is >> https://mailarchive.ietf.org/arch/msg/dnsop/mEhSf6861Re8QaR0RY5t0sIBWvE/ >> . >> >>> -----Message d'origine----- >>> De : Rebecca VanRheenen <[email protected]> >>> Envoyé : jeudi 16 juillet 2026 00:50 >>> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >>> [email protected]; [email protected] >>> Cc : RFC Editor <[email protected]>; auth48archive@rfc- >>> editor.org; [email protected]; [email protected]; dnsop- >>> [email protected]; [email protected] >>> Objet : [AD] Re: Final Review: RFC-to-be 10001 (draft-ietf-dnsop- >>> 3901bis) in XML >>> >>> >>> Hi Med, >>> >>> As AD, please review and approve the following changes. These >>> changes are best viewed in these diff files: >>> >>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc10001- >>> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5 >>> e9ff3209cc4d26290908dee2c35f8f%7C90c7a20af34b40bfbc48b9253b6f5d20% >>> 7C0%7C0%7C639197525907828867%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4EdV2VBX5%2Fmpe%2BUrgwjPkYOUobkY3 >>> k8CE2Vf6NIvASM%3D&reserved=0 (only shows changes made during Final >>> Review) >>> >>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> www.rfc-editor.org%2Fauthors%2Frfc10001-alt- >>> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5e9ff32 >>> 09cc4d26290908dee2c35f8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>> 0%7C639197525907850203%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >>> Q%3D%3D%7C0%7C%7C%7C&sdata=H%2Flrm88DShA8hJ1Dq9nECqWn5edIWRmWCmeGJ >>> 0KoxaI%3D&reserved=0 (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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>> queue.rfc-editor.org%2Ffinal- >>> review%2Frfc10001%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com >>> %7Ca5e9ff3209cc4d26290908dee2c35f8f%7C90c7a20af34b40bfbc48b9253b6f >>> 5d20%7C0%7C0%7C639197525907863457%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 >>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC >>> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RNnyJu398PbwSbIXn9BBJr8i5eqT >>> CRbysc72Kk%2Fp1t0%3D&reserved=0). >>>> >>>> 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 <tfiebig@mpi- >>> inf.mpg.de> 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 >>>> >> >> _____________________________________________________________________ >> _______________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender >> and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. > > -- > 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]
