[v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Sun, 07 July 2019 12:58 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0512002E; Sun, 7 Jul 2019 05:58:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>, v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com>
Date: Sun, 07 Jul 2019 05:58:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Z8LFhUn0PB64S5NF1TxP-Jex_Jo>
Subject: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jul 2019 12:58:14 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-v6ops-nat64-deployment-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello Jordi, Thank you for the work put into this clear and well-written document. I only wonder whether section 3 and section 4 should be swapped for a more logical flow: explain the issues, then describe working solutions. Probably too late in the publication to change though. The underlying message of "464XLAT solves everything" is annoying but I must admit that this is true ;-) Please find below many COMMENTs in the hope of improving the readability and factual data points in the document. -éric == COMMENTS == Is there a description of the use of DNS64 in the host as it fixes the DNSSEC issues ? (except in section 3.2.2.) -- Section 3.1 -- "known to work": can you add references or data backing this statement ? -- Section 3.1.1 -- When discussing scenarii, please refer to the figure ID in the text for clarity. -- Section 3.1.2 -- It is unclear to me whether "The support of this scenario" refers to the UE-only or the CPE deployment. Same demand as above: please refer to the figure ID in the text for clarity. -- Sectio 3.2.1 -- I really wonder whether it is useful to describe this scenario as 'working under special conditions'... those 'special conditions' will probably never met in real life. More generally, I am unsure about the value of the whole section 3.2 (it is more like an academic thing). -- Section 4.1.1. -- Can you add reference and/or data for "monitored by some governmental bodies and other institutions". Please add a reference for the use of "ipv4only.arpa". AFAIK draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead. -- Section 4.1.2 -- The leading paragraph is a little confusing as it assumed that CLAT exists (stated in the text but not in the section title). -- Section 4.1.5 -- The section title is rather misleading "ACL of clients" and I wonder why a dual-stack client would use a DNS64 server as its recursive DNS server. Isn't it an obvious configuration mistake? -- Section 4.4.1 -- Some explanations of the consequences of a foreign DNS would be welcome. -- Section 4.4.2 -- Rather than using "DNS privacy" please use "DNS request confidentiality" as the DNS64 will learn/glean about the client activities. -- Section 4.6 -- Please explain why older API is a problem (or rather rephrase it into applications using IPv4-only API). -- Section 4.10 -- draft-ietf-tram-turnbis is also able to support IPv6-only client. It is currently in the same IESG status as this document. -- Section 5 -- Please add data/references for "with hundreds of millions of users" -- Section 7 -- Not so much about security but about privacy. I would appreciate to have some text around the lack of privacy when using an external DNS64 as this server will learn about all clients activities. == NITS == Generally, please refrain from using "HEv2" in place of "Happy Eyeball version 2". -- Section 3.1.1. -- Figure 1 shows a box containing both NAT64 and DNS64 while those functions could reside in different devices. s/One more equivalent scenario/One additional equivalent scenario/ ? -- Section 4.1 -- s/to an IPv6-only WAN/to an IPv6-only access network/
- [v6ops] Éric Vyncke's No Objection on draft-ietf-… Éric Vyncke via Datatracker
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… JORDI PALET MARTINEZ
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… Eric Vyncke (evyncke)
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… JORDI PALET MARTINEZ
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… Mudric, Dusan (Dusan)
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… JORDI PALET MARTINEZ
- Re: [v6ops] Éric Vyncke's No Objection on draft-i… JORDI PALET MARTINEZ