Authors,
While reviewing this document during Final Review, please resolve (as
necessary) the following questions, which are also in the source file.
1) <!-- [rfced] How may we update the abbreviated title of the document to be
more descriptive? The abbreviated title only appears in the running header at
the top of each page of the PDF output.
Original:
3901bis
Perhaps:
Guidelines for DNS Transport
-->
2) <!-- [rfced] Section 1.1 contains the boilerplate paragraph about RFC
2119/8174 key words. May we move this paragraph to Section 2 ("Terminology")?
-->
3) <!-- [rfced] Section 2 ("Terminology") contains definitions for "IPv4 name
server", "IPv6 name server", and "Dual-stack name server" and notes that this
document uses these terms. However, we do not see these terms used outside of
Section 2. We see one instance of "IPv4-reachable and two IPv6-reachable name
servers" in Section 4.1.
Please review and let us know if any updates are needed.
-->
4) <!-- [rfced] How may we clarify "for its in-domain NS' names"?
Original:
If the parent provides glue records for both IP address families
but the child zone itself lacks corresponding A or AAAA RRs for
its in-domain NS' names, resolution via the missing IP address
family will fail during delegation revalidation (see, e.g.,
[I-D.ietf-dnsop-ns-revalidation]).
Perhaps:
If the parent provides glue records for both IP address families
but the child zone itself lacks corresponding A or AAAA RRs for
names of its in-domain NS, resolution via the missing IP address
family will fail during delegation revalidation (see, e.g.,
[NS-REVALIDATION]).
Or:
If the parent provides glue records for both IP address families
but the child zone itself lacks corresponding A or AAAA RRs for
its in-domain NS names, resolution via the missing IP address
family will fail during delegation revalidation (see, e.g.,
[NS-REVALIDATION]).
-->
5) <!-- [rfced] What does "correspondingly" refer to here? May it be omitted as
"associated" is already used in the sentence?
Original:
It is insufficient if the name
pointed to by the NS RR has an associated A or AAAA RR
correspondingly.
Perhaps:
It is insufficient if the name
pointed to by the NS RR has an associated A or AAAA RR.
-->
6) <!-- [rfced] How may we clarify "are packets requiring fragmentation given a
reduced PMTU and MTU discards" in this sentence?
Original:
The most common issue are packets requiring
fragmentation given a reduced PMTU and MTU discards, i.e., packets
being dropped on-path due to exceeding the MTU of the link to the
next-hop without the sender being notified.
Perhaps:
The most common issue is that packets requiring
fragmentation are given reduced PMTU and MTU discards, i.e., packets
are dropped on-path due to exceeding the MTU of the link to the
next hop without the sender being notified.
-->
7) <!-- [rfced] We removed "Additionally, e.g.," at the beginning of this
sentence because the sentence already includes "additional". Please let us know
any objections. Note that similar text appears in two places in Section 3.2; we
updated both sentences in the same way.
Original:
Additionally, e.g., as an additional precaution or because the DNS
implementation in use does not support limiting the effective
EDNS(0) size, DNS servers MAY opt to explicitly not rely on path
MTU discovery [RFC4821] or PLPMTUD [RFC8899]. It can do so, for
example, by setting IPV6_USE_MIN_MTU=1 from [RFC3542] to avoid the
need to perform PMTU discovery.
Updated:
Additionally, as an additional precaution or because the DNS
implementation in use does not support limiting the effective
EDNS(0) size, DNS servers MAY opt to explicitly not rely on Path
MTU Discovery (PMTUD) [RFC4821] or Packetization Layer Path MTU
Discovery (PLPMTUD) [RFC8899]. It can do so, for example, by
setting IPV6_USE_MIN_MTU=1 from [RFC3542] to avoid the need to
perform PMTU discovery.
-->
8) <!-- [rfced] This sentence does not parse. Should "and performing PMTU" be
updated to "performing PMTUD" or something similar?
Original:
However, as DNS benefits from low latency, and performing PMTU (or
PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) could
lead to DNS requests timing out before the effective PMTU can be
established by the server.
Perhaps:
However, as DNS benefits from low latency, performing PMTUD (or
PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) could
lead to DNS requests timing out before the effective PMTU can be
established by the server.
-->
9) <!-- [rfced] Please review "(stub) recursive resolvers". Is the intended
meaning "stub and recursive resolvers"?
Original:
Similar to authoritative servers, (stub) recursive resolvers may
face broken IP connectivity for either IPv4 or IPv6:
Perhaps:
Similar to authoritative servers, stub and recursive resolvers may
face broken IP connectivity for either IPv4 or IPv6.
-->
10) <!-- [rfced] This sentence is difficult to follow. May we split into two
separate sentences to improve clarity?
Original:
Similarly, [RFC1918]
addressing may be in use on the resolver, while address
translation is not performed, or, similar to the case for IPv6,
when the DNS resolver has a global IPv4 address, but that address
is not forwarded on the resolver's network.
Perhaps:
Similarly, addressing in [RFC1918] may be in use on the resolver, so address
translation is not performed. Or, similar to the case for IPv6,
when the DNS resolver has a global IPv4 address, that address
is not forwarded on the resolver's network.
-->
11) <!-- [rfced] Please review whether the note at the end of Section 3.2
should be in the <aside> element. It is defined as "a container for content
that is semantically less important or tangential to the content that
surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
12) <!-- [rfced] Should "Intentional IP related name space fragmentation" be
updated in one of the following ways?
Original:
Intentional IP related name space fragmentation occurs if an operator
consciously decides not to deploy IPv4 or IPv6 for a part of the
resolution chain.
Perhaps A:
Intentional name space fragmentation occurs if an operator
consciously decides not to deploy IPv4 or IPv6 for a part of the
resolution chain.
Perhaps B:
Intentional name space fragmentation related to IP address family
occurs if an operator
consciously decides not to deploy IPv4 or IPv6 for a part of the
resolution chain.
-->
13) <!-- [rfced] How may we clarify "while it is observed that the first zones
becoming exclusively IPv6 resolvable"?
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].
Perhaps A):
Yet, while it is observed that the first
zones are becoming exclusively IPv6 resolvable, a major
portion of zones still relies solely on IPv4 [V6DNSRDY-23].
Perhaps B:
Yet, while the first
zones are becoming exclusively IPv6 resolvable, a major
portion of zones still relies solely on IPv4 [V6DNSRDY-23].
-->
14) <!-- [rfced] Will "as also mirrored by, e.g.," be clear to readers? Would
"as shown in" (or similar) be more clear?
Original:
Typically, these servers are
geographically diverse and operate under different routing policies
[RFC2182], as also mirrored by, e.g., the IANA requirements for TLD
authoritative name servers [IANANS].
Perhaps:
Typically, these servers are
geographically diverse and operate under different routing policies
[RFC2182], as shown in the IANA requirements for Top-Level Domain (TLD)
authoritative name servers [IANANS].
-->
15) <!-- [rfced] Does "below methods" here mean the methods in this section? If
so, would it be helpful to state that?
Original:
Exceptions apply if one of the below methods to prevent namespace
fragmentation are in place.
Perhaps:
Exceptions apply if one of the methods to prevent namespace
fragmentation described in this section are in place.
-->
16) <!-- [rfced] FYI - We updated "(e.g., [RFC8781])" as follows. Please review
and let us know any concerns.
Original:
If a recursive DNS resolver is aware of a PREF64 to use for NAT64
[RFC6146], either through static configuration or by discovering it
(e.g., [RFC8781]), it MAY synthesize IPv6 addresses for remote
authoritative DNS servers.
Updated:
If a recursive DNS resolver is aware of a PREF64 to use for NAT64
[RFC6146], either through static configuration or by discovering it
(e.g., using the option described in [RFC8781]), it MAY synthesize IPv6
addresses for remote
authoritative DNS servers.
-->
17) <!-- [rfced] Please confirm that "libc" is correct here. We see "glibc" in
the URL listed for the reference entry [MAN] (i.e.,
https://man7.org/linux/man-pages/man5/resolv.conf.5.html).
Original:
When providing multiple DNS servers to stub resolvers, network
operators have to consider that, at the time of writing, various
implementations can only configure a small set of possible DNS
resolvers, e.g., only up to three for libc [MAN], and additional
resolvers provided may be ignored by clients.
-->
18) <!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they may
be made consistent.
name space
namespace
DNS stub resolver
stub DNS resolver
b) FYI - We updated one instance of "MMS_S" to "MSS_S".
-->
19) <!-- [rfced] Hyphenation
a) We typically hyphenate "noun + based" and "noun + related" when used before
a noun. However, hyphenating as "IP Address Family Related" as
"IP-Address-Family-Related" in the titles below (and a few instances in general
text) is a bit awkward. We recast as follows. Please review and let us know any
concerns.
Original:
3. Name Space Fragmentation
3.1. Misconfigurations Causing IP Address Family Related Name
Space Fragmentation
3.2. Network Conditions Causing IP Address Family Related Name
Space Fragmentation
3.3. Reasons for Intentional IP Address Family Related Name
Space Fragmentation
Perhaps:
3. Name Space Fragmentation
3.1. Misconfigurations Causing Name Space Fragmentation Related
to IP Address Family
3.2. Network Conditions Causing Name Space Fragmentation Related
to IP Address Family
3.3. Reasons for Intentional Name Space Fragmentation Related to
IP Address Family
b) In addition to recasting to avoid awkward hyphenation, should this sentence
be updated to align with the titles of Sections 3.1, 3.2, and 3.3?
Specifically, should it mention misconfigurations?
Original:
* Expanded namespace fragmentation, independently discussing IP
address family related namespace fragmentation, network condition
based namespace fragmentation, and intentional namespace
fragmentation.
Perhaps:
* Expanded namespace fragmentation, independently discussing
misconfigurations and network conditions causing namespace fragmentation
related to IP Address Family, as well as intentional namespace
fragmentation.
-->
20) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Extension Mechanisms for DNS (EDNS(0))
Packetization Layer Path MTU Discovery (PLPMTUD)
Regional Internet Registries (RIRs)
Top-Level Domain (TLD)
Recursion Desired (RD)
-->
21) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
Rebecca VanRheenen
RFC Production Center
On Jul 13, 2026, at 6:20 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10001 <draft-ietf-dnsop-3901bis>
Your document is now available for Final Review (previously AUTH48). Once it
has been
reviewed and approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies;
see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using 'REPLY ALL' as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is an archival mailing list
to preserve discussion about the document while in the RPC editorial
queue; it is not an active discussion list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use 'REPLY ALL',
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc10001.xml
https://www.rfc-editor.org/authors/rfc10001.html
https://www.rfc-editor.org/authors/rfc10001.pdf
https://www.rfc-editor.org/authors/rfc10001.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc10001-diff.html
https://www.rfc-editor.org/authors/rfc10001-rfcdiff.html (side by side)
Alt-diff of the text (allows you to more easily view changes
where text has been deleted or moved):
https://www.rfc-editor.org/authors/rfc10001-alt-diff.html
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10001-xmldiff1.html
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10001/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10001 (draft-ietf-dnsop-3901bis)
Title : Operational Guidelines for DNS Transport in Mixed IPv4/IPv6
Environments
Author(s) : M. Yamamoto,
T. Fiebig
WG Chair(s) : Benno Overeinder, Ondřej Surý
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
