[v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-transition-ipv4aas-14: (with COMMENT)
Alissa Cooper <alissa@cooperw.in> Tue, 15 January 2019 22:32 UTC
Return-Path: <alissa@cooperw.in>
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 01B38128CF3; Tue, 15 Jan 2019 14:32:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-transition-ipv4aas@ietf.org, Ron Bonica <rbonica@juniper.net>, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154759153599.10731.5698492684665563607.idtracker@ietfa.amsl.com>
Date: Tue, 15 Jan 2019 14:32:15 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NwCMAWk7b2pqov3r9CDoI7EDBdk>
Subject: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-transition-ipv4aas-14: (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: Tue, 15 Jan 2019 22:32:17 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-transition-ipv4aas-14: 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-transition-ipv4aas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Here is my original COMMENT: == Section 1 == OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional. (Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.) It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure. s/devices or applications/devices and applications/ == Section 3.2 == s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/ s/per interface/per interface/ Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything. == Section 3.2.1 == OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, then the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. NEW It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64. == Section 7 == I would suggest starting this section with "At the time of this writing, ..." == Section 12 == The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2.
- [v6ops] Alissa Cooper's No Objection on draft-iet… Alissa Cooper
- Re: [v6ops] Alissa Cooper's No Objection on draft… JORDI PALET MARTINEZ