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]
