Barry Leiba's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Tue, 17 December 2019 04:50 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E02B6120098; Mon, 16 Dec 2019 20:50:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-ra-pref64@ietf.org, Bob Hinden <bob.hinden@gmail.com>, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org
Subject: Barry Leiba's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <157655824890.24496.6907121559908698996.idtracker@ietfa.amsl.com>
Date: Mon, 16 Dec 2019 20:50:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yM7NziK-JbPE3zD79sqx57C0Jjs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 04:50:49 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-6man-ra-pref64-08: 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-6man-ra-pref64/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I just have a couple of editorial comments about Section 4:

   If the network operator desires to route different
   parts of the IPv4 address space to different NAT64 devices, this can
   be accomplished by routing more specifics of the NAT64 prefix to
   those devices.

What does “more specifics” mean here?  I don’t understand the sentence.

   For example, if the operator is using the RFC1918
   address space, e.g. 10.0.0.0/8 internally and would like to route
   10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space
   through NAT64 device B, and the operator's NAT64 prefix is
   2001:db8:a:b::/96, then the operator can route
   2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/96 to NAT64 B.

This sentence is too long and cumbersome, and would benefit from being split
(which would also fix some awkward missing commas).  How’s this?:

NEW
   For example, suppose an operator is using the RFC1918 address
   space 10.0.0.0/8 internally.  That operator might want to route
   10.0.0.0/8 through NAT64 device A, and the rest of the IPv4 space
   through NAT64 device B.  If the operator's NAT64 prefix is
   2001:db8:a:b::/96, then the operator can route
   2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/96 to NAT64 B.
END