[Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 05 October 2012 15:15 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6121F869C; Fri, 5 Oct 2012 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.11
X-Spam-Level:
X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOdQdSLKZt31; Fri, 5 Oct 2012 08:14:59 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD221F872E; Fri, 5 Oct 2012 08:14:54 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id DF12FA3830; Fri, 5 Oct 2012 08:14:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 50DC51C07FE; Fri, 5 Oct 2012 08:14:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 42A131C0567; Fri, 5 Oct 2012 08:14:49 -0700 (PDT)
Message-ID: <506EF961.7040809@joelhalpern.com>
Date: Fri, 05 Oct 2012 11:14:41 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "A. Jean Mahoney" <mahoney@nostrum.com>
References: <506E0BD9.8050705@nostrum.com>
In-Reply-To: <506E0BD9.8050705@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" <softwires@ietf.org>, gen-art@ietf.org, Yong Cui <cuiyong@tsinghua.edu.cn>, draft-ietf-softwire-stateless-4v6-motivation@tools.ietf.org
Subject: [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2012 15:15:01 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-softwire-stateless-4v6-motivation-04
     Motivations for Carrier-side Stateless IPv4 over IPv6
         Migration Solutions
Reviewer: Joel M. Halpern
Review Date: 5-Oct-2012
IETF LC End Date: 17-Oct-2012
IESG Telechat date: 25-Oct-2012

Summary: This document is nearly ready for publication as an 
Informational RFC.

Major issues:
     I may be misreading the first sub-paragraph in section 3.3.2.  It 
seems to assert that no ALGs are necessary with stateless 4v6 solution 
as "the payload of IPv4 packets is not altered in the path."  This seems 
to make very strong assumptions on the end host behavior, which are not 
called out in the document.

Minor issues:
     It is unfortunate that the elaborations on the motivations do not 
correlate with the initial list of those motivations.  They are not in 
the same order, and do not use the same titles.  This makes it harder 
for the reader who, after reading the base list, is looking for more 
explanation of item(i).

     The description of the anycast capability (Section 3 bullet 5 and 
section 3.2.1 first bullet) is very unclear.  Since packets are not 
addressed to the address translator, this reader is left confused as to 
what "anycast" capability is preserved by this and damaged by stateful 
NAT.  A few additional words in section 3.2.1 would be helpful.

     The issues raised in section 4 of the document ("Discussion") are 
interesting.  But they do not seem related to the motivation for seeking 
a stateless v4v6 solution.  They seem to be details of how such a 
solution might be built.  Why is this section in this document?

Nits/editorial comments: