Hi Tobias,
Thank you for the updated XML file! We created output and diff files (see
below). We also have a few followup questions/comments:
a) Regarding this question:
> 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.
"Dual-stack name server” still only appears in Section 2. Is this okay, or are
further updates needed?
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].
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.
d) FYI - Once we finalize the questions above, we’ll need to ask the AD to
approve some changes that are “above editorial”.
— 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 14, 2026, at 4:51 AM, Tobias Fiebig
> <[email protected]> wrote:
>
> Dear Editor,
>
> thank you for editing our document. I just went over the changes and
> comments.
>
> I replied to the questions you posed in the source document using the
> tag [auth48tf].
>
> Please note that some additional editorial clarifications were
> requested post IESG, which have been implemented now based on feedback
> by Med that this would be a feasible item for AUTH48.
>
> Attached you can find four files:
>
> - draft-ietf-dnsop-3901bis.xml: The source document you provided with
> the additional changes and replies to comments/questions you posed.
>
> Three diffs:
> - addressing_of_rfc_editor_comments.diff: The diff to the version you
> supplied, without the additional editorial suggestions by Erik Nygren
> - clarifications_erik_nygren.diff: The diff based on feedback by Erik
> Nygren on some unclear aspects.
> - full_diff_editor_version.diff: The full diff to the version you
> supplied, i.e., also including the clarifications proposed by Erik
>
> With these changes in place I approve this RFC for publication.
>
> 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
> <full_diff_editor_version.diff><clarifications_erik_nygren.diff><addressing_of_rfc_editor_comments.diff><draft-ietf-dnsop-3901bis.xml>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
