Re: [bmwg] the draft "Benchmarking Methodology for IPv6 Transition Technologies"

Marius Georgescu <liviumarius-g@is.naist.jp> Fri, 21 August 2015 06:57 UTC

Return-Path: <liviumarius-g@is.naist.jp>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77B1A1BFC for <bmwg@ietfa.amsl.com>; Thu, 20 Aug 2015 23:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbn2RQlmTMSy for <bmwg@ietfa.amsl.com>; Thu, 20 Aug 2015 23:57:27 -0700 (PDT)
Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [163.221.80.91]) by ietfa.amsl.com (Postfix) with ESMTP id 743EE1A1B46 for <bmwg@ietf.org>; Thu, 20 Aug 2015 23:57:27 -0700 (PDT)
Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id 15BAABD5; Fri, 21 Aug 2015 15:57:26 +0900 (JST)
Received: from naist-wavenet125-198.naist.jp (naist-wavenet125-198.naist.jp [163.221.125.198]) by mailpost22.naist.jp (Postfix) with ESMTPSA id 0047DBD4; Fri, 21 Aug 2015 15:57:25 +0900 (JST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6499C228-6188-49AF-BDF2-69538EA50F8B"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Marius Georgescu <liviumarius-g@is.naist.jp>
In-Reply-To: <A559E8A1-0CAA-4468-9F16-ABE0AE2870CB@cisco.com>
Date: Fri, 21 Aug 2015 15:57:25 +0900
Message-Id: <AF6809CF-DD28-4A77-90AD-A85C7050AFDA@is.naist.jp>
References: <E063AAC7-4CF7-414C-AE35-321C9AA81D38@is.naist.jp> <CD932701-A631-40BF-8348-EB6ADDD6D227@cisco.com> <6A01278C-E8AE-4A44-81DB-913483C51CDB@cisco.com> <124B3D83-F1BE-4C26-B26B-43DAF41FCD5A@is.naist.jp> <A559E8A1-0CAA-4468-9F16-ABE0AE2870CB@cisco.com>
To: "Fred Baker (fred)" <fred@cisco.com>
X-Mailer: Apple Mail (2.2098)
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21760.005
X-TM-AS-Result: No--5.394-5.0-31-10
X-imss-scan-details: No--5.394-5.0-31-10
X-TMASE-MatchedRID: pLrzZ2yoINWPvrMjLFD6eB5+URxv1WlBWDesRNOOJ5SGEL3ileQHE3h8 GTg/w7cypGgI6JJKreiKD+8G57PVNFlOqKNI2QkGlGudLLtRO1sL8TGleseLPAendw/iiMGQ4dJ viayscewQxaRWT4DlFZZkmXRvtVP1GhA/jdSevJbBtFDYGmaWKpkShYcLpGH9H06W6rwtvNUPmN N74zkTtEEe/bRpAYoLnl5FOmrYECwxf2YzVzIJI1gowyUWHgGdJd2n2XoSRFlNxaJbgJRuON8mf xiZsPBGtzDrWJxEioPc/PswyUm6tFATqJs9uVXRQ5lZokGzOaovcKmqjEcY3rNl/yOgFTFswiyn jxqNU+Sqk8r1Ooo8mP++gjOGfzBm5UcZtwNsCroURSScn+QSXlkMvWAuahr866cYQGo+KX6kSYi /oi9rTtAtbEEX0MxBnH7sbImOEBTy534wDh/JFpF/8C9Y3zO/QqKPbj958jrIRCfou241JlvQkL cb33XRu43DTRRG4Te8bRvOrEJE+94zsDvFoxiDJo7V0eMlEnrAvpLE+mvX8g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/bmwg/9YbnbxkpHJ6NULrSqcWrD4akvxA>
Cc: bmwg@ietf.org
Subject: Re: [bmwg] the draft "Benchmarking Methodology for IPv6 Transition Technologies"
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 06:57:28 -0000

That is an interesting thought. I’ll think about how to shape the cases to stay within the scope claimed in the title and throughout the paper: “IPv6 transition technologies”. 
To be more specific, my biggest concern is with NAT44 and NAT444, which in conjuncture with other technologies can actually represent a transition method to IPv6, but by themselves do not. Anyways, I need to process the thought further. Thank you very much for another good suggestion.

Best regards,
Marius
 

> On Aug 21, 2015, at 15:36, Fred Baker (fred) <fred@cisco.com> wrote:
> 
> The opposite. You're very carefully testing translation from IPv4 to IPv6 to IPv4. As a result, you've done all the legwork to test IPv4/IPv4 or IPv6/IPv6 translation. Why not simply make that be among your cases?