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.
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
