[v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 10 January 2019 14:42 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 7AC59130EEF; Thu, 10 Jan 2019 06:42:40 -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.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154713136049.30772.14214762331468539097.idtracker@ietfa.amsl.com>
Date: Thu, 10 Jan 2019 06:42:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/77va5ituaYFNGX7bhU-IZo0vGSc>
Subject: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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: Thu, 10 Jan 2019 14:42:41 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-v6ops-transition-ipv4aas-13: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I think the standard RFC 8174 boilerplate is needed here. I think it was a
mistake to use the 2119 keywords differently in RFC 7084, and that mistake need
not be repeated. This document uses the normative keywords in the same ways as
many other informational documents. RFC 2119 is not focused on
interoperability, but rather on the requirements that the specification using
the keywords is laying out.

(2) I don't think it is appropriate for this document to defined a new
normative keyword, "DEFAULT," in Section 1.1. The right place to do that would
be an update to RFC 2119 or RFC 8174. This is especially problematic given that
the one place in this document where it is used, it is in a paragraph that also
uses other normative keywords. Since it's only used once, I would suggest just
explaining what it means in that location (3.2.2) rather than defining it as a
keyword.


----------------------------------------------------------------------
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.