IETF Logo Mail Archive

Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt

"S.P.Zeidler" <spz@serpens.de> Wed, 02 March 2011 07:27 UTC

Return-Path: <spz@serpens.de>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C8B3A6C24 for <nat66@core3.amsl.com>; Tue, 1 Mar 2011 23:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPN6hfJmwHZp for <nat66@core3.amsl.com>; Tue, 1 Mar 2011 23:27:44 -0800 (PST)
Received: from serpens.de (serpens.de [IPv6:2001:16e0:101:219:280:10ff:fe00:1731]) by core3.amsl.com (Postfix) with ESMTP id E08A93A6C2A for <nat66@ietf.org>; Tue, 1 Mar 2011 23:27:43 -0800 (PST)
Received: from serpens.de (spz@localhost [127.0.0.1]) by serpens.de (8.14.4/8.13.3) with ESMTP id p227SQY1026003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 08:28:35 +0100 (MET)
Received: (from spz@localhost) by serpens.de (8.14.4/8.12.11) id p227SOhE016835; Wed, 2 Mar 2011 08:28:25 +0100 (MET)
Date: Wed, 2 Mar 2011 08:28:23 +0100
From: "S.P.Zeidler" <spz@serpens.de>
To: Fred Baker <fred@cisco.com>
Message-ID: <20110302072822.GA20321@serpens.de>
References: <20110228223003.13022.10464.idtracker@localhost> <845A4F08-46E7-48EE-B294-0C8368BAD1CB@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <845A4F08-46E7-48EE-B294-0C8368BAD1CB@cisco.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: NAT66 HappyFunBall <nat66@ietf.org>
Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2011 07:27:45 -0000

Hi,

chapter 5, dot 5, >>to "outside" the of it,<< surplus the

in section 5.1 I would not say that the -benefits- are consistent
with the app requirements; the -drawbacks- need to be acceptable for
app requirements instead. How about:

--- snip ---
In light of the above, network planners considering the use of NPTv6	
translation should carefully consider the kinds of applications that	
they will need to run in the future, and determine whether the limitation
on the types of applications that is imposed by using NPTv6 is acceptable,
and will be outweighed by the address stability and provider independence
benefits. It's a trade-off.
--- snip ---

regards,
	spz
-- 
spz@serpens.de (S.P.Zeidler)

v2.8.7 | Report a Bug | By Email