[Softwires] MAP-T to Standards Track

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 01 December 2014 12:00 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5E11A1B43 for <softwires@ietfa.amsl.com>; Mon, 1 Dec 2014 04:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 mOuayBSIn4Gu for <softwires@ietfa.amsl.com>; Mon, 1 Dec 2014 04:00:17 -0800 (PST)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBD11A036F for <softwires@ietf.org>; Mon, 1 Dec 2014 04:00:17 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-8b-547c0865da81
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 83.8F.03307.5680C745; Mon, 1 Dec 2014 07:19:17 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 07:00:15 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Softwires WG <softwires@ietf.org>
Thread-Topic: MAP-T to Standards Track
Thread-Index: AdANXl4yTzBHXq36S6OOovplkxHzwQ==
Date: Mon, 01 Dec 2014 12:00:15 +0000
Message-ID: <E87B771635882B4BA20096B589152EF628986992@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyuXRPlG4qR02IwZxnRhaHl21lcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvEf3cwFm9krnu44zN7A2MPWxcjJISFgItH4axorhC0mceHe eqA4F4eQwBFGiYszd0M5yxglmg/8YwapYgPq2LDzMxOILSKgKvFk5wOwScICihIvl76HiqtJ /J65EaieA8jWk/j/OxIkzCKgIrHu3j52EJtXwFfiQ/8rsFZGoMXfT60Ba2UWEJe49WQ+E8RB AhJL9pxnhrBFJV4+/gd1qJLEx9/z2SHq9SRuTJ3CBmFrSyxb+JoZYr6gxMmZT1gmMArPQjJ2 FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwkI9JsOnuYNzz0vIQowAHoxIPr0FmdYgQa2JZ cWXuIUZpDhYlcd5ZtfOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBqTPPlOb3g15eO76Xv OX5vqthieTj528IEAY4Hq+wUH7pFrIwVDPbXeNX1UMxGdUn7DsGX30I9uIUulpcYXRHZ1Xdx 9/IHTiF71sgu0ve5szJdh13yhtHvmVGBS47FstUohsbklecoekeZn7j/wXn19ttczx4xf5lz 9/65q2c5ju/1qJxu63VIiaU4I9FQi7moOBEApaE/ykUCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/JFdmNAlcNQ6IQEpU284I87zp9f4
Subject: [Softwires] MAP-T to Standards Track
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 12:00:19 -0000

Hi all,
    After looking at the responses on the mailing list, we find that 
there is consensus to change MAP-T into a Standards Track document. 
However, there was an issue raised regarding preservation of DF=1 and 
MF=1 and this warranted inclusion of some advisory text in the draft. 
The following text has been added (Thanks RĂ©mi and Tom) in section 10 of 
version -07.

"Note: The NAT64 [RFC6145] mechanism is not entirely losseless and when 
applied to IPv4 communication paths that traverse double NAT64 networks, 
IPv4 originated ICMP-independent PathMTU Discovery as specified in 
[RFC4821], ceases to be entirely reliable. This is because the[RFC4821] 
  defined DF=1/MF=1 combination, after NAT64	translation, becomes 
DF=0/MF=1."

Authors, Please resubmit a new version (-08) on Standards Track.

Thanks
Suresh & Yong