IETF Last Call Review of draft-ietf-v6ops-rfc6146-bis-07
review-ietf-v6ops-rfc6146-bis-07-dnsdir-lc-reid-2026-06-28-02

I am the dnsdir reviewer for this I-D.

The document has minimal DNS-related content that has no impact on the
DNS protocol or DNS operations. From that perspective, this review is
a no-op. I have reviewed the I-D for its readability and overall
structure.

However the document quality is mixed. In places it's hard to
understand. Some of the text is clumsily worded and appears to have
been machine-generated. Sentences are grammatically correct but hard
to parse. There are lots of extraneous "the"s: probably these get
added when the text was translated into English. For instance,
"because of the IPv4 address scarcity", "the filtering", "for the
connection establishment", etc.

Section 3.5 is clear, precise and well writen. It contrasts starkly
with much of the remaining text.

1) "Together with DNS64 [RFC6147], these two mechanisms allow an
IPv6-only client to initiate communications to an IPv4-only server."

Surely they enable (not allow) communication between IPv6-only and
IPv4-only devices? It is possible to communicate these devices
without using NAT64: proxies or application level gateways.

2) It's confusing to talk about IPv4-only servers because devices
participating in NAT64 might not be servers - for instance an
IPv4-only DNS client.

3) Why stateful NAT64? "this document refers to the stateful NAT64
either as stateful NAT64 or simply as NAT64." Choose one term and use
it consistently throughout the document.

4) "of preexisting state in a NAT64": NAT64 what? implementation,
system, client, server, middlebox?

5) Referring to a NAT64 function is confusing. The term is not
defined. It's not clear what it means or what it does.

6) The I-D repeatedly says "NAT64", "a NAT64" and "the NAT64" without
clarifying if this applies to the protocol itself or an implementation
or some part of an implementation. This is confusing and makes it hard
to understand the document. More context and/or clarify is needed when
these terms are used. At present, it's like saying "the SIP" or "the
HTTP" or...

7) "This helps with the IPv4 address exhaustion." Delete this. It
should be "This eases some of the problems of IPv4 address
exhaustion." but there are other reasons for using NAT64 besides the
IPv4 run-out.

9) "Support for other protocols....." in Section 1.1 should just say
Support for other protocols are not defined in this document.

9) The first paragraph of Section 1.2 is content-free filler IMO. It
should be removed.

10) "synthesize AAAA RRs from the A RRs". Which A RRs?

11) "located in an IPv6-only site" - shouldn't that be IPv6-only
network?

12) The walkthough in Section 1.2.2 mentions the NAT64 function
without explaining what it is, what it does or what role it plays in
interconnecting IPv4 and IPv6 devices.

13) "the local name server does the recursive lookups" should be "the
local resolving DNS server supports DNS64".

14) behaviors (Section 3.5) is a non-word. Use behavior (behaviour is
even better). Behaviour is a mass noun and shouldn't be pluralised.

15) It seems unwise to explicitly reference Protocol Constants defined
in other RFCs. It will mean the eventual RFC has to be updated or
replaced when the values of these constants change. Perhaps the
constants should be listed here as non-normative references,
explaining the values in the relevant RFCs are definitive and subject
to change whenever those RFCs get updated or deprecated.

16) Typos in Sections 5 & 8 (and elsewhere): "[RFC6052]", "Since
[RFC6146]", "[RFC7050], updated by [RFC8880]", "However, [RFC6052]' ,
''is the use [RFC7225]', "resolved by [RFC8781]". {I've lost the will
to live listing all of these and gave up.}

17) The paragraph beginning "Special thanks to Alberto Leiva
Popper..."  is clumsy and needs to be restructured. I'm not sure what
"easing the job to draft the text for resolving this errata" means or
why arreta numbers are given. Nit: errata is plural. So it should be
erratum 8416, erratum 4756. etc.

18) The contact details of the authors of RFC6146 don't need to be
mentioned. They're already given in that RFC! The acknowledgements and
contributors from RFC6416 don't need to be repeated either.
draft-ietf-v6ops-rfc6146-bis should just identify those who worked on
that I-D.

19) Typo: self-synthesys

20) Use of "we" in Section 1.2.2. RFCs (and standards documents in
general) should not use personal pronouns.

21) Over-use of "this document/section/step", duplicating what's already
been said in the section heading or other introductory material.