[art] Re: draft-ietf-v6ops-rfc6146-bis-10 telechat Artart review

[John R Levine <[e-mail]>]

>
> A you know that figure is inherited from RFC6146, which is meant to provide a "simple example".
> Jordi did actually proposed a revised version that I found confusing. I asked him to revert the change and leave 6146.

My impression is that the DNS and NAT talk to both hosts on both networks 
so the figure would look something like this:


              +----------------+                   +---------------+
              |  IPv6 network  |                   |    IPv4       |
              |                |  +-------------+  |  network      |
              |            |---+--| Name server |--+--|            |
              |            |   |  | with DNS64  |  |  |  +----+    |
              |  +----+    |   |  +-------------+  |  |--| H2 |    |
              |  | H1 |----|   |                   |  |  +----+    |
              |  +----+    |   |      +-------+    |  |  192.0.2.1 |
              |2001:db8::1 |---+------| NAT64 |----+--|            |
              |                |      +-------+    |               |
              |                |                   |               |
              +----------------+                   +---------------+


>> -----Message d'origine-----
>> De : John Levine via Datatracker <[e-mail]>
>> Envoyé : jeudi 9 juillet 2026 00:04
>> À : [e-mail]
>> Cc : [e-mail]; last-
>> [e-mail]; [e-mail]
>> Objet : draft-ietf-v6ops-rfc6146-bis-10 telechat Artart review
>>
>>
>> Document: draft-ietf-v6ops-rfc6146-bis
>> Title: Stateful NAT64: Network Address and Protocol Translation
>> from IPv6 Clients to IPv4 Servers Reviewer: John Levine Review
>> result: Ready with Issues
>>
>> ARTART last call review of draft-ietf-v6ops-rfc6146-bis
>>
>> Reviewer: John Levine
>>
>> Overall: Still ready with Issues
>>
>> In the previous review I called out two issues, the confusing
>> Figure one, and the lack of DNSSEC concerns in the security
>> section.  The second issue is fixed with a short addition, the
>> first unfortunately is not.
>>
>> While the authors removed a few line segments from Figure 1, it
>> doesn't help since all of the same issues remain. Rather than
>> trying to tweak it, the authors could start over on a piece of
>> paper with a sketch of the actual topology, then transcribe it
>> preferably into SVG or if need be ASCII art.
>>
>
> ____________________________________________________________________________________________________________
> 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.
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly