From jan@go6.si Sun Apr 1 00:36:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389A621F8698 for ; Sun, 1 Apr 2012 00:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdwhglQXY5F for ; Sun, 1 Apr 2012 00:36:48 -0700 (PDT) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id A993A21F8692 for ; Sun, 1 Apr 2012 00:36:48 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 54E6422B4069 for ; Sun, 1 Apr 2012 09:36:46 +0200 (CEST) Message-ID: <4F780590.2030401@go6.si> Date: Sun, 01 Apr 2012 09:36:48 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B921E47D44C@SZXEML506-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Have the WG drop other stateless solutions already? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 07:36:49 -0000 On 4/1/12 3:24 AM, Fuyu (Eleven) wrote: > Agree. I think we shouldn't drop other stateless solutions as: > > draft-cui-softwire-b4-translated-ds-lite-05 > draft-penno-softwire-sdnat-02 > > They are all belong to stateless scope and with the same network > architecture of IPv4 traffic across IPv6 access network as MAP and > 4rd-U. Please, don't make it even worse as it is now. Internet community awaited the decision and clear recommendation for one stateless A+P standard, we managed to narrow the selection down to two and we were not able to decide at the end. This results in some vendors deploying MAP combo, others 4RD-U and using our inability to choose for their competitive fight. For the sake of the Internet, don't bring back all the others, let's consider and respect result of MAP team (even if that still brought us two of them). As I suggested during Friday Softwires WG, we *need* to decide ASAP. Cheers, Jan From jan@go6.si Sun Apr 1 00:39:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A65A21F86A0 for ; Sun, 1 Apr 2012 00:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[AWL=-0.150, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDxZpr9uD6Dx for ; Sun, 1 Apr 2012 00:39:01 -0700 (PDT) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id 7E11221F8693 for ; Sun, 1 Apr 2012 00:39:01 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id D6B3122B4069 for ; Sun, 1 Apr 2012 09:38:58 +0200 (CEST) Message-ID: <4F780612.7020508@go6.si> Date: Sun, 01 Apr 2012 09:38:58 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> In-Reply-To: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 07:39:02 -0000 On 3/31/12 4:56 PM, Rémi Després wrote: > Alain, > > You had initially announced that either one specification would be > chosen for standard track (among T, E, and U), or specifications > would all become WG drafts on the experimental track ((*) below). In > Paris: (a)The MAP proposal became presented as an inseparable T+E > package. (b) The WG couldn't make a consensus choice between T+E or > U. > > Now publishing both MAP-T+E and 4rd-U as WG documents on the > experimental track, is therefore consistent with what was announced > (and was also asked for by several at the end of the meeting). As you > explained, this won't prevent from selecting one for standard track > later on, based on better market experience. Not sure that was the outcome - as I understood Alain, we'll make a decision here on mailinglist in a very short period of time. Cheers, Jan From chenycmx@gmail.com Sun Apr 1 00:44:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE1921F86A0 for ; Sun, 1 Apr 2012 00:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.797 X-Spam-Level: * X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn70czIHBnrV for ; Sun, 1 Apr 2012 00:44:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1741121F8697 for ; Sun, 1 Apr 2012 00:44:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so3357462iaz.31 for ; Sun, 01 Apr 2012 00:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=Ln1Y2dohy0D1MV25H0BWnW1YQdZbH0x7Yy2GMGMhh0Y=; b=jOo6QJECxVYMxN4FYpPDnphz6l+3aaTlBwVr/ZeKINGRK+HqeNbyoe5ZvNfrJGEU/U yFwWDjFretTDKXGfW8aFZE1bHiBKxP5C9x8EPcAEQKbDL97u+G22oZOCz3BV5IvKn7O0 yrbBE8o3akcJ1kjZHESNJboEbYmmLjBXKSdtDgERzAG4mmPuoOieTBboWDeU5Rlaq0Gi 6K4zyRT0tmaJgOT2NdVxsonfjgKksqnF7bknNBxsVHP4pfxuHgHOCTvsLIDDZ14VOEhJ gFkIKw98ozjsso/ssb4GMyAdKf4h30uGooPGietjHBD8g2GIBfMrBmrUV3GiC1DndVB2 utfg== Received: by 10.50.140.101 with SMTP id rf5mr2649780igb.27.1333266285661; Sun, 01 Apr 2012 00:44:45 -0700 (PDT) Received: from flashfox-PC ([166.111.68.233]) by mx.google.com with ESMTPS id vr4sm18188520igb.1.2012.04.01.00.44.42 (version=SSLv3 cipher=OTHER); Sun, 01 Apr 2012 00:44:44 -0700 (PDT) Date: Sun, 1 Apr 2012 15:44:42 +0800 From: "Yuchi Chen" To: sunjingwen References: X-Priority: 3 X-GUID: 332E22C3-804D-4917-85A3-582853E03CB2 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <2012040115443836452736@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart307385056321_=----" Cc: softwires WG Subject: Re: [Softwires] [softwire]Basic Requirements for Customer Edge Routers X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 07:44:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart307385056321_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBTdW4sDQoNCkl0IHNlZW1zIHRoYXQgeW91IGhhdmUgbWlzc2VkIHNvbWUgc3RhdGVtZW50 cyBpbiB0aGUgZHJhZnQuIEluIHNlY3Rpb24gNC4zLCANCnRoZXJlIGFyZSBzb21lIGxpbmVzIGNs YXJpZnlpbmcgMyBwcmluY2lwbGVzIGZvciBJUHY0IGludGVyZmFjZSBzZWxlY3Rpb24sIGp1c3Qg DQphYm92ZSB0aGUgd29yZHMgeW91IHF1b3RlZDoNCj4xLiAgSVB2NiB0cmFuc3BvcnQgaXMgcHJl ZmVycmVkIG92ZXIgYW55IG90aGVyLg0KDQo+Mi4gIExlc3MgYWRkcmVzcyB0cmFuc2xhdGlvbiBv Y2N1cnJlbmNlcyBpcyBwcmVmZXJyZWQgb3ZlciBtb3JlLg0KICAgICAgIFtSRkM1ODY0XVtJLUQu ZG9ubGV5LW5hdDQ0NC1pbXBhY3RzXQ0KDQo+My4gIFRoZSBjbG9zZXIgdGhlIHN0YXRlIGlzIHRv IHRoZSBlZGdlLCB0aGUgYmV0dGVyLltSRkMxOTU4XQ0KQWNjb3JkaW5nIHRvIHRoZSBmaXJzdCBw cmluY2lwbGUsIHRoZSBJUHY2IHRyYW5zcG9ydCBpcyBwcmlvciB0byBhbnkgIG90aGVyLiBUaGF0 IA0KaXMgdGhlIHJlYXNvbiB3aHkgdGhlIERTLUxpdGUgdHVubmVsIGludGVyZmFjZSBpcyBwcmVm ZXJyZWQgdG8gbmF0aXZlIElQdjQgb25lLg0KDQpBY3R1YWxseSwgSSBoYXZlIGFub3RoZXIgcXVl c3Rpb24gYWJvdXQgdGhpcyBwb2ludC4gSSB0aGluayB0aGUgcXVlc3Rpb24gaXMgDQpub3QgJ1do eSBub3QgdXNlIE5hdGl2ZSBJUHY0IGludGVyZmFjZSBmb3IgYmV0dGVyIHBlcmZvcm1hbmNlJywg YnV0ICdXaHkgcHJlZmVyDQp0aGUgSVB2NiB0dW5uZWwgaW50ZXJmYWNlIHRvIHRoZSBuYXRpdmUg SVB2NCBpbnRlcmZhY2UnLiBJIGRpZG4ndCBmaW5kIHRoZSBhbnN3ZXIgaW4NCnRoZSBkcmFmdC4g UGVyaGFwcyBJJ3ZlIG1pc3NlZCBzb21lIHdvcmRzIGFzIHdlbGwuIElNSE8sIGEgY2xhcmlmaWNh dGlvbiBvZiB0aGUNCnJlYXNvbiBjb3VsZCBiZSBwcm92aWRlZCBpbiB0aGUgZHJhZnQsIGFuZCB0 aHVzIHRoZSBwcmluY2lwbGVzIGFib3V0IG1pZ2h0IHNlZW0NCnRvIGJlIG1vcmUgY29udmljdGl2 ZS4NCg0KQmVzdCBSZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbg0KDQpGcm9tOiBzdW5qaW5nd2Vu DQpEYXRlOiAyMDEyLTA0LTAxIDExOjA1DQpUbzogbWFyazsgb3QNCkNDOiBzb2Z0d2lyZXMgV0cN ClN1YmplY3Q6IFtTb2Z0d2lyZXNdIFtzb2Z0d2lyZV1CYXNpYyBSZXF1aXJlbWVudHMgZm9yIEN1 c3RvbWVyIEVkZ2UgUm91dGVycw0KRGVhciBhdXRob3JzLA0KSSd2ZSByZWFkIHRoZSBkcmFmdC10 b3duc2xleS10cm9hbi1pcHY2LWNlLXRyYW5zaXRpb25pbmctMDIsIGFuZCBJIGhhdmUgYSBxdWVz dGlvbiBjb25mdXNlZCBtZSB2ZXJ5IG11Y2guDQogDQpJbiBzZWN0aW9uIDQuMywgDQo+SW4gdGhl IGNhc2Ugb2YgRFMtTGl0ZSBhbmQgTmF0aXZlIElQdjQgY29uZmlndXJhdGlvbiBiZWluZyBwcmVz ZW50IGF0IHRoZSBzYW1lIHRpbWUsIA0KPkRTLUxpdGUgd291bGQgYmUgcHJlZmVycmVkIGFzIGl0 IHVzZXMgSVB2NiB0cmFuc3BvcnQgYW5kIE5hdGl2ZSBJUHY0IGRvZXMgbm90Lg0KIA0KRG8geW91 IG1lYW4gaWYgdGhlIENFIHJlY2VpdmUgdXNlcqGvcyBJUHY0IHBhY2tldCwgaXQgd2lsbCBjaG9v c2UgdG8gdXNlIHR1bm5lbCByYXRoZXIgdGhhbiBJUHY0Pw0KQnV0IEkgdGhpbmsgaWYgdXNlIG5h dGl2ZSBJUHY0IGNhbiBhbHNvIGFycml2ZSB0aGUgZGVzdGluYXRpb24gKElQdjQgaW50ZXJuZXQp LCB0aGUgbmF0aXZlIElQdjQgd2lsbCBtb3JlIGVmZmljaWVudCB0aGFuIHRoZSB0dW5uZWwsIGJl Y2F1c2UgaXQgbmVlZG6hr3QgZW5jYXBzdWxhdGlvbiBhbmQgZGVjYXBzdWxhdGlvbi4NCiANClBs ZWFzZSBjb3JyZWN0IG1lIGlmIHRoZXJlIGlzIGFueSBtaXN0YWtlfg0KIA0KICAgICBUaGFuayB5 b3UNCg0KDQoNCg0KQmVzdCByZWdhcmRzIQ0Kc3VuIGppbmd3ZW4= ------=_001_NextPart307385056321_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Sun,
 
It seems that you have missed some sta= tements=20 in the draft. In section 4.3,
there are some lines clarifying 3= =20 principles for IPv4 interface selection, just
above the words you quoted:
>1.  IPv6 transport is preferred over any other.

>2.  Less address translation occurrences is preferred over more.
       [RFC5864][I-D.donley-nat444-impacts]

>3.  The closer the state is to the edge, the better.[RFC1958]
According to the first=20 principle, the IPv6 transport is prior to any  other. That
is the reason why the DS-Lite tunnel i= nterface=20 is preferred to native IPv4 one.
 
Actually, I have another question = ;about=20 this point. I think the question is
not 'Why not use Native IPv4 interface= for=20 better performance', but 'Why prefer
the IPv6 tunnel interface to the = native=20 IPv4 interface'. I didn't find the answer in
the draft. Perhaps I've missed some wo= rds as=20 well. IMHO, a clarification of the
reason could be provided in the draft,= and=20 thus the principles about might seem
to be more convictive.
 
Best Regards!
Yuchi Chen
 
From: sunjingwen
Date: 2012-04-01 11:05
Subject: [Softwires] [softwire]Basic Requirements for Cus= tomer=20 Edge Routers

Dear authors,

I've read the draft-townsley-troan-ipv6-ce-transitioning-02, = and I=20 have a question confused me very much.

 

In section 4.3,

<= SPAN=20 style=3D"FONT-FAMILY: =CB=CE=CC=E5; FONT-SIZE: 12pt; mso-bidi-font-family:= =CB=CE=CC=E5; mso-font-kerning: 0pt"=20 lang=3DEN-US>>In the case of DS-Lite and Native IPv4 configuration bein= g=20 present at the same time,

<= SPAN=20 style=3D"FONT-FAMILY: =CB=CE=CC=E5; FONT-SIZE: 12pt; mso-bidi-font-family:= =CB=CE=CC=E5; mso-font-kerning: 0pt"=20 lang=3DEN-US>>DS-Lite would be preferred as it uses IPv6 transport=20 and Native IPv4 does not.

 

Do you mean if the CE receive user=A1=AFs IPv4 packet, it wil= l choose to=20 use tunnel rather than IPv4?

But I think if use native IPv4 can also arrive the destinatio= n (IPv4=20 internet), the native IPv4 will more efficient than the tunnel, because it= =20 needn=A1=AFt encapsulation and decapsulation.

 

Please correct me if there is any mistake~<= /P>

 

     Thank=20 you

 
Best regards!
sun jingwen
------=_001_NextPart307385056321_=------ From ichiroumakino@gmail.com Sun Apr 1 01:42:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21021F8652 for ; Sun, 1 Apr 2012 01:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMnCKzkrH+XL for ; Sun, 1 Apr 2012 01:42:38 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0921F8650 for ; Sun, 1 Apr 2012 01:42:37 -0700 (PDT) Received: by werb10 with SMTP id b10so1413029wer.31 for ; Sun, 01 Apr 2012 01:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=4SnrlxweiJE7MMEuuOquvZte+iCTG68yekUClsWJpfU=; b=t616polOLiSZ97TDDawG+kDP+BfGCikXeemWBN97RQhC8h1YNqwnYSCsakGh7TR4US PRwHCRtXfaOy8icGbfT8o6ZfsN6H3KuRhI0nvI3SVMwfZkN3gZ4GQYMiHjo6S+NNMc3L 7FLZ86TUu9mPHLEym+hkK46B74RSJcEXEG7sy9uZG179VFRwi/lzJCbzQqVuiQECjTtw LncroVRLamkNDubwLy/CrJZYV+zHTi0wHXXQpHveqyyGUMBApQDx9P42zFrAMFvJYXmb 26QBqaBCaO9LPIuFCoXHgEsy/Ogq0PyM99nwW4uHs6GQ3H4/MDNHebVZIUcoPTF4olVp niiQ== Received: by 10.180.107.101 with SMTP id hb5mr15708390wib.3.1333269757089; Sun, 01 Apr 2012 01:42:37 -0700 (PDT) Received: from dhcp-10-61-96-216.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ea6sm23139191wib.5.2012.04.01.01.42.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 01:42:36 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=GB2312 From: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Priority: 3 In-Reply-To: <2012040115443836452736@gmail.com> Date: Sun, 1 Apr 2012 10:42:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2012040115443836452736@gmail.com> To: chenycmx X-Mailer: Apple Mail (2.1257) Cc: softwires WG Subject: Re: [Softwires] [softwire]Basic Requirements for Customer Edge Routers X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 08:42:38 -0000 > It seems that you have missed some statements in the draft. In section = 4.3, > there are some lines clarifying 3 principles for IPv4 interface = selection, just > above the words you quoted: > >1. IPv6 transport is preferred over any other. >=20 > >2. Less address translation occurrences is preferred over more. > [RFC5864][I-D.donley-nat444-impacts] >=20 > >3. The closer the state is to the edge, the better.[RFC1958] >=20 > According to the first principle, the IPv6 transport is prior to any = other. That > is the reason why the DS-Lite tunnel interface is preferred to native = IPv4 one. > =20 > Actually, I have another question about this point. I think the = question is > not 'Why not use Native IPv4 interface for better performance', but = 'Why prefer > the IPv6 tunnel interface to the native IPv4 interface'. I didn't find = the answer in > the draft. Perhaps I've missed some words as well. IMHO, a = clarification of the > reason could be provided in the draft, and thus the principles about = might seem > to be more convictive. the idea was to allow for a controlled move from a native IPv4 = connection (that is being sunet for an IPv6 only access) to IPv4 over = DS-lite. the policy table proposed is all about IPv4 exit, not trying to = optimize what IPv4 link-layer may give the best IPv4 service. cheers, Ole From chenycmx@gmail.com Sun Apr 1 04:38:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290B521F867B for ; Sun, 1 Apr 2012 04:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=2.547, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PalKLGzwtMKk for ; Sun, 1 Apr 2012 04:38:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30221F8622 for ; Sun, 1 Apr 2012 04:38:54 -0700 (PDT) Received: by iazz13 with SMTP id z13so3503545iaz.31 for ; Sun, 01 Apr 2012 04:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=jnTqHD+mqGagBZTVALuew8NhB5WIa4TnehNMfb06UsU=; b=V7oV9dEm5UIqZxGi7GdQTutSbUu4L16r1G2x9Z1/76B7OCLlxjzaX0cVt3HBnMsr+b +IgU33rLIJTRXpJLY+B3Mq+GETM+LlbE80cDMJ5DLWiByyWpcQlqSIVH9zNijbzoAAHO WNgrEp5pZ0pL+Fp8zP3HNpnQgMkqk1anObtu11Gh8yV0dn5GyLrQY3vf9BCDmOpwApNz ohLNhgs9OGHrWE7GcxjcpJU52Rwe6k5YAWAtubBo0qtXFKiDs81BYKORGWD1te8poJ9j TtQHpFNa9qwBX1G3H19CJHJ8VhmoGHJJPEFHg3nFWdyOGcwsntGivO+yd1h0ElFOOxa9 NkOQ== Received: by 10.50.197.132 with SMTP id iu4mr3443258igc.74.1333280334085; Sun, 01 Apr 2012 04:38:54 -0700 (PDT) Received: from user-902eaffedc ([166.111.68.233]) by mx.google.com with ESMTPS id cg9sm8571907igb.17.2012.04.01.04.38.48 (version=SSLv3 cipher=OTHER); Sun, 01 Apr 2012 04:38:53 -0700 (PDT) Date: Sun, 1 Apr 2012 19:38:48 +0800 From: "Yuchi Chen" To: =?utf-8?B?T2xlIFRyw7hhbg==?= References: <2012040115443836452736@gmail.com>, X-Priority: 3 X-GUID: C384BF84-6667-45EF-8BC4-709976260DEE X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201204011938349849434@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart321325238663_=----" Cc: softwires WG Subject: Re: [Softwires] [softwire]Basic Requirements for Customer Edge Routers X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 11:38:55 -0000 This is a multi-part message in MIME format. ------=_001_NextPart321325238663_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBPbGUsDQpUaGFua3MgZm9yIHlvdXIgcXVpY2sgYW5kIHBhdGllbnQgcmVwbHkuSSB3YXMg anVzdCB3b25kZXJpbmcgd2h5IHRoZSBJUHY2IGludGVyZmFjZSANCmlzIHByZWZlcnJlZCB0byB0 aGUgb3RoZXJzLg0KU28gdGhlIHBvaW50IGlzIHRoYXQgYXMgdGhlIGFjY2VzcyBuZXR3b3JrIGlz IHRyYW5zaXRpb25pbmcgdG8gRFMtTGl0ZSwgdGhlIG5hdGl2ZSBJUHY0IA0KaW50ZXJmYWNlIGlz IGJlY29taW5nIG1vcmUgYW5kIG1vcmUgdW5saWtlbHkgdG8gYmUgdXNlZCwgYW5kIGhlbmNlIHRo ZSBJUHY2IHRyYW5zcG9ydCANCnNob3VsZCBiZSBwcmlvciB0byB0aGUgSVB2NCB0cmFuc3BvcnQs IGluIG9yZGVyIHRvIGVuc3VyZSBhIGJldHRlciBJUHY0IHNlcnZpY2UuIEkgaG9wZQ0KSSBoYXZl IHVuZGVyc3Rvb2QgaXQgY29ycmVjdGx5LiANCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkg Q2hlbg0KDQpGcm9tOiBPbGUgVHLDuGFuDQpEYXRlOiAyMDEyLTA0LTAxIDE2OjQyDQpUbzogY2hl bnljbXgNCkNDOiBzdW5qaW5nd2VuOyBzb2Z0d2lyZXMgV0cNClN1YmplY3Q6IFJlOiBbU29mdHdp cmVzXSBbc29mdHdpcmVdQmFzaWMgUmVxdWlyZW1lbnRzIGZvciBDdXN0b21lciBFZGdlIFJvdXRl cnMNCj4gSXQgc2VlbXMgdGhhdCB5b3UgaGF2ZSBtaXNzZWQgc29tZSBzdGF0ZW1lbnRzIGluIHRo ZSBkcmFmdC4gSW4gc2VjdGlvbiA0LjMsDQo+IHRoZXJlIGFyZSBzb21lIGxpbmVzIGNsYXJpZnlp bmcgMyBwcmluY2lwbGVzIGZvciBJUHY0IGludGVyZmFjZSBzZWxlY3Rpb24sIGp1c3QNCj4gYWJv dmUgdGhlIHdvcmRzIHlvdSBxdW90ZWQ6DQo+ID4xLiAgSVB2NiB0cmFuc3BvcnQgaXMgcHJlZmVy cmVkIG92ZXIgYW55IG90aGVyLg0KPiANCj4gPjIuICBMZXNzIGFkZHJlc3MgdHJhbnNsYXRpb24g b2NjdXJyZW5jZXMgaXMgcHJlZmVycmVkIG92ZXIgbW9yZS4NCj4gICAgICAgIFtSRkM1ODY0XVtJ LUQuZG9ubGV5LW5hdDQ0NC1pbXBhY3RzXQ0KPiANCj4gPjMuICBUaGUgY2xvc2VyIHRoZSBzdGF0 ZSBpcyB0byB0aGUgZWRnZSwgdGhlIGJldHRlci5bUkZDMTk1OF0NCj4gDQo+IEFjY29yZGluZyB0 byB0aGUgZmlyc3QgcHJpbmNpcGxlLCB0aGUgSVB2NiB0cmFuc3BvcnQgaXMgcHJpb3IgdG8gYW55 ICBvdGhlci4gVGhhdA0KPiBpcyB0aGUgcmVhc29uIHdoeSB0aGUgRFMtTGl0ZSB0dW5uZWwgaW50 ZXJmYWNlIGlzIHByZWZlcnJlZCB0byBuYXRpdmUgSVB2NCBvbmUuDQo+ICANCj4gQWN0dWFsbHks IEkgaGF2ZSBhbm90aGVyIHF1ZXN0aW9uIGFib3V0IHRoaXMgcG9pbnQuIEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIGlzDQo+IG5vdCAnV2h5IG5vdCB1c2UgTmF0aXZlIElQdjQgaW50ZXJmYWNlIGZvciBi ZXR0ZXIgcGVyZm9ybWFuY2UnLCBidXQgJ1doeSBwcmVmZXINCj4gdGhlIElQdjYgdHVubmVsIGlu dGVyZmFjZSB0byB0aGUgbmF0aXZlIElQdjQgaW50ZXJmYWNlJy4gSSBkaWRuJ3QgZmluZCB0aGUg YW5zd2VyIGluDQo+IHRoZSBkcmFmdC4gUGVyaGFwcyBJJ3ZlIG1pc3NlZCBzb21lIHdvcmRzIGFz IHdlbGwuIElNSE8sIGEgY2xhcmlmaWNhdGlvbiBvZiB0aGUNCj4gcmVhc29uIGNvdWxkIGJlIHBy b3ZpZGVkIGluIHRoZSBkcmFmdCwgYW5kIHRodXMgdGhlIHByaW5jaXBsZXMgYWJvdXQgbWlnaHQg c2VlbQ0KPiB0byBiZSBtb3JlIGNvbnZpY3RpdmUuDQoNCnRoZSBpZGVhIHdhcyB0byBhbGxvdyBm b3IgYSBjb250cm9sbGVkIG1vdmUgZnJvbSBhIG5hdGl2ZSBJUHY0IGNvbm5lY3Rpb24gKHRoYXQg aXMgYmVpbmcgc3VuZXQgZm9yIGFuIElQdjYgb25seSBhY2Nlc3MpIHRvIElQdjQgb3ZlciBEUy1s aXRlLiB0aGUgcG9saWN5IHRhYmxlIHByb3Bvc2VkIGlzIGFsbCBhYm91dCBJUHY0IGV4aXQsIG5v dCB0cnlpbmcgdG8gb3B0aW1pemUgd2hhdCBJUHY0IGxpbmstbGF5ZXIgbWF5IGdpdmUgdGhlIGJl c3QgSVB2NCBzZXJ2aWNlLg0KDQpjaGVlcnMsDQpPbGU= ------=_001_NextPart321325238663_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear Ole,
Thanks for your quick and patient repl= y.I was=20 just wondering why the IPv6 interface
is preferred to the others.
So the point is that as the access net= work is=20 transitioning to DS-Lite, the native IPv4
interface is becoming more and more un= likely=20 to be used, and hence the IPv6 transport
should be prior to the IPv4 transport,= in=20 order to ensure a better IPv4 service. I hope
I have understood it correctly.
 
Best regards!
Yuchi Chen
 
Date: 2012-04-01 16:42
To: chenycmx
CC: sunjingwen;= softwires WG
Subject: Re: [Softwires] [softwire]Basic Requirements for= =20 Customer Edge Routers
> It seems that you have missed = ;some statements in the draft. In section&nb= sp;4.3,
> there are some lines clarifying 3&= nbsp;principles for IPv4 interface selection, jus= t
> above the words you quoted:
> >1.  IPv6 transport is preferre= d over any other.
> 
> >2.  Less address translation o= ccurrences is preferred over more.
>        [RFC5864][I-D.don= ley-nat444-impacts]
> 
> >3.  The closer the state = is to the edge, the better.[RFC1958]
> 
> According to the first principle, = the IPv6 transport is prior to any &nbs= p;other. That
> is the reason why the DS-Lite = ;tunnel interface is preferred to native IPv= 4 one.
>  
> Actually, I have another question = about this point. I think the question = is
> not 'Why not use Native IPv4 = interface for better performance', but 'Why = prefer
> the IPv6 tunnel interface to the&n= bsp;native IPv4 interface'. I didn't find th= e answer in
> the draft. Perhaps I've missed som= e words as well. IMHO, a clarification = of the
> reason could be provided in the&nb= sp;draft, and thus the principles about migh= t seem
> to be more convictive.
 
the idea was to allow for a contro= lled move from a native IPv4 connection = ;(that is being sunet for an IPv6 only&= nbsp;access) to IPv4 over DS-lite. the polic= y table proposed is all about IPv4 exit= , not trying to optimize what IPv4 link= -layer may give the best IPv4 service.
 
cheers,
Ole
 
------=_001_NextPart321325238663_=------ From chenycmx@gmail.com Sun Apr 1 05:09:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F8921F888F for ; Sun, 1 Apr 2012 05:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be9+v07ghefU for ; Sun, 1 Apr 2012 05:09:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E08A121F88E1 for ; Sun, 1 Apr 2012 05:09:47 -0700 (PDT) Received: by iazz13 with SMTP id z13so3524940iaz.31 for ; Sun, 01 Apr 2012 05:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=yXJ2S3tCJTLpDCDIIrYXNHN6qIlT+MmG24RrCAdlBGo=; b=kHfEtKzqfmF1C9Fy/wSvAQSPkb8gFmX8Iv/XB5Hulzyxj8lZrc0bLOevPxNvx4Iodl OxrgJDCIc5Dieu3muxig9r0oi/RFPC4egpVE+SZEdqg/WbcpSBrTDd2r6shgzUkK2ywD VdabsT6Fygjs9A3FJihnD9BZJUMyPtCcxE5lPcUem4GAkULqsrWJUMZpAgxqOQVG5eoZ Ph9f81G5VVJ5X8yzJHTS2o3VPuP+CqW/6lxShkq03dahJQFhe1SanGuq14+CnvjajJ8e rVMy5aFGINz6gJ8eE535JYG+tZgJ2QtSuBDDNyaXzeFmF4ePMBX1HAirRd7YXZuVwd/0 NqCw== Received: by 10.50.220.168 with SMTP id px8mr2998842igc.29.1333282187246; Sun, 01 Apr 2012 05:09:47 -0700 (PDT) Received: from user-902eaffedc ([166.111.68.233]) by mx.google.com with ESMTPS id wf10sm6143705igb.8.2012.04.01.05.09.41 (version=SSLv3 cipher=OTHER); Sun, 01 Apr 2012 05:09:46 -0700 (PDT) Date: Sun, 1 Apr 2012 20:09:40 +0800 From: "Yuchi Chen" To: "Fuyu (Eleven)" References: <5D36713D8A4E7348A7E10DF7437A4B921E47D44C@SZXEML506-MBS.china.huawei.com>, X-Priority: 3 X-GUID: 51AA8A9B-70EB-4125-B7CE-C17547AB0B52 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012040120093546882810@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart308852406381_=----" Cc: softwires WG Subject: Re: [Softwires] Have the WG drop other stateless solutions already? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 12:09:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart308852406381_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBZdSwNCkkgdGhpbmsgdGhlIG1lYW5pbmcgb2Ygd29yZCAnc3RhdGVsZXNzJyBzaG91bGQg YmUgY2xhcmlmaWVkLiBUbyBteSBrbm93bGVkZ2UsIGJvdGggdGhlDQpkcmFmdC1jdWktc29mdHdp cmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlLTA1IGFuZCBkcmFmdC1wZW5uby1zb2Z0d2lyZS1zZG5h dC0wMiBhcmUNCnBlci1mbG93IHN0YXRlbGVzcywgYnV0IHBlci1zdWJzY3JpYmVyIHN0YXRlZnVs LiBUaGV5IGFyZSBub3QgYXMgc3RhdGVsZXNzIGFzIE1BUCBvcg0KNHJkLVUuIEkgZG9uJ3QgdGhp bmsgaXQncyBhcHByb3ByaWF0ZSB0byB0YWtlIHRoZXNlIHR3byBzdGF0ZWZ1bCBzb2x1dGlvbnMg aW50byBhY2NvdW50Lg0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0KDQpZdWNoaSBDaGVuDQoNCkZyb206 IEZ1eXUgKEVsZXZlbikNCkRhdGU6IDIwMTItMDQtMDEgMDk6MjQNClRvOiBTaGVuZyBKaWFuZw0K Q0M6IFNvZnR3aXJlcyBXRw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIEhhdmUgdGhlIFdHIGRy b3Agb3RoZXIgc3RhdGVsZXNzIHNvbHV0aW9ucyBhbHJlYWR5Pw0KQWdyZWUuDQpJIHRoaW5rIHdl IHNob3VsZG4ndCBkcm9wIG90aGVyIHN0YXRlbGVzcyBzb2x1dGlvbnMgYXM6DQoNCmRyYWZ0LWN1 aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUtMDUNCmRyYWZ0LXBlbm5vLXNvZnR3aXJl LXNkbmF0LTAyDQoNClRoZXkgYXJlIGFsbCBiZWxvbmcgdG8gc3RhdGVsZXNzIHNjb3BlIGFuZCB3 aXRoIHRoZSBzYW1lIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIG9mIElQdjQgdHJhZmZpYyBhY3Jvc3Mg SVB2NiBhY2Nlc3MgbmV0d29yayBhcyBNQVAgYW5kIDRyZC1VLg0KDQpDaGVlcnMgDQpZdQ0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hl bmcgSmlhbmcNClNlbnQ6IEZyaWRheSwgTWFyY2ggMzAsIDIwMTIgMTE6MDQgUE0NClRvOiBTb2Z0 d2lyZXMgV0cNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIEhhdmUgdGhlIFdHIGRyb3Agb3RoZXIgc3Rh dGVsZXNzIHNvbHV0aW9ucyBhbHJlYWR5Pw0KDQpIaSwgU29mdHdpcmVycywNCg0KSSBnZXQgdmVy eSBjb25mdXNlZCB3aGVuIEkgd2Fsa2VkIG91dCB0aGUgU29mdHdpcmUgbWVldGluZyB0aGlzIG1v cm5pbmcuIFdoeSBkaWQgd2Ugb25seSB0YWxrIGFib3V0IG1ha2luZyBjaG9pY2UgYmV0d2VlbiA0 cmQtVSBhbmQgTUFQPyBUaGVyZSBhcmUgYWxzbyBzZXZlcmFsIG90aGVyIHN0YXRlbGVzcyBzb2x1 dGlvbnMsIHRvby4gQXMgZmFyIGFzIEkgcmVjYWxsZWQsIHRoZSBTb2Z0d2lyZSBXRyBoYXZlIE5P VCBkZWNpZGVkIHRvIGRyb3AgdGhlbSBhdCBhbGwuIFRoZXkgc2hvdWxkIGJlIGRpc2N1c3NlZCB0 b2dldGhlciBhbmQgZXF1YWxseS4NCg0KSWYgdGhlIFNvZnR3aXJlIFdHIGlzIGdvaW5nIHRvIGNo b29zZSBzaW5nbGUgb25lIHNvbHV0aW9uLCBpdCBzaG91bGQgYmUgY2hvb3NlIGFtb25nIGFsbCB0 aGVzZSBzb2x1dGlvbnMuIFVudGlsIHdlIGhhdmUgZGVjaWRlZCBkcm9wIGFsbCBvdGhlciBzdGF0 ZWxlc3Mgc29sdXRpb25zLCB0aGlzIGlzIG5vdCBhIHR3by1ob3JzZSByYWNlLCB5ZXQuDQoNCkJl c3QgcmVnYXJkcywNCg0KU2hlbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxp bmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NvZnR3aXJlcw== ------=_001_NextPart308852406381_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Yu,
I think the meaning of word 'stateless= ' should=20 be clarified. To my knowledge, both the
draft-cui-softwire-b4-translated-ds-li= te-05=20 and draft-penno-softwire-sdnat-02 are
per-flow stateless, but per-subscriber= =20 stateful. They are not as stateless as MAP or
4rd-U. I don't think it's appropriate = to take=20 these two stateful solutions into account.
 
Best regards!
Yuchi Chen
 
Date: 2012-04-01 09:24
Subject: Re: [Softwires] Have the WG drop other stateless= =20 solutions already?
Agree.
I think we shouldn't drop other statele= ss solutions as:
 
draft-cui-softwire-b4-translated-ds-lite-05
draft-penno-softwire-sdnat-02
 
They are all belong to stateless scope&= nbsp;and with the same network architecture = of IPv4 traffic across IPv6 access network&n= bsp;as MAP and 4rd-U.
 
Cheers 
Yu
 
 
-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@= ietf.org] On Behalf Of Sheng Jiang
Sent: Friday, March 30, 2012 11:04 PM
To: Softwires WG
Subject: [Softwires] Have the WG drop o= ther stateless solutions already?
 
Hi, Softwirers,
 
I get very confused when I walked = out the Softwire meeting this morning. Why&n= bsp;did we only talk about making choice&nbs= p;between 4rd-U and MAP? There are also = ;several other stateless solutions, too. As = far as I recalled, the Softwire WG have=  NOT decided to drop them at all. = They should be discussed together and equall= y.
 
If the Softwire WG is going to cho= ose single one solution, it should be c= hoose among all these solutions. Until we&nb= sp;have decided drop all other stateless sol= utions, this is not a two-horse race, y= et.
 
Best regards,
 
Sheng
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart308852406381_=------ From satoru.matsushima@gmail.com Sun Apr 1 11:02:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6721F871C for ; Sun, 1 Apr 2012 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Z3v51ouEnL for ; Sun, 1 Apr 2012 11:02:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id EFB3621F852D for ; Sun, 1 Apr 2012 11:02:08 -0700 (PDT) Received: by dady13 with SMTP id y13so1867637dad.27 for ; Sun, 01 Apr 2012 11:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c5yttBJ+hMIlmtdiURiVqhIz9/h7dNDiRY9zwKJ5QpI=; b=K3YYku/piNdlWGwHJpLLSAAx7Zctqe62ed7vJ73r0YrOcYpjXpRdDiuAuZNbI/Kiqh NWBjeJGUMkUgORjoyk7Az1D/Q6yxnbBkSH+IdQMsUPsMK5fbqZsAzwibT6oFWvXfMdoh WKIXENTLvzewlVGLV7tdcxCjXjW4vlOuxgvO8fa4mt5NS3/enU3Ob/vHUg0e3WtiUFJW /kKn1fxRsLaWunvkPUugzXv4uAxDBE4m02tfPhXC2JjsfpPeg+ih8PK+faLg5O1gcZmF jOHhyxB+uVpdBzw687Kr+3uyrl3gLlxzgm63hHZvl5A1zB2CP0uTnm63n68zhicr9Pd6 jKGg== Received: by 10.68.203.65 with SMTP id ko1mr14824153pbc.3.1333303328730; Sun, 01 Apr 2012 11:02:08 -0700 (PDT) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id t5sm1777505pbm.64.2012.04.01.11.02.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 11:02:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Satoru Matsushima In-Reply-To: <4F780612.7020508@go6.si> Date: Mon, 2 Apr 2012 03:02:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F780612.7020508@go6.si> To: Softwires WG X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQg==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 18:02:20 -0000 After the meeting, I've figured out that 4rd-u define new type of = transport, since it adds several new semantics in its packet format with = V-octet as a helper of packet format distinguisher. That kind of work is = of course out of scope of Softwire working group. I therefore suggest to = the 4rd-u authors that a new BOF or a working group which named like = 'unified packet format for tunneling'. Best regards, --satoru On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote: > On 3/31/12 4:56 PM, R=E9mi Despr=E9s wrote: >> Alain, >>=20 >> You had initially announced that either one specification would be >> chosen for standard track (among T, E, and U), or specifications >> would all become WG drafts on the experimental track ((*) below). In >> Paris: (a)The MAP proposal became presented as an inseparable T+E >> package. (b) The WG couldn't make a consensus choice between T+E or >> U. >>=20 >> Now publishing both MAP-T+E and 4rd-U as WG documents on the >> experimental track, is therefore consistent with what was announced >> (and was also asked for by several at the end of the meeting). As you >> explained, this won't prevent from selecting one for standard track >> later on, based on better market experience. >=20 > Not sure that was the outcome - as I understood Alain, we'll make a = decision here on mailinglist in a very short period of time. >=20 > Cheers, Jan >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Sun Apr 1 11:12:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962B321F8862 for ; Sun, 1 Apr 2012 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FYN2YEL1GHy for ; Sun, 1 Apr 2012 11:12:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9721F8850 for ; Sun, 1 Apr 2012 11:12:07 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3632031pbb.31 for ; Sun, 01 Apr 2012 11:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kiaiyJMM+LhsrMv4aZt4SNPnFoUgfven+44EYH2qooc=; b=lNsQa/3TJ8MLtOpldS8ek5OkwsAIvJjU0NHtMvdgwU8JeeU15LSlCjUjOuHIIcB4xY FwtBEBIXdbLt+ZA8Lp5W82cuVnTGn9PcdjplSNP8SQk53hi3h2SXi/XqzjXR5h3wXz0a M6TqMiRiy9MLkKpJ1GeT7zOqviAO7wzERR5hJ4y7BPbA14dJdWY62F0W5Hq0SSUFNgtl bawQVS9xyU5ZgDn2KW2BbrMsj+XjbQno5n2IOoAQN5f0hUYA9YI10uYwjoKLpJiY7ITI RcxIrYKW9GUcVFL3VfG1PX9+YWZhE60orMRf2gpRrETuWMTyGnxlg7YSTXHxc78fGPpz q63g== Received: by 10.68.136.162 with SMTP id qb2mr14867022pbb.67.1333303921850; Sun, 01 Apr 2012 11:12:01 -0700 (PDT) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id q1sm3752260pbp.62.2012.04.01.11.11.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 11:12:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Satoru Matsushima In-Reply-To: <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> Date: Mon, 2 Apr 2012 03:11:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F780612.7020508@go6.si> <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> To: Softwires WG X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQg==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 18:12:24 -0000 On 2012/04/02, at 3:02, Satoru Matsushima wrote: > After the meeting, I've figured out that 4rd-u define new type of = transport, since it adds several new semantics in its packet format with = V-octet as a helper of packet format distinguisher. That kind of work is = of course out of scope of Softwire working group. I therefore suggest to = the 4rd-u authors that a new BOF or a working group which named like = 'unified packet format for tunneling'. >=20 > Best regards, > --satoru >=20 In addition, April Fool is ended at JST. cheers, --satoru= From fibrib@gmail.com Sun Apr 1 23:08:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F721F8723 for ; Sun, 1 Apr 2012 23:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu+9XohPJLuc for ; Sun, 1 Apr 2012 23:08:04 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6228721F8722 for ; Sun, 1 Apr 2012 23:08:04 -0700 (PDT) Received: by qaea16 with SMTP id a16so1384484qae.10 for ; Sun, 01 Apr 2012 23:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4EyYDoeELGg60igBacqx7hrrBpPePNGYj1T+W6PfueU=; b=I4yDLScmALxIXLypVd2JlfZbKY0J0XInmGK1vyo5ljwktwNTrp6m/wG/IFqKdDsPce tlr7c+7/zJm5MXQdjPtFE/aK5u20GhkLfXM69mRnC5qOLuEDQOeEMyZQosoZSKph1XYD D4/cbDFqd7T96IWxOGEgqVFeaWhQlSaw1xoyD7rO5GJHWK6ZA4PUcqSqTlBNF71GlupE zZ2lo+ViTQ9FRCw6TeZ143iXbLAv6A0fBKM0EidFxkjguHqmXDww4G0hc9LOw9U0TKd+ WXJyn3VcuBuMU/vVIW5NICXPHnJuFdFrd1VoGKhm5EhHya8VRsBOOsPzJ7H5QevDXaDp uSZQ== MIME-Version: 1.0 Received: by 10.224.59.204 with SMTP id m12mr9552443qah.37.1333346883665; Sun, 01 Apr 2012 23:08:03 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Sun, 1 Apr 2012 23:08:03 -0700 (PDT) In-Reply-To: <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F780612.7020508@go6.si> <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> Date: Mon, 2 Apr 2012 06:08:03 +0000 Message-ID: From: Maoke To: Satoru Matsushima Content-Type: multipart/alternative; boundary=20cf3074d9b45d004b04bcac03d2 Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:08:06 -0000 --20cf3074d9b45d004b04bcac03d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/1 Satoru Matsushima > After the meeting, I've figured out that 4rd-u define new type of > transport, since it adds several new semantics in its packet format with > V-octet as a helper of packet format distinguisher. That kind of work is = of > course out of scope of Softwire working group. I therefore suggest to the > 4rd-u authors that a new BOF or a working group which named like 'unified > packet format for tunneling'. > +1. this is also a good way to achieve the community understanding/acceptance of the architectural building block that 4rd-u offers. - maoke > > Best regards, > --satoru > > > On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote: > > > On 3/31/12 4:56 PM, R=E9mi Despr=E9s wrote: > >> Alain, > >> > >> You had initially announced that either one specification would be > >> chosen for standard track (among T, E, and U), or specifications > >> would all become WG drafts on the experimental track ((*) below). In > >> Paris: (a)The MAP proposal became presented as an inseparable T+E > >> package. (b) The WG couldn't make a consensus choice between T+E or > >> U. > >> > >> Now publishing both MAP-T+E and 4rd-U as WG documents on the > >> experimental track, is therefore consistent with what was announced > >> (and was also asked for by several at the end of the meeting). As you > >> explained, this won't prevent from selecting one for standard track > >> later on, based on better market experience. > > > > Not sure that was the outcome - as I understood Alain, we'll make a > decision here on mailinglist in a very short period of time. > > > > Cheers, Jan > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074d9b45d004b04bcac03d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/1 Satoru Matsushima <satoru.matsushima@g= mail.com>
After the meeting, I've figured out that 4rd-u define new type of trans= port, since it adds several new semantics in its packet format with V-octet= as a helper of packet format distinguisher. That kind of work is of course= out of scope of Softwire working group. I therefore suggest to the 4rd-u a= uthors that a new BOF or a working group which named like 'unified pack= et format for tunneling'.

+1. this is also a good way to achieve the= community understanding/acceptance of the architectural building block tha= t 4rd-u offers. - maoke
=A0

Best regards,
--satoru


On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote:

> On 3/31/12 4:56 PM, R=E9mi Despr=E9s wrote:
>> Alain,
>>
>> You had initially announced that either one specification would be=
>> chosen for standard track (among T, E, and U), or specifications >> would all become WG drafts on the experimental track ((*) below). = In
>> Paris: (a)The MAP proposal became presented as an inseparable T+E<= br> >> package. (b) The WG couldn't make a consensus choice between T= +E or
>> U.
>>
>> Now publishing both MAP-T+E and 4rd-U as WG documents on the
>> experimental track, is therefore consistent with what was announce= d
>> (and was also asked for by several at the end of the meeting). As = you
>> explained, this won't prevent from selecting one for standard = track
>> later on, based on better market experience.
>
> Not sure that was the outcome - as I understood Alain, we'll make = a decision here on mailinglist in a very short period of time.
>
> Cheers, Jan
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074d9b45d004b04bcac03d2-- From wentaoshang@gmail.com Sun Apr 1 23:22:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841B811E80B7 for ; Sun, 1 Apr 2012 23:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtZkvLUqJ0Iu for ; Sun, 1 Apr 2012 23:22:39 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0A11E80B2 for ; Sun, 1 Apr 2012 23:22:38 -0700 (PDT) Received: by werb10 with SMTP id b10so1853289wer.31 for ; Sun, 01 Apr 2012 23:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ggJ7LRWY4+uLOw3c4myvzAj26ucGW8dU9T+KlR0wiU4=; b=JqBp49j8s7gtK2nLiPi8No28q5N44TIthXzWKOvretRn5h58ID/F1kQLB09aRRFNYr bBNAWt++97YEB8zBu4SHzN8dz6kFusUW6mJK0vd6KLO0Ynsy5T+k0c9Dor1YMVhWgfNU n4NZTSvV8iBxjToXMye7kp92jiA+nBXCUhtGB/XWJoGECwehtlcNg7VrY41azgtkqeXM GuUherkodCZLuwDH6JbtYGWu8wseqKBuDW1wpexY9gZLuW9h9r+5j/zBdSkQexIVDfqN QvUBgdNnt+TCL7LruPK0X4FPgveCi+bQZOftCcsVGhGOfJvBm8lVNeJarQJcEzuA82XF fsbA== MIME-Version: 1.0 Received: by 10.180.91.168 with SMTP id cf8mr21649885wib.0.1333347757923; Sun, 01 Apr 2012 23:22:37 -0700 (PDT) Received: by 10.180.94.105 with HTTP; Sun, 1 Apr 2012 23:22:37 -0700 (PDT) In-Reply-To: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> Date: Mon, 2 Apr 2012 14:22:37 +0800 Message-ID: From: Wentao Shang To: Maoke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:22:39 -0000 Totally agree with Maoke. As one of the developers for the MAP design team, I think it's unfair to put both MAP and 4rd-u as experimental. It's good to see the attempt to implement 4rd-u. However, any discussion about standardization should be postponed until it is coded, deployed and fully tested. Regards, Wentao 2012/4/1 Maoke : > hi all, > > i listented to the softwire wg live on March 30 online and recorded my > comments in the jabber room. as the person who was mentioned by the > presenter not less than twice, i have to point out that it is unfair that > the presenter mentioned me with only acknowledgment to my effort but my > point of views. my summerized comment on 4rd-u is: it is flawed in both > architecture and technical aspects, and now still uncertain in several > details. > > it would become as a ridiculous and weird record in the =C2=A0ietf histor= y, had > the wg made a decision of putting two as experimental, one is > well-understood, well-coded and well-practised while the other is mislead= ing > the understanding on the Internet architecture, not yet coded, not yet > tested by any operators. > > our company, as an ISP and as a provider doing also application services, > including those over mobile platforms, is waiting for the MAP standard > desirably. we have no interest in introducing the 4rd-u elements into our > platforms. > > personally i won't code a stuff with obvious architectural flaws but, if = i > were believing in the 4rd-u, i would do the code and operational test wit= h > serious self-checking as MAP-T and MAP-E teams already have done, before > talking on any doc-track issue with the community. this is the way of bei= ng > responsible. > > thanks, > maoke > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --=20 Wentao Shang Master Candidate and Research Assistant at CERNET Center & NGN Lab, EE Department, Tsinghua University From despres.remi@laposte.net Mon Apr 2 02:04:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4F21F8948 for ; Mon, 2 Apr 2012 02:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-z1aCFDkafx for ; Mon, 2 Apr 2012 02:04:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id A5BD521F88E7 for ; Mon, 2 Apr 2012 02:04:18 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id sx4F1i00237Y3f403x4F51; Mon, 02 Apr 2012 11:04:17 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 2 Apr 2012 11:04:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:04:26 -0000 Le 2012-04-01 =E0 00:15, Maoke a =E9crit : > hi all,=20 >=20 > i listented to the softwire wg live on March 30 online and recorded my = comments in the jabber room. as the person who was mentioned by the = presenter not less than twice, i have to point out that it is unfair = that the presenter mentioned me with only acknowledgment to my effort = but my point of views. I acknowledged that some of the recent progress to complete 4rd-U was = due to the technical quality of our dialogue on the ML (... even if = sometimes more aggressive than really needed). I thought it was fair to say it. Sorry if the words I used seemed unfair to you.=20 Please be sure the intention was the opposite. > my summerized comment on 4rd-u is: > it is flawed in both architecture and technical aspects, Which ones? > and now still uncertain in several details. Which ones? I confirm that, in my understanding, all points that were argued with = technical substance, had been dealt with in 4rd-u-06. This is not to negate that you wrote in your last answer, as anyone can = verify: "with your newly proposed solution, yes, IPv4 TTL is fine. but = on the other hand, the IPv6 also needs TTL(HopLimit)=3D255 to protect = something. we have to concern if 4rd-u possibly introduces some new = measures for the attackers breaking such kind of protection mechanism, = as putting the first bit of IPv4 TTL into IPv6 HopLimit CHANGES the = semantics of IPv6's HopLimit!" Frankly, I don't understand the new objection: "concern if 4rd-u = possibly introduces..." is IMHO an incitation to FUD, but not a = technically justified issue. If you can detail what you mean, with a point an experiment might = reveal, dialogue will continue. Without that, I don't understand what you mean. > it would become as a ridiculous and weird record in the ietf history, = had the wg made a decision of putting two as experimental, That was Alain's plan in case no consensus on a single standard would = emerge. It was expressed on the ML well before the meeting. You didn't object to it then, did you? > one is well-understood, This "one" obviously being, in your opinion, MAP-T+E, but: =20 a) The need for disjoint packet IDs form shared address CEs is still = uncovered in MAP-T. b) The MAP-E specification is claimed to work in hub-and-apoke topology, = but when a BR receives an IPv6 packer, "If the CE IPv6 address is equal = to the IPv6 source address in the received IPv6 packet, BR decapsulates = the IPv4 packet and then forward it via the IPv4 interface." c) It has been said during the meeting that, in the tested = double-translation implementation, BRs compute UDP checksums of IPv4 = datagrams when not computed by sources (Null checksums). Nothing is = specified AFAIK specified in the MAP-T document. Is it a MUST, a SHOULD, = a MAY? d) The hub-and-spoke domain parameter, which is needed as Ole = acknowledged on the ML, is still not documented in MAP. (Very easy to = fix, of course, but a sign that there is still work to be done to have a = clear specification.) e) The Port Parameter option of MAP-DHCP specifies 3-bits "offset" AND a = 16-bit "excluded-ports". Which combinations of these values have been = actually tested? Why to have "excluded-ports" if there is an offset = parameter?=20 If these remarks can help E+T proponents to improve their approach, = good, but my interest here is ONLY to make WG members understand that = MAP-E+T isn't the well specified design it is sometimes claimed to be. > well-coded and well-practised A list of once practiced mapping rules for each representative = configuration (for T AND for E, and for mesh AND hub-and-spoke) is still = missing to support this assertion. > while the other is misleading the understanding on the Internet = architecture, If it is a reference to the V octet of 4rd-U, none of the experts I = talked to others than MAP-T+E strong proponents has found any = architectural problem. (It is new, yes, but is also backward compatible = with existing RFCs. No misleading.) If it is a reference to something else, please explain. > not yet coded, not yet tested by any operators. Fair enough, but when Free decided to deploy 6rd, there was not even a = document describing it! Yet, it has been the most effective step toward = IPv6 availability on a large scale. Understanding the specification was = found sufficient.=20 Conclusion: clear theory is sometimes more convincing than "I ran a = successful experiment".=20 > our company, as an ISP and as a provider doing also application = services, including those over mobile platforms, is waiting for the MAP = standard desirably. > we have no interest in introducing the 4rd-u elements into our = platforms. Fair enough, but standardization is a collective effort. Regards, RD > personally i won't code a stuff with obvious architectural flaws but, = if i were believing in the 4rd-u, i would do the code and operational = test with serious self-checking as MAP-T and MAP-E teams already have = done, before talking on any doc-track issue with the community. this is = the way of being responsible. >=20 > thanks, > maoke > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Mon Apr 2 02:13:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686C421F8953 for ; Mon, 2 Apr 2012 02:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svq6eiFq1UZ9 for ; Mon, 2 Apr 2012 02:13:21 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6945621F894F for ; Mon, 2 Apr 2012 02:13:21 -0700 (PDT) Received: by qaea16 with SMTP id a16so1447538qae.10 for ; Mon, 02 Apr 2012 02:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qXx7Ze6jVj6WyfYc9PbCYN+jto0aR1vrpdv5COtxKp4=; b=QqREMJSXJnGJ11OVbyczvC8EGFxr2S7ft0K+2O0CbgDISNANQwPmJj0qy6yQy1g2O8 0G7XkmDMNig+eXIrqA2j4/3vrTn6xp+1vAwvnVLGsc3itxGvjwVCl2uDfTS6A1ly9ydC 9DSjzxK78/blrBG61GqfIc86oUWAUCB/VjcgSxMf4nvq3899coPvYCco39q6rWY7XHSQ GoLTdnJFGrkcPRuFtBq4kTOtIMOiLb3sO84uxn3R35KwACRUf/pxuYslVl6UsL8B0g92 /wakvVXFYzLXclW/mdaiwB3sRfKI7CPwJhT31bE+b9fxaGfMOGlYjMiAL/wO01/oLZCD j0vQ== MIME-Version: 1.0 Received: by 10.224.39.211 with SMTP id h19mr10079740qae.24.1333358000889; Mon, 02 Apr 2012 02:13:20 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 02:13:20 -0700 (PDT) In-Reply-To: <9D6113C9-B8D8-48C5-918E-BF699E6BCA6C@free.fr> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <9D6113C9-B8D8-48C5-918E-BF699E6BCA6C@free.fr> Date: Mon, 2 Apr 2012 09:13:20 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f7d1a00606104bcae9aa2 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:13:22 -0000 --20cf306f7d1a00606104bcae9aa2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 R=E9mi Despr=E9s > > Frankly, I don't understand the new objection: "concern if 4rd-u > possibly introduces..." is IMHO an incitation to FUD, but not a technical= ly > justified issue. > If you can detail what you mean, with a point an experiment might reveal, > dialogue will continue. > Without that, I don't understand what you mean. > well, IMHO i have expressed the question and it is concrete. i gently used the wording "possibly" because the verification could only be done after you have the 4rd-u system built out. > > > > it would become as a ridiculous and weird record in the ietf history, > had the wg made a decision of putting two as experimental, > > That was Alain's plan in case no consensus on a single standard would > emerge. > It was expressed on the ML well before the meeting. > You didn't object to it then, did you? > yes, i did objected (in this very thread) the chair's questions, esp. Q2, with "I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice". regards, maoke --20cf306f7d1a00606104bcae9aa2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 R=E9mi Despr=E9s <remi.despres@free.fr>= ;

=A0 Frankly, I don't understand the new objection: "concern if 4rd-u p= ossibly introduces..." is IMHO an incitation to FUD, but not a technic= ally justified issue.
If you can detail what you mean, with a point an experiment might reveal, d= ialogue will continue.
Without that, I don't understand what you mean.
well, IMHO i have expressed the question and it is concrete. i= gently used the wording "possibly" because the verification coul= d only be done after you have the 4rd-u system built out.=A0
=A0


> it would become as a ridiculous and weird record in the =A0ietf histor= y, had the wg made a decision of putting two as experimental,

That was Alain's plan in case no consensus on a single standard w= ould emerge.
It was expressed on the ML well before the meeting.
You didn't object to it then, did you?

yes, i did objected (in this very th= read) the chair's questions, esp. Q2, with "I don't think it i= s correct now to insert 4rd-u into a sort of exclusive decision of choice&q= uot;.=A0

regards,
maoke
--20cf306f7d1a00606104bcae9aa2-- From fibrib@gmail.com Mon Apr 2 02:16:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8321F8680 for ; Mon, 2 Apr 2012 02:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITPSk0f320m5 for ; Mon, 2 Apr 2012 02:16:23 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4CB21F867F for ; Mon, 2 Apr 2012 02:16:23 -0700 (PDT) Received: by qafi31 with SMTP id i31so1949765qaf.15 for ; Mon, 02 Apr 2012 02:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SwUt1yLC3Eye4EhdciakJKl6nhniW+favQv+kLq3OJk=; b=SHYYD8CAh4MSEDCXww1jaBIuG9g4f1r4EfavzD1fcH50B7t3xxWC3qzz4mPapiXOkD 86yhSUlY65zyf0tY+zhdxQcz3qtH677q291qCuXVrRiylsOwm13/5VM5RWo9M6HZTN1s kpUIS6V+2v+sXvGic2Vehd1tDNGymj/fFJ+7JX1GDqoMn74DLkU5UVJ6qaxKxRwaAoLx S6wlrgKqa2zr420ZuwrZds1+k6pKQ2VmpzxRnWZQqRNXDXnMt/i0gbscHYIZT7xoFjNn W23jrLIB34k/9bTfRQM4e3PkkB/V07AILHJ4KkDIKDC/vbyL5/dpVz1jStsDj6obbANd LfSA== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr2963958qct.71.1333358182906; Mon, 02 Apr 2012 02:16:22 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 02:16:22 -0700 (PDT) In-Reply-To: <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> Date: Mon, 2 Apr 2012 09:16:22 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235452e750d9b9ab04bcaea47b Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:16:24 -0000 --00235452e750d9b9ab04bcaea47b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 R=E9mi Despr=E9s > > > it is flawed in both architecture and technical aspects, > > Which ones? > > > please refer to discussion mails and also my real-time comments on 4rd-u presentation in the jabber room as a brief summary focusing on major points. - maoke --00235452e750d9b9ab04bcaea47b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

=A0 > it is flawed in both architecture and technical aspects,

Which ones?

=A0

please refe= r to discussion mails and also my real-time comments on 4rd-u presentation = in the jabber room as a brief summary focusing on major points. - maoke=A0<= /div>
--00235452e750d9b9ab04bcaea47b-- From jan@go6.si Mon Apr 2 02:28:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7121F8946 for ; Mon, 2 Apr 2012 02:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxsVnDtCQZt for ; Mon, 2 Apr 2012 02:28:23 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id D809121F88DB for ; Mon, 2 Apr 2012 02:28:22 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2a00:ee0:3:4a00:5dbf:3f74:985f:8a89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 7F47523780B5 for ; Mon, 2 Apr 2012 11:28:19 +0200 (CEST) Message-ID: <4F797133.3030100@go6.si> Date: Mon, 02 Apr 2012 11:28:19 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:28:23 -0000 On 4/2/12 8:22 AM, Wentao Shang wrote: > Totally agree with Maoke. > > As one of the developers for the MAP design team, I think it's unfair > to put both MAP and 4rd-u as experimental. It's good to see the > attempt to implement 4rd-u. However, any discussion about > standardization should be postponed until it is coded, deployed and > fully tested. Hi, Do you think we have time for this? Meantime, CGNs have free way into networks without any alternative... Cheers, Jan From despres.remi@laposte.net Mon Apr 2 02:31:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5667B21F8957 for ; Mon, 2 Apr 2012 02:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq1fzOB+DQVs for ; Mon, 2 Apr 2012 02:31:03 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4123421F8955 for ; Mon, 2 Apr 2012 02:31:02 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id sxWz1i00937Y3f403xWzLq; Mon, 02 Apr 2012 11:31:01 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-55-717057295 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 2 Apr 2012 11:30:59 +0200 Message-Id: <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:31:04 -0000 --Apple-Mail-55-717057295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-02 =E0 11:16, Maoke a =E9crit : >=20 >=20 > 2012/4/2 R=E9mi Despr=E9s >=20 > > it is flawed in both architecture and technical aspects, >=20 > Which ones? >=20 > =20 >=20 > please refer to discussion mails I carefully read all emails addressed to me, plus most others, but don't = understand that any flaw really exists in 4rd-u-06. Sorry if I am not as shrewd as I should be in your opinion. > and also my real-time comments on 4rd-u presentation in the jabber = room as a brief summary focusing on major points. - maoke=20 Do you know where I could get access to these comments? Thanks, RD --Apple-Mail-55-717057295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

  > it is flawed in both architecture and technical aspects,

Which ones?

 

please = refer to discussion mails

I = carefully read all emails addressed to me, plus most others, but don't = understand that any flaw really exists in = 4rd-u-06.

Sorry if I am not as shrewd as I = should be in your = opinion.


and also my real-time comments on 4rd-u = presentation in the jabber room as a brief summary focusing on major = points. - maoke 

Do you know where I could get access to = these = comments?

Thanks,
RD

=

= --Apple-Mail-55-717057295-- From despres.remi@laposte.net Mon Apr 2 02:33:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B1021F8887 for ; Mon, 2 Apr 2012 02:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pdD8zVKvjig for ; Mon, 2 Apr 2012 02:33:58 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 60BC221F885F for ; Mon, 2 Apr 2012 02:33:57 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id sxZw1i00G37Y3f403xZwqD; Mon, 02 Apr 2012 11:33:56 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 2 Apr 2012 11:33:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <353AA9A7-9570-4E61-B2CE-AD37D16DBA5D@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F780612.7020508@go6.si> <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:33:58 -0000 Le 2012-04-01 =E0 20:11, Satoru Matsushima a =E9crit : > On 2012/04/02, at 3:02, Satoru Matsushima wrote: >=20 >> After the meeting, I've figured out that 4rd-u define new type of = transport, since it adds several new semantics in its packet format with = V-octet as a helper of packet format distinguisher. That kind of work is = of course out of scope of Softwire working group. I therefore suggest to = the 4rd-u authors that a new BOF or a working group which named like = 'unified packet format for tunneling'. >>=20 >> Best regards, >> --satoru >>=20 >=20 > In addition, April Fool is ended at JST. Thanks for understanding yourself that it could have ben taken as a = fools' day joke ;-). Kind regards, RD =20 >=20 > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Mon Apr 2 02:45:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3121F894F for ; Mon, 2 Apr 2012 02:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGWq8WXg97RQ for ; Mon, 2 Apr 2012 02:45:23 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B521F8935 for ; Mon, 2 Apr 2012 02:45:23 -0700 (PDT) Received: by qaea16 with SMTP id a16so1459916qae.10 for ; Mon, 02 Apr 2012 02:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ely5XEucSei6WIP3168pL2Nq+aWibdkfiVeQHYQ3mr0=; b=Dq55lomMMu+Hw9R9lpYgbCOXd6O5q8gFEsQY9Cn9QP/js4F9B2v/p1QWVIW0jK5IlN Fekqz7Cvt8nraAUpvwRd8YjpOllZSQg7M0rLQGh2al74TZPiawQHaCytSYjwF/mA8N9f cD1wWYyu1A5FYPTiC0H8ZB1Mn+NG/Isgww1Amxevbr7pbik8d1C6OL86nksCJEzg5WGV 2Xm2wKmRcUKjgcFn862zeKslVtkOjz0d0x65vkLxkFtTMnmh1uXX/K47z4kwmK0BWTdI OSPprIQOsVwjHNWi8M2X86CYaFDfu0ReZ0fwngX0vyYcMwiRuK+ZUJW8roRVP4/+sJ3n euRw== MIME-Version: 1.0 Received: by 10.224.102.8 with SMTP id e8mr10078656qao.50.1333359922803; Mon, 02 Apr 2012 02:45:22 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 02:45:22 -0700 (PDT) In-Reply-To: <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> Date: Mon, 2 Apr 2012 09:45:22 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b0d88e751b04bcaf0c6a Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:45:24 -0000 --20cf3074b0d88e751b04bcaf0c6a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 R=E9mi Despr=E9s > > Le 2012-04-02 =E0 11:16, Maoke a =E9crit : > > > > 2012/4/2 R=E9mi Despr=E9s > >> >> > it is flawed in both architecture and technical aspects, >> >> Which ones? >> >> >> > > please refer to discussion mails > > > I carefully read all emails addressed to me, plus most others, but don't > understand that any flaw really exists in 4rd-u-06. > i am still in review on the version -06, but i have found something not qualified (inconsistent semantics). on the other hand, this message is more about progress rather than the technical details. if we have the BoF or new working group for the unified header mapping, i'd love to keep discussion there, with contributing my list of semantics/architecture/technical-detail questions that i found during the review. > > Sorry if I am not as shrewd as I should be in your opinion. > > > and also my real-time comments on 4rd-u presentation in the jabber room a= s > a brief summary focusing on major points. - maoke > > > Do you know where I could get access to these comments? > i guess we have the jabber log. but it is less informative. if the unified header mapping wg or BoF is started, i will contribute a comprehensive, and well-studied list of questions. best, maoke --20cf3074b0d88e751b04bcaf0c6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

Le 2012-04-02 =E0 11:16, = Maoke a =E9crit :


=
2012/4/2 R=E9mi Despr=E9s = <despres.r= emi@laposte.net>

=A0 > it is flawed in both architecture and technical aspects,

Which ones?

=A0

please refer to discussi= on mails

I carefully read= all emails addressed to me, plus most others, but don't understand tha= t any flaw really exists in 4rd-u-06.

i am still in review on the ve= rsion -06, but i have found something not qualified (inconsistent semantics= ). on the other hand, this message is more about progress rather than the t= echnical details. if we have the BoF or new working group for the unified h= eader mapping, i'd love to keep discussion there, with contributing my = list of semantics/architecture/technical-detail questions that i found duri= ng the review.=A0
=A0

Sorry if I am not as shrewd as I should be i= n your opinion.


<= div class=3D"gmail_quote">
and also my real-time comments on 4rd-u pre= sentation in the jabber room as a brief summary focusing on major points. -= maoke=A0

Do you know where I could get access to t= hese comments?

i guess we have = the jabber log. but it is less informative. if the unified header mapping w= g or BoF is started, i will contribute a comprehensive, and well-studied li= st of questions.=A0

best,
maoke=A0

--20cf3074b0d88e751b04bcaf0c6a-- From despres.remi@laposte.net Mon Apr 2 03:10:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36A21F896A for ; Mon, 2 Apr 2012 03:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+cRyLtjDxHB for ; Mon, 2 Apr 2012 03:10:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 7343921F887A for ; Mon, 2 Apr 2012 03:10:25 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id syAM1i00A37Y3f403yAM2F; Mon, 02 Apr 2012 12:10:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-56-719419603 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 2 Apr 2012 12:10:21 +0200 Message-Id: <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:10:27 -0000 --Apple-Mail-56-719419603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-04-02 11:45, Maoke: ... > i am still in review on the version -06, but i have found something = not qualified (inconsistent semantics). Asserting there are flaws implies ability to describe them. What you have already "found" will be looked at fairly when described. = (Just saying "inconsistent semantics" is unsuffcient). > on the other hand, this message is more about progress rather than the = technical details. > if we have the BoF or new working group for the unified header = mapping, i'd love to keep discussion there, with contributing my list of = semantics/architecture/technical-detail questions that i found during = the review. If Satoru-san and yourself want to set up a BOF on this, that remains up = to you. AFAIK, it won't prevent those who want to test 4rd-U-06 to do it. > Sorry if I am not as shrewd as I should be in your opinion. >=20 >=20 >> and also my real-time comments on 4rd-u presentation in the jabber = room as a brief summary focusing on major points. - maoke=20 >=20 > Do you know where I could get access to these comments? >=20 > i guess we have the jabber log. Not seen where. And there isn't AFAIK an audio record either. > but it is less informative. Less informative than what? > if the unified header mapping wg or BoF is started, i will contribute = a comprehensive, and well-studied list of questions.=20 A WG now without a previous BOF is of course completely unrealistic. If this is to say that until a BOF is started, you will keep your = objection(s) unknown, I continue to take it as a lack of identified = objections. Fair enough? Cheers, RD >=20 > best, > maoke=20 >=20 --Apple-Mail-56-719419603 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
i am still in review on the version -06, but = i have found something not qualified (inconsistent semantics). =

Asserting there are flaws = implies ability to describe them.
What you have already = "found" will be looked at fairly when described. (Just saying = "inconsistent semantics" is = unsuffcient).


on the other hand, this message is more about = progress rather than the technical details. =

if we have the BoF or new working group for = the unified header mapping, i'd love to keep discussion there, with = contributing my list of semantics/architecture/technical-detail = questions that i found during the = review.

If Satoru-san and = yourself want to set up a BOF on this, that remains up to = you.
AFAIK, it won't prevent those who want to test 4rd-U-06 = to do it.


Sorry if I am not = as shrewd as I should be in your opinion.


and also my real-time = comments on 4rd-u presentation in the jabber room as a brief summary = focusing on major points. - maoke 

Do you know where I could get access = to these comments?

i guess = we have the jabber log.

Not seen = where.
And there isn't AFAIK an audio record = either.

but it is less informative. =

Less informative than = what?

if the unified header mapping wg or BoF is = started, i will contribute a comprehensive, and well-studied list of = questions. 

A WG now without = a previous BOF is of course completely = unrealistic.

If this is to say that until a BOF = is started, you will keep your objection(s) unknown, I continue to take = it as a lack of identified objections.
Fair = enough?

Cheers,
RD

=

=

best,
maoke 

=

= --Apple-Mail-56-719419603-- From fibrib@gmail.com Mon Apr 2 03:30:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7650C21F889D for ; Mon, 2 Apr 2012 03:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8XvtumfeVjV for ; Mon, 2 Apr 2012 03:30:11 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A721F889B for ; Mon, 2 Apr 2012 03:30:11 -0700 (PDT) Received: by qafi31 with SMTP id i31so1989974qaf.15 for ; Mon, 02 Apr 2012 03:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pmyGeU4tiOoGFy+/bxy5T/RIvoNiDy/KPDN2oIKgZ4w=; b=g8cSvmkpVZCOyHDjMkcj2cfvUHMFz4V09gQceQwHCwf/3xL+/XA/MXT/SvJTQT9NZF 5ZrBPCXfRkV+DRHcHDVjV3A0JviBTVj4X7MH3AsHoWKCJtCfq/zQMlONfGNqBbcCTNQO K30XA37jnOdSU5rAbN0l3+uhHnzK36ywS0IuKFeo1Q3c4CE5MUl8eMuKba1vEAl1huuC SJP/9t7EKr0BuYwQu0CXjTd8E8b8T6T+QB7tvtKNkGYWz9XtRPD0jZLmvNNy4jy4savV e99e0jzI2XquV9lY7G2630vU0a9VfcfklBNQH2MjtmbOUrkrQQvzk1BLXuTW4hUDynZF v8ew== MIME-Version: 1.0 Received: by 10.224.59.204 with SMTP id m12mr10322699qah.37.1333362611290; Mon, 02 Apr 2012 03:30:11 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 03:30:11 -0700 (PDT) In-Reply-To: <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> Date: Mon, 2 Apr 2012 10:30:11 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074d9b4cd822204bcafacd5 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:30:12 -0000 --20cf3074d9b4cd822204bcafacd5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 R=E9mi Despr=E9s > > but it is less informative. > > > Less informative than what? > well i found that, through the ietf agenda page: http://www.ietf.org/jabber/logs/softwire/2012-03-30.html, FYI. less informative than my email discussions. > > if the unified header mapping wg or BoF is started, i will contribute a > comprehensive, and well-studied list of questions. > > > A WG now without a previous BOF is of course completely unrealistic. > > If this is to say that until a BOF is started, you will keep your > objection(s) unknown, I continue to take it as a lack of identified > objections. > Fair enough? > i din't say what if the BoF is not started but only said about what if the BoF would started. ;-) best, maoke > > Cheers, > RD > --20cf3074d9b4cd822204bcafacd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

but it is less informative.

Less informative than what?
<= div>
well i found that, through the ietf agenda page: http://www.ietf.o= rg/jabber/logs/softwire/2012-03-30.html, FYI.=A0
less informa= tive than my email discussions.=A0
=A0

if the unified header mapping wg or BoF is started, i will contribute = a comprehensive, and well-studied list of questions.=A0

A WG now without a previous BOF is of course comp= letely unrealistic.

If this is to say that until a BOF is started, you will= keep your objection(s) unknown, I continue to take it as a lack of identif= ied objections.
Fair enough?

i din't say what if the BoF is not started but only said abo= ut what if the BoF would started. ;-)=A0

best,
maoke
=A0

Cheers,
R= D

--20cf3074d9b4cd822204bcafacd5-- From ichiroumakino@gmail.com Mon Apr 2 03:33:43 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7565621F88E2 for ; Mon, 2 Apr 2012 03:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKk+guI7uSSm for ; Mon, 2 Apr 2012 03:33:43 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id B668121F86DB for ; Mon, 2 Apr 2012 03:33:42 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2332373wib.1 for ; Mon, 02 Apr 2012 03:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PR+GbLmhxSArzm0vhP61VGriYiioOpFAG6GED0oVF0I=; b=N65oVM9ORC9OvoB3zbfPCDG3Z1ApfYlTObdDC8HKxtpObR0sgzIEDN++hEioXp6Q0a uQRJHlasCWV1qrKS5MJlmiQPIPxV1djNEwbsgrz5MpJk7qF3lEYAL65SQmlxd/zxpnno 28dMr/Q/qHAVVPxkCoHlncqGgm/dAEQwFoCFMj+kyFKYK79wWLfWH6ow7hU3HbWknNH1 QE4b79/QjlhVZ3nGLtl5HCogmWr3hXBqYI71sX8cCAFIzhCSA4F9EdaMuC2bo4vvae9+ SCrZgiGLTl46cBT7w4rh68MMb3CdG4GB35zY2bfzcY2ZiRctw0o/xD8HlpJIuy0+UtbJ oFaw== Received: by 10.180.79.72 with SMTP id h8mr24533781wix.1.1333362821746; Mon, 02 Apr 2012 03:33:41 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-172.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n8sm53517121wix.10.2012.04.02.03.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 03:33:40 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> Date: Mon, 2 Apr 2012 12:33:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:33:43 -0000 > If this is to say that until a BOF is started, you will keep your = objection(s) unknown, I continue to take it as a lack of identified = objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution * injection of IPv4 routes into IPv6 * transparency * hard to identify IPv4 traffic in the "core" * higher risk of leakage. i.e single translation / packets outside = the domain (all these apply equally to MAP-T btw) - redefining the modified EUI-64 format (V-octet) and the consequences = standardization wise of that - overloading information in the fragment header (please don't respond to these, FYI only. I'm on Easter holiday.) if it wasn't for my general "uncomfortableness" with double-translation = I'd could be convinced that a single solution was possible. the status quo; with no path forward just means that we'll effectively = kill A+P. I would certainly not recommend my product managers to implement either = of this given the risk. is there consensus to abandon these efforts (which is basically what we = do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 = address problem solved. ;-) cheers, Ole From fibrib@gmail.com Mon Apr 2 03:37:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19621F8962 for ; Mon, 2 Apr 2012 03:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXo4wJ9VZubz for ; Mon, 2 Apr 2012 03:37:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0F21F8946 for ; Mon, 2 Apr 2012 03:37:32 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1817653qcs.31 for ; Mon, 02 Apr 2012 03:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlgEAAwE3b45fy135RbbjF6nN2ZUHQrm2ndaShCnqGY=; b=Eg1narRP4yb5C0uqMwVrHFEMzP/Y25RCwU4lYmko5oxy41wy/hY3REKsHLafv0hRgG RRbUKLlL5xovkJqDNQ1+TYvIizyTdxqOlgLfSBYG667KTrLx1Xt71Oz/DSBKb671/3u2 GGc13VvSfjOkGwygR0IttJo+d4Q12ae+acKYPrGgxeSSDZMihCqrmc/w1bnY7X/cpRML ohdIxihzcln6M4KN5v6piYCvW+smaYPxC9pxD1vhk7RWVQWmy+hyMXsfSn/xrAqNe/M9 eAfUjEgyFZ41N4VuA+EJ1G2W+gXPmikO1NYPVjFqla7nwjFcPWNls44GrZfteMQyqC9f uBLg== MIME-Version: 1.0 Received: by 10.229.137.80 with SMTP id v16mr3049414qct.31.1333363051954; Mon, 02 Apr 2012 03:37:31 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 03:37:31 -0700 (PDT) In-Reply-To: <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> Date: Mon, 2 Apr 2012 10:37:31 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023545300901181b104bcafc741 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:37:38 -0000 --0023545300901181b104bcafc741 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 R=E9mi Despr=E9s > > 2012-04-02 11:45, Maoke: > ... > > i am still in review on the version -06, but i have found something not > qualified (inconsistent semantics). > > > Asserting there are flaws implies ability to describe them. > What you have already "found" will be looked at fairly when described. > (Just saying "inconsistent semantics" is unsuffcient). > because i don't think we didn't cover that topic before. > > > on the other hand, this message is more about progress rather than the > technical details. > > > if we have the BoF or new working group for the unified header mapping, > i'd love to keep discussion there, with contributing my list of > semantics/architecture/technical-detail questions that i found during the > review. > > > If Satoru-san and yourself want to set up a BOF on this, that remains up > to you. > AFAIK, it won't prevent those who want to test 4rd-U-06 to do it. > > i don't believe 4rd-u but we respect your belief and therefore we suggest you do. but what we can make is only suggestion. surely it is welcome if anyone would like to test 4rd-u. but the test is not the scope of softwire, and AFAIK, the test of 4rd-u won't prevent those who want to deploy MAP in real. regards, maoke --0023545300901181b104bcafc741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

2012-04-02 =A011:= 45, Maoke:
...
<= div class=3D"gmail_quote">
i am still in review on the version -06, but i have found something no= t qualified (inconsistent semantics).

Asserting there are flaws implies ability to describe them.
What you have already "found" will be looked at fairly when = described. (Just saying "inconsistent semantics" is unsuffcient).=

because i don't thin= k we didn't cover that topic before.=A0
=A0


<= div class=3D"gmail_quote">
on the other hand, this message is more about progress rather than the= technical details.

=
if we have the BoF or new working group for= the unified header mapping, i'd love to keep discussion there, with co= ntributing my list of semantics/architecture/technical-detail questions tha= t i found during the review.

If Satoru-san and yourself want to = set up a BOF on this, that remains up to you.
AFAIK, it won't= prevent those who want to test 4rd-U-06 to do it.


i don't believe 4rd-u but we res= pect your belief and therefore we suggest you do. but what we can make is o= nly suggestion. surely it is welcome if anyone would like to test 4rd-u. bu= t the test is not the scope of softwire, and AFAIK, the test of 4rd-u won&#= 39;t prevent those who want to deploy MAP in real.=A0

regards,
maoke
--0023545300901181b104bcafc741-- From fibrib@gmail.com Mon Apr 2 03:41:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010A21F8602 for ; Mon, 2 Apr 2012 03:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqrtAzDUIRUM for ; Mon, 2 Apr 2012 03:41:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF70C21F8600 for ; Mon, 2 Apr 2012 03:41:33 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1819612qcs.31 for ; Mon, 02 Apr 2012 03:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dumx6ZB/xNzLAJhFdzFlLb9ToEwagxLpL3o6gBHX+Wg=; b=Yl8bkSsdZepp5ume4mrxnB5YMJXGgHKwPyd7+IG+2lH4YeTn5QA61S36gsNAh57WaE N0wdllSCbZyXsuTXt3L1H/CVVH70+6veb59z0vH8mDiCF6Wni3evfoP2TO/UP+KUReFJ FvNB2RPHxsGYHbqP/XtetwF7x/6OeB3ngznFkFClrcUMUx2od1PeNH4sbzSTvR1stWAO W3fCmXEW7rg7NmyFl+SkahKXXVc0oyIMBiH+119l7JQrOmrem5LaHGucOe8ObICrsCab FsYLrRUswvYjo8rOWOIrEQtWuJ5PW4zWIfTBDR56vvW9rJg8kh8S4HzEqKov2Ejw9VzL F4Ug== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr3054620qct.71.1333363291321; Mon, 02 Apr 2012 03:41:31 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Mon, 2 Apr 2012 03:41:31 -0700 (PDT) In-Reply-To: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> Date: Mon, 2 Apr 2012 10:41:31 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235452e75055f78d04bcafd50b Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:41:34 -0000 --00235452e75055f78d04bcafd50b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/2 Maoke > > > 2012/4/2 R=E9mi Despr=E9s > >> >> 2012-04-02 11:45, Maoke: >> ... >> >> i am still in review on the version -06, but i have found something not >> qualified (inconsistent semantics). >> >> >> Asserting there are flaws implies ability to describe them. >> What you have already "found" will be looked at fairly when described. >> (Just saying "inconsistent semantics" is unsuffcient). >> > > because i don't think we didn't cover that topic before. > > sorry here my wording is impolite. i mean we covered that and therefore please let me later include that into my summary instead of putting it separetely for easy read. regards, maoke --00235452e75055f78d04bcafd50b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/2 Maoke <fibrib@gmail.com>


2012/4/2 R=E9mi Despr= =E9s <despres.remi@laposte.net>

2012-04-02 =A011:= 45, Maoke:
...
i am still in review on the version -06, but i have found something no= t qualified (inconsistent semantics).

Asserting there are flaws implies ability to describe them.
What you have already "found" will be looked at fairly when = described. (Just saying "inconsistent semantics" is unsuffcient).=

because i don'= t think we didn't cover that topic before.=A0
=A0

sorry here= my wording is impolite. i mean we covered that and therefore please let me= later include that into my summary instead of putting it separetely for ea= sy read.=A0

regards,
maoke
--00235452e75055f78d04bcafd50b-- From wentaoshang@gmail.com Mon Apr 2 03:42:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6826121F8975 for ; Mon, 2 Apr 2012 03:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKhbH7+SAkCg for ; Mon, 2 Apr 2012 03:42:50 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD221F8971 for ; Mon, 2 Apr 2012 03:42:50 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2017669wib.13 for ; Mon, 02 Apr 2012 03:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t8QFZ0TKbV1HGCq85ItFB+7LZDJ4SI9AykAf65o1ff8=; b=VXtSi6pA1VthweBHlrDnVfkLzo30ohI42eIHF5cxIdnaKrqnrhnpsrY7QW+f+QLcg9 5bEiNKb4peGCAtht4Q0SHkejKpxs/jH07nP5zZ+HHaOgS3FX9EJ0aGUiCM2XtXZF6std q9186nusQ9jBPT4pwt3YPfuZ2cqYRcRbyAXD5E7YzjmCg8yzsM9/IXhjMX1IGPsaYa+C f8/OOfXvHbn2XdPflUIejHODUR4Y0IZf9JTJQvGeighFGQdUzMj3dAxqiNHaQeXjZBqq OljqGYfK7JBrRs5tyBHoe1waGzAAAMRttijrK0SvebyshrJ0GAG/Q1BRckUB3vbkAXiI CvqA== MIME-Version: 1.0 Received: by 10.180.88.67 with SMTP id be3mr23584820wib.20.1333363369636; Mon, 02 Apr 2012 03:42:49 -0700 (PDT) Received: by 10.180.94.105 with HTTP; Mon, 2 Apr 2012 03:42:49 -0700 (PDT) In-Reply-To: <4F797133.3030100@go6.si> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F797133.3030100@go6.si> Date: Mon, 2 Apr 2012 18:42:49 +0800 Message-ID: From: Wentao Shang To: "Jan Zorz @ go6.si" Content-Type: text/plain; charset=UTF-8 Cc: softwires@ietf.org Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:42:51 -0000 Well, IMHO operational test is definitely necessary, as is already done by the MAP design. It is unresponsible and even dangerous to publish an untested design, not to mention standardizing it. regards, Wentao 2012/4/2 Jan Zorz @ go6.si : > On 4/2/12 8:22 AM, Wentao Shang wrote: >> >> Totally agree with Maoke. >> >> As one of the developers for the MAP design team, I think it's unfair >> to put both MAP and 4rd-u as experimental. It's good to see the >> attempt to implement 4rd-u. However, any discussion about >> standardization should be postponed until it is coded, deployed and >> fully tested. > > > Hi, > > Do you think we have time for this? Meantime, CGNs have free way into > networks without any alternative... > > Cheers, Jan > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires -- Wentao Shang Master Candidate and Research Assistant at CERNET Center & NGN Lab, EE Department, Tsinghua University From jan@go6.si Mon Apr 2 03:44:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402E321F8971 for ; Mon, 2 Apr 2012 03:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FClT6Ac64ho4 for ; Mon, 2 Apr 2012 03:44:27 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22D021F896E for ; Mon, 2 Apr 2012 03:44:27 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 8DF0A23780B5 for ; Mon, 2 Apr 2012 12:44:25 +0200 (CEST) Message-ID: <4F798309.7010508@go6.si> Date: Mon, 02 Apr 2012 12:44:25 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> In-Reply-To: <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:44:28 -0000 On 4/2/12 12:33 PM, Ole Trřan wrote: > the status quo; with no path forward just means that we'll > effectively kill A+P. I would certainly not recommend my product > managers to implement either of this given the risk. is there > consensus to abandon these efforts (which is basically what we do by > publishing them as experimental anyway)? > > the alternatives we have are perfectly fine: - Shared IPv4 address > over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 > transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 > transport -> DS-lite with Public IPv4 address > > problem solved. ;-) So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. Cheers, Jan Zorz (speaking for myself only) From sunjingwen@live.cn Mon Apr 2 04:11:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB921F8716 for ; Mon, 2 Apr 2012 04:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.105 X-Spam-Level: * X-Spam-Status: No, score=1.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alI56+y9wfXg for ; Mon, 2 Apr 2012 04:11:22 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id 246F121F8713 for ; Mon, 2 Apr 2012 04:11:22 -0700 (PDT) Received: from BLU0-SMTP218 ([65.55.111.137]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 04:11:21 -0700 X-Originating-IP: [59.64.255.246] X-Originating-Email: [sunjingwen@live.cn] Message-ID: Received: from COMPUTER ([59.64.255.246]) by BLU0-SMTP218.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 04:11:20 -0700 Date: Mon, 2 Apr 2012 19:11:18 +0800 From: sunjingwen To: chenycmx , =?utf-8?B?T2xlIFRyw7hhbg==?= References: <2012040115443836452736@gmail.com>, , <201204011938349849434@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart051656422203_=----" X-OriginalArrivalTime: 02 Apr 2012 11:11:20.0735 (UTC) FILETIME=[552CE2F0:01CD10C1] Cc: softwires WG Subject: Re: [Softwires] [softwire]Basic Requirements for Customer Edge Routers X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sunjingwen List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:11:23 -0000 ------=_001_NextPart051656422203_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBPbGUgYW5kIHl1Y2hpIGNoZW4sDQogICBUaGFuayB5b3UgZm9yIHlvdXIgY29ycmVjdGlv bi4gSSBoYXZlIHVuZGVyc3Rvb2QgaXQuDQoNCkJlc3QgcmVnYXJkISANCg0KDQoNCnN1bmppbmd3 ZW4NCg0KRnJvbTogWXVjaGkgQ2hlbg0KRGF0ZTogMjAxMi0wNC0wMSAxOTozOA0KVG86IE9sZSBU csO4YW4NCkNDOiBzb2Z0d2lyZXMgV0c7IHN1bmppbmd3ZW4NClN1YmplY3Q6IFJlOiBSZTogW1Nv ZnR3aXJlc10gW3NvZnR3aXJlXUJhc2ljIFJlcXVpcmVtZW50cyBmb3IgQ3VzdG9tZXIgRWRnZSBS b3V0ZXJzDQpEZWFyIE9sZSwNClRoYW5rcyBmb3IgeW91ciBxdWljayBhbmQgcGF0aWVudCByZXBs eS5JIHdhcyBqdXN0IHdvbmRlcmluZyB3aHkgdGhlIElQdjYgaW50ZXJmYWNlIA0KaXMgcHJlZmVy cmVkIHRvIHRoZSBvdGhlcnMuDQpTbyB0aGUgcG9pbnQgaXMgdGhhdCBhcyB0aGUgYWNjZXNzIG5l dHdvcmsgaXMgdHJhbnNpdGlvbmluZyB0byBEUy1MaXRlLCB0aGUgbmF0aXZlIElQdjQgDQppbnRl cmZhY2UgaXMgYmVjb21pbmcgbW9yZSBhbmQgbW9yZSB1bmxpa2VseSB0byBiZSB1c2VkLCBhbmQg aGVuY2UgdGhlIElQdjYgdHJhbnNwb3J0IA0Kc2hvdWxkIGJlIHByaW9yIHRvIHRoZSBJUHY0IHRy YW5zcG9ydCwgaW4gb3JkZXIgdG8gZW5zdXJlIGEgYmV0dGVyIElQdjQgc2VydmljZS4gSSBob3Bl DQpJIGhhdmUgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHkuIA0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0K DQpZdWNoaSBDaGVuDQoNCkZyb206IE9sZSBUcsO4YW4NCkRhdGU6IDIwMTItMDQtMDEgMTY6NDIN ClRvOiBjaGVueWNteA0KQ0M6IHN1bmppbmd3ZW47IHNvZnR3aXJlcyBXRw0KU3ViamVjdDogUmU6 IFtTb2Z0d2lyZXNdIFtzb2Z0d2lyZV1CYXNpYyBSZXF1aXJlbWVudHMgZm9yIEN1c3RvbWVyIEVk Z2UgUm91dGVycw0KPiBJdCBzZWVtcyB0aGF0IHlvdSBoYXZlIG1pc3NlZCBzb21lIHN0YXRlbWVu dHMgaW4gdGhlIGRyYWZ0LiBJbiBzZWN0aW9uIDQuMywNCj4gdGhlcmUgYXJlIHNvbWUgbGluZXMg Y2xhcmlmeWluZyAzIHByaW5jaXBsZXMgZm9yIElQdjQgaW50ZXJmYWNlIHNlbGVjdGlvbiwganVz dA0KPiBhYm92ZSB0aGUgd29yZHMgeW91IHF1b3RlZDoNCj4gPjEuICBJUHY2IHRyYW5zcG9ydCBp cyBwcmVmZXJyZWQgb3ZlciBhbnkgb3RoZXIuDQo+IA0KPiA+Mi4gIExlc3MgYWRkcmVzcyB0cmFu c2xhdGlvbiBvY2N1cnJlbmNlcyBpcyBwcmVmZXJyZWQgb3ZlciBtb3JlLg0KPiAgICAgICAgW1JG QzU4NjRdW0ktRC5kb25sZXktbmF0NDQ0LWltcGFjdHNdDQo+IA0KPiA+My4gIFRoZSBjbG9zZXIg dGhlIHN0YXRlIGlzIHRvIHRoZSBlZGdlLCB0aGUgYmV0dGVyLltSRkMxOTU4XQ0KPiANCj4gQWNj b3JkaW5nIHRvIHRoZSBmaXJzdCBwcmluY2lwbGUsIHRoZSBJUHY2IHRyYW5zcG9ydCBpcyBwcmlv ciB0byBhbnkgIG90aGVyLiBUaGF0DQo+IGlzIHRoZSByZWFzb24gd2h5IHRoZSBEUy1MaXRlIHR1 bm5lbCBpbnRlcmZhY2UgaXMgcHJlZmVycmVkIHRvIG5hdGl2ZSBJUHY0IG9uZS4NCj4gIA0KPiBB Y3R1YWxseSwgSSBoYXZlIGFub3RoZXIgcXVlc3Rpb24gYWJvdXQgdGhpcyBwb2ludC4gSSB0aGlu ayB0aGUgcXVlc3Rpb24gaXMNCj4gbm90ICdXaHkgbm90IHVzZSBOYXRpdmUgSVB2NCBpbnRlcmZh Y2UgZm9yIGJldHRlciBwZXJmb3JtYW5jZScsIGJ1dCAnV2h5IHByZWZlcg0KPiB0aGUgSVB2NiB0 dW5uZWwgaW50ZXJmYWNlIHRvIHRoZSBuYXRpdmUgSVB2NCBpbnRlcmZhY2UnLiBJIGRpZG4ndCBm aW5kIHRoZSBhbnN3ZXIgaW4NCj4gdGhlIGRyYWZ0LiBQZXJoYXBzIEkndmUgbWlzc2VkIHNvbWUg d29yZHMgYXMgd2VsbC4gSU1ITywgYSBjbGFyaWZpY2F0aW9uIG9mIHRoZQ0KPiByZWFzb24gY291 bGQgYmUgcHJvdmlkZWQgaW4gdGhlIGRyYWZ0LCBhbmQgdGh1cyB0aGUgcHJpbmNpcGxlcyBhYm91 dCBtaWdodCBzZWVtDQo+IHRvIGJlIG1vcmUgY29udmljdGl2ZS4NCg0KdGhlIGlkZWEgd2FzIHRv IGFsbG93IGZvciBhIGNvbnRyb2xsZWQgbW92ZSBmcm9tIGEgbmF0aXZlIElQdjQgY29ubmVjdGlv biAodGhhdCBpcyBiZWluZyBzdW5ldCBmb3IgYW4gSVB2NiBvbmx5IGFjY2VzcykgdG8gSVB2NCBv dmVyIERTLWxpdGUuIHRoZSBwb2xpY3kgdGFibGUgcHJvcG9zZWQgaXMgYWxsIGFib3V0IElQdjQg ZXhpdCwgbm90IHRyeWluZyB0byBvcHRpbWl6ZSB3aGF0IElQdjQgbGluay1sYXllciBtYXkgZ2l2 ZSB0aGUgYmVzdCBJUHY0IHNlcnZpY2UuDQoNCmNoZWVycywNCk9sZQ== ------=_001_NextPart051656422203_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear Ole and yuchi chen,
   Thank you for your correction. I have understood it.
 
Best regard! 
sunjingwen
 
From: Yuchi Chen
Date: 2012-04-01 19:38
Subject: Re: Re: [Softwires] [softwire]Basic Requirements= for=20 Customer Edge Routers
Dear Ole,
Thanks for your quick and patient repl= y.I was=20 just wondering why the IPv6 interface
is preferred to the others.
So the point is that as the access net= work is=20 transitioning to DS-Lite, the native IPv4
interface is becoming more and more un= likely=20 to be used, and hence the IPv6 transport
should be prior to the IPv4 transport,= in=20 order to ensure a better IPv4 service. I hope
I have understood it correctly.
 
Best regards!
Yuchi Chen
 
Date: 2012-04-01 16:42
To: chenycmx
CC: sunjingwen;= softwires WG
Subject: Re: [Softwires] [softwire]Basic Requirements for= =20 Customer Edge Routers
> It seems that you have missed = ;some statements in the draft. In section&nb= sp;4.3,
> there are some lines clarifying 3&= nbsp;principles for IPv4 interface selection, jus= t
> above the words you quoted:
> >1.  IPv6 transport is preferre= d over any other.
> 
> >2.  Less address translation o= ccurrences is preferred over more.
>        [RFC5864][I-D.don= ley-nat444-impacts]
> 
> >3.  The closer the state = is to the edge, the better.[RFC1958]
> 
> According to the first principle, = the IPv6 transport is prior to any &nbs= p;other. That
> is the reason why the DS-Lite = ;tunnel interface is preferred to native IPv= 4 one.
>  
> Actually, I have another question = about this point. I think the question = is
> not 'Why not use Native IPv4 = interface for better performance', but 'Why = prefer
> the IPv6 tunnel interface to the&n= bsp;native IPv4 interface'. I didn't find th= e answer in
> the draft. Perhaps I've missed som= e words as well. IMHO, a clarification = of the
> reason could be provided in the&nb= sp;draft, and thus the principles about migh= t seem
> to be more convictive.
 
the idea was to allow for a contro= lled move from a native IPv4 connection = ;(that is being sunet for an IPv6 only&= nbsp;access) to IPv4 over DS-lite. the polic= y table proposed is all about IPv4 exit= , not trying to optimize what IPv4 link= -layer may give the best IPv4 service.
 
cheers,
Ole
 
------=_001_NextPart051656422203_=------ From ichiroumakino@gmail.com Mon Apr 2 04:13:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C621F8984 for ; Mon, 2 Apr 2012 04:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnSHoCpADQTJ for ; Mon, 2 Apr 2012 04:13:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2145921F8983 for ; Mon, 2 Apr 2012 04:13:39 -0700 (PDT) Received: by werb10 with SMTP id b10so2029686wer.31 for ; Mon, 02 Apr 2012 04:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vuVo24CE5Pj+vJkAX+m5c46wquStg1MoXteoGrQ6UwU=; b=oh734BTZ9n/XW625zBR9bl78iqnTA5ZLf81idxM9FZxD0ZbDTJnPknq8v1LD/oFRic BAOY8I3Nlqn24KoJNziq1LNNbn5iE6Ouk9QfrlccQ8VLcnWXqtGHcinpn7UiixxWVAMj hm8hdk2zyKG43l8QNE4g58Fd6lQilXLP4nvt8QMJ8al8eI/kuITZHT8On1GW51ZOz0Zp ZphxMUFctvA1tO7Hivy4O0L23ahHhKAfnonytR6KRxhnCCktKYM5x/04ax3sFoFv83Mw 3bv/oOaNcTioLLC5JmZ8gB9jXVayO0gVH1FDD0v0fiSmbiyB30RMt7shBmnSpfQA7aCD Y2zQ== Received: by 10.180.24.66 with SMTP id s2mr23984441wif.7.1333365219210; Mon, 02 Apr 2012 04:13:39 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-172.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n20sm53968981wiw.5.2012.04.02.04.13.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 04:13:38 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4F798309.7010508@go6.si> Date: Mon, 2 Apr 2012 13:13:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F798309.7010508@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:13:41 -0000 On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: > On 4/2/12 12:33 PM, Ole Tr=F8an wrote: >> the status quo; with no path forward just means that we'll >> effectively kill A+P. I would certainly not recommend my product >> managers to implement either of this given the risk. is there >> consensus to abandon these efforts (which is basically what we do by >> publishing them as experimental anyway)? >>=20 >> the alternatives we have are perfectly fine: - Shared IPv4 address >> over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 >> transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 >> transport -> DS-lite with Public IPv4 address >>=20 >> problem solved. ;-) >=20 > So, if we deprecate RFC6346 and with that the whole A+P idea - is that = solving anything? Really? - less IPv4 exit mechanisms to implement and choose among. that must be = good, no? (currently there are at least 4 mechanisms proposed in the A+P H&S and = mesh space) - large stateful boxes in the SP network; we know how to build them, and we can charge more for them. that's a good thing too, no? ;-) > I'm also really tempted to do that if this community can't decide what = to do in a quick time manner, showing the industry the path forward. yes, if there was a path forward I would also be a lot less despondent = with regards to A+P. cheers, Ole= From satoru.matsushima@gmail.com Mon Apr 2 04:44:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3B21F891C for ; Mon, 2 Apr 2012 04:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAg9da+xHpwQ for ; Mon, 2 Apr 2012 04:44:05 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE0321F889B for ; Mon, 2 Apr 2012 04:43:39 -0700 (PDT) Received: by dady13 with SMTP id y13so2942792dad.27 for ; Mon, 02 Apr 2012 04:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=13yRIrXLE9gnt1auIzXsjEC8M+wbdjP4DDub8imZWgM=; b=G8CgmqRQSNSx1DnxNnzjrkAMXaztu9PwT9Yc58TUxk/dS4kjE6xLI938E5jO/PaIxl 1knoMfUsOHMLBGfWWHl87cdZsvxBiNCWZaO+FsmPM4WsORLDjYA/L3RGsg9T396BiI9z evP1fBiwsCMiC9tnG4C1N1gba07qWkPCvjALAiV5ljrMdsjxjqIDPfltPQFU0DLG9erW pPR8ofchKVV5Pcsfdu+i53F4AuZfdFGlKL+QgJtd36bTE930YlUdRNHGG97gWOqUD0K6 VizJ9pitZagiiweRieMEpJahKT5cT3CA1EKtH9guS74Yxn1WO6UcxTZqmlPBiY9mKXcK ajvQ== Received: by 10.68.201.37 with SMTP id jx5mr7845839pbc.109.1333367019183; Mon, 02 Apr 2012 04:43:39 -0700 (PDT) Received: from [10.201.82.174] ([202.45.12.141]) by mx.google.com with ESMTPS id o9sm13956883pbe.60.2012.04.02.04.43.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 04:43:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> Date: Mon, 2 Apr 2012 20:43:35 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <93698BF8-E9B7-41E1-AB04-60DA3AF9BD1F@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> To: Softwires-wg X-Mailer: Apple Mail (2.1257) Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQg==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:44:06 -0000 So, I choose MAP. > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 = address Otherwise, I'm tempted to do the above, if the wg decide to choose = 4rd-u. As an operator, the 4rd-u scares us too much since no experience of = 4rd-u's new unified tunneling in our circumstance at this time. Sorry, = Remi-san. I really respect you, but I can't decide to do 4rd-u in our = real production network. cheers, --satoru On 2012/04/02, at 19:33, Ole Tr=C3=B8an wrote: >> If this is to say that until a BOF is started, you will keep your = objection(s) unknown, I continue to take it as a lack of identified = objections. >=20 > the objections I'm aware of are: > - people are uncomfortable with only a double translation solution > * injection of IPv4 routes into IPv6 > * transparency > * hard to identify IPv4 traffic in the "core" > * higher risk of leakage. i.e single translation / packets outside = the domain > (all these apply equally to MAP-T btw) > - redefining the modified EUI-64 format (V-octet) and the consequences = standardization wise of that > - overloading information in the fragment header >=20 > (please don't respond to these, FYI only. I'm on Easter holiday.) >=20 > if it wasn't for my general "uncomfortableness" with = double-translation I'd could be convinced that a single solution was = possible. >=20 > the status quo; with no path forward just means that we'll effectively = kill A+P. > I would certainly not recommend my product managers to implement = either of this given the risk. > is there consensus to abandon these efforts (which is basically what = we do by publishing them as experimental anyway)? >=20 > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 = address >=20 > problem solved. ;-) >=20 > cheers, > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Apr 2 05:16:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0364121F868C for ; Mon, 2 Apr 2012 05:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awoijVg5SDsb for ; Mon, 2 Apr 2012 05:16:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2D121F8564 for ; Mon, 2 Apr 2012 05:16:18 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id B86079400C8; Mon, 2 Apr 2012 14:16:10 +0200 (CEST) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 14:16:09 +0200 Message-Id: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> To: Congxiao Bao Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 12:16:21 -0000 Hi, Congxiao, During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws". Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft.=20 Since you have AFAIK made no previous contribution on the mailing list = to justify such an assertion, would you be kind enough to explain what, = in your understanding, wouldn't work in 4rd-U?=20 Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want). Thanks, RD=20 From despres.remi@laposte.net Mon Apr 2 06:46:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8521F84DA for ; Mon, 2 Apr 2012 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JhBukpsgeYB for ; Mon, 2 Apr 2012 06:46:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CB80B21F84D6 for ; Mon, 2 Apr 2012 06:46:25 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id D1018940093; Mon, 2 Apr 2012 15:46:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> Date: Mon, 2 Apr 2012 15:46:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:46:34 -0000 Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit : >> If this is to say that until a BOF is started, you will keep your = objection(s) unknown, I continue to take it as a lack of identified = objections. >=20 > the objections I'm aware of are: > - people are uncomfortable with only a double translation solution Are you furtively suggesting that 4rd-U has all limitations of a real = double translation solution like MAP-T?=20 That mays sound tactically smart, but isn't justified by facts. > * injection of IPv4 routes into IPv6 No need for this with 4rd-U (and BTW not even needed with MAP-T, AFAIK) > * transparency 4rd-U is fully transparent. It has been precisely designed for this (and to simultaneously keep = compatibility with IPv6-only O&M). > * hard to identify IPv4 traffic in the "core" The V octet is precisely what facilitates IPv4-traffic identification in = the core. > * higher risk of leakage. i.e single translation / packets outside = the domain > (all these apply equally to MAP-T btw) ??? If you have a reference explaining which new risk you see, I will look = at it. > - redefining the modified EUI-64 format (V-octet) As said in the draft, the u=3Dg=3D1 combinations of the V octet 'differs = from "u" =3D 0, reserved for local-scope Interface IDs, and also differs = from "u" =3D 1 and "g"=3D 0, reserved for unicast Interface IDs using = the EUI-64 format.' There is therefore no "redefinition" of the modified EUI-64 format. > and the consequences standardization wise of that > - overloading information in the fragment header Using, between CEs and BRs, unused bits of packet IDs doesn't interfere = with any existing RFC, independently from its being considered = overloading or not.=20 > (please don't respond to these, FYI only. I'm on Easter holiday.) Asking that a list of objections shouldn't be answered is to me very = unusual! (You need not to look at my response before you return from holiday!) > if it wasn't for my general "uncomfortableness" with = double-translation I'd could be convinced that a single solution was = possible. >=20 > the status quo; with no path forward just means that we'll effectively = kill A+P. Validating 4rd-U with running code, clearly isn't status quo; It is a path forward which, in case of success, will also be success of = the generic A+P approach.=20 > I would certainly not recommend my product managers to implement = either of this given the risk. Either of this??? > is there consensus to abandon these efforts (which is basically what = we do by publishing them as experimental anyway)? Suggesting that validating 4rd-U would be abandoning the A+P effort is = very daring.=20 It is precisely a way to try and have a clean and unique standard for = shared addresses: - working on mesh topologies - without per-customer state in ISP nodes > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 = address Your suggesting that these three might be sufficient is really strange:=20= - none of these supports mesh topologies - In order to support shared addresses, all these need per-customer or = per session states in network devices. > problem solved. ;-) Enjoy you vacation. RD >=20 > cheers, > Ole >=20 From xing@cernet.edu.cn Mon Apr 2 06:50:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232521F854E for ; Mon, 2 Apr 2012 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyXl7T5uGawD for ; Mon, 2 Apr 2012 06:50:31 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF33321F849D for ; Mon, 2 Apr 2012 06:50:30 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.50.215]) by centos (Coremail) with SMTP id AQAAf3BLaALPrXlPsH0AAA--.2515S2; Mon, 02 Apr 2012 21:46:57 +0800 (CST) Message-ID: <4F79AE94.90709@cernet.edu.cn> Date: Mon, 02 Apr 2012 21:50:12 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F798309.7010508@go6.si> <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> In-Reply-To: <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3BLaALPrXlPsH0AAA--.2515S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WrW7Cw4UJFWDAr45Ar1rXrb_yoW8WFWkpF Z0kF4kGa4DJF1fZ3yv9w4Yv3sYv3W8X3y7Jry3JwnxAayaqryIyrWrKay5ZF97Wr4rJw1a vryF9Fy5Ja15ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUSmb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2 jsIE14v26r4j6F4UM28EF7xvwVC2z280aVCY1x0267AKxVW8JVW8Jr1le2I262IYc4CY6c 8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx kIecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07bonQUUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: softwires@ietf.org Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:50:32 -0000 于 2012/4/2 19:13, Ole Trøan 写道: > On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: > >> On 4/2/12 12:33 PM, Ole Trøan wrote: >>> the status quo; with no path forward just means that we'll >>> effectively kill A+P. I would certainly not recommend my product >>> managers to implement either of this given the risk. is there >>> consensus to abandon these efforts (which is basically what we do by >>> publishing them as experimental anyway)? >>> >>> the alternatives we have are perfectly fine: - Shared IPv4 address >>> over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 >>> transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 >>> transport -> DS-lite with Public IPv4 address >>> >>> problem solved. ;-) >> So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? > - less IPv4 exit mechanisms to implement and choose among. that must be good, no? > (currently there are at least 4 mechanisms proposed in the A+P H&S and mesh space) > - large stateful boxes in the SP network; we know how to build them, > and we can charge more for them. that's a good thing too, no? ;-) > >> I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. > yes, if there was a path forward I would also be a lot less despondent with regards to A+P. I choose MAP and fully believe in A+P, based on the operation experiences of the large IPv6-only network - CERNET2. Regards, xing > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From ichiroumakino@gmail.com Mon Apr 2 07:05:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0897B21F8518 for ; Mon, 2 Apr 2012 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeWxLczl1+dY for ; Mon, 2 Apr 2012 07:05:13 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4221F8516 for ; Mon, 2 Apr 2012 07:05:13 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2182614wib.13 for ; Mon, 02 Apr 2012 07:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nVfZkL9iTYMS6yR9f+VRnir96RJ1E5JA9fQKdBa2Q2s=; b=ykg/Lm6UgDwCsZDW+BGsJ5PbSU9MftkUI5+OgWZaLb0NkvMQYEeW7rhUqTmCTyTmtW r/Ln0d2ujsomKVvmEZBL41dhQ/MbulFWj5ODm/yIqgmAbR0/5WSwaNrWYAIjDgWMAGY9 ltQDvu02kCtmkBPi/GxiHOuWhBpPtDVgp3he/Rns6MC1qU/tHiO/Kg9d7XJnCiHDynzr inIN1bIPtXd0wopmsswQpRaqOSLBo9YKbz20gfQ9e3UKl34P9S2m5NQJixO8/8iOi0rP YXTWRtxgtNffxXRBhK22nz0Xgc2T5TLFw76Tz41dWSvlDc/E/7VEWhvA5Iqu+eC6F+xy 8naA== Received: by 10.180.107.101 with SMTP id hb5mr25365550wib.7.1333375512527; Mon, 02 Apr 2012 07:05:12 -0700 (PDT) Received: from dhcp-10-61-98-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k6sm34336929wiy.7.2012.04.02.07.05.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 07:05:11 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 2 Apr 2012 16:05:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F768763-7E8A-4404-80A2-A79DDFC5C63B@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:05:14 -0000 Remi, >> (please don't respond to these, FYI only. I'm on Easter holiday.) >=20 > Asking that a list of objections shouldn't be answered is to me very = unusual! it was to remind you of the problems with 4rd-U. we have been many = rounds on these exact arguments, and I don't see the point of rehashing = the discussion. we're going to continue to have different views on the = new use of u/g, the overloading of fragmentation, and that double = translation can replace tunneling. I'd rather see arguments from = non-authors. (this reminds me of cockfighting; somewhat entertaining for the = spectators (if that's your kind of thing), one is declared a winner, but = both combatants die... cheers, Ole= From despres.remi@laposte.net Mon Apr 2 07:34:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7744421F858E for ; Mon, 2 Apr 2012 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzjqW9rBr2lW for ; Mon, 2 Apr 2012 07:34:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4C21F8592 for ; Mon, 2 Apr 2012 07:34:46 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id t2ah1i00E37Y3f4032aiTs; Mon, 02 Apr 2012 16:34:44 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <7F768763-7E8A-4404-80A2-A79DDFC5C63B@employees.org> Date: Mon, 2 Apr 2012 16:34:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42618524-4F76-4341-8F14-0B58203875BD@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <7F768763-7E8A-4404-80A2-A79DDFC5C63B@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:34:49 -0000 Le 2012-04-02 =E0 16:05, Ole Tr=F8an a =E9crit : > Remi, >=20 >>> (please don't respond to these, FYI only. I'm on Easter holiday.) >>=20 >> Asking that a list of objections shouldn't be answered is to me very = unusual! >=20 > it was to remind you of the problems with 4rd-U. > we have been many rounds on these exact arguments, and I don't see the = point of rehashing the discussion.=20 Then, don't do it yourself. > we're going to continue to have different views on the new use of u/g, = the overloading of fragmentation, and that double translation can = replace tunneling. > I'd rather see arguments from non-authors. Then, arguments from others than MAP-team members and 4rd-U authors = would be the most valuable. Sheng Jiang of Huawei writing "we are going to implement 4rd-u and do = operational tests" is therefore a very important one (like it or not). > (this reminds me of cockfighting; somewhat entertaining for the = spectators (if that's your kind of thing), one is declared a winner, but = both combatants die... You may fear that MAP T+E would be about to die (your judgement) but, in = particular in view of the quotation above, I think 4rd-U as in a good = position to remain alive. Your recent comment suggesting that hub&spoke and per-customer stateful = solutions might after all be sufficient seems to me a sheer lack of = confidence in the solution you propose. (It looks like you become tired = to work on the double-standard approach, knowing that arguments for it = are too weak for success.) This doesn't justify, however, your trying to also kill the single = standard solution, the most credible A+P approach we have on the table. RD >=20 > cheers, > Ole From cb.list6@gmail.com Mon Apr 2 08:09:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DEE21F85EF for ; Mon, 2 Apr 2012 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUFLL3EM0HBr for ; Mon, 2 Apr 2012 08:09:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1358021F85F1 for ; Mon, 2 Apr 2012 08:09:21 -0700 (PDT) Received: by iazz13 with SMTP id z13so5219459iaz.31 for ; Mon, 02 Apr 2012 08:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xEsk7VwmHwjCXuyD78LdklG69hwB6tpWNc0rT8hu14U=; b=Q2p+EeMP2OaHPrsxqwpaPo9pb48Lw37H473673l0CeqXli0MI89V4QK48EVftTyTXz AR6FoGi5ykYEe257U0LQyVR1NrOpHIa0yw5qIOF95nWF8yb07xmQObfgbsehmEbcZPVf Hljxc7O6Z62DjYj6tO118J5nMa74bK5cLslui9fCOxiRGXK8O+7MoaVRUV3cUU/BFcmx 1bYDezCi5d50kNXvTLcayLGwQ9nEU1rQ2sHY0zJZzJoljnpC1d+fTaFNKC9sVPIqkDZW Vs7jdaWzCDyVajlajLdlzwi6TdrPVE+ErVk1z/pEacqojzpqQL2WwXyYIoVDxcggmvSS Xv8w== MIME-Version: 1.0 Received: by 10.50.216.232 with SMTP id ot8mr7086654igc.22.1333379360758; Mon, 02 Apr 2012 08:09:20 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:08:50 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:08:50 -0700 (PDT) In-Reply-To: <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F798309.7010508@go6.si> <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> Date: Mon, 2 Apr 2012 08:08:50 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=14dae934048d261a5f04bcb39336 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:09:22 -0000 --14dae934048d261a5f04bcb39336 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 2, 2012 4:13 AM, "Ole Tr=F8an" wrote: > > > On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: > > > On 4/2/12 12:33 PM, Ole Tr=F8an wrote: > >> the status quo; with no path forward just means that we'll > >> effectively kill A+P. I would certainly not recommend my product > >> managers to implement either of this given the risk. is there > >> consensus to abandon these efforts (which is basically what we do by > >> publishing them as experimental anyway)? > >> > >> the alternatives we have are perfectly fine: - Shared IPv4 address > >> over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 > >> transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 > >> transport -> DS-lite with Public IPv4 address > >> > >> problem solved. ;-) > > > > So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? > > - less IPv4 exit mechanisms to implement and choose among. that must be good, no? > (currently there are at least 4 mechanisms proposed in the A+P H&S and mesh space) > - large stateful boxes in the SP network; we know how to build them, > and we can charge more for them. that's a good thing too, no? ;-) > Do you have data? Or are you perpetuating the myth that stateless is cheaper? Last I checked stateless requires some heavy duty provisioning systems and less efficient static allocation of expensive ipv4 addresses > > I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. > I ietf has seldom shown the path forward. In this particular context ....especially so. > yes, if there was a path forward I would also be a lot less despondent with regards to A+P. > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --14dae934048d261a5f04bcb39336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2012 4:13 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>
>
> On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si= wrote:
>
> > On 4/2/12 12:33 PM, Ole Tr=F8an wrote:
> >> the status quo; with no path forward just means that we'l= l
> >> effectively kill A+P. I would certainly not recommend my prod= uct
> >> managers to implement either of this given the risk. is there=
> >> consensus to abandon these efforts (which is basically what w= e do by
> >> publishing them as experimental anyway)?
> >>
> >> the alternatives we have are perfectly fine: - Shared IPv4 ad= dress
> >> over IPv4 transport -> =A0NAT444 / CGN - Shared IPv4 addre= ss over IPv6
> >> transport -> =A0464XLAT / DS-lite - Full IPv4 address over= IPv6
> >> transport -> =A0DS-lite with Public IPv4 address
> >>
> >> problem solved. ;-)
> >
> > So, if we deprecate RFC6346 and with that the whole A+P idea - is= that solving anything? Really?
>
> - less IPv4 exit mechanisms to implement and choose among. that must b= e good, no?
> =A0(currently there are at least 4 mechanisms proposed in the A+P H&am= p;S and mesh space)
> - large stateful boxes in the SP network; we know how to build them, > =A0and we can charge more for them. that's a good thing too, no? ;= -)
>

Do you have data? Or are you perpetuating the myth that stateless is che= aper?

Last I checked stateless requires some heavy duty provisioning systems a= nd less efficient static allocation of expensive ipv4 addresses

> > I'm also really tempted to do that if this community can&#= 39;t decide what to do in a quick time manner, showing the industry the pat= h forward.
>

I ietf has seldom shown the path forward. In this particular context ...= .especially so.

> yes, if there was a path forward I would also be a lot less despond= ent with regards to A+P.
>
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--14dae934048d261a5f04bcb39336-- From cb.list6@gmail.com Mon Apr 2 08:11:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD521F861B for ; Mon, 2 Apr 2012 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHAKriphwWZ3 for ; Mon, 2 Apr 2012 08:11:15 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 436D621F861A for ; Mon, 2 Apr 2012 08:11:15 -0700 (PDT) Received: by dady13 with SMTP id y13so3268555dad.27 for ; Mon, 02 Apr 2012 08:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OvkDeMIMBoAit5AdF69XAPAAF1QDADgxKMFRTfiU1MU=; b=qDoTnLwFN4y6vFEigY8mDoZAyA1Shns+H3mORHFzAin4y5ofZtArfbo55Qs/vBl6FU fBeFj+97H4Zp5h7cGgNVpLXIm35Ni01A1id9CiSGNF3RgE6eax5nhARVrxA+i+SDCfE3 t0tcmk0MapSKJ1OQVftUpgcA+pE0uC1kxrCnJf/GX/Y48QsalV0f4Xah5KIFARDYeGZR 5+rB/w2Pu3M6blIw4Rwc/gzWYzt7RfS1cXc9EDMD3c20HdDkm3Avog6TqKcJcDPkH7Ks 7pd38/oMslnYAMwAobDL5S6lk7Odo/zUcFuOVEAN2xQ6uzTKi2C5ogaScK0nGBEvpdXa eDUg== MIME-Version: 1.0 Received: by 10.68.200.9 with SMTP id jo9mr21735744pbc.19.1333379472335; Mon, 02 Apr 2012 08:11:12 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:08:50 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:08:50 -0700 (PDT) In-Reply-To: <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F798309.7010508@go6.si> <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> Date: Mon, 2 Apr 2012 08:08:50 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=047d7b15fbcfcca38d04bcb39934 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:11:16 -0000 --047d7b15fbcfcca38d04bcb39934 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 2, 2012 4:13 AM, "Ole Tr=F8an" wrote: > > > On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: > > > On 4/2/12 12:33 PM, Ole Tr=F8an wrote: > >> the status quo; with no path forward just means that we'll > >> effectively kill A+P. I would certainly not recommend my product > >> managers to implement either of this given the risk. is there > >> consensus to abandon these efforts (which is basically what we do by > >> publishing them as experimental anyway)? > >> > >> the alternatives we have are perfectly fine: - Shared IPv4 address > >> over IPv4 transport -> NAT444 / CGN - Shared IPv4 address over IPv6 > >> transport -> 464XLAT / DS-lite - Full IPv4 address over IPv6 > >> transport -> DS-lite with Public IPv4 address > >> > >> problem solved. ;-) > > > > So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? > > - less IPv4 exit mechanisms to implement and choose among. that must be good, no? > (currently there are at least 4 mechanisms proposed in the A+P H&S and mesh space) > - large stateful boxes in the SP network; we know how to build them, > and we can charge more for them. that's a good thing too, no? ;-) > Do you have data? Or are you perpetuating the myth that stateless is cheaper? Last I checked stateless requires some heavy duty provisioning systems and less efficient static allocation of expensive ipv4 addresses > > I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. > I ietf has seldom shown the path forward. In this particular context ....especially so. > yes, if there was a path forward I would also be a lot less despondent with regards to A+P. > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --047d7b15fbcfcca38d04bcb39934 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2012 4:13 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>
>
> On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si= wrote:
>
> > On 4/2/12 12:33 PM, Ole Tr=F8an wrote:
> >> the status quo; with no path forward just means that we'l= l
> >> effectively kill A+P. I would certainly not recommend my prod= uct
> >> managers to implement either of this given the risk. is there=
> >> consensus to abandon these efforts (which is basically what w= e do by
> >> publishing them as experimental anyway)?
> >>
> >> the alternatives we have are perfectly fine: - Shared IPv4 ad= dress
> >> over IPv4 transport -> =A0NAT444 / CGN - Shared IPv4 addre= ss over IPv6
> >> transport -> =A0464XLAT / DS-lite - Full IPv4 address over= IPv6
> >> transport -> =A0DS-lite with Public IPv4 address
> >>
> >> problem solved. ;-)
> >
> > So, if we deprecate RFC6346 and with that the whole A+P idea - is= that solving anything? Really?
>
> - less IPv4 exit mechanisms to implement and choose among. that must b= e good, no?
> =A0(currently there are at least 4 mechanisms proposed in the A+P H&am= p;S and mesh space)
> - large stateful boxes in the SP network; we know how to build them, > =A0and we can charge more for them. that's a good thing too, no? ;= -)
>

Do you have data? Or are you perpetuating the myth that stateless is che= aper?

Last I checked stateless requires some heavy duty provisioning systems a= nd less efficient static allocation of expensive ipv4 addresses

> > I'm also really tempted to do that if this community can&#= 39;t decide what to do in a quick time manner, showing the industry the pat= h forward.
>

I ietf has seldom shown the path forward. In this particular context ...= .especially so.

> yes, if there was a path forward I would also be a lot less despond= ent with regards to A+P.
>
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--047d7b15fbcfcca38d04bcb39934-- From wdec.ietf@gmail.com Mon Apr 2 08:17:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F1B21F861B for ; Mon, 2 Apr 2012 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYbiq3B8nxUk for ; Mon, 2 Apr 2012 08:17:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9722421F85B7 for ; Mon, 2 Apr 2012 08:17:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so1658582qae.10 for ; Mon, 02 Apr 2012 08:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2uvAF02XAnMSuU2GiixM6WV/zMT+5+vEbEFimvo2YIE=; b=NFpbhr+Zv1VODhn+SVyplxqsGu/Zu8uL37WioRMpYgh5hmM639W97YyFnrVFwZJKAL i+LzyR4NfUUuFTKqowEIFQSTMaG9dVvhHNvOUWSei5GFfyiXBDBNHPTzVzgfHYYG+gPh xpIR7BOUUcAoJXDY1r/xYMMYPpjp69B/Gw3nz6Ng4065mqkPPf4+4t7yWqMahexqM+3Z HR57hDFQx4tjArxRnW2FDP/3h7ZlGbWhyixv2TlejYZ2XAOBXnoe86sH3R+LdCqnNRKt I20Bf8XV3pB6hMYgIAMtzzSvllZfW4bSDyF6z2lW60PXD0wE7XIB6eF0V0KkSE0jUA+A Z4yg== MIME-Version: 1.0 Received: by 10.229.105.88 with SMTP id s24mr3449249qco.53.1333379851868; Mon, 02 Apr 2012 08:17:31 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Mon, 2 Apr 2012 08:17:31 -0700 (PDT) In-Reply-To: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> Date: Mon, 2 Apr 2012 17:17:31 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235429cf406bd98804bcb3b088 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:17:33 -0000 --00235429cf406bd98804bcb3b088 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2 April 2012 15:46, R=E9mi Despr=E9s wrote: > > Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit : > > >> If this is to say that until a BOF is started, you will keep your > objection(s) unknown, I continue to take it as a lack of identified > objections. > > > > the objections I'm aware of are: > > - people are uncomfortable with only a double translation solution > > Are you furtively suggesting that 4rd-U has all limitations of a real > double translation solution like MAP-T? > That mays sound tactically smart, but isn't justified by facts. > Woj> Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, or if it does then is requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u + "something" else is manageable is a mystery) 2. 4rd-u is incompatible with NAT64 use or deployment 2. MAP solution (call it MAP, divi, or other variants) has proven deploymen= t 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. Indeed 4rd-u deserves an "experimental" status track, more than anything. -Wojciech. --00235429cf406bd98804bcb3b088 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 April 2012 15:46, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:

Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit :

>> If this is to say that until a BOF is started, you will keep your = objection(s) unknown, I continue to take it as a lack of identified objecti= ons.
>
> the objections I'm aware of are:
> - people are uncomfortable with only a double translation solution

Are you furtively suggesting that 4rd-U has all limitations of a real= double translation solution like MAP-T?
That mays sound tactically smart, but isn't justified by facts.

Woj> Well, in terms of fa= cts we have
1. 4rd-U does not supporting single translation mode, or if= it does then is requires NAT64/BIH/Something else. (How anybody thinks tha= t deploying 4rd-u + "something" else is manageable is a mystery)<= br> 2. 4rd-u is incompatible with NAT64 use or deployment
2. MAP solution (c= all it MAP, divi, or other variants) has proven deployment
3. Any operat= or who runs NAT64 today is a proof point that 4rd-U solves problems that ar= e non-issues to operators.
4. 4rd-u changes the basic structure/use of the v6 header, which is a chang= e to IPv6 that needs to be vetted by 6man, etc. Creating such "novel&q= uot; (bogus?) IPv6 packets, that no regular IPv6 host today will recognize = and use, effectively creates a new IPv6 protocol sub-class.

Indeed 4rd-u deserves an "experimental" status track, more th= an anything.

-Wojciech.
--00235429cf406bd98804bcb3b088-- From cb.list6@gmail.com Mon Apr 2 08:36:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1221F864A for ; Mon, 2 Apr 2012 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0foWCyji0XV for ; Mon, 2 Apr 2012 08:36:50 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BA82D21F8642 for ; Mon, 2 Apr 2012 08:36:50 -0700 (PDT) Received: by dady13 with SMTP id y13so3318193dad.27 for ; Mon, 02 Apr 2012 08:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2i0Xs/mEHqgjZCBEf64u9MFQ6U2Stx05VZIHp1Un6Gk=; b=AknhsFLzD4DMp1bMnoPLBjf+FnAT32IhyiWf49a3C5o3gWJtZssQkgkeNLs+L2ZatR eDo3jRI4y9uklchmRgL5o43bDELV9H9M5SSbq1rQSM4esoqdIC1jCj6eG9EoPUpOEafR 2MUugEQUSixqdNe5qtShTrg9o3ZBmFl7gDHMCW7eFxfOGpXTPqn+B9DsaUZvt+oeK3aH ln7+wS4xlyIjL71jG5p5wCF/LeayLZ/VyyseEf8hgwi/eDyPR7qINZUfS2gxs68elGyI EvNAy8vY7j26K/2z+r5EN5cu4IALK0gqouBdKSgS4iHmoyPYqThG4SpPKxzj4S6AO+Ym 5MQg== MIME-Version: 1.0 Received: by 10.68.132.36 with SMTP id or4mr21204906pbb.115.1333381010447; Mon, 02 Apr 2012 08:36:50 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:36:50 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Mon, 2 Apr 2012 08:36:50 -0700 (PDT) In-Reply-To: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> Date: Mon, 2 Apr 2012 08:36:50 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7b15a4c97a5c2104bcb3f5b6 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:36:51 -0000 --047d7b15a4c97a5c2104bcb3f5b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 2, 2012 8:17 AM, "Wojciech Dec" wrote: > > > > On 2 April 2012 15:46, R=E9mi Despr=E9s wrote: >> >> >> Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit : >> >> >> If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. >> > >> > the objections I'm aware of are: >> > - people are uncomfortable with only a double translation solution >> >> Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? >> That mays sound tactically smart, but isn't justified by facts. > > > Woj> Well, in terms of facts we have > 1. 4rd-U does not supporting single translation mode, or if it does then is requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u + "something" else is manageable is a mystery) > 2. 4rd-u is incompatible with NAT64 use or deployment > 2. MAP solution (call it MAP, divi, or other variants) has proven deployment Just for my own clarification, do these proven deployments use static ipv4 address+port sharing with coordinated dhcp assignment? These are the key feature and method of map-t, and it would be good to know if and how these key features have been proven. Cb > 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. > 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. > > Indeed 4rd-u deserves an "experimental" status track, more than anything. > > -Wojciech. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7b15a4c97a5c2104bcb3f5b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2012 8:17 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:
>
>
>
> On 2 April 2012 15:46, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>
>>
>> Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit :
>>
>> >> If this is to say that until a BOF is started, you will k= eep your objection(s) unknown, I continue to take it as a lack of identifie= d objections.
>> >
>> > the objections I'm aware of are:
>> > - people are uncomfortable with only a double translation sol= ution
>>
>> Are you furtively suggesting that 4rd-U has all limitations of a r= eal double translation solution like MAP-T?
>> That mays sound tactically smart, but isn't justified by facts= .
>
>
> Woj> Well, in terms of facts we have
> 1. 4rd-U does not supporting single translation mode, or if it does th= en is requires NAT64/BIH/Something else. (How anybody thinks that deploying= 4rd-u + "something" else is manageable is a mystery)
> 2. 4rd-u is incompatible with NAT64 use or deployment
> 2. MAP solution (call it MAP, divi, or other variants) has proven depl= oyment

Just for my own clarification, do these proven deployments use static ip= v4 address+port sharing with coordinated dhcp assignment? These are the key= feature and method of map-t, and it would be good to know if and how these= key features have been proven.

Cb
> 3. Any operator who runs NAT64 today is a proof point that 4rd-U solve= s problems that are non-issues to operators.
> 4. 4rd-u changes the basic structure/use of the v6 header, which is a = change to IPv6 that needs to be vetted by 6man, etc. Creating such "no= vel" (bogus?) IPv6 packets, that no regular IPv6 host today will recog= nize and use, effectively creates a new IPv6 protocol sub-class.
>
> Indeed 4rd-u deserves an "experimental" status track, more t= han anything.
>
> -Wojciech.
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires
>

--047d7b15a4c97a5c2104bcb3f5b6-- From ichiroumakino@gmail.com Mon Apr 2 09:59:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E1321F865D for ; Mon, 2 Apr 2012 09:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5iR9RQBNs0p for ; Mon, 2 Apr 2012 09:59:44 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 46C6C21F8657 for ; Mon, 2 Apr 2012 09:59:44 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2623036wib.1 for ; Mon, 02 Apr 2012 09:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=N4hCc2+HgXcTePwu/J6yOh4N22Lywic6gYShq4QL2hU=; b=Jtxs/5+apUF1rWfLhs+MR8zxQTHyk8ewio7BY02IKaxe6tkqTPtfvHdlXuat6MToBc S1Y01ro9eczXvk0WcM2XClY30byBG3dGbb9CmvJ6Bpu4wfnKf+8NC8cB13fGr8/jiaty H7JLDO8XemR1RZkDOg1QDQvSxxxDo4rO8wgESMHOQc3z7u23Je76eduK7dsR8WJnNb1l bBfiDphmRcBz0dX9HeX0kjP49r1ZWJQrIg2QGeBtoRIH/b6+KCWc8MeR59gumDSYGMuJ VBBMK8r09iwq8afFyb6jrVUFOZAu31GNxGPNj1dhxlHZ5LfWp9f1xm3IireKTH3VT368 tzYw== Received: by 10.180.24.7 with SMTP id q7mr27264740wif.11.1333385983411; Mon, 02 Apr 2012 09:59:43 -0700 (PDT) Received: from dhcp-10-61-98-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm35441866wib.2.2012.04.02.09.59.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 09:59:42 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 2 Apr 2012 18:59:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31FD86EB-ECFC-4CBD-8795-37D99B683313@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F798309.7010508@go6.si> <160D3825-BCA9-4CD8-A3A8-716A0A37E814@employees.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:59:46 -0000 Cameron, > > - less IPv4 exit mechanisms to implement and choose among. that must = be good, no? > > (currently there are at least 4 mechanisms proposed in the A+P H&S = and mesh space) > > - large stateful boxes in the SP network; we know how to build them, > > and we can charge more for them. that's a good thing too, no? ;-) > > >=20 > Do you have data? Or are you perpetuating the myth that stateless is = cheaper? where did you get the "myth idea" from? cost obviously depends on platform. scaling a solution based on per flow = state, versus per subscriber state versus no state at all. it obviously = costs money to keep this state around, increased complexity to maintain = it and so on. in addition you need solutions for redundancy that = typically involves hot-standbys. while a purely stateless solution can = easily do load balancing between multiple active systems. of course, if we end up with all platforms have to support all = mechanisms, including stateful translation, then these may end up on = special service cards anyway... > Last I checked stateless requires some heavy duty provisioning systems = and less efficient static allocation of expensive ipv4 addresses I don't think a DHCP server was considered a "heavy duty provisioning" = system. > > > I'm also really tempted to do that if this community can't decide = what to do in a quick time manner, showing the industry the path = forward. > > >=20 > I ietf has seldom shown the path forward. In this particular context = ....especially so. >=20 > > yes, if there was a path forward I would also be a lot less = despondent with regards to A+P. cheers, Ole= From ichiroumakino@gmail.com Mon Apr 2 10:04:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE921F85FF for ; Mon, 2 Apr 2012 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3EiPDk-aDxa for ; Mon, 2 Apr 2012 10:04:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE621F85D5 for ; Mon, 2 Apr 2012 10:04:04 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1967436wgb.13 for ; Mon, 02 Apr 2012 10:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9JVrurApY0b/33SWToa7UMhBVK0NEkS7T4ER64Sg1h4=; b=jAj0hpZPy9X5Ut+uVQT3c1/K5RNeB52h23dV3BjxUfW7v/7rTDy32PJm7YuboMnKXx ycGKLbWEQf4tKlOF1s8wC6LDgAYc/CMysD2O1l8vzcCZeabuwJWLvXtnYkoT/WqxgEjw vlSCBA3pajtswTxqkvPSlCxX9wPPY8D4ynUxmRjXyzK0LwHSnjoMhecoblNRg4KIEVT8 FNcYggEg8aVZxnNEWFt+s82XnupADVHR+b7iCbQDFqE5iBOlIZkFx8h8m73gUrO81EJh J261Zda5G7pjIBrXRSMWnG7xZ80SVaj2zsUHb7AE8VEgAFkJeotL/OZm4BDCNEC36ewx OHBg== Received: by 10.180.102.129 with SMTP id fo1mr26772726wib.6.1333386243483; Mon, 02 Apr 2012 10:04:03 -0700 (PDT) Received: from dhcp-10-61-98-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ea6sm35437369wib.5.2012.04.02.10.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:04:02 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <42618524-4F76-4341-8F14-0B58203875BD@laposte.net> Date: Mon, 2 Apr 2012 19:04:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6A1C49-1345-45E3-87E2-EEE3B912F78F@employees.org> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <7F768763-7E8A-4404-80A2-A79DDFC5C63B@employees.org> <42618524-4F76-4341-8F14-0B58203875BD@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:04:05 -0000 Remi, >> (this reminds me of cockfighting; somewhat entertaining for the = spectators (if that's your kind of thing), one is declared a winner, but = both combatants die... >=20 > You may fear that MAP T+E would be about to die (your judgement) but, = in particular in view of the quotation above, I think 4rd-U as in a good = position to remain alive. >=20 > Your recent comment suggesting that hub&spoke and per-customer = stateful solutions might after all be sufficient seems to me a sheer = lack of confidence in the solution you propose. (It looks like you = become tired to work on the double-standard approach, knowing that = arguments for it are too weak for success.) can we just cite irreconcilable differences and stop discussing this? > This doesn't justify, however, your trying to also kill the single = standard solution, the most credible A+P approach we have on the table. I believe that a consequence of us not being able to agree on a A+P = solution will have the effect of killing A+P. the "problem" with MAP isn't that it has two modes of encapsulation. the = problem with MAP is 4rd-U. the unification of churches rarely work. I = would have been happy to concede and go with 4rd-U, but only if I = thought it worked. and would have an easy way through standardization. = unfortunately, the esoteric features with the V-octet and fragment = header will make that not so. this is my last mail to you on this subject. Ole= From despres.remi@laposte.net Mon Apr 2 10:10:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7240221F866A for ; Mon, 2 Apr 2012 10:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arMNqIc8+msT for ; Mon, 2 Apr 2012 10:10:43 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF021F8668 for ; Mon, 2 Apr 2012 10:10:42 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id t5Ac1i00F37Y3f4035AdC8; Mon, 02 Apr 2012 19:10:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-744634950 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 2 Apr 2012 19:10:36 +0200 Message-Id: <09DFBD23-582E-4841-802D-DBAAEFB631AE@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> To: Softwires-wg X-Mailer: Apple Mail (2.1084) Cc: Ralph Droms , Yong Cui Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:10:44 -0000 --Apple-Mail-1-744634950 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, Following some points made on the ML, please find below some = clarifications on 4rd-U. 2012-04-02 17:36, Cameron Byrne:=20 > On Apr 2, 2012 8:17 AM, "Wojciech Dec" wrote: >=20 ... > > Woj> Well, in terms of facts we have=20 > > 1. 4rd-U does not supporting single translation mode, >=20 Not claimed to. > or if it does then is requires NAT64/BIH/Something else. >=20 The 4rd-u-06 draft says: "This specification only concerns IPv4 communication between = IPv4-capable endpoints. For communication between IPv4-only endpoints = and IPv6 only remote endpoints, the BIH specification of [RFC6535] can = be used. It can coexist in a node with the CE function, including if = the IPv4-only function is a NAT44 [RFC1631]" The reference here to NAT64 and "something else" is clearly = inappropriate. > (How anybody thinks that deploying 4rd-u + "something" else is = manageable is a mystery) >=20 In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record is = received (which characterizes an an IPv6-only host). If 4rd-U is = activated in the same node, IPv4 packets of the IPv4 stack are simply = tunneled across IPv6, according to the 4rd-U specification. No mystery. > > 2. 4rd-u is incompatible with NAT64 use or deployment >=20 Not claimed to, and no need to. 464XLAT, for example, doesn't need MAP-T (and even less MAP-E) to work = with NAT64.=20 In this respect, 464XLAT and BIH work identically. The sentence of RFC6535 that doesn' "recommend" using BIH for double = translation, isn't a formal objection to using it if it is the only way = to satisfy a need. (In this instance, the exact need that the 464XLAT = draft identifies) I added a copy to Teemu Savolainen, a better specialist of BIH than I = am.=20 > > 2. MAP solution (call it MAP, divi, or other variants) has proven = deployment >=20 > Just for my own clarification, do these proven deployments use static = ipv4 address+port sharing with coordinated dhcp assignment? These are = the key feature and method of map-t, and it would be good to know if and = how these key features have been proven. >=20 +1=20 (To renew, once more, my request to know which set of MAP-T mapping = rules have actually been validated.)=20 > Cb >=20 > > 3. Any operator who runs NAT64 today is a proof point that 4rd-U = solves problems that are non-issues to operators. >=20 According to this statement, co-authors of 4rd-U coming from network = operators don't understand their problems as well as Wojciech does.=20 I find this doubtful. > > 4. 4rd-u changes the basic structure/use of the v6 header, which is = a change to IPv6 that needs to be vetted by 6man, etc. Creating such = "novel" (bogus?) IPv6 packets, that no regular IPv6 host today will = recognize and use, effectively creates a new IPv6 protocol sub-class.=20 >=20 In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire, = Lorenzo Colitti, I didn't get any indication that using the unused u-g = combination, if useful, would be a big issue. Making a backward-compatible extension of RFC2373 shouldn't in my = understanding be too difficult (if confirmed to be useful for 4rd-U). > > > > Indeed 4rd-u deserves an "experimental" status track, more than = anything. >=20 Well, with no WG consensus achieved on any 4via6 solution working on = mesh topologies, that's probably the best that can be done so far. Still, it is a step forward.=20 Regards, RD > > > > -Wojciech. > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > --Apple-Mail-1-744634950 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 2, 2012 8:17 AM, "Wojciech Dec" <wdec.ietf@gmail.com> = wrote:

...

> Woj> Well, in terms of facts we have
> 1. 4rd-U does not supporting single translation = mode,

Not claimed to.

or if it does then is requires NAT64/BIH/Something = else.

The 4rd-u-06 draft says:
"This = specification only concerns IPv4 communication between IPv4-capable = endpoints.  For communication between IPv4-only endpoints and IPv6 = only remote endpoints, the BIH specification of [RFC6535] can be used. =  It can coexist in a node with the CE function, including if the = IPv4-only function is a NAT44 [RFC1631]"

The = reference here to NAT64 and "something else" is clearly = inappropriate.

(How = anybody thinks that deploying 4rd-u + "something" else is manageable is = a mystery)

In RFC6535, BIH lets the IPv4 stack = to be used if only an AAAA record is received (which characterizes an an = IPv6-only host). If 4rd-U is activated in the same node, IPv4 packets of = the IPv4 stack are simply tunneled across IPv6, according to the 4rd-U = specification. No mystery.

> 2. 4rd-u is incompatible with NAT64 use or = deployment

Not claimed to, and no need = to.

464XLAT, for example, doesn't need MAP-T = (and even less MAP-E) to work with NAT64. 
In this = respect, 464XLAT and BIH work identically.
The sentence of = RFC6535 that doesn' "recommend" using BIH for double translation, isn't = a formal objection to using it if it is the only way to satisfy a need. = (In this instance, the exact need that the 464XLAT draft = identifies)

I added a copy to Teemu Savolainen, = a better specialist of BIH than I am. 

> 2. MAP solution (call it MAP, divi, or other variants) has proven = deployment

Just for my own clarification, do these proven = deployments use static ipv4 address+port sharing with coordinated dhcp = assignment? These are the key feature and method of map-t, and it would = be good to know if and how these key features have been proven. =

+1 
(To renew, once more, my = request to know which set of MAP-T mapping rules have actually been = validated.) 

Cb

> = 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves = problems that are non-issues to = operators.

According to this statement, = co-authors of 4rd-U coming from network operators don't understand their = problems as well as Wojciech does. 
I find this = doubtful.

> 4. 4rd-u changes the basic structure/use of the v6 header, which is = a change to IPv6 that needs to be vetted by 6man, etc. Creating such = "novel" (bogus?) IPv6 packets, that no regular IPv6 host today will = recognize and use, effectively creates a new IPv6 protocol sub-class. =

In discussions in Paris with Dave Thaler, Dan = Wing, Stuart Cheshire, Lorenzo Colitti, I didn't get any indication that = using the unused u-g combination, if useful, would be a big = issue.
Making a backward-compatible extension of RFC2373 = shouldn't in my understanding be too difficult (if confirmed to be = useful for 4rd-U).

>
> Indeed 4rd-u deserves an "experimental" status track, more than = anything.

Well, with no WG consensus = achieved on any 4via6 solution working on mesh topologies, that's = probably the best that can be done so far.
Still, it is a step = forward. 

Regards,
RD

>
> -Wojciech.
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.= org/mailman/listinfo/softwires
>


= --Apple-Mail-1-744634950-- From tom.taylor.stds@gmail.com Mon Apr 2 10:47:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BC21F8649 for ; Mon, 2 Apr 2012 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOeAXCdXyywd for ; Mon, 2 Apr 2012 10:47:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF47421F8646 for ; Mon, 2 Apr 2012 10:47:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2214444vbb.31 for ; Mon, 02 Apr 2012 10:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=pyNg9uv1jQOEIYrVte8R5hYL/b2tAUo8wrAD0Q7Tw70=; b=uBGEuX0t8W48iHWIx/KUYLo0FRlG2FQIP3NU2GCTbE22dAmMuBq2uPqQDC+nto7vKk DWAoY+3QDTL3u7Cbpa7G6RK/p590YazxUfD2DzkefXSkIGZm1KngNr7BlefwJNiVtaHF Z60wyDMcdimlp40SKF11i8Voi0kO1yoHgK8X/87E5bwxzqN/c7i+kcv3p0z9p2EcUo8F qvgvV7eikp948KtJCQsZ6B+qxyzdAzc3rgtZnw+/9cIAaSLNUW6Bcns/VH9p4ccLzXUk TeAeRwHGskpxQ+3l6fiM98FrPFh3xvlPZLPIzN3Rv9C031COk3mgCvO2Wx3DyyN9/IBY tNeA== Received: by 10.220.52.71 with SMTP id h7mr4388127vcg.43.1333388842381; Mon, 02 Apr 2012 10:47:22 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id iz3sm5568983vdb.11.2012.04.02.10.47.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:47:20 -0700 (PDT) Message-ID: <4F79E627.4080305@gmail.com> Date: Mon, 02 Apr 2012 13:47:19 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120402-0, 02/04/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:47:23 -0000 People on the list might get the impression that Rene is single-handedly holding up WG progress. I have not been involved in this work, but did observe at the meeting a show of hands for 4rd-U at least as numerous as that for MAP. For whatever reason, the WG at large does not seem prepared to commit to a single solution. On 02/04/2012 11:17 AM, Wojciech Dec wrote: > On 2 April 2012 15:46, Rémi Després wrote: > >> >> Le 2012-04-02 ŕ 12:33, Ole Trřan a écrit : >> >>>> If this is to say that until a BOF is started, you will keep your >> objection(s) unknown, I continue to take it as a lack of identified >> objections. >>> >>> the objections I'm aware of are: >>> - people are uncomfortable with only a double translation solution >> >> Are you furtively suggesting that 4rd-U has all limitations of a real >> double translation solution like MAP-T? >> That mays sound tactically smart, but isn't justified by facts. >> > > Woj> Well, in terms of facts we have > 1. 4rd-U does not supporting single translation mode, or if it does then is > requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u > + "something" else is manageable is a mystery) > 2. 4rd-u is incompatible with NAT64 use or deployment > 2. MAP solution (call it MAP, divi, or other variants) has proven deployment > 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves > problems that are non-issues to operators. > 4. 4rd-u changes the basic structure/use of the v6 header, which is a > change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" > (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and > use, effectively creates a new IPv6 protocol sub-class. > > Indeed 4rd-u deserves an "experimental" status track, more than anything. > > -Wojciech. > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Mon Apr 2 11:19:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652B821F85D7 for ; Mon, 2 Apr 2012 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iter9AeeEwzJ for ; Mon, 2 Apr 2012 11:19:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41BAC21F8532 for ; Mon, 2 Apr 2012 11:19:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2152616qcs.31 for ; Mon, 02 Apr 2012 11:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iZw5X06CxtxNYO1yWAsT6ZMNrKuWriUyib6+KA1jYIg=; b=C+1CEMQIC0T8628ZFZMWc/3Xqn0Z7bSADet0vXphvaelgr90inSHBFb1O9NJFVMYk3 9o5hLz7kRDQBmFSX8o0UBfQ9PTAow78pGa//4b9psLMNtImg9YuSOE12lYlyvprgVR/a 13jWQhU4Nd5KpaMvuXO0LgPCt4HGSwtF+ebNCqotkTh6Se+HrOjYPRn40r/xt0hKDQ3b zrTw27oe4/KhARMPjpISiuCDIgdcNDrL0SlUZo8t9ucG+gZh1n+r/5QoQneG8yHj01X+ At6wHZuDpMeOk7Ly2DffRrPYa4esMd2V4A+pVHQEAiLejGawi2l1l4OBqCO44XTf/JVt DU/Q== MIME-Version: 1.0 Received: by 10.224.214.196 with SMTP id hb4mr12801609qab.12.1333390740663; Mon, 02 Apr 2012 11:19:00 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Mon, 2 Apr 2012 11:18:59 -0700 (PDT) In-Reply-To: <09DFBD23-582E-4841-802D-DBAAEFB631AE@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <09DFBD23-582E-4841-802D-DBAAEFB631AE@laposte.net> Date: Mon, 2 Apr 2012 20:18:59 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300fb25771abed04bcb6391a Cc: Softwires-wg Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:19:03 -0000 --20cf300fb25771abed04bcb6391a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2 April 2012 19:10, R=E9mi Despr=E9s wrote: > > > > Woj> Well, in terms of facts we have > > 1. 4rd-U does not supporting single translation mode, > > Not claimed to. > It's good to get clarity now that previous 4rd-U claims of supporting services such as web-caching, log-on-portals, etc. are now false, and no longer claimed. MAP(-T) continues to allow these. or if it does then is requires NAT64/BIH/Something else. > > The 4rd-u-06 draft says: > "This specification only concerns IPv4 communication between IPv4-capable > endpoints. For communication between IPv4-only endpoints and IPv6 only > remote endpoints, the BIH specification of [RFC6535] can be used. It can > coexist in a node with the CE function, including if the IPv4-only functi= on > is a NAT44 [RFC1631]" > > The reference here to NAT64 and "something else" is clearly inappropriate= . > There already is a decent solution for IPv4-IPv4 only, without loss of info =3D IPinIP tunnel. Now, let "something else" be BIH (or whatever), this is = an admission that 4rd-U is not any kind of unified solution, but rather a different collation a novel "pseudo-tunneling" solution with an addon in the form of BIH. Ironically since BIH is NAT64 based, all the problems 4rd-U tries to solve, remain still applicable in that BIH dimension. It is thus no complete solution. > > (How anybody thinks that deploying 4rd-u + "something" else is manageable > is a mystery) > > In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record is > received (which characterizes an an IPv6-only host). If 4rd-U is activate= d > in the same node, IPv4 packets of the IPv4 stack are simply tunneled acro= ss > IPv6, according to the 4rd-U specification. No mystery. > The managing of a MAP deployment looks far much simpler, and less mysterious too, including the use of less moving parts. > > > 2. 4rd-u is incompatible with NAT64 use or deployment > > Not claimed to, and no need to. > That's your call, but its neither the starting point of most customers who deploy and use NAT64 today, or the direction which sees NAT64 usage. With 4rd-u, such NAT64's need to be replaced or extra operational complexity brought in by running in parallel with 4rd-u (possibly serving the same end points). > > 464XLAT, for example, doesn't need MAP-T (and even less MAP-E) to work > with NAT64. > In this respect, 464XLAT and BIH work identically. > The sentence of RFC6535 that doesn' "recommend" using BIH for double > translation, isn't a formal objection to using it if it is the only way t= o > satisfy a need. (In this instance, the exact need that the 464XLAT draft > identifies) > > I added a copy to Teemu Savolainen, a better specialist of BIH than I am. > This is not about BIH, but rather that 4rd-U needs "something else" to cover the MAP space. It thus is no unifying solution at all as it claims to be > > > 2. MAP solution (call it MAP, divi, or other variants) has proven > deployment > > Just for my own clarification, do these proven deployments use static ipv= 4 > address+port sharing with coordinated dhcp assignment? These are the key > feature and method of map-t, and it would be good to know if and how thes= e > key features have been proven. > > +1 > (To renew, once more, my request to know which set of MAP-T mapping rules > have actually been validated.) > One work in progress... http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02. More data was presented at the softwire IETF interim (lost the link for now= ) > Cb > > > 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves > problems that are non-issues to operators. > > According to this statement, co-authors of 4rd-U coming from network > operators don't understand their problems as well as Wojciech does. > I find this doubtful. > Rather, according to this statement co-authors of MAP, including numerous operators, don't care about the problems 4rd-U solves. > > > 4. 4rd-u changes the basic structure/use of the v6 header, which is a > change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel= " > (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and > use, effectively creates a new IPv6 protocol sub-class. > > In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire, > Lorenzo Colitti, I didn't get any indication that using the unused u-g > combination, if useful, would be a big issue. > Making a backward-compatible extension of RFC2373 shouldn't in my > understanding be too difficult (if confirmed to be useful for 4rd-U). > Not sure how the above constitute the v6man WG, or what the personal opinions of these individuals have to do with the fact that ultimately you're changing core IPv6 semantics, incl those of the fragmentation header, which is not within softwire charter. > > > Indeed 4rd-u deserves an "experimental" status track, more than anythin= g. > > Well, with no WG consensus achieved on any 4via6 solution working on mesh > topologies, that's probably the best that can be done so far. > Still, it is a step forward. > For 4rd-U experimental would indeed be a fitting track, given that it has a lot of experimentation and proving yet to do, less so for MAP. -Woj. > > Regards, > RD > > > > > > -Wojciech. > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > > > > --20cf300fb25771abed04bcb6391a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 April 2012 19:10, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:


> Woj> Well, in terms of facts we have
> 1. 4rd-U does not supporting single translation mode,

=
Not claimed to.

It&= #39;s good to get clarity now that previous 4rd-U claims of supporting serv= ices such as web-caching, log-on-portals, etc. are now false, and no longer= claimed. MAP(-T) continues to allow these.

or if it does = then is requires NAT64/BIH/Something else.

The 4rd-u-06 draft says:
"This specificat= ion only concerns IPv4 communication between IPv4-capable endpoints. =A0For= communication between IPv4-only endpoints and IPv6 only remote endpoints, = the BIH specification of [RFC6535] can be used. =A0It can coexist in a node= with the CE function, including if the IPv4-only function is a NAT44 [RFC1= 631]"

The reference here to NAT64 and "something else&qu= ot; is clearly inappropriate.

There = already is a decent solution for IPv4-IPv4 only, without loss of info =3D I= PinIP tunnel. Now, let "something else" be BIH (or whatever), thi= s is an admission that 4rd-U is not any kind of unified solution, but rathe= r a different collation a novel "pseudo-tunneling" solution with = an addon in the form of BIH.
Ironically since BIH is NAT64 based, all the problems 4rd-U tries to solve,= remain still applicable in that BIH dimension. It is thus no complete solu= tion.

(How anybody thinks that deploying 4rd-u + "someth= ing" else is manageable is a mystery)

In RFC6535, BIH lets the IPv4 stack to be used if only an AAAA record = is received (which characterizes an an IPv6-only host). If 4rd-U is activat= ed in the same node, IPv4 packets of the IPv4 stack are simply tunneled acr= oss IPv6, according to the 4rd-U specification. No mystery.
=A0
The managing of a MAP dep= loyment looks far much simpler, and less mysterious too, including the use = of less moving parts.
=A0

> 2. 4rd-u is incompatible with NAT64 use or deployment

Not claimed to, and no need to.

That's your call, but its neither=A0 the starting point of most c= ustomers who deploy and use NAT64 today, or the direction which sees NAT64 = usage. With 4rd-u, such NAT64's need to be replaced or extra operationa= l complexity brought in by running in parallel with 4rd-u (possibly serving= the same end points).
=A0

464XLAT, for example, doesn= 9;t need MAP-T (and even less MAP-E) to work with NAT64.=A0
In this respect, 464XLAT and BIH work identically.
The sente= nce of RFC6535 that doesn' "recommend" using BIH for double t= ranslation, isn't a formal objection to using it if it is the only way = to satisfy a need. (In this instance, the exact need that the 464XLAT draft= identifies)

I added a copy to Teemu Savolainen, a better specialist= of BIH than I am.=A0

This is not ab= out BIH, but rather that 4rd-U needs "something else" to cover th= e MAP space. It thus is no unifying solution at all as it claims to be

> 2. MAP solution (call it MAP, divi, or other variants) has proven depl= oyment

Just for my own clarification, do these proven deployments use= static ipv4 address+port sharing with coordinated dhcp assignment? These a= re the key feature and method of map-t, and it would be good to know if and= how these key features have been proven.

+1=A0
(To renew, once more, my request to= know which set of MAP-T mapping rules have actually been validated.)=A0

One work in progress... http://tools.iet= f.org/html/draft-sunq-v6ops-ivi-sp-02.
More data was presented at the softwire IETF interim (lost the link for now= )

Cb

> 3. Any operator who runs NAT64 today is a= proof point that 4rd-U solves problems that are non-issues to operators.

According to this statement, co-authors of 4r= d-U coming from network operators don't understand their problems as we= ll as Wojciech does.=A0
I find this doubtful.

Rat= her, according to this statement co-authors of MAP, including numerous oper= ators, don't care about the problems 4rd-U solves.

> 4. 4rd-u changes the basic structure/use of the v6 header, which is a = change to IPv6 that needs to be vetted by 6man, etc. Creating such "no= vel" (bogus?) IPv6 packets, that no regular IPv6 host today will recog= nize and use, effectively creates a new IPv6 protocol sub-class.

In discussions in Paris with Dave Thaler, Dan W= ing, Stuart Cheshire, Lorenzo Colitti, I didn't get any indication that= using the unused u-g combination, if useful, would be a big issue.
Making a backward-compatible extension of RFC2373 shouldn't in my = understanding be too difficult (if confirmed to be useful for 4rd-U).
=

Not sure how the above constitute t= he v6man WG, or what the personal opinions of these individuals have to do = with the fact that ultimately you're changing core IPv6 semantics, incl= those of the fragmentation header, which is not within softwire charter.

>
> Indeed 4rd-u deserves an "experimental" status track, more t= han anything.

Well, with=A0no WG consensus a= chieved on any 4via6 solution working on mesh topologies,=A0that's prob= ably the best that can be done so far.
Still, it is a step forward.=A0

For 4rd-U experimental would indeed be a fitting track, given that i= t has a lot of experimentation and proving yet to do, less so for MAP.

-Woj.

Regards,<= /div>
RD


>
> -Wojciech.
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires
>



--20cf300fb25771abed04bcb6391a-- From Tetsuya.Murakami@ipinfusion.com Mon Apr 2 11:27:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E293421F86AB for ; Mon, 2 Apr 2012 11:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD8hO8rfnjhZ for ; Mon, 2 Apr 2012 11:27:37 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8463821F8668 for ; Mon, 2 Apr 2012 11:27:37 -0700 (PDT) Received: from mail116-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 18:27:36 +0000 Received: from mail116-va3 (localhost [127.0.0.1]) by mail116-va3-R.bigfish.com (Postfix) with ESMTP id D80013C012B; Mon, 2 Apr 2012 18:27:36 +0000 (UTC) X-SpamScore: -23 X-BigFish: PS-23(z3e15hzbb2dI9371Ic89bhc85eh98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail116-va3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail116-va3 (localhost.localdomain [127.0.0.1]) by mail116-va3 (MessageSwitch) id 1333391255331724_7466; Mon, 2 Apr 2012 18:27:35 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.243]) by mail116-va3.bigfish.com (Postfix) with ESMTP id 3FCE8800B4; Mon, 2 Apr 2012 18:27:35 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 18:27:33 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.250]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0135.002; Mon, 2 Apr 2012 18:27:28 +0000 From: Tetsuya Murakami To: Satoru Matsushima Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=85?= Thread-Index: AQHNEP5BWKpHYF/wW0GZO0j3iFx1VA== Date: Mon, 2 Apr 2012 18:27:27 +0000 Message-ID: <4F777A4C-D4A7-48DE-B9A9-340AE8EA2383@ipinfusion.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <4F780612.7020508@go6.si> <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> In-Reply-To: <46F71FF5-95C7-4CE9-BB68-5B93685DE238@gmail.com> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_4F777A4CD4A748DEB9A9340AE8EA2383ipinfusioncom_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT002.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT002.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:32:39 -0000 --_000_4F777A4CD4A748DEB9A9340AE8EA2383ipinfusioncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1. 4rd-u is tweaking IPv6 header such as fragment header, hop limit, V-octet, = etc to create a unified transport instead of the encapsulation (MAP-E) and = the translation (MAP-T). MAP-E and MAP-T do not intend to create a new tran= sport. In fact, MAP-E utilizes rfc2473 and MAP-T utilizes rfc6145. We imple= mented the mapping rule with the standard transport. So, from my point of v= iew, since 4rd-u focus on defining a new transport, the discussion point of= 4rd is a little bit different from MAP-E/MAP-T. Also, the following idea i= s a good way to get the consensus widely to define the new transport instea= d of the existing tunneling/translation. Thanks, Tetsuya Murakami On 2012/04/01, at 11:02, Satoru Matsushima wrote: After the meeting, I've figured out that 4rd-u define new type of transport= , since it adds several new semantics in its packet format with V-octet as = a helper of packet format distinguisher. That kind of work is of course out= of scope of Softwire working group. I therefore suggest to the 4rd-u autho= rs that a new BOF or a working group which named like 'unified packet forma= t for tunneling'. Best regards, --satoru On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote: On 3/31/12 4:56 PM, R=E9mi Despr=E9s wrote: Alain, You had initially announced that either one specification would be chosen for standard track (among T, E, and U), or specifications would all become WG drafts on the experimental track ((*) below). In Paris: (a)The MAP proposal became presented as an inseparable T+E package. (b) The WG couldn't make a consensus choice between T+E or U. Now publishing both MAP-T+E and 4rd-U as WG documents on the experimental track, is therefore consistent with what was announced (and was also asked for by several at the end of the meeting). As you explained, this won't prevent from selecting one for standard track later on, based on better market experience. Not sure that was the outcome - as I understood Alain, we'll make a decisio= n here on mailinglist in a very short period of time. Cheers, Jan _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_4F777A4CD4A748DEB9A9340AE8EA2383ipinfusioncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable +1.= =
=
= 4rd-u is tweaking IPv6 header such as fragment header, hop limit, V-octet, = etc to create a unified transport instead of the encapsulation (MAP-E) and = the translation (MAP-T). MAP-E and MAP-T do not intend to create a new transport. In fact, MAP-E utilizes rfc2473 a= nd MAP-T utilizes rfc6145. We implemented the mapping rule with the standar= d transport. So, from my point of view, since 4rd-u focus on defining a new= transport, the discussion point of 4rd is a little bit different from MAP-E/MAP-T. Also, the following ide= a is a good way to get the consensus widely to define the new transport ins= tead of the existing tunneling/translation.
=
= Thanks,
= Tetsuya Murakami

On 2012/04/01, at 11:02, Satoru Matsushima wrote:

After the meeting, I've figured out that 4rd-u define new type of tran= sport, since it adds several new semantics in its packet format with V-octe= t as a helper of packet format distinguisher. That kind of work is of cours= e out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a workin= g group which named like 'unified packet format for tunneling'.

Best regards,
--satoru


On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote:

On 3/31/12 4:56 PM, R=E9mi Despr=E9s wrote:
Alain,

You had initially announced that either one speci= fication would be
chosen for standard track (among T, E, and U), or= specifications
would all become WG drafts on the experimental tr= ack ((*) below). In
Paris: (a)The MAP proposal became presented as an= inseparable T+E
package. (b) The WG couldn't make a consensus cho= ice between T+E or
U.

Now publishing both MAP-T+E and 4rd-U as WG d= ocuments on the
experimental track, is therefore consistent with = what was announced
(and was also asked for by several at the end of = the meeting). As you
explained, this won't prevent from selecting one = for standard track
later on, based on better market experience.

Not sure that was the outcome - as I understood A= lain, we'll make a decision here on mailinglist in a very short period of t= ime.

Cheers, Jan

_______________________________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--_000_4F777A4CD4A748DEB9A9340AE8EA2383ipinfusioncom_-- From Tetsuya.Murakami@ipinfusion.com Mon Apr 2 11:28:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50721F86A4 for ; Mon, 2 Apr 2012 11:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieTl4eON+Nxq for ; Mon, 2 Apr 2012 11:28:06 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99E21F8668 for ; Mon, 2 Apr 2012 11:28:06 -0700 (PDT) Received: from mail47-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 18:28:05 +0000 Received: from mail47-db3 (localhost [127.0.0.1]) by mail47-db3-R.bigfish.com (Postfix) with ESMTP id 68F31A079F; Mon, 2 Apr 2012 18:28:05 +0000 (UTC) X-SpamScore: -32 X-BigFish: PS-32(z3e15hzbb2dIc89bh936eKc85eh98dK14ffO4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail47-db3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3 (MessageSwitch) id 1333391282654760_28543; Mon, 2 Apr 2012 18:28:02 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.252]) by mail47-db3.bigfish.com (Postfix) with ESMTP id 9B18B4A01A8; Mon, 2 Apr 2012 18:28:02 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 18:28:01 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.250]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0135.002; Mon, 2 Apr 2012 18:27:54 +0000 From: Tetsuya Murakami To: =?Windows-1252?Q?R=E9mi_Despr=E9s?= Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=85?= Thread-Index: AQHNEP5RWKpHYF/wW0GZO0j3iFx1VA== Date: Mon, 2 Apr 2012 18:27:53 +0000 Message-ID: <677FAEE5-6DD2-41C6-A289-4219086FF558@ipinfusion.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> In-Reply-To: <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_677FAEE56DD241C6A2894219086FF558ipinfusioncom_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT004.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT004.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:32:59 -0000 --_000_677FAEE56DD241C6A2894219086FF558ipinfusioncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Remi, As you pointed out, the text related to Hub & Spoke model in MAP-E draft co= uld is not correct. I will correct it soon in the next version. But, we have already implemented hub&spoke model in our MAP-E/MAP-T impleme= ntation. Our implementation is having the following option for map tunnel. ip -6 tunnel change map1 fmr disable Also, we have already tested hub&spoke model in MAP-E/MAP-T. Of course, mes= h model has been already implemented/tested in our MAP-T/MAP-E implementati= on. Thanks, Tetsuya Murakami On 2012/04/02, at 2:04, R=E9mi Despr=E9s wrote: Le 2012-04-01 =E0 00:15, Maoke a =E9crit : hi all, i listented to the softwire wg live on March 30 online and recorded my comm= ents in the jabber room. as the person who was mentioned by the presenter n= ot less than twice, i have to point out that it is unfair that the presente= r mentioned me with only acknowledgment to my effort but my point of views. I acknowledged that some of the recent progress to complete 4rd-U was due t= o the technical quality of our dialogue on the ML (... even if sometimes mo= re aggressive than really needed). I thought it was fair to say it. Sorry if the words I used seemed unfair to you. Please be sure the intention was the opposite. my summerized comment on 4rd-u is: it is flawed in both architecture and technical aspects, Which ones? and now still uncertain in several details. Which ones? I confirm that, in my understanding, all points that were argued with techn= ical substance, had been dealt with in 4rd-u-06. This is not to negate that you wrote in your last answer, as anyone can ver= ify: "with your newly proposed solution, yes, IPv4 TTL is fine. but on the = other hand, the IPv6 also needs TTL(HopLimit)=3D255 to protect something. w= e have to concern if 4rd-u possibly introduces some new measures for the at= tackers breaking such kind of protection mechanism, as putting the first bi= t of IPv4 TTL into IPv6 HopLimit CHANGES the semantics of IPv6's HopLimit!" Frankly, I don't understand the new objection: "concern if 4rd-u possibly i= ntroduces..." is IMHO an incitation to FUD, but not a technically justified= issue. If you can detail what you mean, with a point an experiment might reveal, d= ialogue will continue. Without that, I don't understand what you mean. it would become as a ridiculous and weird record in the ietf history, had = the wg made a decision of putting two as experimental, That was Alain's plan in case no consensus on a single standard would emerg= e. It was expressed on the ML well before the meeting. You didn't object to it then, did you? one is well-understood, This "one" obviously being, in your opinion, MAP-T+E, but: a) The need for disjoint packet IDs form shared address CEs is still uncove= red in MAP-T. b) The MAP-E specification is claimed to work in hub-and-apoke topology, bu= t when a BR receives an IPv6 packer, "If the CE IPv6 address is equal to th= e IPv6 source address in the received IPv6 packet, BR decapsulates the IPv4= packet and then forward it via the IPv4 interface." c) It has been said during the meeting that, in the tested double-translati= on implementation, BRs compute UDP checksums of IPv4 datagrams when not com= puted by sources (Null checksums). Nothing is specified AFAIK specified in = the MAP-T document. Is it a MUST, a SHOULD, a MAY? d) The hub-and-spoke domain parameter, which is needed as Ole acknowledged = on the ML, is still not documented in MAP. (Very easy to fix, of course, bu= t a sign that there is still work to be done to have a clear specification.= ) e) The Port Parameter option of MAP-DHCP specifies 3-bits "offset" AND a 16= -bit "excluded-ports". Which combinations of these values have been actuall= y tested? Why to have "excluded-ports" if there is an offset parameter? If these remarks can help E+T proponents to improve their approach, good, b= ut my interest here is ONLY to make WG members understand that MAP-E+T isn'= t the well specified design it is sometimes claimed to be. well-coded and well-practised A list of once practiced mapping rules for each representative configuratio= n (for T AND for E, and for mesh AND hub-and-spoke) is still missing to sup= port this assertion. while the other is misleading the understanding on the Internet architectur= e, If it is a reference to the V octet of 4rd-U, none of the experts I talked= to others than MAP-T+E strong proponents has found any architectural probl= em. (It is new, yes, but is also backward compatible with existing RFCs. No= misleading.) If it is a reference to something else, please explain. not yet coded, not yet tested by any operators. Fair enough, but when Free decided to deploy 6rd, there was not even a docu= ment describing it! Yet, it has been the most effective step toward IPv6 av= ailability on a large scale. Understanding the specification was found suff= icient. Conclusion: clear theory is sometimes more convincing than "I ran a success= ful experiment". our company, as an ISP and as a provider doing also application services, i= ncluding those over mobile platforms, is waiting for the MAP standard desir= ably. we have no interest in introducing the 4rd-u elements into our platforms. Fair enough, but standardization is a collective effort. Regards, RD personally i won't code a stuff with obvious architectural flaws but, if i = were believing in the 4rd-u, i would do the code and operational test with = serious self-checking as MAP-T and MAP-E teams already have done, before ta= lking on any doc-track issue with the community. this is the way of being r= esponsible. thanks, maoke _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_677FAEE56DD241C6A2894219086FF558ipinfusioncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Remi= ,
=
= As you pointed out, the text related to Hub & Spoke model in MAP-E draf= t could is not correct. I will correct it soon in the next version.<= span class=3D"Apple-style-span" style=3D"font-family: monospace; ">
=
= But, we have already implemented hub&spoke model in our MAP-E/MAP-T imp= lementation. Our implementation is having the following option for map tunn= el.
=
= ip -6 tunnel change map1 fmr disable
=
= Also, we have already tested hub&spoke model in MAP-E/MAP-T. Of course,= mesh model has been already implemented/tested in our MAP-T/MAP-E implemen= tation.
=
= Thanks,
= Tetsuya Murakami

On 2012/04/02, at 2:04, R=E9mi Despr=E9s wrote:


Le 2012-04-01 =E0 00:15, Maoke a =E9crit :

hi all,

i listented to the softwire wg live on March 30 o= nline and recorded my comments in the jabber room. as the person who was me= ntioned by the presenter not less than twice, i have to point out that it i= s unfair that the presenter mentioned me with only acknowledgment to my effort but my point of views.

I acknowledged that some of the recent progress to complete 4rd-U was due t= o the technical quality of our dialogue on the ML (... even if sometimes mo= re aggressive than really needed).
I thought it was fair to say it.
Sorry if the words I used seemed unfair to you.
Please be sure the intention was the opposite.

my summerized comment on 4rd-u is:

it is flawed in both architecture and technical a= spects,

Which ones?

and now still uncertain in several details.

Which ones?

I confirm that, in my understanding, all points that were argued with techn= ical substance, had been dealt with in 4rd-u-06.
This is not to negate that you wrote in your last answer, as anyone can ver= ify: "with your newly proposed solution, yes, IPv4 TTL is fine. but on= the other hand, the IPv6 also needs TTL(HopLimit)=3D255 to protect somethi= ng. we have to concern if 4rd-u possibly introduces some new measures for the attackers breaking such kind of prote= ction mechanism, as putting the first bit of IPv4 TTL into IPv6 HopLimit CH= ANGES the semantics of IPv6's HopLimit!"

Frankly, I don't understand the new objection: "concern if 4rd-u possi= bly introduces..." is IMHO an incitation to FUD, but not a technically= justified issue.
If you can detail what you mean, with a point an experiment might reveal, d= ialogue will continue.
Without that, I don't understand what you mean.


it would become as a ridiculous and weird record = in the  ietf history, had the wg made a decision of putting two as exp= erimental,

That was Alain's plan in case no consensus on a single standard would emerg= e.
It was expressed on the ML well before the meeting.
You didn't object to it then, did you?


one is well-understood,

This "one" obviously being, in your opinion, MAP-T+E, but: &n= bsp;

a) The need for disjoint packet IDs form shared address CEs is still uncove= red in MAP-T.

b) The MAP-E specification is claimed to work in hub-and-apoke topology, bu= t when a BR receives an IPv6 packer, "If the CE IPv6 address is equal = to the IPv6 source address in the received IPv6 packet, BR decapsulates the= IPv4 packet and then forward it via the IPv4 interface."

c) It has been said during the meeting that, in the tested double-translati= on implementation, BRs compute UDP checksums of IPv4 datagrams when not com= puted by sources (Null checksums). Nothing is specified AFAIK specified in = the MAP-T document. Is it a MUST, a SHOULD, a MAY?

d) The hub-and-spoke domain parameter, which is needed as Ole acknowledged = on the ML, is still not documented in MAP. (Very easy to fix, of course, bu= t a sign that there is still work to be done to have a clear specification.= )

e) The Port Parameter option of MAP-DHCP specifies 3-bits "offset"= ; AND a 16-bit "excluded-ports". Which combinations of these valu= es have been actually tested? Why to have "excluded-ports" if the= re is an offset parameter?

If these remarks can help E+T proponents to improve their approach, goo= d, but my interest here is ONLY to make WG members understand that MAP-E= 3;T isn't the well specified design it is sometimes claimed to be.

well-coded and well-practised

A list of once practiced mapping rules for each representative configuratio= n (for T AND for E, and for mesh AND hub-and-spoke) is still missing to sup= port this assertion.

while the other is misleading the understanding o= n the Internet architecture,

If it is  a reference to the V octet of 4rd-U, none of the experts I t= alked to others than MAP-T+E strong proponents has found any architectu= ral problem. (It is new, yes, but is also backward compatible with existing= RFCs. No misleading.)

If it is a reference to something else, please explain.

not yet coded, not yet tested by any operators.

Fair enough, but when Free decided to deploy 6rd, there was not even a docu= ment describing it! Yet, it has been the most effective step toward IPv6 av= ailability on a large scale. Understanding the specification was found suff= icient.
Conclusion: clear theory is sometimes more convincing than "I ran a su= ccessful experiment".

our company, as an ISP and as a provider doing al= so application services, including those over mobile platforms, is waiting = for the MAP standard desirably.

we have no interest in introducing the 4rd-u elem= ents into our platforms.

Fair enough, but standardization is a collective effort.

Regards,
RD


personally i won't code a stuff with obvious arch= itectural flaws but, if i were believing in the 4rd-u, i would do the code = and operational test with serious self-checking as MAP-T and MAP-E teams al= ready have done, before talking on any doc-track issue with the community. this is the way of being responsib= le.

thanks,
maoke
_______________________________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--_000_677FAEE56DD241C6A2894219086FF558ipinfusioncom_-- From satoru.matsushima@gmail.com Mon Apr 2 18:53:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96E21F8697 for ; Mon, 2 Apr 2012 18:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nuscy+M+pn2 for ; Mon, 2 Apr 2012 18:53:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2921F868C for ; Mon, 2 Apr 2012 18:53:12 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4928813pbb.31 for ; Mon, 02 Apr 2012 18:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=O4LVPPDmdOeUBHSPCx8ZL1K9r3d56P7tJQedJ7Y9UQM=; b=rtdTdg1t/uXJGrEZgXWeET7gtZ8j3UYRtb99B2+ZymfxjaZcnOwwMfi2JubGr+zGJo tY2B+3Jhi7uqtB10QV9ubtYsdFPmQYG9RlP2SL8YLbpvKpag14wDCIA6l+hOEBmtnQLn m6foBZPEMcaFpcaICGbKn86L4ErguYpfZbzbqLlNzS/9z0J1/70M/vZZATideIDc5Tiw jmyVyWfI3nMZ9ITFeMxPKcdEYHJtpRi5VVzQATmFBm2+MaX303zXyCTtbAWb5VScNOVg 6DOuzgv9ozDzCpEotLNuB4icxK52L/257c/Gvak46wk95hLc652Oem8sZj2InY0HeKOA 6DYw== Received: by 10.68.218.72 with SMTP id pe8mr25554506pbc.45.1333417991971; Mon, 02 Apr 2012 18:53:11 -0700 (PDT) Received: from [10.201.82.174] ([202.45.12.141]) by mx.google.com with ESMTPS id ko12sm15174215pbb.52.2012.04.02.18.53.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 18:53:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Satoru Matsushima In-Reply-To: <4F79E627.4080305@gmail.com> Date: Tue, 3 Apr 2012 10:53:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQg==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 01:53:31 -0000 FYI, choosing MAP doesn't mean that committing to a 'single'. But = choosing 4rd-u means that committing to a 'single'. There're just transport variants, which are encapsulation, translation = and new one we've never seen before. Proponents of the new one claim to = unify transport only to the new one, which means that eliminating both = encapsulation and translation variants of MAP because they say two = choice of transport type would make confusion for operators. The new one = is transparent than translation, but less than encapsulation. I couldn't = decide transport type to be unified with the new one. No evidence, no = expertise, no experience for that. Do we need them to be sure in spite = of we already have existing mature transport variants? cheers, --satoru On 2012/04/03, at 2:47, Tom Taylor wrote: > People on the list might get the impression that Rene is = single-handedly holding up WG progress. I have not been involved in this = work, but did observe at the meeting a show of hands for 4rd-U at least = as numerous as that for MAP. For whatever reason, the WG at large does = not seem prepared to commit to a single solution. >=20 > On 02/04/2012 11:17 AM, Wojciech Dec wrote: >> On 2 April 2012 15:46, R=E9mi Despr=E9s = wrote: >>=20 >>>=20 >>> Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit : >>>=20 >>>>> If this is to say that until a BOF is started, you will keep your >>> objection(s) unknown, I continue to take it as a lack of identified >>> objections. >>>>=20 >>>> the objections I'm aware of are: >>>> - people are uncomfortable with only a double translation solution >>>=20 >>> Are you furtively suggesting that 4rd-U has all limitations of a = real >>> double translation solution like MAP-T? >>> That mays sound tactically smart, but isn't justified by facts. >>>=20 >>=20 >> Woj> Well, in terms of facts we have >> 1. 4rd-U does not supporting single translation mode, or if it does = then is >> requires NAT64/BIH/Something else. (How anybody thinks that deploying = 4rd-u >> + "something" else is manageable is a mystery) >> 2. 4rd-u is incompatible with NAT64 use or deployment >> 2. MAP solution (call it MAP, divi, or other variants) has proven = deployment >> 3. Any operator who runs NAT64 today is a proof point that 4rd-U = solves >> problems that are non-issues to operators. >> 4. 4rd-u changes the basic structure/use of the v6 header, which is a >> change to IPv6 that needs to be vetted by 6man, etc. Creating such = "novel" >> (bogus?) IPv6 packets, that no regular IPv6 host today will recognize = and >> use, effectively creates a new IPv6 protocol sub-class. >>=20 >> Indeed 4rd-u deserves an "experimental" status track, more than = anything. >>=20 >> -Wojciech. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wentaoshang@gmail.com Mon Apr 2 20:17:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7421F86F4 for ; Mon, 2 Apr 2012 20:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwZLlRzZsbVJ for ; Mon, 2 Apr 2012 20:17:53 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 713FA21F86A1 for ; Mon, 2 Apr 2012 20:17:53 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2609500wib.13 for ; Mon, 02 Apr 2012 20:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MCSIJi28SPW0zsLP57sVzVYFo0t/XNfXWRCPHIrQqVE=; b=a2SV9UIR96yRJtZQ2u4NNESMXyG2/vhKUMIVxccAVW/cIHspKv+JBi63S8lNSOATQv cLGQrGEi27mHaw8nrfdirYor/a17osl3iYQ2DoH4IxbC41/9qeXrDw8kLGbsOeTNHxpD MeLfPimlWg945LudgsMreoikA7kLZCpswhgbfmszENs19+DudmmSzZR5w4BNY9P7sOCa Mz3jF/2/QaHrMuYaWhMmnFj+WB5Qm+gawWeaEPjy/nLA2MAlV9pAKPBgAFnbbAShD/uV J90jZbTVGiTukhv/ywZafZ4fHO2mnJvu/sYjOKI+u8wJtrvMPNzb/RMZNr87ge4yjwES baxQ== MIME-Version: 1.0 Received: by 10.180.88.67 with SMTP id be3mr31368985wib.20.1333423072519; Mon, 02 Apr 2012 20:17:52 -0700 (PDT) Received: by 10.180.94.105 with HTTP; Mon, 2 Apr 2012 20:17:52 -0700 (PDT) In-Reply-To: <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> Date: Tue, 3 Apr 2012 11:17:52 +0800 Message-ID: From: Wentao Shang To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:17:54 -0000 2012/4/3 Satoru Matsushima : > FYI, choosing MAP doesn't mean that committing to a 'single'. But choosin= g 4rd-u means that committing to a 'single'. > > There're just transport variants, which are encapsulation, translation an= d new one we've never seen before. Proponents of the new one claim to unify= transport only to the new one, which means that eliminating both encapsula= tion and translation variants of MAP because they say two choice of transpo= rt type would make confusion for operators. The new one is transparent than= translation, but less than encapsulation. I couldn't decide transport type= to be unified with the new one. No evidence, no expertise, no experience f= or that. Do we need them to be sure in spite of we already have existing ma= ture transport variants? +1. With all due respect, I cannot image making a standard that has neither rough consensus nor running code. Regards, Wentao > > cheers, > --satoru > > On 2012/04/03, at 2:47, Tom Taylor wrote: > >> People on the list might get the impression that Rene is single-handedly= holding up WG progress. I have not been involved in this work, but did obs= erve at the meeting a show of hands for 4rd-U at least as numerous as that = for MAP. For whatever reason, the WG at large does not seem prepared to com= mit to a single solution. >> >> On 02/04/2012 11:17 AM, Wojciech Dec wrote: >>> On 2 April 2012 15:46, R=C3=A9mi Despr=C3=A9s= =C2=A0wrote: >>> >>>> >>>> Le 2012-04-02 =C3=A0 12:33, Ole Tr=C3=B8an a =C3=A9crit : >>>> >>>>>> If this is to say that until a BOF is started, you will keep your >>>> objection(s) unknown, I continue to take it as a lack of identified >>>> objections. >>>>> >>>>> the objections I'm aware of are: >>>>> - people are uncomfortable with only a double translation solution >>>> >>>> Are you furtively suggesting that 4rd-U has all limitations of a real >>>> double translation solution like MAP-T? >>>> That mays sound tactically smart, but isn't justified by facts. >>>> >>> >>> Woj> =C2=A0Well, in terms of facts we have >>> 1. 4rd-U does not supporting single translation mode, or if it does the= n is >>> requires NAT64/BIH/Something else. (How anybody thinks that deploying 4= rd-u >>> + "something" else is manageable is a mystery) >>> 2. 4rd-u is incompatible with NAT64 use or deployment >>> 2. MAP solution (call it MAP, divi, or other variants) has proven deplo= yment >>> 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves >>> problems that are non-issues to operators. >>> 4. 4rd-u changes the basic structure/use of the v6 header, which is a >>> change to IPv6 that needs to be vetted by 6man, etc. Creating such "nov= el" >>> (bogus?) IPv6 packets, that no regular IPv6 host today will recognize a= nd >>> use, effectively creates a new IPv6 protocol sub-class. >>> >>> Indeed 4rd-u deserves an "experimental" status track, more than anythin= g. >>> >>> -Wojciech. >>> >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --=20 Wentao Shang Master Candidate and Research Assistant at CERNET Center & NGN Lab, EE Department, Tsinghua University From bupthgl@gmail.com Mon Apr 2 20:26:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64E721F86CF for ; Mon, 2 Apr 2012 20:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.627 X-Spam-Level: *** X-Spam-Status: No, score=3.627 tagged_above=-999 required=5 tests=[AWL=2.525, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1rxzZbtyOKl for ; Mon, 2 Apr 2012 20:26:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEE521F86CA for ; Mon, 2 Apr 2012 20:26:03 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2443537qcs.31 for ; Mon, 02 Apr 2012 20:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9YK9DhZ+CjJjJysLZoTwY3LhI8GLbtxZBkasYDEyZu0=; b=HuEyRwWVlJQIssBdJjOC3asknw1euDA+ZqbmeMyCEgKPFBdn3ablv/V/Li7ydbtNHH KLZPW886cuy8zFQpjmfk/QaAOFvaerRdo4lpXjxnFJXhB5GbVFqn8MbPvRpTcISfZvLW z23wsb2ZqooozVGzi/FiihiMZ8oljsb2dngUEIQUT1FAbWbxkeHY9TRuVhri4NvPNRtl KrWIvuI99zyxB1bFRIcVVvL4d91tnulEMR3jI7QGVFnp4/aAcDagPQj6NICrtF7K5Ki6 dHGyVZqk3y/oy6Wdj3OnEgxjyCf/MqJ+sobJ5VqlLcytmdudkvbdFu6oFYoLCO69wQN5 wwVg== MIME-Version: 1.0 Received: by 10.224.32.12 with SMTP id a12mr14608336qad.0.1333423563013; Mon, 02 Apr 2012 20:26:03 -0700 (PDT) Received: by 10.229.158.195 with HTTP; Mon, 2 Apr 2012 20:26:02 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Tue, 3 Apr 2012 11:26:02 +0800 Message-ID: From: =?GB2312?B?uqu5+sG6?= To: softwires@ietf.org Content-Type: multipart/alternative; boundary=20cf306f72facefc5e04bcbddd33 Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:26:05 -0000 --20cf306f72facefc5e04bcbddd33 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1. As a follower of MAP team, I participated much in developing and deploying double-translation in CERNET. As far as I am concerned, in the translation scenario, 4rd-U only solved some corner cases but missed some other cases simultaneously. As an example, I suppose one fragmentation case as following: (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 network on the right side is 800. Now an IPv4 host on the left side sends a packet with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet could traverse the IPv6 access network, but will be blocked in the IPv4 network. In this case, BR(Core Translator) must set DF to 0 when translating from IPv6 back to IPv4, instead of preserving the original IPv4 DF bit. In fact, according to RFC6145, if BR(Core Translator) receives an ICMP Packet Too Big packet whose indicating MTU is less than 1280 bytes, it will change it to 1280. So if the BR preserve the DF bit, the sender will always believe the path MTU is 1280, which will certainly lead to a black hole. This is only one deployment problem, and we don't know how many issues will be encountered in the future. So my point is that 4rd-U still needs examination in the actual deployment, and it's a bit early to propose it as an Informational/Standards Track Document= . The mail sent yesterday seemed to encounter some problems. So if you see this mail twice, sorry for that. regards, Guoliang 2012/3/26 Maoke > hi Remi, > > let me remove those you have marked as "end". they are fine to me too. > only one point: no implementation nor operation trouble !=3D it is safe t= o > say it an architectural building block of tunnel. if we both say 4rd-u is > an alternative for translation, it would be much clear. (i don't think it > is a tunnel variant at all, due to not providing virtual links; while you > insist it not a translation at all). > > 2012/3/25 R=E9mi Despr=E9s > >> >> >> c) MAP-A+P says "Each MAP node in the domain has the same set of >>>> rules" while MAP-T says "if a CE knows only a subset of the mapping ru= les >>>> ..." >>>> >>>> >>> >>> first of all, they are not conflicting logically. >>> >>> >>> ??? >>> >>> second, if you mean one doc is superior than multiple with better >>> consistency in writing, i could agree. >>> >>> >>> This is not the point. >>> Separate documents can be consistent, but they aren't on this point. >>> >>> One of the two assertions must be changed. >>> Remaining question: which one? >>> >>> >> >> well. this is why i said they are not conflict in logic. as a >> definition of the MAP rule, right, each MAP node in the domain SHOULD ha= ve >> the same set of rules. however, in practice of operation, it is possible >> that this MAY not strictly achieved due to some information losses (whic= h >> is often happens in the Internet environment), MAP-T defines the CE work= ing >> as it were in hub&spokes mode for an unknown destination CE. >> >> >> I am not aware that a CE might receive some of the MAP DHCPv6 parameters >> but not all due to lost packets. >> Clarification on this will be welcome. >> > > my understanding is: DHCPv6 is not running on a reliable protocol, while > MAP DHCPv6 does not yet determine if all FMR would be carried in a single > or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has > done with this, please teach me, thanks!) > > if you assume Internet is always reliable for everything, we must change > our discussion on a lot of issues. > > >> >> if you mean the single mapping rule in IVI case, the answer is NONE, >> surely. IVI uses RFC6052 address format rather than the MAP, without the >> business of MAP. >> >> >> OK >> (In this respect at least, IVI significantly differs from a running >> version of MAP-T). >> > > well, here i don't know how "significantly" you mean. IVI/dIVI/MAP-T(or > dIVI-pd) are same in header processing but different in address mapping a= nd > operation. the context of "IVI" above mentioned the original IVI/dIVI tha= t > applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules. > > >> >> >> if you mean using the MAP for the single translation as we did in IVI >> (though actually we have IVI working for both single and double >> translations simultaneously), MAP-T Sec 8.3 has answered your question. >> >> >> Saying that there is no mapping rule in IVI is sufficient an answer. >> > > then there is no more "not reaching collective understanding" for this > point. End of this topic for me. > > >> >> None? >>> If one, is it a DMR or a BMR? >>> If two, what are they? >>> ... >>> OK, could have been clearer. >>> Yet, I think you understand that with U, one has SIMULTANEOUSLY, >>> transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes= that >>> look at TCP ports. >>> >>> >> >> ok. then may i conclude, for the major part of U, that 1) U, as a >> stated enhancement for double translation, gain the transparency for >> DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); >> >> >> 1) A statistic at a given time, and in a given place, isn't a proof >> that the same ratio will be found later and somewhere else. >> 2) Those that happen to be in the sacrificed minority, be it small, may >> not like their situation. Solving the problem, be it only for them, is >> progress. >> > > 1) not only one statistics. i did it at Tsinghua University. prof. Bao an= d > others did it at CERNET. other guys did it in Europe and published in > IMC'07. and if you carefully read that paper, you may found that case was > very abnormal. > 2) well, it is good if we can take care of the minority without putting > the majority into potential trouble and uncertainty. > > >> >> 2) with introducing #1. weird definition of the fragment header of >> IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? >> >> >> AFAIK, not weird to those who are open to accept that it is very simple. >> > > AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2 > well discussed with the ICMP designers before concluding they are "not > weird"! i am not so open. to those who are open to accept this, i think > they should be also open to the following propositions (that are wrong to > me): > > *1. IPv6 option header, as long as there are reverved or not-yet-used or > padding bits, could be redefined as we like. > *2. it is a useless design that ICMP(v4 or v6) error message body contain= s > part of the original IP(v4 or v6) packet, where the source address is > identical to the destination of the IP(v4 or v6) header carrying the > ICMP(v4 or v6) message. > *3. it is a useless design that ICMPv6 header checksum contains > pseudo-header of the IPv6 header carrying it. > *4. IPv4 header checksum is actually useless. > > if the community would accept these *1 ~ *4 as true statements, i would b= e > also open to accept the above 2). but don't conclude before we get the > feedback from the community! > > ... >> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are >> major flaws (as we discussed so much, i was not convinced at all). i don= 't >> think others who read the specification don't see them and other issues. >> >> >> ICMPv4 payloads in IPv6 packets appear only during domain traversal, >> where they don't hurt anyone. >> > > see above. > > >> >> If a host is IPv6 only, it isn't a 4rd-U host. >> For communication between IPv4-only applications of DS hosts and >> IPv6-only hosts, there are already workable RFCs. >> > > common understanding, including RFC6052/RFC6145/RFC6146 but surely not > limited to these. > > >> BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. >> A new solution for this isn't needed. >> > > BIH serves DS hosts connected to DS networks. the use case does not cover > the all cases of IPv4-IPv6 mutual communciations. > > >> >> an operator definitely needs the encapsulation as a fully featured >> virtual link (underlay infrastructure) in real O&A for IPv4 communicatio= ns >> over IPv6 infrastructure. U cannot replace E at all. >> >> >> Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) woul= d >> give substance to this claim. >> Open to look at it. >> > > in my personal experience i could give you at least three quick examples > of the use case for the building block of "virtual link": > > first example, if the IPv4 customer network plays BGP over IPv4 with the > provider, through the BGP session between CE and BR, a virtual link is > desired. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv= 4 > world) > > second example, there are dynamic routing protocols like RIP running in > the following (multihoming) topology for IPv4 routing. the operator may > want to treat the CE-BR as a single hop in order the virtual link is > considered the distance vector calculation. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR > ----(IPv4 world) > \ / > \ / > +------------ CE ----(Another, IPv4 domain)----------+ > > third example, same topology as above but OSPF are applied, and OSPF > TTL-security check are enabled to ensure hop-passings less than a specifi= ed > threshold. if the operator would like to treat CE---(IPv6-only domain)---= BR > as one hop because it is considered as virtual link, 4rd-u's rudiness in > decreasing TTL will hurt. > > MAP-E (and other E) surely has no limitation in supporting any features o= f > existing routing protocols. with at least the above three examples, i > conclude "U cannot replace E at all"! (btw, surely the translation has th= e > same limitation not to support the above features but, e.g., as you also > said, it opens transport-layer stuff to the middle boxes). therefore i sa= id > operators may use either encapsulation or translation according to what > they attach importance to.) > > >> >> but U needs still discussion >> >> >> T too. >> See, for example, (*) above. >> > > you have ended that subject. fine to me. people have known the difference > between the "needs discussions" for the both. > > >> >> and running code approval. it cannot replace T at least this moment. >> >> >> Understanding how U's header mapping works doesn't need great expertise. >> Co-autors readily understood it, with origins as varied as >> router-and-host vendor, software vendor, broadband operator, mobile >> operator. >> > > well, it works just like another translator, surely it doesn't need great > expertise. > > >> >> Running code as soon couldn't be done yet, but isn't a big deal at all >> (see (**) below) >> >> ... >> >> MAP can work even without the V-octet and CNP, at least in significant >> cases. >> >> >> Not a valid reason to stop progress, especially if easy to understand. >> At least Med suggested to look at V octet even in the context of MAP (if >> chosen for standard track). >> > > no problem if you keep debate in/with the MAP design team. just our > current understanding is: it is not necessary. > > >> >> if we have the standard of MAP, we can immediately deploy it into >> practice through applying MAP rules into the already well understood, we= ll >> approved, well standardized encapsulation and translation modules, >> without waiting for the approval of the new features in the address >> format, and the approval of the reversible header mapping tightly couple= d >> with the address format. >> >> >> (**) >> When we discussed in Taipei, you first said you might code 4rd-U so that >> it could be tested for real. You didn't do it for reasons that I perfect= ly >> respect. >> > > yes but i also mentioned the prerequisite: "when i fully understand it an= d > see it qualified". i also talked with some others that i was interested i= n > that and, if possible and necessary, i would try to code it out and test > it, but again the prerequisite was attached. i have no reason to do a cod= e > for a stuff even suspected by myself. you should remember that, after a > large amount of discussion, i told you i wouldn't code it when we reached > the problem of IPv6 carrying ICMPv4. this made me re-think the issue in t= he > aspect of architectural building block. sure the company's resource > allocation was a reason but this reason was tightly correlated to my own > academic judgement on the necessity. > > thanks, > - maoke > > >> Yet, modifying T code to support header mapping remains quite simple >> (you even call it a translation variant). Starting from E code, it's sim= ple >> too. >> When this is done, all verifications can be easily done that what >> analysis says is right is also right with running code. >> >> >> Regards, >> RD >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf306f72facefc5e04bcbddd33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1.
=A0
As a follower of MAP team, I participated much in developing and deplo= ying
double-translation in CERNET. As far as I am concerned, in the tra= nslation scenario,
4rd-U only solved some corner cases but missed some o= ther cases simultaneously.
=A0
As an example,=A0I suppose one fragmentation case as following:=
=A0
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translato= r)--(IPv4 network)---IPv4 host
=A0
The minumum MTU of IPv6 access network is 1400, and the minimum MTU of= IPv4
network on the right side is 800. Now an IPv4 host on the left si= de sends a packet
with length set to 1200 and MTU set to 1, to the IPv4= host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 net= work.
In this case, BR(Core Translator) must set DF to 0 when translati= ng from IPv6 back to IPv4,
instead of preserving the original IPv4 DF bi= t.
=A0
In fact, according to RFC6145, if BR(Core Translator) receives an ICMP= Packet Too Big packet
whose indicating MTU is less than 1280 bytes, it= will change it to 1280. So if the BR preserve
the DF bit, the sender wi= ll always believe the path MTU is 1280, which will certainly lead to
a black hole.
=A0
This is only one deployment problem, and we don't know how many is= sues will be encountered
in the future. So my point is that 4rd-U still = needs examination in the actual deployment, and
it's a bit early to= propose it as an Informational/Standards Track Document.
=A0
The mail sent yesterday seemed to encounter some problems. So if you s= ee this mail twice,=A0sorry for that.=A0
=A0
regards,
Guoliang

=A0
2012/3/26 Maoke <fibrib@gmail.com>
hi Remi,=A0

let me remove those you have marked as "end". they are fine = to me too. only one point: no implementation nor operation trouble !=3D it = is safe to say it an architectural building block of tunnel. if we both say= 4rd-u is an alternative for translation, it would be much clear. (i don= 9;t think it is a tunnel variant at all, due to not providing virtual links= ; while you insist it not a translation at all).=A0

2012/3/25 R=E9mi Despr=E9s <= ;despres.remi= @laposte.net>


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mappi= ng rules ..." =A0
=A0
=A0
first of all, they are not conflicting logically.

???

second, if you mean one doc is superior than multiple with better cons= istency in writing, i could agree.

This is not the point.
Separate documents can be consistent, but they aren't on this poin= t.

One of the two assertions must be changed.=A0
Remaining question: which one?
=A0
=A0
well. this is why i said they are not conflict in logic. as a definiti= on of the MAP rule, right, each MAP node in the domain SHOULD have the same= set of rules. however, in practice of operation, it is possible that this = MAY not strictly achieved due to some information losses (which is often ha= ppens in the Internet environment), MAP-T defines the CE working as it were= in=A0hub&spokes mode for an unknown destination CE.

I am not aware that a CE might receive some of the MAP DH= CPv6 parameters but not all due to lost packets.
Clarification on this will be welcome.

my understanding is: DHCPv6 is not running on a reliable protocol, whi= le MAP DHCPv6 does not yet determine if all FMR would be carried in a singl= e or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has = done with this, please teach me, thanks!)

if you assume Internet is always reliable for everything, we must chan= ge our discussion on a lot of issues.=A0
=A0

if you mean the single mapping rule in IVI case, the answer is NONE, s= urely. IVI uses RFC6052 address format rather than the MAP, without the bus= iness of MAP.

OK
(In this respect at least, IVI significantly differs from a running ve= rsion of MAP-T).

well, here i don't know how "significantly" you mean. IV= I/dIVI/MAP-T(or dIVI-pd) are same in header processing but different in add= ress mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T (dIVI-pd) a= pplies MAP mapping rules.=A0
=A0

=A0
if you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double translation= s simultaneously),=A0MAP-T Sec 8.3 has answered your question.

Saying that there is no mapping rule in IVI is suffici= ent an answer.

then there is no more "not reaching collective understanding"= ; for this point. End of this topic for me.=A0
=A0

None?=A0
If one, is it a DMR or a BMR?
If two, what are they?
...
OK, could have been clearer.
Yet, I think you understand that with U, one=A0has=A0SIMULTANEOUSLY, t= ransparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes that= look at TCP ports.
=A0
=A0
ok. then may i conclude, for the major part of U,=A0that 1) U, as a st= ated=A0enhancement for=A0double translation,=A0gain the transparency for DF= =3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal);

1) A statistic at a given time, and in a given place, isn't a proo= f that the same ratio will be found later and somewhere else.
2) Those that happen to be in the sacrificed minority, be it small, ma= y not like their situation. Solving the problem, be it only for them, is pr= ogress.

1) not only one statistics. i did it at Tsinghua University. prof. Bao= and others did it at CERNET. other guys did it in Europe and published in = IMC'07. and if you carefully read that paper, you may found that case w= as very abnormal.=A0
2) well, it is good if we can take care of the minority without puttin= g the majority into potential trouble and uncertainty.=A0
=A0

2) with introducing #1. weird definition of the fragment header of IPv= 6; #2 weird packet of IPv6 carrying ICMPv4 messages?

AFAIK, not weird to those who are open to accept that = it is very simple.

AFAIK, you'd better to have #1 accepted by the IPv6 protocol and h= ave #2 well discussed with the ICMP designers before concluding they are &q= uot;not weird"! i am not so open. to those who are open to accept this= , i think they should be also open to the following propositions (that are = wrong to me):

*1. IPv6 option header, as long as there are reverved or not-yet-used = or padding bits, could be redefined as we like.
*2. it is a useless design that ICMP(v4 or v6) error message body cont= ains part of the original IP(v4 or v6) packet, where the source address is = identical to the destination of the IP(v4 or v6) header carrying the ICMP(v= 4 or v6) message.=A0
*3. it is a useless design that ICMPv6 header checksum contains pseudo= -header of the IPv6 header carrying it.=A0
*4. IPv4 header checksum is actually useless.=A0

if the community would accept these *1 ~ *4 as true statements, i woul= d be also open to accept the above 2). but don't conclude before we get= the feedback from the community!

...=A0
well, i mostly argue that=A0the ICMPv4 being carried by IPv6 and CNP a= re major flaws (as we discussed so much, i was not convinced at all). i don= 't think others who read the specification don't see them and other= issues.

ICMPv4 payloads in IPv6 packets appear only during domain traversal, w= here they don't hurt anyone.

see above.=A0
=A0

If a host is IPv6 only, it isn't a 4rd-U host.=A0
For communication between IPv4-only applications of DS hosts and IPv6-= only hosts,=A0there are already workable RFCs.=A0

common understanding, including RFC6052/RFC6145/RFC6146 but surely not= limited to these.=A0
=A0
BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.= =A0
A new solution for this isn't needed.=A0

BIH serves DS hosts connected to DS networks. the use case does not co= ver the all cases of IPv4-IPv6 mutual communciations.=A0
=A0

an operator definitely needs the encapsulation as a fully featured vir= tual link (underlay infrastructure)=A0in real O&A for IPv4 communicatio= ns over IPv6 infrastructure. U cannot replace E at all.

Different understanding.
An detailed E use case that cannot be supported by U=A0(if it exists)= =A0would give substance to this claim.
Open to look at it. =A0

in my personal experience i could give you at least three quick exampl= es of the use case for the building block of "virtual link":=A0

first example, if the IPv4 customer network plays BGP over IPv4 with t= he provider, through the BGP session between CE and BR, a virtual link is d= esired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR -= ---(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0
second example, there are dynamic routing protocols like RIP running i= n the following (multihoming) topology for IPv4 routing. the operator may w= ant to treat the CE-BR as a single hop in order the virtual link is conside= red the distance vector calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR -= ---(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

third example, same topology as above but OSPF are applied, and OSPF T= TL-security check are enabled to ensure hop-passings less than a specified = threshold. if the operator would like to treat CE---(IPv6-only domain)---BR= as one hop because it is considered as virtual link, 4rd-u's rudiness = in decreasing TTL will hurt.=A0

MAP-E (and other E) surely has no limitation in supporting any feature= s of existing routing protocols. with at least the above three examples, i = conclude "U cannot replace E at all"! (btw, surely the translatio= n has the same limitation not to support the above features but, e.g., as y= ou also said, it opens transport-layer stuff to the middle boxes). therefor= e i said operators may use either encapsulation or translation according to= what they attach importance to.)=A0



but U needs still discussion

T too.
See, for example, (*) above.

you have ended that subject. fine to me. people have known the differe= nce between the "needs discussions" for the both.=A0
=A0

and running code approval. it cannot replace T at least this moment. <= /div>

Understanding how U's header mapping works doesn't need great = expertise.
Co-autors readily understood it, with origins as varied as router-and-= host vendor, software vendor, broadband operator, mobile operator.

well, it works just like another translator, surely it doesn't nee= d great expertise.=A0
=A0

Running code as soon couldn't be done yet, but isn't a big dea= l at all (see (**) below)

...=A0

MAP can work even without the V-octet and CNP, at least in significant= cases.

Not a valid reason to stop progress, especially if eas= y to understand.
At least Med suggested to look at V octet even in the context of MAP (= if chosen for standard track).

no problem if you keep debate in/with the MAP design team. just our cu= rrent understanding is: it is not necessary.=A0
=A0

=A0if we have the standard of MAP, we=A0can immediately=A0deploy it in= to practice through applying MAP rules into the=A0already well understood, = well approved, well standardized=A0encapsulation and translation modules, = =A0without=A0waiting for the approval of the new features in the address fo= rmat, and the approval of the reversible header mapping tightly coupled wit= h the address format.

(**)
When we discussed in Taipei, you first said you might code 4rd-U so th= at it could be tested for real. You didn't do it for reasons that I per= fectly respect.

yes but i also mentioned the prerequisite: "when i fully understa= nd it and see it qualified". i also talked with some others that i was= interested in that and, if possible and necessary, i would try to code it = out and test it, but again the prerequisite was attached. i have no reason = to do a code for a stuff even suspected by myself. you should remember that= , after a large amount of discussion, i told you i wouldn't code it whe= n we reached the problem of IPv6 carrying ICMPv4. this made me re-think the= issue in the aspect of architectural building block. sure the company'= s resource allocation was a reason but this reason was tightly correlated t= o my own academic judgement on the necessity.=A0

thanks,
- maoke
=A0
Yet, modifying T code to support header mapping remains quite simple (= you even call it a translation variant). Starting from E code, it's sim= ple too.
When this is done, all verifications can be easily done that what anal= ysis says is right is also right with running code.


Regards,
RD


_________________= ______________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/ma= ilman/listinfo/softwires


--20cf306f72facefc5e04bcbddd33-- From jan@go6.si Tue Apr 3 00:41:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52EE21F855B for ; Tue, 3 Apr 2012 00:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcrraWC6wyOG for ; Tue, 3 Apr 2012 00:41:07 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA021F852B for ; Tue, 3 Apr 2012 00:41:07 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id BBD8B22B4069 for ; Tue, 3 Apr 2012 09:41:03 +0200 (CEST) Message-ID: <4F7AA98F.4000800@go6.si> Date: Tue, 03 Apr 2012 09:41:03 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> In-Reply-To: <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:41:08 -0000 On 4/3/12 3:53 AM, Satoru Matsushima wrote: > FYI, choosing MAP doesn't mean that committing to a 'single'. But > choosing 4rd-u means that committing to a 'single'. > > There're just transport variants, which are encapsulation, > translation and new one we've never seen before. Proponents of the > new one claim to unify transport only to the new one, which means > that eliminating both encapsulation and translation variants of MAP > because they say two choice of transport type would make confusion > for operators. The new one is transparent than translation, but less > than encapsulation. I couldn't decide transport type to be unified > with the new one. No evidence, no expertise, no experience for that. > Do we need them to be sure in spite of we already have existing > mature transport variants? > > cheers, --satoru +1 Given the situation with IPv4 exhaustion we have to hurry and go with what we know and what is proven to work today with no funky new features. I agree that 4RD-U brings some good new features, but as it changes the IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through revision of also other working groups that needs to say their understanding of changed IPv6 transport behavior. I also believe that when 4RD-U goes through the whole proper procedure it might be widely adopted later as MAP replacement. Meantime - let's fix the problem with what we know and understand. Speaking as A+P (RFC6346) co-author, we got many questions about A+P progress from operators and we learned that the time-frame for decision between CGN and something else is already nearly expired. If we want anything-A+P to still reach the operators, then the time for decision is now. We already missed the majority of that train, but last seats in last wagon are still reachable. We need to act and not just to push the endless discussion (that is not that uncommon for any IETF WG :) ). Cheers, Jan Zorz From despres.remi@laposte.net Tue Apr 3 01:32:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECC521F8618 for ; Tue, 3 Apr 2012 01:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCySZSPY+irn for ; Tue, 3 Apr 2012 01:32:00 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 77AFF21F860B for ; Tue, 3 Apr 2012 01:31:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id tLXx1i00D37Y3f403LXxiQ; Tue, 03 Apr 2012 10:31:58 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-799915826 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 10:31:57 +0200 Message-Id: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> To: =?utf-8?B?6Z+p5Zu95qKB?= X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:32:02 -0000 --Apple-Mail-2-799915826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Guoliang, Interesting enough, the example you give illustrates that MAP-T needs to = remain experimental, more than any other solution. 1. RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. 2. With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. = This is exactly what is necessary for PMTU discovery to work. 3. Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAIK = from RFC6145, and therefore from MAP-T. When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. Regards, RD Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit : > +1. > =20 > As a follower of MAP team, I participated much in developing and = deploying=20 > double-translation in CERNET. As far as I am concerned, in the = translation scenario, > 4rd-U only solved some corner cases but missed some other cases = simultaneously. > =20 > As an example, I suppose one fragmentation case as following: > =20 > (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host > =20 > The minumum MTU of IPv6 access network is 1400, and the minimum MTU of = IPv4=20 > network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 > with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 > could traverse the IPv6 access network, but will be blocked in the = IPv4 network.=20 > In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, > instead of preserving the original IPv4 DF bit. > =20 > In fact, according to RFC6145, if BR(Core Translator) receives an ICMP = Packet Too Big packet=20 > whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve > the DF bit, the sender will always believe the path MTU is 1280, which = will certainly lead to=20 > a black hole. > =20 > This is only one deployment problem, and we don't know how many issues = will be encountered > in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 > it's a bit early to propose it as an Informational/Standards Track = Document. > =20 > The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 > =20 > regards,=20 > Guoliang >=20 > =20 > 2012/3/26 Maoke > hi Remi,=20 >=20 > let me remove those you have marked as "end". they are fine to me too. = only one point: no implementation nor operation trouble !=3D it is safe = to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all).=20 >=20 > 2012/3/25 R=C3=A9mi Despr=C3=A9s >=20 >=20 >>> c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 >>> =20 >>> =20 >>> first of all, they are not conflicting logically. >>=20 >> ??? >>=20 >>> second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. >>=20 >> This is not the point. >> Separate documents can be consistent, but they aren't on this point. >>=20 >> One of the two assertions must be changed.=20 >> Remaining question: which one? >> =20 >> =20 >> well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an unknown = destination CE. >=20 > I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets. > Clarification on this will be welcome. >=20 > my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!) >=20 > if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues.=20 > =20 >=20 >> if you mean the single mapping rule in IVI case, the answer is NONE, = surely. IVI uses RFC6052 address format rather than the MAP, without the = business of MAP. >=20 > OK > (In this respect at least, IVI significantly differs from a running = version of MAP-T). >=20 > well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules.=20 > =20 >=20 >> =20 >> if you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. >=20 > Saying that there is no mapping rule in IVI is sufficient an answer. >=20 > then there is no more "not reaching collective understanding" for this = point. End of this topic for me.=20 > =20 >=20 >> None?=20 >> If one, is it a DMR or a BMR? >> If two, what are they? >> ... >> OK, could have been clearer. >> Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. >> =20 >> =20 >> ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); >=20 > 1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else. > 2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress. >=20 > 1) not only one statistics. i did it at Tsinghua University. prof. Bao = and others did it at CERNET. other guys did it in Europe and published = in IMC'07. and if you carefully read that paper, you may found that case = was very abnormal.=20 > 2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty.=20 > =20 >=20 >> 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? >=20 > AFAIK, not weird to those who are open to accept that it is very = simple. >=20 > AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have = #2 well discussed with the ICMP designers before concluding they are = "not weird"! i am not so open. to those who are open to accept this, i = think they should be also open to the following propositions (that are = wrong to me): >=20 > *1. IPv6 option header, as long as there are reverved or not-yet-used = or padding bits, could be redefined as we like. > *2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message.=20 > *3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it.=20 > *4. IPv4 header checksum is actually useless.=20 >=20 > if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community! >=20 >> ...=20 >> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP = are major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. >=20 > ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. >=20 > see above.=20 > =20 >=20 > If a host is IPv6 only, it isn't a 4rd-U host.=20 > For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 >=20 > common understanding, including RFC6052/RFC6145/RFC6146 but surely not = limited to these.=20 > =20 > BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20= > A new solution for this isn't needed.=20 >=20 > BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations.=20 > =20 >=20 >> an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. >=20 > Different understanding. > An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. > Open to look at it. =20 >=20 > in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >=20 > first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >=20 > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 > =20 > second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >=20 > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 > \ = / > \ = / > +------------ CE ----(Another, IPv4 = domain)----------+ >=20 > third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >=20 > MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.)=20 >=20 >=20 >=20 >> but U needs still discussion >=20 > T too. > See, for example, (*) above. >=20 > you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both.=20 > =20 >=20 >> and running code approval. it cannot replace T at least this moment. >=20 > Understanding how U's header mapping works doesn't need great = expertise. > Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. >=20 > well, it works just like another translator, surely it doesn't need = great expertise.=20 > =20 >=20 > Running code as soon couldn't be done yet, but isn't a big deal at all = (see (**) below) >=20 > ...=20 >=20 >> MAP can work even without the V-octet and CNP, at least in = significant cases. >=20 > Not a valid reason to stop progress, especially if easy to understand. > At least Med suggested to look at V octet even in the context of MAP = (if chosen for standard track). >=20 > no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary.=20 > =20 >=20 >> if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. >=20 > (**) > When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect. >=20 > yes but i also mentioned the prerequisite: "when i fully understand it = and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the necessity.=20 >=20 > thanks, > - maoke > =20 > Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. > When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. >=20 >=20 > Regards, > RD >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-2-799915826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Guoliang,

Interesting enough, the example you give = illustrates that MAP-T needs to remain experimental, more than any other = solution.

1.
RFC6145 doesn't say that = a PTB<1280 WILL BE changed to PTB=3D1280. It specifies two behaviors, = one that does this, and one that doesn't. Which one to choose isn't = AFAIK specified in the MAP-T = draft.

2.
With 4rd-U, an ICMPv4 = PTB<1280 always goes to its destination unchanged. This is exactly = what is necessary for PMTU discovery to = work.

3.
Now, you suggest to replace = DF=3D1 by DF=3D0 in BRs. This differs AFAIK from RFC6145, and therefore = from MAP-T.

When we have a detailed report on = which parts of MAP-T have been validated, with which options of RFC6145, = it will be easier to analyze scenarios like the one you = propose.


In any case, thanks for = providing one more evidence that the MAP-T specification isn't as clear = as claimed to all those who support it, and in particular to some also = criticize 4rd-U with invalid = arguments.

Regards,
RD


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2= =81 a =C3=A9crit :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network.
In this case, BR(Core Translator) must set DF to 0 when = translating from IPv6 back to IPv4,
instead of preserving the = original IPv4 DF bit.
 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang

 
2012/3/26 Maoke <fibrib@gmail.com>
hi Remi, 

let me remove those you have marked as "end". they are fine to me = too. only one point: no implementation nor operation trouble !=3D it is = safe to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all). 

2012/3/25 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..."  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree.

This is not the point.
Separate documents can be consistent, but they aren't on this = point.

One of the two assertions must be changed. 
Remaining question: which one?
 
 
well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an = unknown destination CE.

I am not aware that a CE might receive some of the MAP = DHCPv6 parameters but not all due to lost packets.
Clarification on this will be = welcome.

my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!)

if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues. 
 

if you mean the single mapping rule in IVI case, the answer is = NONE, surely. IVI uses RFC6052 address format rather than the MAP, = without the business of MAP.

OK
(In this respect at least, IVI significantly differs from a running = version of MAP-T).

well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules. 
 

 
if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your = question.

Saying that there is no mapping rule in IVI is = sufficient an answer.

then there is no more "not reaching collective understanding" for = this point. End of this topic for me. 
 

None? 
If one, is it a DMR or a BMR?
If two, what are they?
...
OK, could have been clearer.
Yet, I think you understand that with U, = one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports.
 
 
ok. then may i conclude, for the major part of U, that 1) U, = as a stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else.
2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress.

1) not only one statistics. i did it at Tsinghua University. prof. = Bao and others did it at CERNET. other guys did it in Europe and = published in IMC'07. and if you carefully read that paper, you may found = that case was very abnormal. 
2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty. 
 

2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? =

AFAIK, not weird to those who are open to accept = that it is very simple.

AFAIK, you'd better to have #1 accepted by the IPv6 protocol and = have #2 well discussed with the ICMP designers before concluding they = are "not weird"! i am not so open. to those who are open to accept this, = i think they should be also open to the following propositions (that are = wrong to me):

*1. IPv6 option header, as long as there are reverved or = not-yet-used or padding bits, could be redefined as we like.
*2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message. 
*3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it. 
*4. IPv4 header checksum is actually useless. 

if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community!

... 
well, i mostly argue that the ICMPv4 being carried by IPv6 and = CNP are major flaws (as we discussed so much, i was not convinced at = all). i don't think others who read the specification don't see them and = other issues.

ICMPv4 payloads in IPv6 packets appear only during domain = traversal, where they don't hurt = anyone.

see above. 
 

If a host is IPv6 only, it isn't a 4rd-U host. 
For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable = RFCs. 

common understanding, including RFC6052/RFC6145/RFC6146 but surely = not limited to these. 
 
BIH in DS hosts is AFAIK particularly powerful, and IMHO = sufficient. 
A new solution for this isn't = needed. 

BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations. 
 

an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. =

Different understanding.
An detailed E use case that cannot be supported by U (if it = exists) would give substance to this claim.
Open to look at it.  

in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 customer network plays BGP over IPv4 = with the provider, through the BGP session between CE and BR, a virtual = link is desired. 

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
                  =                   =  
second example, there are dynamic routing protocols like RIP = running in the following (multihoming) topology for IPv4 routing. the = operator may want to treat the CE-BR as a single hop in order the = virtual link is considered the distance vector calculation.

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
               \   =                     =                     =              /
                \   =                     =                     =            /
                =  +------------ CE ----(Another, IPv4 domain)----------+

third example, same topology as above but OSPF are applied, and = OSPF TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt. 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.) 



but U needs still discussion

T too.
See, for example, (*) above.

you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both. 
 

and running code approval. it cannot replace T at least this = moment.

Understanding how U's header mapping works doesn't need great = expertise.
Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator.

well, it works just like another translator, surely it doesn't need = great expertise. 
 

Running code as soon couldn't be done yet, but isn't a big deal at = all (see (**) below)

... 

MAP can work even without the V-octet and CNP, at least in = significant cases.

Not a valid reason to stop progress, especially if = easy to understand.
At least Med suggested to look at V octet even in the context of = MAP (if chosen for standard track).

no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary. 
 

 if we have the standard of MAP, we can = immediately deploy it into practice through applying MAP rules into = the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format.

(**)
When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect.

yes but i also mentioned the prerequisite: "when i fully understand = it and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the = necessity. 

thanks,
- maoke
 
Yet, modifying T code to support header mapping remains quite = simple (you even call it a translation variant). Starting from E code, = it's simple too.
When this is done, all verifications can be easily done that what = analysis says is right is also right with running code.


Regards,
=
RD


________________= _______________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-2-799915826-- From fibrib@gmail.com Tue Apr 3 02:07:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97C21F8535 for ; Tue, 3 Apr 2012 02:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRiKVVaAmaJu for ; Tue, 3 Apr 2012 02:07:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E40BF21F848A for ; Tue, 3 Apr 2012 02:07:00 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2578520qcs.31 for ; Tue, 03 Apr 2012 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f4kQj1zOmqoNXFppXBNOed7dYZCiXIlto3ocm1f4LRs=; b=rEVFyE1L0sBn00eFQxEpkPlflhD41qUdhNtdm0GuVsh62wgLB72t7NyrVwtbfsxZSD q5UL0U3N7VmMkGoB0zz/xK62elfZHFgv6G1690UzelNUNNF2jNaCTskt5WYz4fF6q7Cf ArZF+es013ldUBEb+XHyK7TZhCZ6iFG5Ux1Z5xTsFzNGbC3KoZQ/fc1GMqJVqag0e2rZ a1ArNQWZ3bOE6EzHWgAS2yNZlJPpKBi+YOLWp3hRDzvkN4AMHP/MG64Q87R175jEiYMq SY61w9157ao91GvzSKH8YDszt3Qgm2E+qmfGzosQ5rDp1xMqwpAaeZi5x3vUKBvtJzl6 c5tA== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr15902140qab.36.1333444020310; Tue, 03 Apr 2012 02:07:00 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 02:07:00 -0700 (PDT) In-Reply-To: <4F7AA98F.4000800@go6.si> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> <4F7AA98F.4000800@go6.si> Date: Tue, 3 Apr 2012 09:07:00 +0000 Message-ID: From: Maoke To: "Jan Zorz @ go6.si" Content-Type: multipart/alternative; boundary=20cf300faff528921d04bcc2a1c1 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:07:02 -0000 --20cf300faff528921d04bcc2a1c1 Content-Type: text/plain; charset=ISO-8859-1 2012/4/3 Jan Zorz @ go6.si > On 4/3/12 3:53 AM, Satoru Matsushima wrote: > >> FYI, choosing MAP doesn't mean that committing to a 'single'. But >> choosing 4rd-u means that committing to a 'single'. >> >> There're just transport variants, which are encapsulation, >> translation and new one we've never seen before. Proponents of the >> new one claim to unify transport only to the new one, which means >> that eliminating both encapsulation and translation variants of MAP >> because they say two choice of transport type would make confusion >> for operators. The new one is transparent than translation, but less >> than encapsulation. I couldn't decide transport type to be unified >> with the new one. No evidence, no expertise, no experience for that. >> Do we need them to be sure in spite of we already have existing >> mature transport variants? >> >> cheers, --satoru >> > > +1 > > Given the situation with IPv4 exhaustion we have to hurry and go with what > we know and what is proven to work today with no funky new features. > > I agree that 4RD-U brings some good new features, but as it changes the > IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through > revision of also other working groups that needs to say their understanding > of changed IPv6 transport behavior. I also believe that when 4RD-U goes > through the whole proper procedure it might be widely adopted later as MAP > replacement. > > Meantime - let's fix the problem with what we know and understand. > agree and have the same feeling. i'd love to keep study what 4rd-u brings to the transition architecture and more practices are not excluded along with the 4rd-u getting well-understood. and if 4rd-u is approved/improved/verified superior to both -T and -E through the whole procedure, i don't think it will be a problem that MAP would be obsoleted in the future. but that's of not our current situation, fixing the problem with well-understood building blocks is what we must do as soon as possible. - maoke > > Speaking as A+P (RFC6346) co-author, we got many questions about A+P > progress from operators and we learned that the time-frame for decision > between CGN and something else is already nearly expired. If we want > anything-A+P to still reach the operators, then the time for decision is > now. We already missed the majority of that train, but last seats in last > wagon are still reachable. > > We need to act and not just to push the endless discussion (that is not > that uncommon for any IETF WG :) ). > > Cheers, Jan Zorz > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf300faff528921d04bcc2a1c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/3 Jan Zorz @ go6.si <jan@go= 6.si>
On 4/3/12 3:53 AM, Satoru Matsushima wrote:
FYI, choosing MAP doesn't mean that committing to a 'single'. B= ut
choosing 4rd-u means that committing to a 'single'.

There're just transport variants, which are encapsulation,
translation and new one we've never seen before. Proponents of the
new one claim to unify transport only to the new one, which means
that eliminating both encapsulation and translation variants of MAP
because they say two choice of transport type would make confusion
for operators. The new one is transparent than translation, but less
than encapsulation. I couldn't decide transport type to be unified
with the new one. No evidence, no expertise, no experience for that.
Do we need them to be sure in spite of we already have existing
mature transport variants?

cheers, --satoru

+1

Given the situation with IPv4 exhaustion we have to hurry and go with what = we know and what is proven to work today with no funky new features.

I agree that 4RD-U brings some good new features, but as it changes the IPv= 6 current usage I suggest to redirect 4RD-U to BoF and to go through revisi= on of also other working groups that needs to say their understanding of ch= anged IPv6 transport behavior. I also believe that when 4RD-U goes through = the whole proper procedure it might be widely adopted later as MAP replacem= ent.

Meantime - let's fix the problem with what we know and understand.
<= /blockquote>

agree and have the same feeling. i'd lo= ve to keep study what 4rd-u brings to the transition architecture and more = practices are not excluded along with the 4rd-u getting well-understood. an= d if 4rd-u is approved/improved/verified superior to both -T and -E through= the whole procedure, i don't think it will be a problem that MAP would= be obsoleted in the future.=A0but that's of not our current situation,= fixing the problem with well-understood building blocks is what we must do= as soon as possible.=A0

- maoke
=A0

Speaking as A+P (RFC6346) co-author, we got many questions about A+P progre= ss from operators and we learned that the time-frame for decision between C= GN and something else is already nearly expired. If we want anything-A+P to= still reach the operators, then the time for decision is now. We already m= issed the majority of that train, but last seats in last wagon are still re= achable.

We need to act and not just to push the endless discussion (that is not tha= t uncommon for any IETF WG :) ).

Cheers, Jan Zorz

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--20cf300faff528921d04bcc2a1c1-- From despres.remi@laposte.net Tue Apr 3 02:07:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9973621F8546 for ; Tue, 3 Apr 2012 02:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+bstKoBd4Rx for ; Tue, 3 Apr 2012 02:07:36 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDE121F848A for ; Tue, 3 Apr 2012 02:07:35 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id tM7Z1i00M37Y3f403M7ZQr; Tue, 03 Apr 2012 11:07:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> Date: Tue, 3 Apr 2012 11:07:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:07:36 -0000 Le 2012-04-03 =E0 03:53, Satoru Matsushima a =E9crit : > FYI, choosing MAP doesn't mean that committing to a 'single'. But = choosing 4rd-u means that committing to a 'single'. >=20 > There're just transport variants, which are encapsulation, translation = and new one we've never seen before. Proponents of the new one claim to = unify transport only to the new one, which means that eliminating both = encapsulation and translation variants of MAP because they say two = choice of transport type would make confusion for operators. > The new one is transparent than translation, but less than = encapsulation. If you would have a detailed scenario where ANY transparency difference = could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this = sentence would be fair. However, you haven't shown such a scenario, and AFAIK you can't have one = because it doesn't exist. The above assertion, being wrong, is therefore misleading. > I couldn't decide transport type to be unified with the new one. > No evidence, no expertise, no experience for that. But many of those who have no motivation to look for flaws that don't = exist, do understand that the design is safe. > Do we need them to be sure in spite of we already have existing mature = transport variants? MAP-E+T isn't as mature as repeatedly claimed. MAP-T may be more imprecise than MAP-E in this respect, but both have = known bugs to be fixed (at least packet IDs of shared-addres CEs of = MAP-T, and BR hairpinning in MAP-E). Besides, the exact list of MAP DHCPv6 parameters has yet to be = finalized. Cheers, RD >=20 > cheers, > --satoru >=20 > On 2012/04/03, at 2:47, Tom Taylor wrote: >=20 >> People on the list might get the impression that Rene is = single-handedly holding up WG progress. I have not been involved in this = work, but did observe at the meeting a show of hands for 4rd-U at least = as numerous as that for MAP. For whatever reason, the WG at large does = not seem prepared to commit to a single solution. >>=20 >> On 02/04/2012 11:17 AM, Wojciech Dec wrote: >>> On 2 April 2012 15:46, R=E9mi Despr=E9s = wrote: >>>=20 >>>>=20 >>>> Le 2012-04-02 =E0 12:33, Ole Tr=F8an a =E9crit : >>>>=20 >>>>>> If this is to say that until a BOF is started, you will keep your >>>> objection(s) unknown, I continue to take it as a lack of identified >>>> objections. >>>>>=20 >>>>> the objections I'm aware of are: >>>>> - people are uncomfortable with only a double translation solution >>>>=20 >>>> Are you furtively suggesting that 4rd-U has all limitations of a = real >>>> double translation solution like MAP-T? >>>> That mays sound tactically smart, but isn't justified by facts. >>>>=20 >>>=20 >>> Woj> Well, in terms of facts we have >>> 1. 4rd-U does not supporting single translation mode, or if it does = then is >>> requires NAT64/BIH/Something else. (How anybody thinks that = deploying 4rd-u >>> + "something" else is manageable is a mystery) >>> 2. 4rd-u is incompatible with NAT64 use or deployment >>> 2. MAP solution (call it MAP, divi, or other variants) has proven = deployment >>> 3. Any operator who runs NAT64 today is a proof point that 4rd-U = solves >>> problems that are non-issues to operators. >>> 4. 4rd-u changes the basic structure/use of the v6 header, which is = a >>> change to IPv6 that needs to be vetted by 6man, etc. Creating such = "novel" >>> (bogus?) IPv6 packets, that no regular IPv6 host today will = recognize and >>> use, effectively creates a new IPv6 protocol sub-class. >>>=20 >>> Indeed 4rd-u deserves an "experimental" status track, more than = anything. >>>=20 >>> -Wojciech. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Tue Apr 3 02:21:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB4021F854E for ; Tue, 3 Apr 2012 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UxmuIJXxxns for ; Tue, 3 Apr 2012 02:21:47 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 98DA221F854F for ; Tue, 3 Apr 2012 02:21:47 -0700 (PDT) Received: by qaea16 with SMTP id a16so2181860qae.10 for ; Tue, 03 Apr 2012 02:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLcCNWKZrLCQUNKt/vTEy1Vat+7zHsNZ3e5oYce+Rnk=; b=u/08BMxw/NnMlcLNoglUliznvU15fU3pVRqHI3Q41yujmzVgS76+xqyVI7WdhrMqgR yl+Xt4AISyMhL022F3BY7L29AIHRrCPZxdqzC904+yrH+G+GSX7SuCa/VqE48yRXdxsn nrdbRE/knx+LxcMawnyJQ6OI0z2DBoeu+mM5eO1EmQpxuLyJ+3YssyixwDoQ61iho/c6 r6At1v+rs/aBRIcC1QgTNYEBCbwTElXrp+S+Gq1cZ0Ziova9r3oJM2syoT/gTsNQcZAy AE4DYcvhHpWAToSYT2occKfgFBwIFtG2W7OKA5qfDAwnNNA5WBJzQyjKij6e9Di4GVJF vmjQ== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr11745609qab.49.1333444907022; Tue, 03 Apr 2012 02:21:47 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 02:21:46 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Tue, 3 Apr 2012 09:21:46 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dcfc902baba04bcc2d6df Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:21:49 -0000 --485b397dcfc902baba04bcc2d6df Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable dear Remi, 1. for this issue, you are in misunderstanding. i checked the RFC6145 logic and behavior, very carefully, with the PTB < 1280 issue. there is no two behaviors but only one behavior supporting independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no question on which one to choose in the MAP-T draft. (i think you may accept that a "if...else..." logic does not mean option). 2. it is necessary to verify, in practice, if the feature that IPv6 is carrying ICMPv4 message is secure. it is new to the IP/ICMP architecture. 3. please refer to RFC6145 Sec 6 for the details (but maybe other sections are also needed to read). i think your objection to RFC6145 and MAP-T here is invalid. regards, maoke 2012/4/3 R=A8=A6mi Despr=A8=A6s > Hi, Guoliang, > > Interesting enough, the example you give illustrates that MAP-T needs to > remain experimental, more than any other solution. > > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It > specifies two behaviors, one that does this, and one that doesn't. Which > one to choose isn't AFAIK specified in the MAP-T draft. > > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. > This is exactly what is necessary for PMTU discovery to work. > > 3. > Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAIK f= rom > RFC6145, and therefore from MAP-T. > > When we have a detailed report on which parts of MAP-T have been > validated, with which options of RFC6145, it will be easier to analyze > scenarios like the one you propose. > > > In any case, thanks for providing one more evidence that the MAP-T > specification isn't as clear as claimed to all those who support it, and = in > particular to some also criticize 4rd-U with invalid arguments. > > Regards, > RD > > > Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit : > > +1. > > As a follower of MAP team, I participated much in developing and deployin= g > double-translation in CERNET. As far as I am concerned, in the translatio= n > scenario, > 4rd-U only solved some corner cases but missed some other cases > simultaneously. > > As an example, I suppose one fragmentation case as following: > > (IPv4 customer network)--CE---(IPv6 access network)--BR(Core > Translator)--(IPv4 network)---IPv4 host > > The minumum MTU of IPv6 access network is 1400, and the minimum MTU of > IPv4 > network on the right side is 800. Now an IPv4 host on the left side sends > a packet > with length set to 1200 and MTU set to 1, to the IPv4 host in the right > side. The packet > could traverse the IPv6 access network, but will be blocked in the IPv4 > network. > In this case, BR(Core Translator) must set DF to 0 when translating from > IPv6 back to IPv4, > instead of preserving the original IPv4 DF bit. > > In fact, according to RFC6145, if BR(Core Translator) receives an ICMP > Packet Too Big packet > whose indicating MTU is less than 1280 bytes, it will change it to 1280. > So if the BR preserve > the DF bit, the sender will always believe the path MTU is 1280, which > will certainly lead to > a black hole. > > This is only one deployment problem, and we don't know how many issues > will be encountered > in the future. So my point is that 4rd-U still needs examination in the > actual deployment, and > it's a bit early to propose it as an Informational/Standards Track > Document. > > The mail sent yesterday seemed to encounter some problems. So if you see > this mail twice, sorry for that. > > regards, > Guoliang > > --485b397dcfc902baba04bcc2d6df Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
dear Remi, 

1. for this issue, you a= re in misunderstanding. 

i checked the RFC614= 5 logic and behavior, very carefully, with the PTB < 1280 issue. there i= s no two behaviors but only one behavior supporting independent working of = the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no question on = which one to choose in the MAP-T draft. (i think you may accept that a &quo= t;if...else..." logic does not mean option). 

2. it is necessary to verify, in practice, if the featu= re that IPv6 is carrying ICMPv4 message is secure. it is new to the IP/ICMP= architecture. 

3. please refer to RFC6145 Se= c 6 for the details (but maybe other sections are also needed to read).&nbs= p;

i think your objection to RFC6145 and MAP-T here is inv= alid. 

regards,
maoke

2012/4/3 R=A8=A6mi Despr=A8=A6s &l= t;despres.remi@laposte.net&= gt;
Hi, Guol= iang,

Interesting enough, the example you give illustrat= es that MAP-T needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280= WILL BE changed to PTB=3D1280. It specifies two behaviors, one that does t= his, and one that doesn't. Which one to choose isn't AFAIK specifie= d in the MAP-T draft.

2.
With 4rd-U, an ICMPv4 PTB<1280 always g= oes to its destination unchanged. This is exactly what is necessary for PMT= U discovery to work.

3.
Now, you suggest= to replace DF=3D1 by DF=3D0 in BRs. This differs AFAIK from RFC6145, and t= herefore from MAP-T.

When we have a detailed report on which parts of MAP-T = have been validated, with which options of RFC6145, it will be easier to an= alyze scenarios like the one you propose.


In any case, thanks for providing one more evidence that the MAP= -T specification isn't as clear as claimed to all those who support it,= and in particular to some also criticize 4rd-U with invalid arguments.

Regards,
RD


Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit :
+1.
 
As a follower of MAP team, I participated much in developing and deplo= ying
double-translation in CERNET. As far as I am concerned, in the tra= nslation scenario,
4rd-U only solved some corner cases but missed some o= ther cases simultaneously.
 
As an example, I suppose one fragmentation case as foll= owing:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translato= r)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU of= IPv4
network on the right side is 800. Now an IPv4 host on the left si= de sends a packet
with length set to 1200 and MTU set to 1, to the IPv4= host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 net= work.
In this case, BR(Core Translator) must set DF to 0 when translati= ng from IPv6 back to IPv4,
instead of preserving the original IPv4 DF bi= t.
 
In fact, according to RFC6145, if BR(Core Translator) receives an ICMP= Packet Too Big packet
whose indicating MTU is less than 1280 bytes, it= will change it to 1280. So if the BR preserve
the DF bit, the sender wi= ll always believe the path MTU is 1280, which will certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many is= sues will be encountered
in the future. So my point is that 4rd-U still = needs examination in the actual deployment, and
it's a bit early to= propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if you s= ee this mail twice, sorry for that. 
 
regards,
Guoliang

--485b397dcfc902baba04bcc2d6df-- From repenno@cisco.com Tue Apr 3 02:22:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70721F84D2 for ; Tue, 3 Apr 2012 02:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.302 X-Spam-Level: X-Spam-Status: No, score=-8.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpv5aVn7MJAV for ; Tue, 3 Apr 2012 02:22:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7C50221F8497 for ; Tue, 3 Apr 2012 02:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=10048; q=dns/txt; s=iport; t=1333444975; x=1334654575; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=5MbeBQSo3WDIlHQP+di1xoGryH8Op4ntOXH+Qspzris=; b=L1oEJJFPNDfIhKSNn5UUAS0GZolds3+wfHsd05tUBXP8KKQmgqvUULRQ dD9kjuTXEJbljCkzecNUFiRl/2Ddy/Gzobt/pm1hFX6GWYDSXGZvhlBi2 ZU6VTn/1beAHGwz+iQApnn7PMABioloPse6vpSHVVaPfJBKy8Vp2QtKUs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcGAB3Bek+rRDoJ/2dsb2JhbABDglNLq2sBh3Z5gQeCCQEBAQMBAQEBDwEqLgMLEwgRAQIBAgFPBiIDAwgGAQ0FIodiBAygKZcmig6GWASIJTONC4VwhUODFIFpgwc X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208,217";a="36245268" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 03 Apr 2012 09:22:53 +0000 Received: from [10.21.73.128] ([10.21.73.128]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q339Mi5G007034; Tue, 3 Apr 2012 09:22:52 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 03 Apr 2012 02:22:45 -0700 From: Reinaldo Penno To: Maoke , "Jan Zorz @ go6.si" Message-ID: Thread-Topic: [Softwires] Path to move forward with =?ISO-8859-1?B?NHJkig==?= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3416264575_26208613" Cc: softwires@ietf.org Subject: Re: [Softwires] =?iso-8859-1?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:22:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416264575_26208613 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello, I was not part of the design team and maybe my question was already answere= d in some design team ML. Is there a document describing where MAP-T was tested, which products, operators, test timespan, test plan, was it production network, etc? And btw, I'm not talking about IVI or the part of MAP-T that is compatible with IVI. Sorry, but If I will back MAP-T I would like to see MAP-T data, not a look alike. I guess this brings another question whether there is a plan to write a document to for those that have deployed IVI and want to transition to MAP-T. Thanks, Reinaldo From: Maoke Date: Tue, 3 Apr 2012 09:07:00 +0000 To: "Jan Zorz @ go6.si" Cc: Subject: Re: [Softwires] Path to move forward with 4rd=8A 2012/4/3 Jan Zorz @ go6.si > On 4/3/12 3:53 AM, Satoru Matsushima wrote: >> FYI, choosing MAP doesn't mean that committing to a 'single'. But >> choosing 4rd-u means that committing to a 'single'. >>=20 >> There're just transport variants, which are encapsulation, >> translation and new one we've never seen before. Proponents of the >> new one claim to unify transport only to the new one, which means >> that eliminating both encapsulation and translation variants of MAP >> because they say two choice of transport type would make confusion >> for operators. The new one is transparent than translation, but less >> than encapsulation. I couldn't decide transport type to be unified >> with the new one. No evidence, no expertise, no experience for that. >> Do we need them to be sure in spite of we already have existing >> mature transport variants? >>=20 >> cheers, --satoru >=20 > +1 >=20 > Given the situation with IPv4 exhaustion we have to hurry and go with wha= t we > know and what is proven to work today with no funky new features. >=20 > I agree that 4RD-U brings some good new features, but as it changes the I= Pv6 > current usage I suggest to redirect 4RD-U to BoF and to go through revisi= on of > also other working groups that needs to say their understanding of change= d > IPv6 transport behavior. I also believe that when 4RD-U goes through the = whole > proper procedure it might be widely adopted later as MAP replacement. >=20 > Meantime - let's fix the problem with what we know and understand. agree and have the same feeling. i'd love to keep study what 4rd-u brings t= o the transition architecture and more practices are not excluded along with the 4rd-u getting well-understood. and if 4rd-u is approved/improved/verified superior to both -T and -E through the whole procedure, i don't think it will be a problem that MAP would be obsoleted i= n the future. but that's of not our current situation, fixing the problem wit= h well-understood building blocks is what we must do as soon as possible. - maoke =20 >=20 > Speaking as A+P (RFC6346) co-author, we got many questions about A+P prog= ress > from operators and we learned that the time-frame for decision between CG= N and > something else is already nearly expired. If we want anything-A+P to stil= l > reach the operators, then the time for decision is now. We already missed= the > majority of that train, but last seats in last wagon are still reachable. >=20 > We need to act and not just to push the endless discussion (that is not t= hat > uncommon for any IETF WG :) ). >=20 > Cheers, Jan Zorz >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --B_3416264575_26208613 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hello,

<= div>I was not part of the design team and maybe my question was already answ= ered in some design team ML.

Is there a document de= scribing where MAP-T was tested,  which products, operators, test times= pan,  test plan,  was it production network,  etc? 

And btw, I'm not talking about IVI or the part of MAP-T= that is compatible with IVI. Sorry, but If I will back MAP-T I would like t= o see MAP-T data, not a look alike.  I guess this brings another questi= on whether there is a plan to write a document to for those that have deploy= ed IVI and want to transition to MAP-T. 

Thank= s,

Reinaldo


From: Maoke <fibrib@gmail.com>
Date: Tue, 3 Apr 2012 09:07:00 +0000
To: "Jan Zorz @ go6.si" <jan@go6.si>Cc: <softwires@ietf.org>
Subjec= t: Re: [Softwires] Path to move forward with 4rd…



2012/4/3 Jan Zorz @ go6.si <jan@= go6.si>
On 4/3/12= 3:53 AM, Satoru Matsushima wrote:
FYI, choosing MAP doesn't mean that committing to a 'single'. But
choosing 4rd-u means that committing to a 'single'.

There're just transport variants, which are encapsulation,
translation and new one we've never seen before. Proponents of the
new one claim to unify transport only to the new one, which means
that eliminating both encapsulation and translation variants of MAP
because they say two choice of transport type would make confusion
for operators. The new one is transparent than translation, but less
than encapsulation. I couldn't decide transport type to be unified
with the new one. No evidence, no expertise, no experience for that.
Do we need them to be sure in spite of we already have existing
mature transport variants?

cheers, --satoru

+1

Given the situation with IPv4 exhaustion we have to hurry and go with what = we know and what is proven to work today with no funky new features.

= I agree that 4RD-U brings some good new features, but as it changes the IPv= 6 current usage I suggest to redirect 4RD-U to BoF and to go through revisio= n of also other working groups that needs to say their understanding of chan= ged IPv6 transport behavior. I also believe that when 4RD-U goes through the= whole proper procedure it might be widely adopted later as MAP replacement.=

Meantime - let's fix the problem with what we know and understand.

agree and have the same feeling. i'd love to kee= p study what 4rd-u brings to the transition architecture and more practices = are not excluded along with the 4rd-u getting well-understood. and if 4rd-u = is approved/improved/verified superior to both -T and -E through the whole p= rocedure, i don't think it will be a problem that MAP would be obsoleted in = the future. but that's of not our current situation, fixing the problem= with well-understood building blocks is what we must do as soon as possible= . 

- maoke
 

Speaking as A+P (RFC6346) co-author, we got many questions about A+P progre= ss from operators and we learned that the time-frame for decision between CG= N and something else is already nearly expired. If we want anything-A+P to s= till reach the operators, then the time for decision is now. We already miss= ed the majority of that train, but last seats in last wagon are still reacha= ble.

We need to act and not just to push the endless discussion (that is not tha= t uncommon for any IETF WG :) ).

Cheers, Jan Zorz

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.= org/mailman/listinfo/softwires --B_3416264575_26208613-- From satoru.matsushima@gmail.com Tue Apr 3 02:31:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27421F8505 for ; Tue, 3 Apr 2012 02:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.464 X-Spam-Level: X-Spam-Status: No, score=0.464 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57ZDUWoQqGUX for ; Tue, 3 Apr 2012 02:31:25 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9821F84B6 for ; Tue, 3 Apr 2012 02:31:25 -0700 (PDT) Received: by dady13 with SMTP id y13so4538672dad.27 for ; Tue, 03 Apr 2012 02:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7nEuq3MjcSKcmF0mncxQG8L77qUBEpBJnmEqYDl6+Cs=; b=TpF/uYKrdwSImzTek6nfHJg2lwyS5b//peTy6RhaIVI4mbI23Hv57TG3rzHCtaI/ms 4sqosT2j/pryGpiX86mBeYhtURCIm6DCIzacPRYb0M521A60HV++KPiGpHZMd92Ts3LJ NHUbx0C0dNrd8J3ohT9cJ6kpeTdGSlyOU2c37yrfOxpyrhVx4GGCmxYIT6DZwJoGh/bX fxp7zWAio7k68iviRB2dAIAV8+HCMU98bSFkEecvXSatijEQMPf3SbCyS01iO+GJkMDm gkkI3BoR5xiHx+0bLwAzwk32w38O6bLfysXhqx8bsI8SxY3XW2jeFci4OoUMlNaypXWw dYxg== Received: by 10.68.234.195 with SMTP id ug3mr28769942pbc.4.1333445485393; Tue, 03 Apr 2012 02:31:25 -0700 (PDT) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id z7sm15927989pbk.63.2012.04.03.02.31.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 02:31:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Tue, 3 Apr 2012 18:31:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1C22EB5F-674E-4EE1-B7D4-371FCE1B52B5@gmail.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQiA0cmQtVSBhcyB0cmFuc3BhcmVudCBhcyBNQVAtRQ==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:31:26 -0000 On 2012/04/03, at 18:07, R=E9mi Despr=E9s wrote: >=20 > Le 2012-04-03 =E0 03:53, Satoru Matsushima a =E9crit : >=20 >> FYI, choosing MAP doesn't mean that committing to a 'single'. But = choosing 4rd-u means that committing to a 'single'. >>=20 >> There're just transport variants, which are encapsulation, = translation and new one we've never seen before. Proponents of the new = one claim to unify transport only to the new one, which means that = eliminating both encapsulation and translation variants of MAP because = they say two choice of transport type would make confusion for = operators. >=20 >> The new one is transparent than translation, but less than = encapsulation. >=20 > If you would have a detailed scenario where ANY transparency = difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U = tunnel, this sentence would be fair. > However, you haven't shown such a scenario, and AFAIK you can't have = one because it doesn't exist. > The above assertion, being wrong, is therefore misleading. >=20 I already noticed rfc5082 as a detail. >=20 >> I couldn't decide transport type to be unified with the new one. >=20 >> No evidence, no expertise, no experience for that. >=20 > But many of those who have no motivation to look for flaws that don't = exist, do understand that the design is safe. >=20 I can't understand what you mean. Let us study it in your BOF. >> Do we need them to be sure in spite of we already have existing = mature transport variants? >=20 > MAP-E+T isn't as mature as repeatedly claimed. > MAP-T may be more imprecise than MAP-E in this respect, but both have = known bugs to be fixed (at least packet IDs of shared-addres CEs of = MAP-T, and BR hairpinning in MAP-E). >=20 thanks, the authors of map suite are working to improve the documents. = Don't worry about encapsulation and translation. > Besides, the exact list of MAP DHCPv6 parameters has yet to be = finalized. >=20 Besides, 4rd-u is on the stage of pre-BOF discussion. cheers, --satoru= From ichiroumakino@gmail.com Tue Apr 3 02:40:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A321F852B for ; Tue, 3 Apr 2012 02:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4Tq9I6U1n6h for ; Tue, 3 Apr 2012 02:40:40 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7654D21F84D2 for ; Tue, 3 Apr 2012 02:40:40 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3169626wib.1 for ; Tue, 03 Apr 2012 02:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=BOav+2P1fHGhZrDDNrafJPBTaubhJRUYPXATLA6B1j4=; b=Ms7sPpnSbGy857TB8i26hQrTbuTJQvarHUAjkgDyy1JMmiKowdT+lYKR9Wyl8fZLoH /kG0cO235N9I0q5pATawYf2ja2SXsSUqANhhMz9dUBNc7xkCkXOhljw3lOgp95p36zV1 hSUvmYhcusWKUV81BKZvU7LphelaVUzUrl7rdYDRHUGjX3PW0ypW6dHtVIzmZvKQ2RKt CR+bvELb1HqzOSDaE16V3vf0V4twOkINif2g29CepL6wd+xc9K13eK8TXqkKkVM+qMf+ 4qs1PLqFhqjIO8Af4BaHcf8VA3CN6BuyPcUR5O/qpR6Y2qqUhXk2mqQjD4maE6j3qp8w yHOA== Received: by 10.180.24.35 with SMTP id r3mr4620356wif.7.1333446039667; Tue, 03 Apr 2012 02:40:39 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-172.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm41492397wib.2.2012.04.03.02.40.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 02:40:39 -0700 (PDT) Sender: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 3 Apr 2012 11:40:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> To: Softwires-wg WG X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:40:41 -0000 > If you would have a detailed scenario where ANY transparency = difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U = tunnel, this sentence would be fair. > However, you haven't shown such a scenario, and AFAIK you can't have = one because it doesn't exist. > The above assertion, being wrong, is therefore misleading. there is more to this than comparing the IPv4 packet put into to the = 4rd-U cloud against the packet exiting the 4rd-U cloud. (from that = perspective MAP-T and 4rd-U are for most practical solutions equal = (IMHO)). 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub = and spoke mode with a separate mapping rule per subscriber. in this mode e.g only ports could be = embedded in the address. this is not possible in a translation solution like 4rd-U. 2) a node inside the network will treat translated packets different = from encapsulated ones. e.g. for the purposes of counting or for applying features. for an = encapsulated packet both the complete IPv4 datagram and the IPv6 header is available, and different = features can be applied to both. Ole= From fibrib@gmail.com Tue Apr 3 04:23:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7521F8616 for ; Tue, 3 Apr 2012 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-MBIbfr2M4w for ; Tue, 3 Apr 2012 04:23:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3273521F8585 for ; Tue, 3 Apr 2012 04:23:47 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2648160qcs.31 for ; Tue, 03 Apr 2012 04:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IajMYMwVMEk7nvNMx4AtJM933vYP/R2IWMTlk1TosKk=; b=sEkW6ay3OXl2UhE2fCqXhK8gER/mow1Rp5/TzZiVzmQ70XEfvemKRBxmpNBI8/qqZn voLqLqaQ75ZDhCQF0BA7GlziNXnDDVFBtaLBJ4UzuRiZGxkw5WegYi+X9JW7hmcK0/Az 38l8+aKk2J+uhtkdYVLCmGUjib5PqIP1ef+XkQitM3C+EuAtBiITnfq8p/3KsfmpQN5Z JQvtBjkY87Y7nPFEymGnDLHCh3zTriPUxooksr6QYQUY+Efopzgo88ERCa1QQr/BXaMO 0Jas/w0YeBDQ/V1/XkHYLmJj+TVKigQZ5QBoppR2xv6XRdD0CnRi2F1isNY1oJRWHsyz IPVQ== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr16436577qab.36.1333452226719; Tue, 03 Apr 2012 04:23:46 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 04:23:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Apr 2012 11:23:46 +0000 Message-ID: From: Maoke To: Reinaldo Penno Content-Type: multipart/alternative; boundary=20cf300faff54c716304bcc48ab4 Cc: softwires@ietf.org Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:23:48 -0000 --20cf300faff54c716304bcc48ab4 Content-Type: text/plain; charset=ISO-8859-1 hi Reinaldo, well, you pointed me as the first receiver. AFAIK, everyone participating Beijing interim has viewed the prototype (if you rejected to call that as a product) of MAP-T which is running over a production network. it was surely not IVI, and some important test data has been presented in IETF meetings. others may add information in response to your request but i don't think they are obliged to do so here, in this thread, considering 4rd-u hasn't have no even prototype yet. regarding your second question, MHO, IVI that supported by RFC6052 address mapping has different address plan with the MAP domain (you may be also interested in reading draft-mdt-softwire-map-deployment and RFC6219). they have different use cases in deployment. there is no question about transition from IVI to MAP-T, to my understanding. i may agree if you mean the existing RFCs related to IVI are still not enough to provide an informational guideline for people who would like to deploy it. thanks, maoke 2012/4/3 Reinaldo Penno > Hello, > > I was not part of the design team and maybe my question was already > answered in some design team ML. > > Is there a document describing where MAP-T was tested, which products, > operators, test timespan, test plan, was it production network, etc? > > And btw, I'm not talking about IVI or the part of MAP-T that is compatible > with IVI. Sorry, but If I will back MAP-T I would like to see MAP-T data, > not a look alike. I guess this brings another question whether there is a > plan to write a document to for those that have deployed IVI and want to > transition to MAP-T. > > Thanks, > > Reinaldo > --20cf300faff54c716304bcc48ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Reinaldo,

well, you pointed me as the firs= t receiver. AFAIK, everyone participating Beijing interim has viewed the pr= ototype (if you rejected to call that as a product) of MAP-T which is runni= ng over a production network. it was surely not IVI, and some important tes= t data has been presented in IETF meetings. others may add information in r= esponse to your request but i don't think they are obliged to do so her= e, in this thread, considering 4rd-u hasn't have no even prototype yet.= =A0

regarding your second question, MHO, IVI that sup= ported by RFC6052 address mapping has different address plan with the MAP d= omain (you may be also interested in reading draft-mdt-softwire-map-deploym= ent and RFC6219). they have different use cases in deployment. there is no = question about transition from IVI to MAP-T, to my understanding. i may agr= ee if you mean the existing RFCs related to IVI are still not enough to pro= vide an informational guideline for people who would like to deploy it.=A0<= /div>

thanks,=A0
maoke

2012/4/3 Reinaldo Penno <repenno@cisco.com>
Hello,

I was not part= of the design team and maybe my question was already answered in some desi= gn team ML.

Is there a document describing where MAP-T was tested, = =A0which products, operators, test timespan, =A0test plan, =A0was it produc= tion network, =A0etc?=A0

And btw, I'm not talk= ing about IVI or the part of MAP-T that is compatible with IVI. Sorry, but = If I will back MAP-T I would like to see MAP-T data, not a look alike. =A0I= guess this brings another question whether there is a plan to write a docu= ment to for those that have deployed IVI and want to transition to MAP-T.= =A0

Thanks,

Reinaldo

--20cf300faff54c716304bcc48ab4-- From fibrib@gmail.com Tue Apr 3 04:34:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA5521F86F9 for ; Tue, 3 Apr 2012 04:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiC92UoYErsE for ; Tue, 3 Apr 2012 04:34:33 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3352221F84DD for ; Tue, 3 Apr 2012 04:34:27 -0700 (PDT) Received: by qadc14 with SMTP id c14so2951551qad.10 for ; Tue, 03 Apr 2012 04:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WyWnGm7QkaWMDLLcjLgJZp2ib8pslz+IuhLHSTYx5/I=; b=zFmPMrT6cg1CLX3Mf+nyXlXPsySWLPo1+fIuy1W87bipAn9KLjDc7prkTYn8aC83y+ YlexsgMfnFpelTipmdJstTs26Xjn65NN93NYly5eeN78F1Fl2DCngdE26uJWfaUdjKzH 2uihbuzD4HAUUPStYNgJPGhz3DwJ87F/qKvCsgwORe/xM/ma8BEx+nlW1SkvPoz32rO4 dNrA2VoOFfZ1W9Ja8FpYAh9fTRuBJ3I5QWXmBsefSCV5adZWuhVXFYL50qvJG5jPFxNM j+2RiqlJzcUOr0eSUcqIQ/kvaA4DXnKUPQN6BU2r2jeuAZcMbEv9q6Pki5UWiKy0jCK3 gdrA== MIME-Version: 1.0 Received: by 10.229.136.130 with SMTP id r2mr4699116qct.58.1333452866628; Tue, 03 Apr 2012 04:34:26 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 04:34:26 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Tue, 3 Apr 2012 11:34:26 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c768f9270af8304bcc4b084 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:34:33 -0000 --00248c768f9270af8304bcc4b084 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA4=D4=C23=C8=D5 =C9=CF=CE=E79:21=A3=ACMaoke =D0=B4=B5=C0=A3=BA > dear Remi, > > 1. for this issue, you are in misunderstanding. > > i checked the RFC6145 logic and behavior, very carefully, with the PTB < > 1280 issue. there is no two behaviors but only one behavior supporting > independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. > there is no question on which one to choose in the MAP-T draft. (i think > you may accept that a "if...else..." logic does not mean option). > > 2. it is necessary to verify, in practice, if the feature that IPv6 is > carrying ICMPv4 message is secure. it is new to the IP/ICMP architecture. > > 3. please refer to RFC6145 Sec 6 for the details (but maybe other section= s > are also needed to read). > > i think your objection to RFC6145 and MAP-T here is invalid. > > regards, > maoke > > 2012/4/3 R=A8=A6mi Despr=A8=A6s > >> Hi, Guoliang, >> >> Interesting enough, the example you give illustrates that MAP-T needs to >> remain experimental, more than any other solution. >> > concluding above of my points, here your assert "MAP-T needs to remain experimental" is invalid. - maoke --00248c768f9270af8304bcc4b084 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=D4=DA 2012=C4=EA4=D4=C23=C8=D5 =C9=CF= =CE=E79:21=A3=ACMaoke <fibrib@gmail.com>=D0=B4=B5=C0=A3=BA
dear Remi, 

1. for this issue, you a= re in misunderstanding. 

i checked the RFC614= 5 logic and behavior, very carefully, with the PTB < 1280 issue. there i= s no two behaviors but only one behavior supporting independent working of = the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no question on = which one to choose in the MAP-T draft. (i think you may accept that a &quo= t;if...else..." logic does not mean option). 

2. it is necessary to verify, in practice, if the featu= re that IPv6 is carrying ICMPv4 message is secure. it is new to the IP/ICMP= architecture. 

3. please refer to RFC6145 Se= c 6 for the details (but maybe other sections are also needed to read).&nbs= p;

i think your objection to RFC6145 and MAP-T here is inv= alid. 

regards,
maoke

2012/4/3 R=A8=A6mi Despr=A8= =A6s <despres.remi@laposte.net>
Hi, Guol= iang,

Interesting enough, the example you give illustrat= es that MAP-T needs to remain experimental, more than any other solution.

concl= uding above of my points, here your assert "MAP-T needs to remain expe= rimental" is invalid. - maoke  
 
--00248c768f9270af8304bcc4b084-- From despres.remi@laposte.net Tue Apr 3 05:01:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005A221F8769 for ; Tue, 3 Apr 2012 05:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ+VQHrsJ3RR for ; Tue, 3 Apr 2012 05:01:04 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 0547421F8768 for ; Tue, 3 Apr 2012 05:01:03 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id tQ101i00L37Y3f403Q11i8; Tue, 03 Apr 2012 14:01:01 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <1C22EB5F-674E-4EE1-B7D4-371FCE1B52B5@gmail.com> Date: Tue, 3 Apr 2012 14:00:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4A3ABD-836F-4120-94B9-136F8C6698A5@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> <1C22EB5F-674E-4EE1-B7D4-371FCE1B52B5@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:01:05 -0000 Le 2012-04-03 =E0 11:31, Satoru Matsushima a =E9crit : > On 2012/04/03, at 18:07, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-04-03 =E0 03:53, Satoru Matsushima a =E9crit : >>=20 >>> FYI, choosing MAP doesn't mean that committing to a 'single'. But = choosing 4rd-u means that committing to a 'single'. >>>=20 >>> There're just transport variants, which are encapsulation, = translation and new one we've never seen before. Proponents of the new = one claim to unify transport only to the new one, which means that = eliminating both encapsulation and translation variants of MAP because = they say two choice of transport type would make confusion for = operators. >>=20 >>> The new one is transparent than translation, but less than = encapsulation. >>=20 >> If you would have a detailed scenario where ANY transparency = difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U = tunnel, this sentence would be fair. >> However, you haven't shown such a scenario, and AFAIK you can't have = one because it doesn't exist. >> The above assertion, being wrong, is therefore misleading. >>=20 >=20 > I already noticed rfc5082 as a detail. AFAIK, rfc5082 compatibility is ensured with TTL preservation that is in = 4rd-u-06. Anything more? >=20 >=20 >>=20 >>> I couldn't decide transport type to be unified with the new one. >>=20 >>> No evidence, no expertise, no experience for that. >>=20 >> But many of those who have no motivation to look for flaws that don't = exist, do understand that the design is safe. >>=20 >=20 > I can't understand what you mean. Let us study it in your BOF. There is no such thing as "my BOF"! >>> Do we need them to be sure in spite of we already have existing = mature transport variants? >>=20 >> MAP-E+T isn't as mature as repeatedly claimed. >> MAP-T may be more imprecise than MAP-E in this respect, but both have = known bugs to be fixed (at least packet IDs of shared-addres CEs of = MAP-T, and BR hairpinning in MAP-E). >>=20 >=20 > thanks, the authors of map suite are working to improve the documents. > Don't worry about encapsulation and translation. Just being tired to hear that the spec if clean and complete, and to = have to find out myself what is missing. >> Besides, the exact list of MAP DHCPv6 parameters has yet to be = finalized. Thanks for having implicitly acknowledged this fact (contrary to the = claim that MAP is completely specified). >=20 > Besides, 4rd-u is on the stage of pre-BOF discussion. Sorry to read this kind of argument from you. No other comment. RD >=20 > cheers, > --satoru From simon.perreault@viagenie.ca Tue Apr 3 05:16:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E228B21F8701 for ; Tue, 3 Apr 2012 05:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTVjkr+bQRNZ for ; Tue, 3 Apr 2012 05:16:05 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 512E621F86FF for ; Tue, 3 Apr 2012 05:16:05 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:b87e:b01b:b742:23d3]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9872F40109 for ; Tue, 3 Apr 2012 08:16:04 -0400 (EDT) Message-ID: <4F7AEA04.2060106@viagenie.ca> Date: Tue, 03 Apr 2012 08:16:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:16:06 -0000 On 2012-04-03 05:40, Ole Trřan wrote: > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and spoke mode with a separate > mapping rule per subscriber. in this mode e.g only ports could be embedded in the address. this is not > possible in a translation solution like 4rd-U. This mode of operation was suggested last week during the SD-NAT presentation. There seemed to be consensus among operators that it was not practically feasible. > 2) a node inside the network will treat translated packets different from encapsulated ones. > e.g. for the purposes of counting or for applying features. for an encapsulated packet both the complete > IPv4 datagram and the IPv6 header is available, and different features can be applied to both. In practice, the contents of encapsulated packets are rarely inspected by firewalls and other such devices. IMHO at this point we should let the market decide. Publish both as experimental. Let's work on something else now. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From bupthgl@gmail.com Tue Apr 3 05:53:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0D21F86FF for ; Tue, 3 Apr 2012 05:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.144 X-Spam-Level: * X-Spam-Status: No, score=1.144 tagged_above=-999 required=5 tests=[AWL=1.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cpDbR6qK6-S for ; Tue, 3 Apr 2012 05:53:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5F21F866C for ; Tue, 3 Apr 2012 05:53:33 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2706210qcs.31 for ; Tue, 03 Apr 2012 05:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YyKKA8bP4N5TC2/89hCQiBCAW1Rm5YqcvGHFQ3SiaE8=; b=DYtXGF1EhZl4lXRmjByA5oo1V+QqyueVF6weLBSo/9ptbCKD6zwJnFfHXXA/qv8Uuo iAn5uGq4XGh57myVPKUFmDoHMH1s65mjfGpjWhbi6+on/1Ov70fjo34m5Cyt1yoOAGN4 GjZi2JoQgl05g3zv6tF7cGetIFwHWdfuurQO3AYDN3RGnzvr/q2CUzkx3oSzCb1UDCMH FPwl/ncBBE+2s65fDWH0BukEZH7w/W9Wg/wFkUxjmj8NR7JxxGDTxQ/WhDGd27HnIWxb zh2eO5ALt5ATnbleIXt6JeHw4N2EssmwzTjJn78ugtiK3tVYbuDpuPeGw9wSDq0jk+HY hAuA== MIME-Version: 1.0 Received: by 10.224.100.197 with SMTP id z5mr16277048qan.61.1333457612624; Tue, 03 Apr 2012 05:53:32 -0700 (PDT) Received: by 10.229.158.195 with HTTP; Tue, 3 Apr 2012 05:53:32 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Tue, 3 Apr 2012 20:53:32 +0800 Message-ID: From: Guoliang To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f744652d23504bcc5cb8e Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:53:34 -0000 --20cf306f744652d23504bcc5cb8e Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Remi: I don't think my case illustrates MAP-T needs to remain experimental, my comments are below: 2012/4/3 R=A8=A6mi Despr=A8=A6s > Hi, Guoliang, > > Interesting enough, the example you give illustrates that MAP-T needs to > remain experimental, more than any other solution. > > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It > specifies two behaviors, one that does this, and one that doesn't. Which > one to choose isn't AFAIK specified in the MAP-T draft. > RFC6145 says in Section 6: "It SHOULD be possible to configure a translator for either of the two approaches", the first approach is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890]", the second approach is to change PTB MTU value to 1280 in case PTB<1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. > > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. > This is exactly what is necessary for PMTU discovery to work. > Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could traverse current IPv6 firewalls successfully. > > 3. > Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAIK f= rom > RFC6145, and therefore from MAP-T. > Please see Section 6 of RFC6145. > > When we have a detailed report on which parts of MAP-T have been > validated, with which options of RFC6145, it will be easier to analyze > scenarios like the one you propose. > > > In any case, thanks for providing one more evidence that the MAP-T > specification isn't as clear as claimed to all those who support it, and = in > particular to some also criticize 4rd-U with invalid arguments. > > Regards, > RD > In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully. Regards, Guoliang > > > Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit : > > +1. > > As a follower of MAP team, I participated much in developing and deployin= g > double-translation in CERNET. As far as I am concerned, in the translatio= n > scenario, > 4rd-U only solved some corner cases but missed some other cases > simultaneously. > > As an example, I suppose one fragmentation case as following: > > (IPv4 customer network)--CE---(IPv6 access network)--BR(Core > Translator)--(IPv4 network)---IPv4 host > > The minumum MTU of IPv6 access network is 1400, and the minimum MTU of > IPv4 > network on the right side is 800. Now an IPv4 host on the left side sends > a packet > with length set to 1200 and MTU set to 1, to the IPv4 host in the right > side. The packet > could traverse the IPv6 access network, but will be blocked in the IPv4 > network. > In this case, BR(Core Translator) must set DF to 0 when translating from > IPv6 back to IPv4, > instead of preserving the original IPv4 DF bit. > > In fact, according to RFC6145, if BR(Core Translator) receives an ICMP > Packet Too Big packet > whose indicating MTU is less than 1280 bytes, it will change it to 1280. > So if the BR preserve > the DF bit, the sender will always believe the path MTU is 1280, which > will certainly lead to > a black hole. > > This is only one deployment problem, and we don't know how many issues > will be encountered > in the future. So my point is that 4rd-U still needs examination in the > actual deployment, and > it's a bit early to propose it as an Informational/Standards Track > Document. > > The mail sent yesterday seemed to encounter some problems. So if you see > this mail twice, sorry for that. > > regards, > Guoliang > > --20cf306f744652d23504bcc5cb8e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Remi:
 
I don't think my case illustrates MAP-T needs to= remain experimental, my comments are below:

2012/4/3 R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net<= /a>>
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D12= 80. It specifies two behaviors, one that does this, and one that doesn'= t. Which one to choose isn't AFAIK specified in the MAP-T draft.
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is th= at "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls = can be administered in compliance with Section 4.3.1 of [RFC4890]", th= e second approach is to change PTB MTU value to 1280 in case PTB<1280 an= d set DF bit to 0 in case the packet is less than or equal to 1280 bytes, i= f the requirements of the first approach can't be met. It doesn't m= ean the administrator can refuse to take the second approach according to h= is will.
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination uncha= nged. This is exactly what is necessary for PMTU discovery to work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U embeddin= g ICMPv4 packets could  traverse current IPv6 firewalls successfully.<= /div>
 

3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAI= K from RFC6145, and therefore from MAP-T.
 
Please see Section 6 of RFC6145.
 

When we have a detailed report on which parts of MAP-T have been valid= ated, with which options of RFC6145, it will be easier to analyze scenarios= like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T spe= cification isn't as clear as claimed to all those who support it, and i= n particular to some also criticize 4rd-U with invalid arguments.

Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, if= you read RFC6145 carefully.
 
Regards,
Guoliang
 


Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit :
+1.
 
As a follower of MAP team, I participated much in developing and deplo= ying
double-translation in CERNET. As far as I am concerned, in the tra= nslation scenario,
4rd-U only solved some corner cases but missed some o= ther cases simultaneously.
 
As an example, I suppose one fragmentation case as foll= owing:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translato= r)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU of= IPv4
network on the right side is 800. Now an IPv4 host on the left si= de sends a packet
with length set to 1200 and MTU set to 1, to the IPv4= host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 net= work.
In this case, BR(Core Translator) must set DF to 0 when translati= ng from IPv6 back to IPv4,
instead of preserving the original IPv4 DF bi= t.
 
In fact, according to RFC6145, if BR(Core Translator) receives an ICMP= Packet Too Big packet
whose indicating MTU is less than 1280 bytes, it= will change it to 1280. So if the BR preserve
the DF bit, the sender wi= ll always believe the path MTU is 1280, which will certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many is= sues will be encountered
in the future. So my point is that 4rd-U still = needs examination in the actual deployment, and
it's a bit early to= propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if you s= ee this mail twice, sorry for that. 
 
regards,
Guoliang
--20cf306f744652d23504bcc5cb8e-- From despres.remi@laposte.net Tue Apr 3 05:57:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4F221F85CD for ; Tue, 3 Apr 2012 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqTw39FxBbEv for ; Tue, 3 Apr 2012 05:57:19 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 904AD21F8535 for ; Tue, 3 Apr 2012 05:57:10 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id tQx91i00337Y3f403Qx9Ua; Tue, 03 Apr 2012 14:57:09 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-815826802 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 14:57:08 +0200 Message-Id: <0CF94F7B-FC8B-4B68-8404-72DA56FDE9A5@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:57:20 -0000 --Apple-Mail-5-815826802 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maoke, Please see in line. Le 2012-04-03 =C3=A0 11:21, Maoke a =C3=A9crit : > dear Remi,=20 >=20 > 1. for this issue, you are in misunderstanding.=20 >=20 > i checked the RFC6145 logic and behavior, very carefully, with the PTB = < 1280 issue. there is no two behaviors but only one behavior supporting = independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 = translators. there is no question on which one to choose in the MAP-T = draft. Although I tried, I cannot share your interpretation: - sec 6 introduces a problem due to some Host/FWs that don't support = IPv6 PTB<1280 (although they should) - Two approaches are proposed. - The second one looses the IPv4 MTU information if < 1280 (creating a = problem for PMTU discovery in IPv4) - The first one isn't described, but consists in avoiding the problem, = apparently by ensuring that all host/FWs support PTB<1280. Implicitly, = this can be understood as no replacement of <1280 by =3D 1280. Anything missed? > (i think you may accept that a "if...else..." logic does not mean = option).=20 >=20 > 2. it is necessary to verify, in practice, if the feature that IPv6 is = carrying ICMPv4 message is secure. it is new to the IP/ICMP = architecture.=20 If you have something in mind, please detail. AFAIK, it isn't difficult in a ISP domain to make sure IPv6 packets are = transparently transmitted between BRs and CEs, even if their next header = is 1 (that of ICMPv4). >=20 > 3. please refer to RFC6145 Sec 6 for the details (but maybe other = sections are also needed to read).=20 See 1. above. =20 > i think your objection to RFC6145 and MAP-T here is invalid.=20 Not convinced by your comment. Besides, even if it would be the case, the mail to which I was answering = below was proposing to always change DF=3D1 into DF=3D0, instead of just = in the fragmented-pcket case. To me, this illustrates that MAP-t specification isn't so easy to = understand where it deals with details of ICMP v4/v6 translations. Criticisms addressed to 4rd-U should be more carefully studied before = being made. Regards, RD >=20 > regards, > maoke >=20 > 2012/4/3 R=C3=A9mi Despr=C3=A9s > Hi, Guoliang, >=20 > Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution. >=20 > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. >=20 > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to work. >=20 > 3. > Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T. >=20 > When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. >=20 >=20 > In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. >=20 > Regards, > RD >=20 >=20 > Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit : >=20 >> +1. >> =20 >> As a follower of MAP team, I participated much in developing and = deploying=20 >> double-translation in CERNET. As far as I am concerned, in the = translation scenario, >> 4rd-U only solved some corner cases but missed some other cases = simultaneously. >> =20 >> As an example, I suppose one fragmentation case as following: >> =20 >> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host >> =20 >> The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4=20 >> network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 >> with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 >> could traverse the IPv6 access network, but will be blocked in the = IPv4 network. (*) >> In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, >> instead of preserving the original IPv4 DF bit. >> =20 >> In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet=20 >> whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve >> the DF bit, the sender will always believe the path MTU is 1280, = which will certainly lead to=20 >> a black hole. >> =20 >> This is only one deployment problem, and we don't know how many = issues will be encountered >> in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 >> it's a bit early to propose it as an Informational/Standards Track = Document. >> =20 >> The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 >> =20 >> regards,=20 >> Guoliang >=20 --Apple-Mail-5-815826802 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
dear Remi, 

1. for = this issue, you are in = misunderstanding. 

i checked the RFC6145 = logic and behavior, very carefully, with the PTB < 1280 issue. there = is no two behaviors but only one behavior supporting independent working = of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no = question on which one to choose in the MAP-T draft. =

Although I tried, I cannot share = your interpretation:
- sec 6 introduces a problem due to some = Host/FWs that don't support IPv6 PTB<1280 (although they = should)
- Two approaches are proposed.
- The second = one looses the IPv4 MTU information if < 1280 (creating a problem for = PMTU discovery in IPv4)
- The first one isn't described, but = consists in avoiding the problem, apparently by ensuring that all = host/FWs support PTB<1280. Implicitly, this can be understood as no = replacement of <1280 by =3D 1280.

Anything = missed?


(i think = you may accept that a "if...else..." logic does not mean = option). 

2. it is necessary to verify, in practice, if the = feature that IPv6 is carrying ICMPv4 message is secure. it is new to the = IP/ICMP architecture. 

If you have = something in mind, please detail.




<= div>


regards,
maoke

2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>
Hi, = Guoliang,

Interesting enough, the example you give = illustrates that MAP-T needs to remain experimental, more than any other = solution.

1.
RFC6145 doesn't say that a PTB<1280 = WILL BE changed to PTB=3D1280. It specifies two behaviors, one that does = this, and one that doesn't. Which one to choose isn't AFAIK specified in = the MAP-T draft.

2.
With 4rd-U, an ICMPv4 PTB<1280 = always goes to its destination unchanged. This is exactly what is = necessary for PMTU discovery to = work.

3.
Now, you suggest to replace = DF=3D1 by DF=3D0 in BRs. This differs AFAIK from RFC6145, and therefore = from MAP-T.

When we have a detailed report on which parts of = MAP-T have been validated, with which options of RFC6145, it will be = easier to analyze scenarios like the one you = propose.


In any case, thanks for providing one more evidence that the = MAP-T specification isn't as clear as claimed to all those who support = it, and in particular to some also criticize 4rd-U with invalid = arguments.
=

Regards,
RD


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9cri= t :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network.

(*)
= In this case, BR(Core Translator) must set DF to 0 when translating from = IPv6 back to IPv4,
instead of preserving the original IPv4 DF = bit.
<= br>
 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang


= --Apple-Mail-5-815826802-- From despres.remi@laposte.net Tue Apr 3 05:58:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A7421F85CD for ; Tue, 3 Apr 2012 05:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti17UNAHjTbm for ; Tue, 3 Apr 2012 05:58:33 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id D766021F8764 for ; Tue, 3 Apr 2012 05:57:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id tQx91i00337Y3f403QxxZH; Tue, 03 Apr 2012 14:57:58 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 14:57:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:58:33 -0000 Le 2012-04-03 =E0 11:40, Ole Tr=F8an a =E9crit : >> If you would have a detailed scenario where ANY transparency = difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U = tunnel, this sentence would be fair. >> However, you haven't shown such a scenario, and AFAIK you can't have = one because it doesn't exist. >> The above assertion, being wrong, is therefore misleading. >=20 > there is more to this than comparing the IPv4 packet put into to the = 4rd-U cloud against the packet exiting the 4rd-U cloud. What else? > (from that perspective MAP-T and 4rd-U are for most practical = solutions equal (IMHO)). Nothing new here, but this is only an opinion, not a technical = consideration. > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using = hub and spoke mode with a separate > mapping rule per subscriber. in this mode e.g only ports could be = embedded in the address. New requirement? New feature? Your draft says "Each MAP node in the domain has the same set of rules." It's getting very confusing. BTW, is this something you claim to have been tested? If you want to pursue this point, a use-case example with its mapping = rules could help to understand what you have in mind. > this is not > possible in a translation solution like 4rd-U. >=20 > 2) a node inside the network will treat translated packets different = from encapsulated ones. Yes, but so what? > e.g. for the purposes of counting or for applying features. for an = encapsulated packet both the complete > IPv4 datagram and the IPv6 header is available, and different = features can be applied to both. I don't see what would be missing with 4rd-U:=20 - the IPv4 payload is available - IPv4 source and destination addresses are available in a fixed = position of IPV6 addresses - IPv6 packets that are header-mapped IPv4 packets are recognizable wit = the V octet of the CE address Cheers, RD >=20 > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Tue Apr 3 06:18:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E821F85A4 for ; Tue, 3 Apr 2012 06:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yLHJLuGvVIi for ; Tue, 3 Apr 2012 06:18:00 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4FB21F8596 for ; Tue, 3 Apr 2012 06:17:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id tRHv1i00937Y3f403RHvq2; Tue, 03 Apr 2012 15:17:56 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-817073893 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 15:17:55 +0200 Message-Id: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> To: guoliang han X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:18:01 -0000 --Apple-Mail-7-817073893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 2012-04-03 14:43, guoliang han : > Hi, Remi: > =20 > I don't think my case illustrates MAP-T needs to remain experimental, = my comments are below: > =20 > =20 > 2012/4/3 R=C3=A9mi Despr=C3=A9s > Hi, Guoliang, >=20 > Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution. >=20 > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. > =20 > =20 > RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is that = "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can = be administered in compliance with Section 4.3.1 of [RFC4890]", the = second approach is to change PTB MTU value to 1280 in case PTB<1280 and = set DF bit to 0 in case the packet is less than or equal to 1280 bytes, = if the requirements of the first approach can't be met. It doesn't mean = the administrator can refuse to take the second approach according to = his will.=20 > =20 >=20 > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to work. > =20 > Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could traverse current IPv6 firewalls = successfully. Typical use cases of 4rd-U have no firewall between BRs and CEs. If some would exist, they should be configured to let ICMPv4 payloads go = through (Protocol =3D 1) This is like configuring them to accept IPv4 headers in IPv6 payloads = (Protocol =3D 4) > 3. > Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T. > =20 > See Section 6 of RFC6145. This isn't in RFC6145, simply a reference to (*) below. If I misunderstood, please explain what. > When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. >=20 >=20 > In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. > =20 > Regards, > RD > =20 > In fact, MAP-T is clear enough to be deployed without any problems, if = you read RFC6145 carefully. Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided for = IPv4 PMTU discovery to work. Still waiting for a clarification on this issue. Regards, RD (retransmitted after deletion of unnecessary old text, message too big = for the ML!)=20 > =20 > regards, > Guoliang > =20 > =20 >=20 >=20 > Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit : >=20 >> +1. >> =20 >> As a follower of MAP team, I participated much in developing and = deploying=20 >> double-translation in CERNET. As far as I am concerned, in the = translation scenario, >> 4rd-U only solved some corner cases but missed some other cases = simultaneously. >> =20 >> As an example, I suppose one fragmentation case as following: >> =20 >> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host >> =20 >> The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4=20 >> network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 >> with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 >> could traverse the IPv6 access network, but will be blocked in the = IPv4 network.=20 (*) >> In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, >> instead of preserving the original IPv4 DF bit. >> =20 >> In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet=20 >> whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve >> the DF bit, the sender will always believe the path MTU is 1280, = which will certainly lead to=20 >> a black hole. >> =20 >> This is only one deployment problem, and we don't know how many = issues will be encountered >> in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 >> it's a bit early to propose it as an Informational/Standards Track = Document. >> =20 >> The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 >> =20 >> regards,=20 >> Guoliang >>=20 --Apple-Mail-7-817073893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, = Remi:
 
I don't think my case illustrates MAP-T needs to remain = experimental, my comments are below:
 
 
2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T = needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280.= It specifies two behaviors, one that does this, and one that doesn't. = Which one to choose isn't AFAIK specified in the MAP-T draft.
 
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach = is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network = firewalls can be administered in compliance with Section 4.3.1 of = [RFC4890]", the second approach is to change PTB MTU value to 1280 in = case PTB<1280 and set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, if the requirements of the first = approach can't be met. It doesn't mean the administrator can refuse = to take the second approach according to his will. 
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to = work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could  traverse current IPv6 firewalls = successfully.

Typical use cases = of 4rd-U have no firewall between BRs and CEs.
If some would = exist, they should be configured to let ICMPv4 payloads go through = (Protocol =3D 1)
This is like configuring them to accept IPv4 = headers in IPv6 payloads (Protocol =3D = 4)


3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T.
 
See Section 6 of = RFC6145.

This isn't in RFC6145, = simply a reference to (*) below.
If I misunderstood, please = explain what.

When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments.
   
    Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 = carefully.

Replacing = IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided = for IPv4 PMTU discovery to work.
Still waiting for a = clarification on this = issue.

Regards,
RD

=
(retransmitted after deletion of unnecessary old text, message too = big for the ML!) 


 
regards,
Guoliang
 
 


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network. =
<= div>
(*)
In= this case, BR(Core Translator) must set DF to 0 when translating from = IPv6 back to IPv4,
instead of preserving the original IPv4 DF = bit.
<= div>

 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang
=


= --Apple-Mail-7-817073893-- From bupthgl@gmail.com Tue Apr 3 06:46:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C095121F860B for ; Tue, 3 Apr 2012 06:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.647 X-Spam-Level: X-Spam-Status: No, score=0.647 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNiq62t3tg-l for ; Tue, 3 Apr 2012 06:46:04 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 811E821F85FD for ; Tue, 3 Apr 2012 06:46:04 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2747813qcs.31 for ; Tue, 03 Apr 2012 06:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DSfReegCrfnyAm6Rv2r4dMoJdoyxztkSOispihk+dng=; b=Pys2tC+AryX0+ZgQoWrMc+SWFydzA8Xu07b0jYe/6YnEHKjUWwaEDYg+rdmIgZIJVV jHZc4YSfKTjGGirN7Rs2JSswkorS95Xip8vanHOXn0DfVGVoJmgEJrB+LLRH9FLmPQJh Pebr84kKrqyxhMsKKAe8NCm7HrBl2yi0iPeqHLqa2K5zqoaZrWanyClrBIdEkDUa4ON2 FcygMX2v26VP3GoDH5ASE/xyuQ4owa/3VeB8/Ub9dwn8COF7jO7zhyLOkQ1T2AuXtHp3 J18iX2EK/XoBNpDg05VZwXl/XttyT8JBOpOPz7wnaY4rQcJdqVVvXemGiOi1CPYPG2vo +ieA== MIME-Version: 1.0 Received: by 10.229.78.206 with SMTP id m14mr4889192qck.78.1333460764041; Tue, 03 Apr 2012 06:46:04 -0700 (PDT) Received: by 10.229.158.195 with HTTP; Tue, 3 Apr 2012 06:46:04 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Tue, 3 Apr 2012 21:46:04 +0800 Message-ID: From: Guoliang To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235447083029a2db04bcc6874c Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:46:05 -0000 --00235447083029a2db04bcc6874c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Remi: Pls read my comments below. 2012/4/3 R=A8=A6mi Despr=A8=A6s > > 2012-04-03 14:43, guoliang han : > > Hi, Remi: > > I don't think my case illustrates MAP-T needs to remain experimental, my > comments are below: > > > 2012/4/3 R=A8=A6mi Despr=A8=A6s > >> Hi, Guoliang, >> >> Interesting enough, the example you give illustrates that MAP-T needs to >> remain experimental, more than any other solution. >> >> 1. >> RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It >> specifies two behaviors, one that does this, and one that doesn't. Which >> one to choose isn't AFAIK specified in the MAP-T draft. >> > > > RFC6145 says in Section 6: "It SHOULD be possible to configure a > translator for either of the two approaches", the first approach is that > "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be > administered in compliance with Section 4.3.1 of [RFC4890]", the second > approach is to change PTB MTU value to 1280 in case PTB<1280 and set DF b= it > to 0 in case the packet is less than or equal to 1280 bytes, if the > requirements of the first approach can't be met. It doesn't mean the > administrator can refuse to take the second approach according to his wil= l. > > >> >> 2. >> With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. >> This is exactly what is necessary for PMTU discovery to work. >> > > Actually, what I worry about is whether IPv6 packets of 4rd-U embedding > ICMPv4 packets could traverse current IPv6 firewalls successfully. > > > Typical use cases of 4rd-U have no firewall between BRs and CEs. > If some would exist, they should be configured to let ICMPv4 payloads go > through (Protocol =3D 1) > This is like configuring them to accept IPv4 headers in IPv6 payloads > (Protocol =3D 4) > Hope so. Still anticipating experimental results proving that yet. > > > 3. >> Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAIK = from >> RFC6145, and therefore from MAP-T. >> > > See Section 6 of RFC6145. > > > This isn't in RFC6145, simply a reference to (*) below. > If I misunderstood, please explain what. > You surely misunderstood that. I mentioned "in that case", instead of replacing DF=3D1 by DF=3D0 in all cases. Replacing DF bit only occurs in th= e case that incoming packet size is less that 1280 bytes, which is exactly the requirement of RFC6145. > > When we have a detailed report on which parts of MAP-T have been >> validated, with which options of RFC6145, it will be easier to analyze >> scenarios like the one you propose. >> >> >> In any case, thanks for providing one more evidence that the MAP-T >> specification isn't as clear as claimed to all those who support it, and= in >> particular to some also criticize 4rd-U with invalid arguments. >> > > Regards, > >> RD >> > > In fact, MAP-T is clear enough to be deployed without any problems, if > you read RFC6145 carefully. > > > Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided for IP= v4 > PMTU discovery to work. > Still waiting for a clarification on this issue. > If the translator set DF bit to 0 in case the packet is less than or equal to 1280 bytes, and replace PTB<1280 by PTB=3D1280, there are no problems on the data path, whether in single/double translation. Regards, Guoliang > > Regards, > RD > > > > > regards, > Guoliang > > > >> >> >> Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit : >> >> +1. >> >> As a follower of MAP team, I participated much in developing and >> deploying >> double-translation in CERNET. As far as I am concerned, in the >> translation scenario, >> 4rd-U only solved some corner cases but missed some other cases >> simultaneously. >> >> As an example, I suppose one fragmentation case as following: >> >> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core >> Translator)--(IPv4 network)---IPv4 host >> >> The minumum MTU of IPv6 access network is 1400, and the minimum MTU of >> IPv4 >> network on the right side is 800. Now an IPv4 host on the left side send= s >> a packet >> with length set to 1200 and MTU set to 1, to the IPv4 host in the right >> side. The packet >> could traverse the IPv6 access network, but will be blocked in the IPv4 >> network. >> >> > (*) > > In this case, BR(Core Translator) must set DF to 0 when translating >> from IPv6 back to IPv4, >> instead of preserving the original IPv4 DF bit. >> >> > > >> >> --00235447083029a2db04bcc6874c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi, Remi:
 
Pls read my comments below.

2012/4/3 R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net<= /a>>

2012-04-03  14:43, guoliang han :

Hi, Remi:
 
I don't think my case illustrates MAP-T needs to remain experiment= al, my comments are below:
 
 
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D12= 80. It specifies two behaviors, one that does this, and one that doesn'= t. Which one to choose isn't AFAIK specified in the MAP-T draft.
 
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is&nb= sp;that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firew= alls can be administered in compliance with Section 4.3.1 of [RFC4890]"= ;, the second approach is to change PTB MTU value to 1280 in case PTB<12= 80 and set DF bit to 0 in case the packet is less than or equal t= o 1280 bytes, if the requirements of the first approach can't be met. I= t doesn't mean the administrator can refuse to take the second app= roach according to his will. 
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination uncha= nged. This is exactly what is necessary for PMTU discovery to work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U embeddin= g ICMPv4 packets could  traverse current IPv6 firewalls successfully.<= /div>

Typical use cases of 4rd-U have no firewall between BRs and = CEs.
If some would exist, they should be configured to let ICMPv4 payloads = go through (Protocol =3D 1)
This is like configuring them to accept IPv4 headers in IPv6 payloads = (Protocol =3D 4)
 
Hope so. Still anticipating experimental results proving that yet.
 


3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs AFAI= K from RFC6145, and therefore from MAP-T.
 
See Section 6 of RFC6145.

This isn't in RFC6145, simply a reference to (*) below.<= /div>
If I misunderstood, please explain what.
 
You surely misunderstood that. I mentioned "in that case", i= nstead of replacing DF=3D1 by DF=3D0 in all cases. Replacing DF bit only oc= curs in the case that incoming packet size is less that 1280 bytes, which i= s exactly the requirement of RFC6145.
 

When we have a detailed report on which parts of MAP-T have been valid= ated, with which options of RFC6145, it will be easier to analyze scenarios= like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T spe= cification isn't as clear as claimed to all those who support it, and i= n particular to some also criticize 4rd-U with invalid arguments.
   
    Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, if= you read RFC6145 carefully.

Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK b= e avoided for IPv4 PMTU discovery to work.
Still waiting for a clarification on this issue.
 
If the translator set DF bit to 0 in case the packet is less than or e= qual to 1280 bytes, and replace PTB<1280 by PTB=3D1280, there are no pro= blems on the data path, whether in single/double translation.
 
Regards,
Guoliang
 

Regards,
RD



 
regards,
Guoliang
 
 


Le 2012-04-03 =A8=A4 05:26, =BA=AB=B9=FA=C1=BA a =A8=A6crit :
+1.
 
As a follower of MAP team, I participated much in developing and deplo= ying
double-translation in CERNET. As far as I am concerned, in the tra= nslation scenario,
4rd-U only solved some corner cases but missed some o= ther cases simultaneously.
 
As an example, I suppose one fragmentation case as foll= owing:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translato= r)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU of= IPv4
network on the right side is 800. Now an IPv4 host on the left si= de sends a packet
with length set to 1200 and MTU set to 1, to the IPv4= host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 net= work.

(*)=20

In this case, BR(Core Translator) must set DF to 0 when translating fr= om IPv6 back to IPv4,
instead of preserving the original IPv4 DF bit.


 
--00235447083029a2db04bcc6874c-- From despres.remi@laposte.net Tue Apr 3 07:52:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE78221F85F0 for ; Tue, 3 Apr 2012 07:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu5yz3hNLa6T for ; Tue, 3 Apr 2012 07:52:56 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3A21F85D6 for ; Tue, 3 Apr 2012 07:52:54 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7A0FF9400C8; Tue, 3 Apr 2012 16:52:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-19-822764337 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 16:52:46 +0200 Message-Id: <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> To: guoliang han X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:52:57 -0000 --Apple-Mail-19-822764337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-04-03 =C3=A0 15:41, Guoliang a =C3=A9crit : > Hi, Remi: > =20 > Pls read my comments below. >=20 > 2012/4/3 R=C3=A9mi Despr=C3=A9s >=20 > Le 2012-04-03 =C3=A0 14:43, guoliang han a =C3=A9crit : >=20 >> Hi, Remi: >> =20 >> I don't think my case illustrates MAP-T needs to remain experimental, = my comments are below: >> =20 >> =20 >> 2012/4/3 R=C3=A9mi Despr=C3=A9s >> Hi, Guoliang, >>=20 >> Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution. >>=20 >> 1. >> RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. >> =20 >> =20 >> RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is that = "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can = be administered in compliance with Section 4.3.1 of [RFC4890]", the = second approach is to change PTB MTU value to 1280 in case PTB<1280 and = set DF bit to 0 in case the packet is less than or equal to 1280 bytes, = if the requirements of the first approach can't be met. It doesn't mean = the administrator can refuse to take the second approach according to = his will.=20 >> =20 >>=20 >> 2. >> With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to work. >> =20 >> Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could traverse current IPv6 firewalls = successfully. >=20 > Typical use cases of 4rd-U have no firewall between BRs and CEs. > If some would exist, they should be configured to let ICMPv4 payloads = go through (Protocol =3D 1) > This is like configuring them to accept IPv4 headers in IPv6 payloads = (Protocol =3D 4) > =20 > Hope so. Still anticipating experimental results proving that yet. > =20 >=20 >=20 >> 3. >> Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T. >> =20 >> See Section 6 of RFC6145. >=20 > This isn't in RFC6145, simply a reference to (*) below. > If I misunderstood, please explain what. > =20 > You surely misunderstood that. I mentioned "in that case", instead of = replacing DF=3D1 by DF=3D0 in all cases. Replacing DF bit only occurs in = the case that incoming packet size is less that 1280 bytes, which is = exactly the requirement of RFC6145. The so called "corner case" where RFC6145 looses the DF=3D1 is when a = packet with DF=3D1 is already fragmented by its source.=20 In this case, because there are several fragments, translates back to = IPv4 with DF=3D0. In the example you give, RFC6145 doesn't add a fragment header, in the = IPv4 to IPv6 translation because the packet has DF=3D1 and isn't = fragmented (sec 4). The inverse translation, seeing no fragment header, the DF bit is = normally set to 1 (sec 5.1). (A configuration option is mentioned so = that the node MAY set it to 0 in some conditions, but MAP-T makes clear = this must not be the case: "the IPv4 packets with DF=3D1 will be = translated to IPv6 packets without fragmentation header and will be = translated back to IPv4 packets with DF=3D1".) >> When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. >>=20 >>=20 >> In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. >> =20 >> Regards, >> RD >> =20 >> In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 carefully. >=20 > Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided for = IPv4 PMTU discovery to work. > Still waiting for a clarification on this issue. > =20 > If the translator set DF bit to 0 in case the packet is less than or = equal to 1280 bytes, and replace PTB<1280 by PTB=3D1280, there are no = problems on the data path, whether in single/double translation.=20 In any case, not a MAP-T feature. RD > =20 > Regards, > Guoliang > =20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 >> =20 >> regards, >> Guoliang >> =20 >> =20 >>=20 >>=20 >> Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = : >>=20 >>> +1. >>> =20 >>> As a follower of MAP team, I participated much in developing and = deploying=20 >>> double-translation in CERNET. As far as I am concerned, in the = translation scenario, >>> 4rd-U only solved some corner cases but missed some other cases = simultaneously. >>> =20 >>> As an example, I suppose one fragmentation case as following: >>> =20 >>> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host >>> =20 >>> The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4=20 >>> network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 >>> with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 >>> could traverse the IPv6 access network, but will be blocked in the = IPv4 network.=20 >=20 > (*) >=20 >>> In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, >>> instead of preserving the original IPv4 DF bit. >=20 >=20 >>> =20 >>> In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet=20 >>> whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve >>> the DF bit, the sender will always believe the path MTU is 1280, = which will certainly lead to=20 >>> a black hole. >>> =20 >>> This is only one deployment problem, and we don't know how many = issues will be encountered >>> in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 >>> it's a bit early to propose it as an Informational/Standards Track = Document. >>> =20 >>> The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 >>> =20 >>> regards,=20 >>> Guoliang >>=20 >=20 --Apple-Mail-19-822764337 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, Remi:
 
Pls read my comments below.

2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>

Le 2012-04-03 =C3=A0 14:43, guoliang han a =C3=A9crit :

Hi, Remi:
 
I don't think my case illustrates MAP-T needs to remain = experimental, my comments are below:
 
 
2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T = needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280.= It specifies two behaviors, one that does this, and one that doesn't. = Which one to choose isn't AFAIK specified in the MAP-T draft.
 
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach = is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network = firewalls can be administered in compliance with Section 4.3.1 of = [RFC4890]", the second approach is to change PTB MTU value to 1280 in = case PTB<1280 and set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, if the requirements of the first = approach can't be met. It doesn't mean the administrator can refuse = to take the second approach according to his will. 
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to = work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could  traverse current IPv6 firewalls = successfully.

Typical use cases of 4rd-U have no firewall between BRs = and CEs.
If some would exist, they should be configured to let ICMPv4 = payloads go through (Protocol =3D 1)
This is like configuring them to accept IPv4 headers in IPv6 = payloads (Protocol =3D 4)
 
Hope so. Still anticipating experimental results proving that = yet.
 


3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T.
 
See Section 6 of RFC6145.

This isn't in RFC6145, simply a reference to (*) = below.
If I misunderstood, please explain what.
 
You surely misunderstood that. I mentioned "in that = case", instead of replacing DF=3D1 by DF=3D0 in all cases. = Replacing DF bit only occurs in the case that incoming packet size = is less that 1280 bytes, which is exactly the requirement of = RFC6145.

The so called = "corner case" where RFC6145 looses the DF=3D1 is when a packet with DF=3D1= is already fragmented by its source. 
In this case, = because there are several fragments, translates back to IPv4 with = DF=3D0.

In the example you give, RFC6145 = doesn't add a fragment header, in the IPv4 to IPv6 translation because = the packet has DF=3D1 and isn't fragmented (sec 4).
The = inverse translation, seeing no fragment header, the DF bit is normally = set to 1 (sec 5.1). (A configuration option is mentioned so that the = node MAY set it to 0 in some conditions, but MAP-T makes clear this must = not be the case: "the IPv4 packets with DF=3D1 will be translated to = IPv6 packets without fragmentation header and will be translated back to = IPv4 packets with DF=3D1".)


When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments.
   
    Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 carefully.

Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 = should AFAIK be avoided for IPv4 PMTU discovery to work.
Still waiting for a clarification on this = issue.
 
If the translator set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, and replace PTB<1280 by PTB=3D1280, = there are no problems on the data path, whether in single/double = translation. 

In any = case, not a MAP-T = feature.

RD


 
Regards,
Guoliang
 

Regards,
RD




 
regards,
Guoliang
 
 


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network. =

(*)=20

In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4,
instead of preserving the original IPv4 DF = bit.


 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang
=

<= /div>

= --Apple-Mail-19-822764337-- From jan@go6.si Tue Apr 3 08:14:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B7C11E80BD for ; Tue, 3 Apr 2012 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDqC++DRjp6L for ; Tue, 3 Apr 2012 08:14:29 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156411E80BE for ; Tue, 3 Apr 2012 08:14:29 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2a00:ee0:3:4a00:51c6:31b:3c6d:a173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id AB2BD22BC002 for ; Tue, 3 Apr 2012 17:14:24 +0200 (CEST) Message-ID: <4F7B13D1.9040702@go6.si> Date: Tue, 03 Apr 2012 17:14:25 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> In-Reply-To: <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:14:30 -0000 Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) From repenno@cisco.com Tue Apr 3 08:14:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B008011E80CB for ; Tue, 3 Apr 2012 08:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEIfI4ebi80Y for ; Tue, 3 Apr 2012 08:14:43 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C737411E80A2 for ; Tue, 3 Apr 2012 08:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=7194; q=dns/txt; s=iport; t=1333466083; x=1334675683; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=KL3u3kzPa88FBXIno/hPWxjGoWTJW5/FhId0kQWwnes=; b=Zncn07CahRObepC7Hdt1mtI0+1H7+u8hvlkZMJgVePrwx3/YRfpyovoC a3CMpIGv8etTimpPaqacS1Ekxg4JI/xQu3CTf76oKc/+fzxEhdgdobKu6 qIr/5iUwFoBvTZDe3+BmVRVfT63wKXazFy/z0hOShPV+L7TtLgVRUm49B M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAHADwTe0+rRDoH/2dsb2JhbABCglNLs3R5gQeCCQECBBIBKjwTCBEDAQJQKwMIBg4FIodmoAGXIooOhlgEiFiNC4VwhUODFIFpgwc X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208,217";a="35745797" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 03 Apr 2012 15:14:43 +0000 Received: from [10.21.74.92] ([10.21.74.92]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33FEdoA003541; Tue, 3 Apr 2012 15:14:42 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 03 Apr 2012 08:14:39 -0700 From: Reinaldo Penno To: Maoke Message-ID: Thread-Topic: [Softwires] Path to move forward with =?ISO-8859-2?B?NHJkqQ==?= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3416285683_26805284" Cc: softwires@ietf.org Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:14:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416285683_26805284 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable From: Maoke Date: Tue, 3 Apr 2012 11:23:46 +0000 To: Cisco Employee Cc: "Jan Zorz @ go6.si" , Subject: Re: [Softwires] Path to move forward with 4rd=A9 hi Reinaldo, well, you pointed me as the first receiver. AFAIK, everyone participating Beijing interim has viewed the prototype (if you rejected to call that as a product) of MAP-T which is running over a production network= . it was surely not IVI, and some important test data has been presented in IETF meetings. [Reinaldo] I was not at the Interim meeting Can you point to the test data so we can put this issue to rest? others may add information in response to your request but i don't think they are obliged to do so here, in this thread, considering 4rd-u hasn't have no even prototype yet. [Reinaldo] humm....So, basically you are saying that since 4rd-U has no prototype, others are not obliged to show their goods either. I thought it would be the other way around, I.e., go for the finish line: Let's push fo= r rough consensus and running code, put the issue to rest and get MAP adopted. =20 regarding your second question, MHO, IVI that supported by RFC6052 address mapping has different address plan with the MAP domain (you may be also interested in reading draft-mdt-softwire-map-deployment and RFC6219). they have different use cases in deployment. there is no question about transition from IVI to MAP-T, to my understanding. i may agree if you mean the existing RFCs related to IVI are still not enough to provide an informational guideline for people who would like to deploy it. [Reinaldo] Certainly. thanks,=20 maoke 2012/4/3 Reinaldo Penno > Hello, >=20 > I was not part of the design team and maybe my question was already answe= red > in some design team ML. >=20 > Is there a document describing where MAP-T was tested, which products, > operators, test timespan, test plan, was it production network, etc? >=20 > And btw, I'm not talking about IVI or the part of MAP-T that is compatibl= e > with IVI. Sorry, but If I will back MAP-T I would like to see MAP-T data,= not > a look alike. I guess this brings another question whether there is a pl= an to > write a document to for those that have deployed IVI and want to transiti= on to > MAP-T.=20 >=20 > Thanks, >=20 > Reinaldo --B_3416285683_26805284 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable


From: Maoke <fibrib@gmail.com>
Date: Tue, 3 Apr 2012 11:23:46 +0000
To: Cisco Employee <repenno@cisco.com= >
Cc: "Jan Zorz @ go6.si" &= lt;jan@go6.si>, <softwires@ietf.org>
= Subject: Re: [Softwires] Path to move forward with 4rd=A9

hi Reinaldo,

well, you pointed me = as the first receiver. AFAIK, everyone
participating Beiji= ng interim has viewed the prototype (if you rejected to call that as a produ= ct) of MAP-T which is running over a production network. it was surely not I= VI, and some important test data has been presented in IETF meetings.
<= div>
[Reinaldo]  I was not at the Interim meeting Can you= point to the test data so we can put this issue to rest? 
others may add information in r= esponse to your request but i don't think they are obliged to do so here, in= this thread, considering 4rd-u hasn't have no even prototype yet. 

[Reinaldo] humm….So, basically you are sa= ying that since 4rd-U has no prototype, others are not obliged to show their= goods either.  I thought it would be the other way around, I.e.,  = ;go for the finish line: Let's push for rough consensus and running code, &n= bsp;put the issue to rest and get MAP adopted.  

regarding your second question, MHO, IVI = that supported by RFC6052 address mapping has different address plan with th= e MAP domain (you may be also interested in reading draft-mdt-softwire-map-d= eployment and RFC6219). they have different use cases in deployment. there i= s no question about transition from IVI to MAP-T, to my understanding. i may= agree if you mean the existing RFCs related to IVI are still not enough to = provide an informational guideline for people who would like to deploy it.&n= bsp;

[Reinaldo] Certainly. 

thanks, 
maoke<= /div>
2012/4/3 Reinaldo Penno &l= t;repenno@cisco.com>
Hello,

=
I was not part of the design team and maybe my question was already ans= wered in some design team ML.

Is there a document d= escribing where MAP-T was tested,  which products, operators, test time= span,  test plan,  was it production network,  etc? 

And btw, I'm not talking about IVI or the part of MAP-= T that is compatible with IVI. Sorry, but If I will back MAP-T I would like = to see MAP-T data, not a look alike.  I guess this brings another quest= ion whether there is a plan to write a document to for those that have deplo= yed IVI and want to transition to MAP-T. 

Than= ks,

Reinaldo

--B_3416285683_26805284-- From Tetsuya.Murakami@ipinfusion.com Tue Apr 3 09:31:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F8711E8152 for ; Tue, 3 Apr 2012 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGrPeren5VUk for ; Tue, 3 Apr 2012 09:31:28 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id BEEAD11E8143 for ; Tue, 3 Apr 2012 09:31:27 -0700 (PDT) Received: from mail86-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 3 Apr 2012 16:31:26 +0000 Received: from mail86-am1 (localhost [127.0.0.1]) by mail86-am1-R.bigfish.com (Postfix) with ESMTP id 524854000C6; Tue, 3 Apr 2012 16:31:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail86-am1: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail86-am1 (localhost.localdomain [127.0.0.1]) by mail86-am1 (MessageSwitch) id 1333470685129823_8689; Tue, 3 Apr 2012 16:31:25 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.237]) by mail86-am1.bigfish.com (Postfix) with ESMTP id 9EC86220073; Tue, 3 Apr 2012 16:31:24 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 3 Apr 2012 16:31:22 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.250]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0135.002; Tue, 3 Apr 2012 16:31:21 +0000 From: Tetsuya Murakami To: =?Windows-1252?Q?R=E9mi_Despr=E9s?= Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=85_4rd-U_as_tr?= =?Windows-1252?Q?ansparent_as_MAP-E?= Thread-Index: AQHNEXk5RMlbmLH7I0CXiJsf3rkUaJaJS3WA Date: Tue, 3 Apr 2012 16:31:21 +0000 Message-ID: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <865CD94FB3788D468FB97B54DEA726DB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT003.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT003.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: Softwires-wg WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:31:28 -0000 Hi Remi, >> Do we need them to be sure in spite of we already have existing mature t= ransport variants? >=20 > MAP-E+T isn't as mature as repeatedly claimed. > MAP-T may be more imprecise than MAP-E in this respect, but both have kno= wn bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and= BR hairpinning in MAP-E). If you pointed out bugs in the text of MAP-E/MAP-T drafts, we will correct = it soon. But what you pointed out in the above has been already tested with= our implementation of MAP-T/MAP-E. So, our MAP-E/MAP-T implementation has = already supported BR hairpinning (hub&spoke model). Thanks, Tetsuya Murakami= From marc.blanchet@viagenie.ca Tue Apr 3 10:03:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91221F85F7 for ; Tue, 3 Apr 2012 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ0HrVGXKpCF for ; Tue, 3 Apr 2012 10:03:27 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED221F85B8 for ; Tue, 3 Apr 2012 10:03:26 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id B32F21C24C for ; Tue, 3 Apr 2012 13:03:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Marc Blanchet In-Reply-To: <4F7B13D1.9040702@go6.si> Date: Tue, 3 Apr 2012 12:32:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> To: softwires@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:03:28 -0000 I don't see a way out of this thread.=20 my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. Above all, I think having a stable specification (i.e. RFC) that = implementers can code against and providers to require is what is = needed first.=20 Marc. Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : > Dear Softwires WG chairs. >=20 > For how long will you leave this useless cockfight go on instead of = steering the working group into a direction, that may enable us to = decide on something and chose the direction? >=20 > We are running in circles here and just amplificating the noise, = coming from certain usual suspects. >=20 > Cheers, Jan >=20 > P.S: I too enjoy observing the roosters fight, but I don't think we = have time for this now. :) > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Tue Apr 3 11:56:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D740321F859F for ; Tue, 3 Apr 2012 11:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilY7tiO7DR2Z for ; Tue, 3 Apr 2012 11:56:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C85E621F858F for ; Tue, 3 Apr 2012 11:56:46 -0700 (PDT) Received: by qcsq13 with SMTP id q13so17029qcs.31 for ; Tue, 03 Apr 2012 11:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9znCihzY12MFBtkAXptwTAY+aRnshHGaK7smdvgs59I=; b=ufMsSEJvm08R5OCifsjABXqxnKTrvcbizIVlraPCPlP8QOyI6Yc19JMkvHzMy6UZoU 1XW818Gydk4gTGWgqfokiBpFYoAV7h/UGyNUart9UHBuxw5k+3UTUTD7/iifDrF8J7+w HN/TeNuHwQFIjMzgPp0LL5N+T8i1EcMOFauLce8sINdCvsVXxF2ke3cjZAHoO3BrxuQn vMUFhynjl+DxntNBh8HKqDCdDJoEwsCboTTn4gGZ/f5krDLy99uoIo3bTBOE0uh7hc1P mvcQI8gFW52XzmJIulluaQWUE3360i5A075eqfnsf+IO+miN/gLlEGG1WkzgU28huJpL C9Ew== MIME-Version: 1.0 Received: by 10.229.136.17 with SMTP id p17mr5522670qct.151.1333479406054; Tue, 03 Apr 2012 11:56:46 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 3 Apr 2012 11:56:45 -0700 (PDT) In-Reply-To: <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> Date: Tue, 3 Apr 2012 20:56:45 +0200 Message-ID: From: Wojciech Dec To: Marc Blanchet Content-Type: multipart/alternative; boundary=00248c70f9f1502e3a04bccadee9 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 18:56:48 -0000 --00248c70f9f1502e3a04bccadee9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The irony is that this is an apples and oranges comparison, and throwing away ripe apples into some box with raw oranges looks rather unfair. Some of the of the indicators are: - MAP is not only the result of a consensus of a broad WG design team, but also that of numerous authors of the merged drafts whihc have been discussed for 1 year+. The 4rd-u technical proposals were evaluated by the design team, and have not gained support there. - MAP running code exist - 4rd-U covers a technical corner case that is "self created" (if not self invented/motivated) - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means "universal". As admitted it requires the coupling with BIH, which features the same technical corner case that 4rd-u claims to solve (doh). The other aspect is that some different measure appears to be being applied in this selection *for WG adoption* vs the selection of the other drafts in softwire, which have gained WG draft status without even a shred of running code. -Woj. On 3 April 2012 18:32, Marc Blanchet wrote: > I don't see a way out of this thread. > > my suggestion: > - published both as experimental > - let the market decide > - come back later to move one or the other standard track. > > Above all, I think having a stable specification (i.e. RFC) that > implementers can code against and providers to require is what is needed > first. > > Marc. > > Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : > > > Dear Softwires WG chairs. > > > > For how long will you leave this useless cockfight go on instead of > steering the working group into a direction, that may enable us to decide > on something and chose the direction? > > > > We are running in circles here and just amplificating the noise, coming > from certain usual suspects. > > > > Cheers, Jan > > > > P.S: I too enjoy observing the roosters fight, but I don't think we hav= e > time for this now. :) > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00248c70f9f1502e3a04bccadee9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The irony is that this is an apples and oranges comparison, and throwing aw= ay ripe apples into some box with raw oranges looks rather unfair.

S= ome of the of the indicators are:
- MAP is not only the result of a cons= ensus of a broad WG design team, but also that of numerous authors of the m= erged drafts whihc have been discussed for 1 year+. The 4rd-u technical pro= posals were evaluated by the design team, and have not gained support there= .
- MAP running code exist
- 4rd-U covers a technical corner case that is = "self created" (if not self invented/motivated)
- 4rd-U does n= ot allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means "universal". As admitted it requires = the coupling with BIH, which features the same technical corner case that 4= rd-u claims to solve (doh).

The other aspect is that some different = measure appears to be being applied in this selection *for WG adoption* vs = the selection of the other drafts in softwire, which have gained WG draft s= tatus without even a shred of running code.

-Woj.

On 3 April 2012 18:32, Marc Bla= nchet <ma= rc.blanchet@viagenie.ca> wrote:
I don't see a way out of this thread.

my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.

Above all, I think having a stable specification (i.e. RFC) that implemente= rs can code against =A0and providers to require is what is needed first.
Marc.

Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit :

> Dear Softwires WG chairs.
>
> For how long will you leave this useless cockfight go on instead of st= eering the working group into a direction, that may enable us to decide on = something and chose the direction?
>
> We are running in circles here and just amplificating the noise, comin= g from certain usual suspects.
>
> Cheers, Jan
>
> P.S: I too enjoy observing the roosters fight, but I don't think w= e have time for this now. :)
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00248c70f9f1502e3a04bccadee9-- From marc.blanchet@viagenie.ca Tue Apr 3 13:07:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1296911E8192 for ; Tue, 3 Apr 2012 13:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNQBYn+7lezC for ; Tue, 3 Apr 2012 13:07:11 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id F21ED11E8111 for ; Tue, 3 Apr 2012 13:07:10 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id CDDFA1C24B; Tue, 3 Apr 2012 16:07:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_7E430A9C-6E24-4964-B02C-DFB324EE6906" From: Marc Blanchet In-Reply-To: Date: Tue, 3 Apr 2012 16:07:08 -0400 Message-Id: <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> To: Wojciech Dec X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:07:12 -0000 --Apple-Mail=_7E430A9C-6E24-4964-B02C-DFB324EE6906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 well, let's see the other way around: what is the problem of publishing = the two documents now?So that they are stable and have a RFC number. = Then any implementer can implement based on the RFC. Providers can = request their manufacturers to have a product which conforms to the RFC. Marc. Le 2012-04-03 =E0 14:56, Wojciech Dec a =E9crit : > The irony is that this is an apples and oranges comparison, and = throwing away ripe apples into some box with raw oranges looks rather = unfair. >=20 > Some of the of the indicators are: > - MAP is not only the result of a consensus of a broad WG design team, = but also that of numerous authors of the merged drafts whihc have been = discussed for 1 year+. The 4rd-u technical proposals were evaluated by = the design team, and have not gained support there. > - MAP running code exist > - 4rd-U covers a technical corner case that is "self created" (if not = self invented/motivated) > - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 = sign-up portal, etc) > - 4rd-U is not by any means "universal". As admitted it requires the = coupling with BIH, which features the same technical corner case that = 4rd-u claims to solve (doh). >=20 > The other aspect is that some different measure appears to be being = applied in this selection *for WG adoption* vs the selection of the = other drafts in softwire, which have gained WG draft status without even = a shred of running code. >=20 > -Woj. >=20 > On 3 April 2012 18:32, Marc Blanchet = wrote: > I don't see a way out of this thread. >=20 > my suggestion: > - published both as experimental > - let the market decide > - come back later to move one or the other standard track. >=20 > Above all, I think having a stable specification (i.e. RFC) that = implementers can code against and providers to require is what is = needed first. >=20 > Marc. >=20 > Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : >=20 > > Dear Softwires WG chairs. > > > > For how long will you leave this useless cockfight go on instead of = steering the working group into a direction, that may enable us to = decide on something and chose the direction? > > > > We are running in circles here and just amplificating the noise, = coming from certain usual suspects. > > > > Cheers, Jan > > > > P.S: I too enjoy observing the roosters fight, but I don't think we = have time for this now. :) > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail=_7E430A9C-6E24-4964-B02C-DFB324EE6906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 well, = let's see the other way around: what is the problem of publishing the = two documents now?So that they are stable and have a RFC number. Then = any implementer can implement based on the RFC. Providers can request = their manufacturers to have a product which conforms to the = RFC.

Marc.

Le = 2012-04-03 =E0 14:56, Wojciech Dec a =E9crit :

The irony = is that this is an apples and oranges comparison, and throwing away ripe = apples into some box with raw oranges looks rather unfair.

Some = of the of the indicators are:
- MAP is not only the result of a = consensus of a broad WG design team, but also that of numerous authors = of the merged drafts whihc have been discussed for 1 year+. The 4rd-u = technical proposals were evaluated by the design team, and have not = gained support there.
- MAP running code exist
- 4rd-U covers a technical corner case that = is "self created" (if not self invented/motivated)
- 4rd-U does not = allow v4-v6 communication (say a v4 host to a v6 sign-up portal, = etc)
- 4rd-U is not by any means "universal". As admitted it requires the = coupling with BIH, which features the same technical corner case that = 4rd-u claims to solve (doh).

The other aspect is that some = different measure appears to be being applied in this selection *for WG = adoption* vs the selection of the other drafts in softwire, which have = gained WG draft status without even a shred of running code.

-Woj.

On 3 April 2012 18:32, Marc = Blanchet <marc.blanchet@viagenie.ca>= ; wrote:
I don't see a way out of this thread.

my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.

Above all, I think having a stable specification (i.e. RFC) that = implementers can code against  and providers to require is what is = needed first.

Marc.

Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit :

> Dear Softwires WG chairs.
>
> For how long will you leave this useless cockfight go on instead of = steering the working group into a direction, that may enable us to = decide on something and chose the direction?
>
> We are running in circles here and just amplificating the noise, = coming from certain usual suspects.
>
> Cheers, Jan
>
> P.S: I too enjoy observing the roosters fight, but I don't think we = have time for this now. :)
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail=_7E430A9C-6E24-4964-B02C-DFB324EE6906-- From tom.taylor.stds@gmail.com Tue Apr 3 18:22:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1C11E80E8 for ; Tue, 3 Apr 2012 18:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veehWOm9tM6T for ; Tue, 3 Apr 2012 18:22:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8565211E8075 for ; Tue, 3 Apr 2012 18:22:49 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so245096vbb.31 for ; Tue, 03 Apr 2012 18:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=043tRI7obPjNTMRDkaStSdSe4YnIFtr7Dzp3wq7hEPE=; b=OPNd2AqpcuRIE+XrCWToSmGzvoHXBz0nlFID//hYLjBJmhoid50ytzB4MrdVFtwaH2 tVnSf9ogU4hcWDKrDmUfNvxxGwu87b+FXSHOD0vjQTXItcFiZPtH1p+DqrcLW+PvYjJV lVkSZtUxpqb6Zi54iyZYcNHqU+D+SbrgPv7ijzax3Ys4vSarxbU4EqkzXqsCUYd+vvRW 9r//r4ka4qXFRCSxNTNtLHxAD1iDpcI5EX7xrDzCgNbxGI31mnunUuzVxvXOXRLUWSXj Bv4zQ6C+h74XNKiwxCDZWtxeCGS+zNuWLa33qrIsiU9lY/uTjSwcEaVDr61YQiETqmiS AJDw== Received: by 10.52.98.4 with SMTP id ee4mr5817500vdb.128.1333502568967; Tue, 03 Apr 2012 18:22:48 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id e4sm26369129vdh.10.2012.04.03.18.22.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 18:22:48 -0700 (PDT) Message-ID: <4F7BA265.7060001@gmail.com> Date: Tue, 03 Apr 2012 21:22:45 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120403-2, 03/04/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Relative support for MAP vs. 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 01:22:50 -0000 I have been advised privately by a couple of people that I erred in my description of relative support for MAP vs. 4rd-U at the meeting. Support for MAP was predominant, but not to the point of rough consensus. I was startled at the meeting by how much support 4rd-U got, given that Remi is the only one who defends it on the list. I guess that affected my judgement of the numbers -- it just looked like a room-full of hands, comparable to the showing for MAP. Sorry for the misdirection. Tom Taylor From fibrib@gmail.com Tue Apr 3 19:25:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAA11E80E8 for ; Tue, 3 Apr 2012 19:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJT+0ZEostva for ; Tue, 3 Apr 2012 19:25:15 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B26ED11E8072 for ; Tue, 3 Apr 2012 19:25:15 -0700 (PDT) Received: by qaea16 with SMTP id a16so70928qae.10 for ; Tue, 03 Apr 2012 19:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tbvvMvlasu/kMxNPyUMljrsAPitTDal5Rr1kKgkC5Q4=; b=cw1SyWxGwHejITJVi8WOBXfHcCUh6gbBEDFeqPWK4NPMEqrXzgZP8fBztz+/1qn3vM GrQf22FEPvSw5c62o+zSmaQHcpcSeeRPa+QjYUNICRO3+tM+senMuURojVLAUJUfoyNR WDlRca8/Zw7vyT99Iao41RXTxD0wUqtiWYIYDiEZ4Src2t5upp29nvnVakBE8q2viuIr GqqCtVS8GmSRoafItvDsrXqqKDQ904soOrRgnd2OSm+s7tbDWdh8VExWxANL+8U2YTqC aFfB94h1KCI8Rv9pmrJqzuMMwlhceOsJ/A01oma77x03UC5kF6BAFLnHhGyhmYo/zKJY 0mLw== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr20214042qao.23.1333506314855; Tue, 03 Apr 2012 19:25:14 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 19:25:14 -0700 (PDT) In-Reply-To: <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> Date: Wed, 4 Apr 2012 02:25:14 +0000 Message-ID: From: Maoke To: Marc Blanchet Content-Type: multipart/alternative; boundary=20cf3074b41a33e68204bcd122b9 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 02:25:17 -0000 --20cf3074b41a33e68204bcd122b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable well, i cannot help but send out this late Apr-1 joke: let's see what is the problem publishing the two document plus an informational doc analysing what problems 4rd-u introduces to architecture and real operation, with them all stable and having an RFC number for each? if this is fine, we all could be happy and the peace comes. lol a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers. - maoke ---- - we reject kings, presidents, and voting... - Rex redivit. vive le Roi. 2012/4/3 Marc Blanchet > well, let's see the other way around: what is the problem of publishing > the two documents now?So that they are stable and have a RFC number. Then > any implementer can implement based on the RFC. Providers can request the= ir > manufacturers to have a product which conforms to the RFC. > > Marc. > > Le 2012-04-03 =E0 14:56, Wojciech Dec a =E9crit : > > The irony is that this is an apples and oranges comparison, and throwing > away ripe apples into some box with raw oranges looks rather unfair. > > Some of the of the indicators are: > - MAP is not only the result of a consensus of a broad WG design team, bu= t > also that of numerous authors of the merged drafts whihc have been > discussed for 1 year+. The 4rd-u technical proposals were evaluated by th= e > design team, and have not gained support there. > - MAP running code exist > - 4rd-U covers a technical corner case that is "self created" (if not sel= f > invented/motivated) > - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up > portal, etc) > - 4rd-U is not by any means "universal". As admitted it requires the > coupling with BIH, which features the same technical corner case that 4rd= -u > claims to solve (doh). > > The other aspect is that some different measure appears to be being > applied in this selection *for WG adoption* vs the selection of the other > drafts in softwire, which have gained WG draft status without even a shre= d > of running code. > > -Woj. > > On 3 April 2012 18:32, Marc Blanchet wrote: > >> I don't see a way out of this thread. >> >> my suggestion: >> - published both as experimental >> - let the market decide >> - come back later to move one or the other standard track. >> >> Above all, I think having a stable specification (i.e. RFC) that >> implementers can code against and providers to require is what is neede= d >> first. >> >> Marc. >> >> Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : >> >> > Dear Softwires WG chairs. >> > >> > For how long will you leave this useless cockfight go on instead of >> steering the working group into a direction, that may enable us to decid= e >> on something and chose the direction? >> > >> > We are running in circles here and just amplificating the noise, comin= g >> from certain usual suspects. >> > >> > Cheers, Jan >> > >> > P.S: I too enjoy observing the roosters fight, but I don't think we >> have time for this now. :) >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf3074b41a33e68204bcd122b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
well, i cannot help but send out this late Apr-1 joke: let's see w= hat is the problem publishing the two document plus an informational doc an= alysing what problems 4rd-u introduces to architecture and real operation, = with them all stable and having an RFC number for each? if this is fine, we= all could be happy and the peace comes. lol

a serious point not of the Apr-1 joke: as an IETF= WG, we are obliged to provide surely high-quality document to the market. = even we believe market choice, at least we have to publish what we ourselve= s have well understood, carefully coded and well tested. otherwise, the mar= ket would see IETF more of a group of doc-makers rather than technology-exp= lorers.

- maoke=A0

----
- we= reject kings, presidents, and voting...
- Rex redivit. vive le R= oi.=A0

2012/4/3 Marc Blanchet <marc.blanchet@viagenie.ca>
well, le= t's see the other way around: what is the problem of publishing the two= documents now?So that they are stable and have a RFC number. Then any impl= ementer can implement based on the RFC. Providers can request their manufac= turers to have a product which conforms to the RFC.

Marc.

Le 2012-04-03 =E0 1= 4:56, Wojciech Dec a =E9crit :

The irony is that this is an apples and oranges comparison, and throwing a= way ripe apples into some box with raw oranges looks rather unfair.

Some of the of the indicators are:
- MAP is not only the result of a= consensus of a broad WG design team, but also that of numerous authors of = the merged drafts whihc have been discussed for 1 year+. The 4rd-u technica= l proposals were evaluated by the design team, and have not gained support = there.
- MAP running code exist
- 4rd-U covers a technical corner case that is = "self created" (if not self invented/motivated)
- 4rd-U does n= ot allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means "universal". As admitted it requires = the coupling with BIH, which features the same technical corner case that 4= rd-u claims to solve (doh).

The other aspect is that some different = measure appears to be being applied in this selection *for WG adoption* vs = the selection of the other drafts in softwire, which have gained WG draft s= tatus without even a shred of running code.

-Woj.

On 3 April 2012 18:32, Marc Bla= nchet <marc.blanchet@viagenie.ca> wrote:
I don't see a way out of this thread.

my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.

Above all, I think having a stable specification (i.e. RFC) that implemente= rs can code against =A0and providers to require is what is needed first.
Marc.

Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit :

> Dear Softwires WG chairs.
>
> For how long will you leave this useless cockfight go on instead of st= eering the working group into a direction, that may enable us to decide on = something and chose the direction?
>
> We are running in circles here and just amplificating the noise, comin= g from certain usual suspects.
>
> Cheers, Jan
>
> P.S: I too enjoy observing the roosters fight, but I don't think w= e have time for this now. :)
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



________________________= _______________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


--20cf3074b41a33e68204bcd122b9-- From cx.cernet@gmail.com Tue Apr 3 19:35:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120421F856A for ; Tue, 3 Apr 2012 19:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpKY6Dj3jsfL for ; Tue, 3 Apr 2012 19:35:21 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 343D421F8568 for ; Tue, 3 Apr 2012 19:35:21 -0700 (PDT) Received: by werb10 with SMTP id b10so236262wer.31 for ; Tue, 03 Apr 2012 19:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GybyKe/EtOla8ynmTak5yApCUF7GPTbco26AdDxwYlM=; b=IA01SRzsumfRQH+pAC/WNE363BmIMNJlgqL1J6cX/UqEyPRqfnziAEx6pmAVbG3/01 05pAeLvdrqauYTKK/NBc9x00DwQfSgUAgPD4Y8ZW6EwbLbZA3PL0uXlEMVNQbDsBRmY0 jJDnUNVnu1ZxZNM4K/spo+errLirxZUX4wQtwHDGD+8/4Ed7TrBgj2y8Lv/pFoLZBovX uJmCu9cqlVJpYUACErTMGydZgzl3Em7yw8CSNMaxV5BLGC2VcoGmlTNlIGl9TsxI+8ER 6AxBzm/b79w07IHvKBHiTc/0L9nsV/1T2T8dGXqQEQUuH4xY7Y21q3zHkXnhqHF3kiGZ qZ+A== MIME-Version: 1.0 Received: by 10.180.107.104 with SMTP id hb8mr1044496wib.8.1333506920445; Tue, 03 Apr 2012 19:35:20 -0700 (PDT) Received: by 10.216.19.85 with HTTP; Tue, 3 Apr 2012 19:35:20 -0700 (PDT) In-Reply-To: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> Date: Wed, 4 Apr 2012 10:35:20 +0800 Message-ID: From: Congxiao Bao To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 02:35:22 -0000 Hi Remi, 2012/4/2 R=E9mi Despr=E9s > > Hi, Congxiao, > > During the Softwire meeting, you came to the mike to assert that the 4rd-= U specification was known to have "flaws". > > Yes, I said that and I insist on saying that again today. > > > > > Yet, you do know that the 4rd-U specification has been reviewed by compet= ent contributors of widely varied origin, with no identified flaw left in t= he draft. That's NOT true. What I can see in the mailing-list before and after WG meeting is that many points which indicated that 4rd-U are flawed have been raised by the MAP-E/T authors and DT members, like Maoke, etc, and several operators. I am sorry to say that even though they repeated the same arguments several times, you ignored their statements and said there is no identified flaw left. I have to say this makes the discussion in the mailing-list without efficiency, even the conclusion is OBVIOUSLY clear. > > > Since you have AFAIK made no previous contribution on the mailing list to= justify such an assertion, would you be kind enough to explain what, in yo= ur understanding, wouldn't work in 4rd-U? For my perspective, 4rd-U is not on the same level compared with MAP for the technical maturity if we freeze the current version of MAP Series and 4rd-U. The MAP series are the extensions of existing RFCs and have well tested running codes, while 4rd-U redefined things in existing RFCs and have not been tested. Per your request, I can summarize my check list here, some have been already shown in the mailing-list, hopefully I don=92t need to repeat the same arguments again in the future: (1) 4rd-u tries to replace MAP-E, however, 4rd-u cannot support IPv4 option. In the case when perfect IPv4 transparency is required, MAP-E cannot be avoided. (2) 4rd-u tries to replace Map-T, however, 4rd-u is not compatible with IPv4/IPv6 single translation. For the networks which also deploy single translation, MAP-T cannot be avoided. For example, the web caching in the IPv6 only network between BR and CEs requires single translation mechanism, which 4rd-u cannot support. Don=92t mention BIH, if you want to combine BIH, 4rd-U is not the Unified solution as you claimed. (3) 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) and IPv6 address architecture (u/g-bits), the later conflicts with RFC4291. These are the fundamental changes, which needs the proof from 6man. The experimental data should also be presented to show this design is not harmful. (4) If 4rd-u becomes the standard, then there will be new defined =93IPv6.1=94 packets on the Internet (new meaning of u/g-bits, new defined fragmentation header, new type of ICMPv6, etc, more details in (6) and (8)), and no existing IPv6 devices can understand those packets. (5) 4rd-u is designed to achieve better transparency compared to MAP-T, however, it only addresses a corner case (DF=3D1 and MF=3D1) and the experimental data indicates that there is only 10e-5% of such packets and those packets are not representing normal traffic. The experimental data of 4rd-u deployment should be presented to show that your redefinition of (3) and the risk of (4), is worth bringing the benefit of just addressing to this corner case (DF=3D1 and MF=3D1). I don't think the corner case can make significant difference to the user experience. Further more, can you give me the use case of that corner case? (6) In order to address corner case (DF=3D1 and MF=3D1), 4rd-u always inserts the IPv6 fragmentation header and overload the ID field (DF, TTL, TOS). The IPv6 fragment header has been shown to cause operational difficulties in practice due to limited firewall fragmentation support. In addition, the packets with MF=3D0 and Offset=3D0 are "atomic fragments", this issues is under discussion in 6man and likely requires the OS and security updates (draft-gont-6man-ipv6-atomic-fragments-00). Furthermore, if an IPv6 packet, which contains fragmentation header and the ID has =93DF set by the definition of 4rd-U=94, reaches a 4rd-U end point, it will be translated to IPv4 packets with DF=3D1, and the DF transparency may be lost. The experimental data should be presented to show this design is not harmful. (7) 4rd-u tries to add checksum neutral hex in the address, however, it still cannot support new transport layer standard when NAT44 is used. (8) New types of ICMPv6 defined by 4rd-u needs the update of RFC4443. The existing IPv6 firewall cannot support it. (9) 4rd-u tries to reinvent the wheel by defining new schemes in IPv6, just for the IPv4 to IPv6 transition and only addresses corner cases. I wonder if this is worth the huge cost even the technical flaw could be removed. The lessons I learned in Behave and v6ops is that changing IPv6 architecutre which can only be used for the IPv4 to IPv6 transition is a bad idea and harmful. > > > Without that, your statement might be understood as an attempt at biasing= people's understanding just before a vote (which I suppose you didn't want= ). On the Friday=92s meeting, I just want to speak out my own option and I would like to say it again here: For a reasonable ISP, it pursues simple (single) solution for sure, but FIRST of ALL, that solution should be technically Correct. Considering both the previous discussion in the mailing-list (before the WG meeting) and on-site discussions before the open MIC, and the first run of concensus, I strongly believed that the rough consensus has been reached: MAP is superior to 4rd-U. Even for the second run of consensus, MAP still stands out (25 to 12). Please respect those audiences on site, who understand MAP series and 4rd-U, they raised their hands for MAP representing their neutral technique position, which of course can not be biased by me. Please also note that on the mailing list, many people present their comments, that sould wait more than the hands (without voices on the mailing list) in the meeting. Regards, Congxiao > > > Thanks, > RD > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From cx.cernet@gmail.com Tue Apr 3 21:04:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B10921F85D6 for ; Tue, 3 Apr 2012 21:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H6Lr1nc3i8e for ; Tue, 3 Apr 2012 21:04:07 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97E21F85D4 for ; Tue, 3 Apr 2012 21:04:07 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so102510wib.13 for ; Tue, 03 Apr 2012 21:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JTxxZKcy2CLgVuvdS7V76vnes9yzJkRMPFK2hxOMgPc=; b=XWjrEOrHpe3Uby+IU9Mgw6AeUSvG9sVsCN0v9sbijAtbbRR5dTQM2uCu46LczENHX3 FyH1DMi1FREGVW/qO80LbFZ0POSuY6yPn5qg9bLXWBJ/GtGrCzTCkzMl+yuSzxwG2v1b pZ+bB6SAfM8k4kHyRxxKE+E450b8MZMEoGwGJEWnv+uEXnDNw+fx8HZAdSse2HiC88ii gLo8eFOxNk1dyXqb/PZw01qOkReX9XnKTMC9YkZMU0jhTTCec/dH9pkfkSayzfRG0Fb+ V4AkfBwc2nrcA6lTseb6j4jvyeqV4wdlWSsZ0bgs7AGm8AdQbnp+1KdGXy0IJrb/RjJl ry9w== MIME-Version: 1.0 Received: by 10.180.89.9 with SMTP id bk9mr1473033wib.11.1333512246520; Tue, 03 Apr 2012 21:04:06 -0700 (PDT) Received: by 10.216.19.85 with HTTP; Tue, 3 Apr 2012 21:04:06 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> Date: Wed, 4 Apr 2012 12:04:06 +0800 Message-ID: From: Congxiao Bao To: Maoke Content-Type: multipart/alternative; boundary=f46d0444812dc1ecfc04bcd28375 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 04:04:09 -0000 --f46d0444812dc1ecfc04bcd28375 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fully agree with Maoke! This is not just the issue of publishing two documents.......To accormodate with 4rd-U, many existing RFCs should be updated, like RFC 4291,RFC6052,etc. There is no evidence to show that we need to do that because 4rd-U havn't been shown that it is workable in today's Internet. Congxiao 2012/4/4 Maoke > well, i cannot help but send out this late Apr-1 joke: let's see what is > the problem publishing the two document plus an informational doc analysi= ng > what problems 4rd-u introduces to architecture and real operation, with > them all stable and having an RFC number for each? if this is fine, we al= l > could be happy and the peace comes. lol > > a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to > provide surely high-quality document to the market. even we believe marke= t > choice, at least we have to publish what we ourselves have well understoo= d, > carefully coded and well tested. otherwise, the market would see IETF mor= e > of a group of doc-makers rather than technology-explorers. > > - maoke > > ---- > - we reject kings, presidents, and voting... > - Rex redivit. vive le Roi. > > 2012/4/3 Marc Blanchet > >> well, let's see the other way around: what is the problem of publishing >> the two documents now?So that they are stable and have a RFC number. The= n >> any implementer can implement based on the RFC. Providers can request th= eir >> manufacturers to have a product which conforms to the RFC. >> >> Marc. >> >> Le 2012-04-03 =E0 14:56, Wojciech Dec a =E9crit : >> >> The irony is that this is an apples and oranges comparison, and throwing >> away ripe apples into some box with raw oranges looks rather unfair. >> >> Some of the of the indicators are: >> - MAP is not only the result of a consensus of a broad WG design team, >> but also that of numerous authors of the merged drafts whihc have been >> discussed for 1 year+. The 4rd-u technical proposals were evaluated by t= he >> design team, and have not gained support there. >> - MAP running code exist >> - 4rd-U covers a technical corner case that is "self created" (if not >> self invented/motivated) >> - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-u= p >> portal, etc) >> - 4rd-U is not by any means "universal". As admitted it requires the >> coupling with BIH, which features the same technical corner case that 4r= d-u >> claims to solve (doh). >> >> The other aspect is that some different measure appears to be being >> applied in this selection *for WG adoption* vs the selection of the othe= r >> drafts in softwire, which have gained WG draft status without even a shr= ed >> of running code. >> >> -Woj. >> >> On 3 April 2012 18:32, Marc Blanchet wrote: >> >>> I don't see a way out of this thread. >>> >>> my suggestion: >>> - published both as experimental >>> - let the market decide >>> - come back later to move one or the other standard track. >>> >>> Above all, I think having a stable specification (i.e. RFC) that >>> implementers can code against and providers to require is what is need= ed >>> first. >>> >>> Marc. >>> >>> Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : >>> >>> > Dear Softwires WG chairs. >>> > >>> > For how long will you leave this useless cockfight go on instead of >>> steering the working group into a direction, that may enable us to deci= de >>> on something and chose the direction? >>> > >>> > We are running in circles here and just amplificating the noise, >>> coming from certain usual suspects. >>> > >>> > Cheers, Jan >>> > >>> > P.S: I too enjoy observing the roosters fight, but I don't think we >>> have time for this now. :) >>> > _______________________________________________ >>> > Softwires mailing list >>> > Softwires@ietf.org >>> > https://www.ietf.org/mailman/listinfo/softwires >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --f46d0444812dc1ecfc04bcd28375 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fully agree with Maoke!
=A0
This is not just the i= ssue of publishing two documents.......To accormodate with 4rd-U, many exis= ting RFCs should be updated, like RFC 4291,RFC6052,etc. There is no evidenc= e to show that we need to do that because 4rd-U havn't been shown that = it is workable in today's Internet.
=A0
Congxiao

2012/4/= 4 Maoke <fibrib@gm= ail.com>
well, i cannot help but send out this late Apr-1 joke: let's see w= hat is the problem publishing the two document plus an informational doc an= alysing what problems 4rd-u introduces to architecture and real operation, = with them all stable and having an RFC number for each? if this is fine, we= all could be happy and the peace comes. lol

a serious point not of the Apr-1 joke: as an IETF= WG, we are obliged to provide surely high-quality document to the market. = even we believe market choice, at least we have to publish what we ourselve= s have well understood, carefully coded and well tested. otherwise, the mar= ket would see IETF more of a group of doc-makers rather than technology-exp= lorers.

- maoke=A0

----
- we= reject kings, presidents, and voting...
- Rex redivit. vive le R= oi.=A0

2012/4/3 Marc Blanchet <marc.blanchet@viagenie.ca>
well, let's see th= e other way around: what is the problem of publishing the two documents now= ?So that they are stable and have a RFC number. Then any implementer can im= plement based on the RFC. Providers can request their manufacturers to have= a product which conforms to the RFC.

Marc.

Le 2012-04-03 =E0 1= 4:56, Wojciech Dec a =E9crit :

The irony is that this is an apples and oranges comparison, and throwing a= way ripe apples into some box with raw oranges looks rather unfair.

Some of the of the indicators are:
- MAP is not only the result of a= consensus of a broad WG design team, but also that of numerous authors of = the merged drafts whihc have been discussed for 1 year+. The 4rd-u technica= l proposals were evaluated by the design team, and have not gained support = there.
- MAP running code exist
- 4rd-U covers a technical corner case that is = "self created" (if not self invented/motivated)
- 4rd-U does n= ot allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means "universal". As admitted it requires = the coupling with BIH, which features the same technical corner case that 4= rd-u claims to solve (doh).

The other aspect is that some different = measure appears to be being applied in this selection *for WG adoption* vs = the selection of the other drafts in softwire, which have gained WG draft s= tatus without even a shred of running code.

-Woj.

On 3 April 2012 18:32, Marc Bla= nchet <marc.blanchet@viagenie.ca> wrote:
I don't see a way out of this thread.

my suggestion:
- published both as experimental
- let the market decide
- come back later to move one or the other standard track.

Above all, I think having a stable specification (i.e. RFC) that implemente= rs can code against =A0and providers to require is what is needed first.
Marc.

Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit :

> Dear Softwires WG chairs.
>
> For how long will you leave this useless cockfight go on instead of st= eering the working group into a direction, that may enable us to decide on = something and chose the direction?
>
> We are running in circles here and just amplificating the noise, comin= g from certain usual suspects.
>
> Cheers, Jan
>
> P.S: I too enjoy observing the roosters fight, but I don't think w= e have time for this now. :)
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



________________________= _______________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--f46d0444812dc1ecfc04bcd28375-- From fibrib@gmail.com Tue Apr 3 23:04:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9621F86BD for ; Tue, 3 Apr 2012 23:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCB9a54aSRPv for ; Tue, 3 Apr 2012 23:04:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2AE21F86B5 for ; Tue, 3 Apr 2012 23:04:52 -0700 (PDT) Received: by qcsq13 with SMTP id q13so327430qcs.31 for ; Tue, 03 Apr 2012 23:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m3kMVeypv1HeeWYntCQVcCMCiTA2F8mLA+YVRtkoSX8=; b=o1pcizG16F3D0rHN/8BQYFfiqxsToW81h6g5971aJYM1rvcu/PhbjRA+2eBGLeAf4R bxpAyCVo+0v0J+DNmihJ0CCfksB/oh0Xv/r6W+NXpJ325mjGyIKasK3cXm5QIILnNFlv WRbAK+98fI7Xs7Ndr/Zv7MACcVMCnoAlzO9hvh3yWHk6qQLmsSmbJQBSH1+ZN3I1gYvo ZFUe/RX+f8uNlwXSNCMVVthH+YvPpZDf+kwZytw8SXzzokfFSFhbZ30kueCv1Rw9pP68 GKIC0KCHm8w9440CsjTNu9J41VBms1o+JqS9rhwTND8AisLg38VlpGtwpkmIZxkMt2n5 Oe1w== MIME-Version: 1.0 Received: by 10.229.106.201 with SMTP id y9mr6086834qco.38.1333519492317; Tue, 03 Apr 2012 23:04:52 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 23:04:52 -0700 (PDT) In-Reply-To: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> Date: Wed, 4 Apr 2012 06:04:52 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235446fde8a4028004bcd433ee Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:04:54 -0000 --00235446fde8a4028004bcd433ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/4/2 R=E9mi Despr=E9s > Hi, Congxiao, > > During the Softwire meeting, you came to the mike to assert that the 4rd-= U > specification was known to have "flaws". > > Yet, you do know that the 4rd-U specification has been reviewed by > competent contributors of widely varied origin, with no identified flaw > left in the draft. > the "with no identified flaw left in the draft" is only your statement instead of the conclusion of the competent contributors. if the draft -06 or -07 limits the scope of 4rd-u with at least the following constrainsts, i guess it could be better with less flaws. - the domain having IPv6 firewalls or filters or IP/ICMP integrity varification mechanism between CE and BR is out of scope - the domain having IPv6 dynamic routing ttl-security mechanism is out of scope - simultaneously supporting single translation with using IPv4-mapped address for native IPv6-only networks/nodes is out of scope - supporting L4 protocol that not yet supported by NAT44 is out of scope (even for the case where NAT44 is bypassed, like 1:1 address mapping) - the IPv4 option transparency is out of scope, even for temporary end-to-end usage for some reason like experiments. were 4rd-u-06 updated with the above constraints, it is still have some technical inconsistency. i'd love to point them out when i have seen the scope clarification made by the authors. because the problem impact would change when the scope is changed. (well, it is another problem if people would like to have such a so-limited stuff) > Since you have AFAIK made no previous contribution on the mailing list to > justify such an assertion, would you be kind enough to explain what, in > your understanding, wouldn't work in 4rd-U? > > Without that, your statement might be understood as an attempt at biasing > people's understanding just before a vote (which I suppose you didn't wan= t). > one doesn't write too much in cockfighting mails !=3D he/she doesn't think, listen, and analyze. on the other hand, i understand the statement (no matter oral or written) in the venue is also considered as IETF contribution. do you think your statement on "no identified flaws left", ignoring the fact that competent contributors keep arguing, is not an attempt at biasing people's understanding in the venue? - maoke > > Thanks, > RD > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00235446fde8a4028004bcd433ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,=A0

2012/4/2 R=E9mi = Despr=E9s <despres.remi@laposte.net>
Hi, Congxiao,

During the Softwire meeting, you came to the mike to assert that the 4rd-U = specification was known to have "flaws".

Yet, you do know that the 4rd-U specification has been reviewed by competen= t contributors of widely varied origin, with no identified flaw left in the= draft.

the "with no identified fl= aw left in the draft" is only your statement instead of the conclusion= of the competent contributors.=A0

if the draft -06 or -07 limits the scope of 4rd-u with = at least the following constrainsts, i guess it could be better with less f= laws.=A0
- the domain having IPv6 firewalls or filters or IP/ICMP= integrity varification mechanism between CE and BR is out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is out= of scope=A0
- simultaneously supporting single translation with = using IPv4-mapped address for native IPv6-only networks/nodes is out of sco= pe
- supporting L4 protocol that not yet supported by NAT44 is out of sco= pe (even for the case where NAT44 is bypassed, like 1:1 address mapping)
- the IPv4 option transparency is out of scope, even for temporary = end-to-end usage for some reason like experiments.=A0

were 4rd-u-06 updated with the above constraints, it is= still have some technical inconsistency. i'd love to point them out wh= en i have seen the scope clarification made by the authors. because the pro= blem impact would change when the scope is changed. (well, it is another pr= oblem if people would like to have such a so-limited stuff)


Since you have AFAIK made no previous contribution on the mailing list to j= ustify such an assertion, would you be kind enough to explain what, in your= understanding, wouldn't work in 4rd-U?

Without that, your statement might be understood as an attempt at biasing p= eople's understanding just before a vote (which I suppose you didn'= t want).

one doesn't write too much= in cockfighting mails !=3D he/she doesn't think, listen, and analyze. = on the other hand, i understand the statement (no matter oral or written) i= n the venue is also considered as IETF contribution.

do you think your statement on "no identified flaw= s left", ignoring the fact that competent contributors keep arguing, i= s not an attempt at biasing people's understanding in the venue?=A0

- maoke=A0
=A0

Thanks,
RD

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00235446fde8a4028004bcd433ee-- From jan@go6.si Tue Apr 3 23:32:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9367321F86E1 for ; Tue, 3 Apr 2012 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbIptlccC-jp for ; Tue, 3 Apr 2012 23:32:03 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97C721F85F0 for ; Tue, 3 Apr 2012 23:32:02 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2a00:ee0:3:4a00:30a9:9a20:8b12:1410]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 5343222B4069 for ; Wed, 4 Apr 2012 08:31:58 +0200 (CEST) Message-ID: <4F7BEADF.5000806@go6.si> Date: Wed, 04 Apr 2012 08:31:59 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <4F7BA265.7060001@gmail.com> In-Reply-To: <4F7BA265.7060001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Relative support for MAP vs. 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:32:03 -0000 On 4/4/12 3:22 AM, Tom Taylor wrote: > I have been advised privately by a couple of people that I erred in my > description of relative support for MAP vs. 4rd-U at the meeting. > Support for MAP was predominant, but not to the point of rough consensus. > > I was startled at the meeting by how much support 4rd-U got, given that > Remi is the only one who defends it on the list. I guess that affected > my judgement of the numbers -- it just looked like a room-full of hands, > comparable to the showing for MAP. I'm with you - but what I was missing was the question "how many of you read all 3 drafts and understands them", followed by "those of you, who raised your hand, which one do you support". In this way we would probably easily find the way out. Room full of hands was political voting, I'm afraid. My question is, can we do it here, over mailinglist? :) Cheers, Jan From fibrib@gmail.com Tue Apr 3 23:48:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8AE21F85FD for ; Tue, 3 Apr 2012 23:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlU5HkUE600y for ; Tue, 3 Apr 2012 23:48:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 706A021F85F0 for ; Tue, 3 Apr 2012 23:48:28 -0700 (PDT) Received: by qcsq13 with SMTP id q13so344071qcs.31 for ; Tue, 03 Apr 2012 23:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+SWyZRQku/2XbfDIgzt/1yIADwxY0p0fJaJhgMWDd6I=; b=XvpFwb3WzPBF36NegYjpcICnj4Yo5hm9g7eMPo//3tXQZWrI/u2LgkG9ErL5wX9CSK fqyXCWY3BOuO9KVUkN1NMfdOMZE0WDtvoVzsfLceSPYvhEhZVpI4MRLtfBllUqg/euGu BvC0keqSilHThD/Ifhqa73aN4OpW2ZkjjHoghPUd3K3Hc4OSC2FYYmU1FMWHqhF13lp4 bDg64wRTwgZ38nzUYs/+cIU8K/gMHnfZO5yJJZqnWLGr6fM2h45nHIxg294YLDTSvGmt w+gsTsrVvZR8rM4N/pMKdiprXc6CBTm/uL04Z5wobRqh+SP7XQ9ZK3VtF4XCIlTGKs/k ALjQ== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr20982288qao.23.1333522107961; Tue, 03 Apr 2012 23:48:27 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 3 Apr 2012 23:48:27 -0700 (PDT) In-Reply-To: <4F7BA265.7060001@gmail.com> References: <4F7BA265.7060001@gmail.com> Date: Wed, 4 Apr 2012 06:48:27 +0000 Message-ID: From: Maoke To: Tom Taylor Content-Type: multipart/alternative; boundary=20cf3074b41a8b915104bcd4cf3a Cc: Softwires Subject: Re: [Softwires] Relative support for MAP vs. 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:48:29 -0000 --20cf3074b41a8b915104bcd4cf3a Content-Type: text/plain; charset=ISO-8859-1 hi Tom, a neutral point: as a person who were not in the venue (but only through listening and jabber), i also heard it seemed some, never joining either mail list or venue discussion, held up their hands. i doubt they care the techniques itself. it is a question mark if the comparable number shows there is no rough consensus. but logically i do agree with Ralph, that it was hard to conclude the rough consensus through the numbers. voting is surely never an unbiased estimation method for the consensus. ;-) regards, maoke 2012/4/4 Tom Taylor > I have been advised privately by a couple of people that I erred in my > description of relative support for MAP vs. 4rd-U at the meeting. Support > for MAP was predominant, but not to the point of rough consensus. > > I was startled at the meeting by how much support 4rd-U got, given that > Remi is the only one who defends it on the list. I guess that affected my > judgement of the numbers -- it just looked like a room-full of hands, > comparable to the showing for MAP. > > Sorry for the misdirection. > > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b41a8b915104bcd4cf3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Tom,=A0

a neutral point: as a person who w= ere not in the venue (but only through listening and jabber), i also heard = it seemed some, never joining either mail list or venue discussion, held up= their hands. i doubt they care the techniques itself.=A0

it is a question mark if the comparable number sh= ows there is no rough consensus. but logically i do agree with Ralph, that = it was hard to conclude the rough consensus through the numbers. voting is = surely never an unbiased estimation method for the consensus. ;-)=A0

regards,
maoke

2012/4/4 Tom Taylor <tom.taylor.stds@gmail.com>
I have been advised privately by a couple of people that I erred in my desc= ription of relative support for MAP vs. 4rd-U at the meeting. Support for M= AP was predominant, but not to the point of rough consensus.

I was startled at the meeting by how much support 4rd-U got, given that Rem= i is the only one who defends it on the list. I guess that affected my judg= ement of the numbers -- it just looked like a room-full of hands, comparabl= e to the showing for MAP.

Sorry for the misdirection.

Tom Taylor
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b41a8b915104bcd4cf3a-- From fibrib@gmail.com Wed Apr 4 00:14:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D811E8072 for ; Wed, 4 Apr 2012 00:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N5RRKlzxfSQ for ; Wed, 4 Apr 2012 00:14:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC421F85ED for ; Wed, 4 Apr 2012 00:14:53 -0700 (PDT) Received: by qcsq13 with SMTP id q13so355235qcs.31 for ; Wed, 04 Apr 2012 00:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OP6pQRm8iq3IybvAuQw9EwwUU5FS3olGXDulwmQnumo=; b=NXt7mpy4CRZUhbXmP4BP041QniUzUI7Wffm2QU0hOM3j+Zexujq5XIm+d7jihNPKYL pH8+6QAtNkm1ly4EmnAgr+Nke8bM2ndoZrXCZg8Vfk4rjzo45fC/YuAMXS4b6rtDD3Wj r+GVS4+Q3Q71Ilz687QFLsdyqXe8LnS4BeHcpxUaUMkzRxtJrGAyK28fxTWRC+wEI4ZM Kn4DM/Em9E5KZL1R9mtbXOM9ZV4eazptYLBRXKL6iFPlNozkNffaYB1IwpzbdJg3PlwR sRagNG27ICMLn99hQkhurs66yr3jUWAjX/qTmoG+KVEHDOUACA049WP8iip/njqVUIuW uUvw== MIME-Version: 1.0 Received: by 10.229.78.206 with SMTP id m14mr6124458qck.78.1333523693286; Wed, 04 Apr 2012 00:14:53 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 4 Apr 2012 00:14:53 -0700 (PDT) In-Reply-To: <4F7BEADF.5000806@go6.si> References: <4F7BA265.7060001@gmail.com> <4F7BEADF.5000806@go6.si> Date: Wed, 4 Apr 2012 07:14:53 +0000 Message-ID: From: Maoke To: "Jan Zorz @ go6.si" Content-Type: multipart/alternative; boundary=00235447083009b8c804bcd52e98 Cc: softwires@ietf.org Subject: Re: [Softwires] Relative support for MAP vs. 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:14:55 -0000 --00235447083009b8c804bcd52e98 Content-Type: text/plain; charset=ISO-8859-1 2012/4/4 Jan Zorz @ go6.si > On 4/4/12 3:22 AM, Tom Taylor wrote: > >> I have been advised privately by a couple of people that I erred in my >> description of relative support for MAP vs. 4rd-U at the meeting. >> Support for MAP was predominant, but not to the point of rough consensus. >> >> I was startled at the meeting by how much support 4rd-U got, given that >> Remi is the only one who defends it on the list. I guess that affected >> my judgement of the numbers -- it just looked like a room-full of hands, >> comparable to the showing for MAP. >> > > I'm with you - but what I was missing was the question "how many of you > read all 3 drafts and understands them", followed by "those of you, who > raised your hand, which one do you support". > > In this way we would probably easily find the way out. > > Room full of hands was political voting, I'm afraid. > > My question is, can we do it here, over mailinglist? :) > +0.5. i heard the chair said at the close of the meeting that the mailing list vote would be done within one week. but again, it is a voting, a political method, as i mentioned, not an unbiased estimation for the rough consensus. logically it is strange to me that a group of people playing the vote but without the game rule for the vote. vote is a way of reaching a certain result. if we don't like to make endless voting circles, let's follow the rule of voting: majority wins. cheers, maoke > > Cheers, Jan > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00235447083009b8c804bcd52e98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/4 Jan Zorz @ go6.si <jan@go= 6.si>
On 4/4/12 3:22 AM, Tom Taylor wrote:
I have been advised privately by a couple of people that I erred in my
description of relative support for MAP vs. 4rd-U at the meeting.
Support for MAP was predominant, but not to the point of rough consensus.
I was startled at the meeting by how much support 4rd-U got, given that
Remi is the only one who defends it on the list. I guess that affected
my judgement of the numbers -- it just looked like a room-full of hands, comparable to the showing for MAP.

I'm with you - but what I was missing was the question "how many o= f you read all 3 drafts and understands them", followed by "those= of you, who raised your hand, which one do you support".

In this way we would probably easily find the way out.

Room full of hands was political voting, I'm afraid.

My question is, can we do it here, over mailinglist? :)

+0.5. i heard the chair said at the close of the meeting t= hat the mailing list vote would be done within one week. but again, it is a= voting, a political method, as i mentioned, not an unbiased estimation for= the rough consensus. logically it is strange to me that a group of people = playing the vote but without the game rule for the vote.=A0

vote is a way of reaching a certain result. if we don&#= 39;t like to make endless voting circles, let's follow the rule of voti= ng: majority wins.=A0

cheers,=A0
maoke
=A0

Cheers, Jan

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--00235447083009b8c804bcd52e98-- From phdgang@gmail.com Wed Apr 4 00:25:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D221F86DC for ; Wed, 4 Apr 2012 00:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEC+iyDXJJue for ; Wed, 4 Apr 2012 00:25:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA521F86D6 for ; Wed, 4 Apr 2012 00:25:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so318498wgb.13 for ; Wed, 04 Apr 2012 00:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HjPbgrIAv3hWj8Ovww/zPeqbiFeefDyWgAYf3mFhiz4=; b=z++fzCSYmI7h0xmaRgEeGBmBe3y+PgG5dQQQ8gcLzrVtOulEilhY72+8w1HrWoJFpf IcqwETJR37ZotPdScOXT6IMX42FXEPf2fX1x1qDukBfq9nbk7YyRjtI3coWPk3iVBPh9 YBy93AOxTZFvx5i5Ghy1pxs/0WpfhEX7u0tyepuqjDaVkOTLYHuQWD93Tw5J3bKUAPiC C27Zf8NsyZ57+zlw0q0bcgF7svmx5UT5C8wjqqzP91RzI4oXcupJzFsoujlUJBcgipbr J4zYggzP+nnq4NDsOWrQwkLKL+WYtVxNMVAf17mW1vwPaO5tB8r9GCozDnoiZYobXjZs A8Jw== MIME-Version: 1.0 Received: by 10.216.131.212 with SMTP id m62mr739319wei.20.1333524312303; Wed, 04 Apr 2012 00:25:12 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Wed, 4 Apr 2012 00:25:12 -0700 (PDT) In-Reply-To: References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <09DFBD23-582E-4841-802D-DBAAEFB631AE@laposte.net> Date: Wed, 4 Apr 2012 15:25:12 +0800 Message-ID: From: GangChen To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:25:14 -0000 2012/4/3, Wojciech Dec : > On 2 April 2012 19:10, R=E9mi Despr=E9s wrote: > >> >> >> > Woj> Well, in terms of facts we have >> > 1. 4rd-U does not supporting single translation mode, >> >> Not claimed to. >> > > It's good to get clarity now that previous 4rd-U claims of supporting > services such as web-caching, log-on-portals, etc. are now false, and no > longer claimed. MAP(-T) continues to allow these. I don't see the difference between 4rd-U and MAP-T on this pionts. BTW, woj, do you really see the value of supporting single translation. I guess that is not targeting scenario for Softwires wg. IMHO, this single translation is not sufficient in the wild. It's only applicable for a subset of IPv6 address (i.e. IPv4-converted addresses communicating with IPv4-translatable addresses) BRs Gang From despres.remi@laposte.net Wed Apr 4 00:36:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B00921F8597 for ; Wed, 4 Apr 2012 00:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8iz5NqTnl3C for ; Wed, 4 Apr 2012 00:36:39 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDB521F853A for ; Wed, 4 Apr 2012 00:36:37 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4E18D9400AF; Wed, 4 Apr 2012 09:36:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 4 Apr 2012 09:36:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> To: Congxiao Bao X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:36:40 -0000 Congxiao, None of what follows leaves AFAIK what would be a flaw preventing = operational deployments to be successful. Yet, thank you for this clarification of your understanding. Unless you wish to pursue, this is enough for me.=20 Le 2012-04-04 =E0 04:35, Congxiao Bao a =E9crit : > Hi Remi, >=20 > 2012/4/2 R=E9mi Despr=E9s >>=20 >> Hi, Congxiao, >>=20 >> During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws". >>=20 >>=20 >=20 > Yes, I said that and I insist on saying that again today. >>=20 >>=20 >>=20 >>=20 >> Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft. >=20 > That's NOT true. What I can see in the mailing-list before and after > WG meeting is that many points which indicated that 4rd-U are flawed > have been raised by the MAP-E/T authors and DT members, like Maoke, > etc, and several operators. I am sorry to say that even though they > repeated the same arguments several times, you ignored their > statements and said there is no identified flaw left. >=20 > I have to say this makes the discussion in the mailing-list without > efficiency, even the conclusion is OBVIOUSLY clear. >=20 >>=20 >>=20 >> Since you have AFAIK made no previous contribution on the mailing = list to justify such an assertion, would you be kind enough to explain = what, in your understanding, wouldn't work in 4rd-U? >=20 > For my perspective, 4rd-U is not on the same level compared with MAP > for the technical maturity if we freeze the current version of MAP > Series and 4rd-U. The MAP series are the extensions of existing RFCs > and have well tested running codes, while 4rd-U redefined things in > existing RFCs and have not been tested. Per your request, I can > summarize my check list here, some have been already shown in the > mailing-list, > hopefully I don=92t need to repeat the same arguments > again in the future: >=20 > (1) 4rd-u tries to replace MAP-E, however, 4rd-u cannot support IPv4 > option. In the case when perfect IPv4 transparency is required, MAP-E > cannot be avoided. No ISP I know justifies having two standards just because of IPv4 = options. IPv4 options have never been a requirement of Softwire stateless = solutions, and shouldn't therefore be claimed to be a flaw. > (2) 4rd-u tries to replace Map-T, however, 4rd-u is not compatible > with IPv4/IPv6 single translation. For the networks which also deploy > single translation, MAP-T cannot be avoided. False. 4rd-U clearly can coexist with NAT64 and with BIH which are both single = translation. This isn't an identified flaw.=20 > For example, the web > caching in the IPv6 only network between BR and CEs requires single > translation mechanism, which 4rd-u cannot support. 4rd-U does support web caches AFAIK. Unless you provide evidence of this assertion, this doesn't make an = identified flaw. > Don=92t mention BIH, > if you want to combine BIH, 4rd-U is not the Unified solution as you > claimed. >=20 > (3) 4rd-u changes the IPv6 header architecture (redefine = fragmentation > header extension) and IPv6 address architecture (u/g-bits), the later > conflicts with RFC4291. A backward-compatible extension has always been one of the approaches to = make progress (in this instance, a clear and simple use of an existing = escape combination and of some unused bits). This isn't an identified flaw.=20 =20 > These are the fundamental changes, which needs > the proof from 6man. The experimental data should also be presented to > show this design is not harmful. > (4) If 4rd-u becomes the standard, then there will be new defined > =93IPv6.1=94 packets on the Internet (new meaning of u/g-bits, new = defined > fragmentation header, new type of ICMPv6, etc, more details in (6) and > (8)), and no existing IPv6 devices can understand those packets. The draft says what needs to be said. - No need for any IPv6.1! - No problem with any existing IPv6 device has been identified This isn't an identified flaw. > (5) 4rd-u is designed to achieve better transparency compared to > MAP-T, however, it only addresses a corner case (DF=3D1 and MF=3D1) = and > the experimental data indicates that there is only 10e-5% of such > packets and those packets are not representing normal traffic. The > experimental data of 4rd-u deployment should be presented to show that > your redefinition of (3) and the risk of (4), is worth bringing the > benefit of just addressing to this corner case (DF=3D1 and MF=3D1). This point isn't describing a (supposed) flaw. > don't think the corner case can make significant difference to the > user experience. Further more, can you give me the use case of that > corner case? The benefit is a one standard instead of two (as transparent as E and as = open to IPv6-only O&M as T). > (6) In order to address corner case (DF=3D1 and MF=3D1), 4rd-u = always > inserts the IPv6 fragmentation header and overload the ID field (DF, > TTL, TOS). The IPv6 fragment header has been shown to cause > operational difficulties in practice due to limited firewall > fragmentation support. The same applies to RFC6145 when it adds a fragment header. If this would be a flaw, it would apply also to MAP-T. > In addition, the packets with MF=3D0 and Offset=3D0 > are "atomic fragments", this issues is under discussion in 6man and > likely requires the OS and security updates > (draft-gont-6man-ipv6-atomic-fragments-00). Furthermore, if an IPv6 > packet, which contains fragmentation header and the ID has =93DF set = by > the definition of 4rd-U=94, reaches a 4rd-U end point, it will be > translated to IPv4 packets with DF=3D1, and the DF transparency may be > lost. The experimental data should be presented to show this design is > not harmful. >=20 > (7) 4rd-u tries to add checksum neutral hex in the address, however, > it still cannot support new transport layer standard when NAT44 is > used. If this would be a flaw, it would apply also to MAP-T. >=20 > (8) New types of ICMPv6 defined by 4rd-u needs the update of = RFC4443. > The existing IPv6 firewall cannot support it. No new ICMPv6 type is defined AFAIK for 4rd-U. Cannot therefore be claimed to be a flaw. > (9) 4rd-u tries to reinvent the wheel by defining new schemes in > IPv6, just for the IPv4 to IPv6 transition and only addresses corner > cases. I wonder if this is worth the huge cost even the technical flaw > could be removed. The lessons I learned in Behave and v6ops is that > changing IPv6 architecutre which can only be used for the IPv4 to IPv6 > transition is a bad idea and harmful. This is a comment, not identification of a (supposed) flaw. >> Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want). >=20 > On the Friday=92s meeting, I just want to speak out my own option and = I > would like to say it again here: > For a reasonable ISP, it pursues > simple (single) solution for sure, but FIRST of ALL, that solution > should be technically Correct. Agreed. > Considering both the previous > discussion in the mailing-list (before the WG meeting) and on-site > discussions before the open MIC, and the first run of concensus, I > strongly believed that the rough consensus has been reached: MAP is > superior to 4rd-U. Even for the second run of consensus, MAP still > stands out (25 to 12). I have been told 25 to 13, but in any case substantial support for both.=20= Tom Taylor's initial perception does confirm that there was no rough = consensus. > Please respect those audiences on site, who > understand MAP series and 4rd-U, they raised their hands for MAP > representing their neutral technique position, which of course can not > be biased by me. Of course, understanding MAP doesn't imply understanding also 4rd-U.=20 Your comment was to disqualify 4rd-U for those who didn't know it yet.=20= I respect ALL participants (but find it a duty to rectify invalid = arguments, i.e. to do normal standardization work). > Please also note that on the mailing list, many > people present their comments, that sould wait more than the hands > (without voices on the mailing list) in the meeting. Applies also to 4rd-U, in particular with 3 co-authors absent in the = Paris meeting. Regards, RD >=20 > Regards, >=20 > Congxiao >=20 >>=20 >>=20 >> Thanks, >> RD >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Apr 4 00:38:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509F721F865E for ; Wed, 4 Apr 2012 00:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIvaF3I52sdu for ; Wed, 4 Apr 2012 00:38:55 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 972E821F859B for ; Wed, 4 Apr 2012 00:38:55 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id tjet1i00237Y3f403jet9D; Wed, 04 Apr 2012 09:38:53 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F7BA265.7060001@gmail.com> Date: Wed, 4 Apr 2012 09:38:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7BA265.7060001@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Relative support for MAP vs. 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:38:56 -0000 Le 2012-04-04 =E0 03:22, Tom Taylor a =E9crit : > I have been advised privately by a couple of people that I erred in my = description of relative support for MAP vs. 4rd-U at the meeting. = Support for MAP was predominant, but not to the point of rough = consensus. Right. That's a fact. > I was startled at the meeting by how much support 4rd-U got, given = that Remi is the only one who defends it on the list. Actually not the only one. > I guess that affected my judgement of the numbers -- it just looked = like a room-full of hands, comparable to the showing for MAP. There was indeed support from all sides of the room. That's a fact. All documents as experimental was the plan if no consensus on a single = design. Changing the plan because some are disappointed of having the WG didn't = go their way wouldn't be justified. Regards, RD >=20 > Sorry for the misdirection. >=20 > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Apr 4 00:49:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F1521F8714 for ; Wed, 4 Apr 2012 00:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4vX-J1AWP2M for ; Wed, 4 Apr 2012 00:49:45 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8721F85E4 for ; Wed, 4 Apr 2012 00:49:43 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id tjpe1i00C37Y3f403jpegd; Wed, 04 Apr 2012 09:49:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-22-883776011 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 4 Apr 2012 09:49:37 +0200 Message-Id: References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:49:45 -0000 --Apple-Mail-22-883776011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-04 =E0 08:04, Maoke a =E9crit : > dear Remi,=20 >=20 > 2012/4/2 R=E9mi Despr=E9s > Hi, Congxiao, >=20 > During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws". >=20 > Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft. >=20 > the "with no identified flaw left in the draft" is only your statement = instead of the conclusion of the competent contributors.=20 >=20 > if the draft -06 or -07 limits the scope of 4rd-u with at least the = following constrainsts, i guess it could be better with less flaws.=20 > - the domain having IPv6 firewalls or filters or IP/ICMP integrity = varification mechanism between CE and BR is out of scope > - the domain having IPv6 dynamic routing ttl-security mechanism is out = of scope=20 > - simultaneously supporting single translation with using IPv4-mapped = address for native IPv6-only networks/nodes is out of scope > - supporting L4 protocol that not yet supported by NAT44 is out of = scope (even for the case where NAT44 is bypassed, like 1:1 address = mapping) > - the IPv4 option transparency is out of scope, even for temporary = end-to-end usage for some reason like experiments.=20 >=20 > were 4rd-u-06 updated with the above constraints, it is still have = some technical inconsistency. i'd love to point them out when i have = seen the scope clarification made by the authors. because the problem = impact would change when the scope is changed. (well, it is another = problem if people would like to have such a so-limited stuff) >=20 >=20 > Since you have AFAIK made no previous contribution on the mailing list = to justify such an assertion, would you be kind enough to explain what, = in your understanding, wouldn't work in 4rd-U? >=20 > Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want). >=20 > one doesn't write too much in cockfighting mails !=3D he/she doesn't = think, listen, and analyze. on the other hand, i understand the = statement (no matter oral or written) in the venue is also considered as = IETF contribution. >=20 > do you think your statement on "no identified flaws left", ignoring = the fact that competent contributors keep arguing, Keeping arguing isn' sufficient to identify a real flaw. In all fairness, I believe that all real points you raised were covered, = either by clarifications or with complements in the design, and that = absence of flaws will be verified on actual implementations.=20 Now, I think time has now come to calm down, and apply with the chair's = announced plan before the meeting in case no single choice would emerge: = have all documents published as WG drafts on experimental track. Regards, RD > is not an attempt at biasing people's understanding in the venue?=20 >=20 > - maoke=20 > =20 >=20 > Thanks, > RD >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-22-883776011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
dear = Remi, 

2012/4/2 R=E9mi = Despr=E9s <despres.remi@laposte.net><= /span>
Hi, Congxiao,

During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws".

Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft.

the "with no = identified flaw left in the draft" is only your statement instead of the = conclusion of the competent contributors. 

if the draft -06 or -07 limits the scope of 4rd-u = with at least the following constrainsts, i guess it could be better = with less flaws. 
- the domain having IPv6 firewalls or = filters or IP/ICMP integrity varification mechanism between CE and BR is = out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is = out of scope 
- simultaneously supporting single = translation with using IPv4-mapped address for native IPv6-only = networks/nodes is out of scope
- supporting L4 protocol that not yet supported by NAT44 is out of = scope (even for the case where NAT44 is bypassed, like 1:1 address = mapping)
- the IPv4 option transparency is out of scope, even = for temporary end-to-end usage for some reason like = experiments. 

were 4rd-u-06 updated with the above constraints, it = is still have some technical inconsistency. i'd love to point them out = when i have seen the scope clarification made by the authors. because = the problem impact would change when the scope is changed. (well, it is = another problem if people would like to have such a so-limited = stuff)


Since you have AFAIK made no previous contribution on the mailing list = to justify such an assertion, would you be kind enough to explain what, = in your understanding, wouldn't work in 4rd-U?

Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want).

one doesn't write too = much in cockfighting mails !=3D he/she doesn't think, listen, and = analyze. on the other hand, i understand the statement (no matter oral = or written) in the venue is also considered as IETF contribution.


do you think your statement on "no identified = flaws left", ignoring the fact that competent contributors keep arguing, =

Keeping arguing isn' = sufficient to identify a real flaw.
In all fairness, I believe = that all real points you raised were covered, either by clarifications = or with complements in the design, and that absence of flaws will be = verified on actual implementations. 

Now, = I think time has now come to calm down, and apply with the chair's = announced plan before the meeting in case no single choice would = emerge: have all documents published as WG drafts on experimental = track.

Regards,
RD

=



is not an attempt at biasing people's = understanding in the venue? 

- maoke 
 

Thanks,
RD

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-22-883776011-- From despres.remi@laposte.net Wed Apr 4 03:23:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA921F86E5 for ; Wed, 4 Apr 2012 03:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVIlaImksbhQ for ; Wed, 4 Apr 2012 03:23:55 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 10EBF21F86A2 for ; Wed, 4 Apr 2012 03:23:54 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id tmPq1i00L37Y3f403mPrbM; Wed, 04 Apr 2012 12:23:52 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-893028553 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 4 Apr 2012 12:23:50 +0200 Message-Id: References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 10:23:56 -0000 --Apple-Mail-23-893028553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-04 =E0 08:04, Maoke a =E9crit : > dear Remi,=20 >=20 > 2012/4/2 R=E9mi Despr=E9s > Hi, Congxiao, >=20 > During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws". >=20 > Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft. >=20 > the "with no identified flaw left in the draft" is only your statement = instead of the conclusion of the competent contributors.=20 a) I believe that all co-authors of the 4rd-U proposal are competent = contributors. b) They did review the specification, and so far don't find any of the = the alleged flaws. There is nothing more intended in my statement above.=20 Even after the last mail exchanges, and although some others think = differently, I honestly think that none of the alleged 4rd-u flaws is = effective in real world, and that any of these would prevent 4rd-U = deployments to be useful and flawless. Regards, RD >=20 > if the draft -06 or -07 limits the scope of 4rd-u with at least the = following constrainsts, i guess it could be better with less flaws.=20 > - the domain having IPv6 firewalls or filters or IP/ICMP integrity = varification mechanism between CE and BR is out of scope > - the domain having IPv6 dynamic routing ttl-security mechanism is out = of scope=20 > - simultaneously supporting single translation with using IPv4-mapped = address for native IPv6-only networks/nodes is out of scope > - supporting L4 protocol that not yet supported by NAT44 is out of = scope (even for the case where NAT44 is bypassed, like 1:1 address = mapping) > - the IPv4 option transparency is out of scope, even for temporary = end-to-end usage for some reason like experiments.=20 >=20 > were 4rd-u-06 updated with the above constraints, it is still have = some technical inconsistency. i'd love to point them out when i have = seen the scope clarification made by the authors. because the problem = impact would change when the scope is changed. (well, it is another = problem if people would like to have such a so-limited stuff) >=20 >=20 > Since you have AFAIK made no previous contribution on the mailing list = to justify such an assertion, would you be kind enough to explain what, = in your understanding, wouldn't work in 4rd-U? >=20 > Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want). >=20 > one doesn't write too much in cockfighting mails !=3D he/she doesn't = think, listen, and analyze. on the other hand, i understand the = statement (no matter oral or written) in the venue is also considered as = IETF contribution. >=20 > do you think your statement on "no identified flaws left", ignoring = the fact that competent contributors keep arguing, is not an attempt at = biasing people's understanding in the venue?=20 >=20 > - maoke=20 > =20 >=20 > Thanks, > RD >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-23-893028553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
dear = Remi, 

2012/4/2 R=E9mi = Despr=E9s <despres.remi@laposte.net><= /span>
Hi, Congxiao,

During the Softwire meeting, you came to the mike to assert that the = 4rd-U specification was known to have "flaws".

Yet, you do know that the 4rd-U specification has been reviewed by = competent contributors of widely varied origin, with no identified flaw = left in the draft.

the "with no = identified flaw left in the draft" is only your statement instead of the = conclusion of the competent = contributors. 

a) I = believe that all co-authors of the 4rd-U proposal are competent = contributors.
b) They did review the specification, and so far = don't find any of the the alleged flaws.
There is nothing more = intended in my statement above. 

Even = after the last mail exchanges, and although some others think = differently, I honestly think that none of the = alleged 4rd-u flaws is effective in real world, and that any = of these would prevent 4rd-U deployments to be useful and = flawless.

Regards,
RD




if the draft -06 or -07 limits the scope of 4rd-u = with at least the following constrainsts, i guess it could be better = with less flaws. 
- the domain having IPv6 firewalls or = filters or IP/ICMP integrity varification mechanism between CE and BR is = out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is = out of scope 
- simultaneously supporting single = translation with using IPv4-mapped address for native IPv6-only = networks/nodes is out of scope
- supporting L4 protocol that not yet supported by NAT44 is out of = scope (even for the case where NAT44 is bypassed, like 1:1 address = mapping)
- the IPv4 option transparency is out of scope, even = for temporary end-to-end usage for some reason like = experiments. 

were 4rd-u-06 updated with the above constraints, it = is still have some technical inconsistency. i'd love to point them out = when i have seen the scope clarification made by the authors. because = the problem impact would change when the scope is changed. (well, it is = another problem if people would like to have such a so-limited = stuff)


Since you have AFAIK made no previous contribution on the mailing list = to justify such an assertion, would you be kind enough to explain what, = in your understanding, wouldn't work in 4rd-U?

Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want).

one doesn't write too = much in cockfighting mails !=3D he/she doesn't think, listen, and = analyze. on the other hand, i understand the statement (no matter oral = or written) in the venue is also considered as IETF contribution.

do you think your statement on "no identified flaws = left", ignoring the fact that competent contributors keep arguing, is = not an attempt at biasing people's understanding in the = venue? 

- maoke 
 

Thanks,
RD

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-23-893028553-- From fibrib@gmail.com Wed Apr 4 03:39:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA0421F86B1 for ; Wed, 4 Apr 2012 03:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUU-OzawbpPA for ; Wed, 4 Apr 2012 03:39:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A094621F86AF for ; Wed, 4 Apr 2012 03:39:30 -0700 (PDT) Received: by qcsq13 with SMTP id q13so71326qcs.31 for ; Wed, 04 Apr 2012 03:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U1ur1A8NpiHLPP6fBrhRblozk0i5B/U3WFk32GtzPTU=; b=GJqgUdmAPnFegEiC5m7hw28vTwujdigQtJm8EDUNA0bljm3PgcBDCprX/QZPKamP49 le0zZL8SRv/rNoqq3mqmzCou/LNroMNm56c8NMfbK+1k/kuUSWdUw9FhMuqhM2GdUMwe L2uZu/kqnyfmjj3+T5oiRkqurOzFg0IqtFWOR/4cjka7LH47ZjzofJB7rWAFhLeOhda5 GsXcwM/19E6fut/ZP/xb36jE8Ns3cZhm99xh3xMqWGZejIk+IrA7B8daMG99McUcEzWI I8J1cBeI8i3UwLEQ6MQeaeOldTvn6rQET5Jxo5JVg5sr7HU6smr9iOjjrs97D1XcahlA H3iQ== MIME-Version: 1.0 Received: by 10.229.136.130 with SMTP id r2mr6328506qct.58.1333535970203; Wed, 04 Apr 2012 03:39:30 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 4 Apr 2012 03:39:30 -0700 (PDT) In-Reply-To: References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> Date: Wed, 4 Apr 2012 10:39:30 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c768f92cc9a6f04bcd80947 Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 10:39:38 -0000 --00248c768f92cc9a6f04bcd80947 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/4 R=E9mi Despr=E9s > > Le 2012-04-04 =E0 08:04, Maoke a =E9crit : > > dear Remi, > > 2012/4/2 R=E9mi Despr=E9s > >> Hi, Congxiao, >> >> During the Softwire meeting, you came to the mike to assert that the >> 4rd-U specification was known to have "flaws". >> >> Yet, you do know that the 4rd-U specification has been reviewed by >> competent contributors of widely varied origin, with no identified flaw >> left in the draft. >> > > the "with no identified flaw left in the draft" is only your statement > instead of the conclusion of the competent contributors. > > > a) I believe that all co-authors of the 4rd-U proposal are competent > contributors. > b) They did review the specification, and so far don't find any of the th= e > alleged flaws. > There is nothing more intended in my statement above. > well, sorry but i supposed i was one of the competent contributors despite i am not an author. :P > > Even after the last mail exchanges, and although some others think > differently, I honestly think that none of the alleged 4rd-u flaws is > effective in real world, and that any of these would prevent 4rd-U > deployments to be useful and flawless. > > "not effective in real world" must be verified in practices. as we have pointed out "DF=3D1/MF=3D1" is not effective in the real world and we have = the statistics from multiple sources. regards, maoke > Regards, > RD > > > > > if the draft -06 or -07 limits the scope of 4rd-u with at least the > following constrainsts, i guess it could be better with less flaws. > - the domain having IPv6 firewalls or filters or IP/ICMP integrity > varification mechanism between CE and BR is out of scope > - the domain having IPv6 dynamic routing ttl-security mechanism is out of > scope > - simultaneously supporting single translation with using IPv4-mapped > address for native IPv6-only networks/nodes is out of scope > - supporting L4 protocol that not yet supported by NAT44 is out of scope > (even for the case where NAT44 is bypassed, like 1:1 address mapping) > - the IPv4 option transparency is out of scope, even for temporary > end-to-end usage for some reason like experiments. > > were 4rd-u-06 updated with the above constraints, it is still have some > technical inconsistency. i'd love to point them out when i have seen the > scope clarification made by the authors. because the problem impact would > change when the scope is changed. (well, it is another problem if people > would like to have such a so-limited stuff) > > >> Since you have AFAIK made no previous contribution on the mailing list t= o >> justify such an assertion, would you be kind enough to explain what, in >> your understanding, wouldn't work in 4rd-U? >> >> Without that, your statement might be understood as an attempt at biasin= g >> people's understanding just before a vote (which I suppose you didn't wa= nt). >> > > one doesn't write too much in cockfighting mails !=3D he/she doesn't thin= k, > listen, and analyze. on the other hand, i understand the statement (no > matter oral or written) in the venue is also considered as IETF > contribution. > > do you think your statement on "no identified flaws left", ignoring the > fact that competent contributors keep arguing, is not an attempt at biasi= ng > people's understanding in the venue? > > - maoke > > >> >> Thanks, >> RD >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --00248c768f92cc9a6f04bcd80947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/4 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

Le 2012= -04-04 =E0 08:04, Maoke a =E9crit :

dear Remi,=A0

2012/4/2 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi, Congxiao,

During the Softwire meeting, you came to the mike to assert that the 4rd-U = specification was known to have "flaws".

Yet, you do know that the 4rd-U specification has been reviewed by competen= t contributors of widely varied origin, with no identified flaw left in the= draft.

the "with no identified fl= aw left in the draft" is only your statement instead of the conclusion= of the competent contributors.=A0

a) I believe that all co-autho= rs of the 4rd-U proposal are competent contributors.
b) They did = review the specification, and so far don't find any of the the alleged = flaws.
There is nothing more intended in my statement above.=A0

well, sorry but i supposed i was one o= f the competent contributors despite i am not an author. :P
=A0

Even after the last mail exchanges, and although some othe= rs think differently, I honestly think that none of the alleged=A04rd-u=A0f= laws is effective in real world, and that any of these would prevent 4rd-U = deployments to be useful and flawless.


"not effec= tive in real world" must be verified in practices. as we have pointed = out "DF=3D1/MF=3D1" is not effective in the real world and we hav= e the statistics from multiple sources.=A0

regards,
maoke
=A0
Regards,<= /div>
RD




if the draft -06 or -07 limits the scope of 4rd-u with = at least the following constrainsts, i guess it could be better with less f= laws.=A0
- the domain having IPv6 firewalls or filters or IP/ICMP= integrity varification mechanism between CE and BR is out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is out= of scope=A0
- simultaneously supporting single translation with = using IPv4-mapped address for native IPv6-only networks/nodes is out of sco= pe
- supporting L4 protocol that not yet supported by NAT44 is out of sco= pe (even for the case where NAT44 is bypassed, like 1:1 address mapping)
- the IPv4 option transparency is out of scope, even for temporary = end-to-end usage for some reason like experiments.=A0

were 4rd-u-06 updated with the above constraints, it is= still have some technical inconsistency. i'd love to point them out wh= en i have seen the scope clarification made by the authors. because the pro= blem impact would change when the scope is changed. (well, it is another pr= oblem if people would like to have such a so-limited stuff)


Since you have AFAIK made no previous contribution on the mailing list to j= ustify such an assertion, would you be kind enough to explain what, in your= understanding, wouldn't work in 4rd-U?

Without that, your statement might be understood as an attempt at biasing p= eople's understanding just before a vote (which I suppose you didn'= t want).

one doesn't write too much= in cockfighting mails !=3D he/she doesn't think, listen, and analyze. = on the other hand, i understand the statement (no matter oral or written) i= n the venue is also considered as IETF contribution.

do you think your statement on "no identified flaw= s left", ignoring the fact that competent contributors keep arguing, i= s not an attempt at biasing people's understanding in the venue?=A0

- maoke=A0
=A0

Thanks,
RD

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--00248c768f92cc9a6f04bcd80947-- From despres.remi@laposte.net Wed Apr 4 04:47:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49821F86A1 for ; Wed, 4 Apr 2012 04:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjspnKnE1m+p for ; Wed, 4 Apr 2012 04:47:51 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5143421F867F for ; Wed, 4 Apr 2012 04:47:48 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 227FC94005C; Wed, 4 Apr 2012 13:47:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-24-898056923 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 4 Apr 2012 13:47:38 +0200 Message-Id: <7251A4C7-62E7-4452-A07F-165FB7953E52@laposte.net> References: <8C1BC5BB-8102-4736-9F3E-FC6FE7255A86@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Congxiao Bao Subject: Re: [Softwires] What are the claimed flaws of 4rd-U? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 11:47:52 -0000 --Apple-Mail-24-898056923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-04-04 12:39, Maoke : ... > Even after the last mail exchanges, and although some others think = differently, I honestly think that none of the alleged 4rd-u flaws is = effective in real world, and that any of these would prevent 4rd-U = deployments to be useful and flawless. >=20 >=20 > "not effective in real world" must be verified in practices. as we = have pointed out "DF=3D1/MF=3D1" is not effective in the real world and = we have the statistics from multiple sources. Maoke, You lost me! - My assertion is that, in 4rd-u-06, none of the identified flaws is = "effective in real-world". - You then answer that (in your opinion) the DF=3DMF=3D1 issue, which is = *a MAP-T-limitation issue*, isn't effective in real world. - I don't share this opinion, in particular because a Murphy's law says = that what can fail will fail, BUT ABOVE ALL this isn't the subject: the = subject is only alleged flaws of 4rd-U. Regards, RD =20 > =20 >=20 > regards, > maoke > =20 > Regards, > RD >=20 >=20 >=20 >>=20 >> if the draft -06 or -07 limits the scope of 4rd-u with at least the = following constrainsts, i guess it could be better with less flaws.=20 >> - the domain having IPv6 firewalls or filters or IP/ICMP integrity = varification mechanism between CE and BR is out of scope >> - the domain having IPv6 dynamic routing ttl-security mechanism is = out of scope=20 >> - simultaneously supporting single translation with using IPv4-mapped = address for native IPv6-only networks/nodes is out of scope >> - supporting L4 protocol that not yet supported by NAT44 is out of = scope (even for the case where NAT44 is bypassed, like 1:1 address = mapping) >> - the IPv4 option transparency is out of scope, even for temporary = end-to-end usage for some reason like experiments.=20 >>=20 >> were 4rd-u-06 updated with the above constraints, it is still have = some technical inconsistency. i'd love to point them out when i have = seen the scope clarification made by the authors. because the problem = impact would change when the scope is changed. (well, it is another = problem if people would like to have such a so-limited stuff) >>=20 >>=20 >> Since you have AFAIK made no previous contribution on the mailing = list to justify such an assertion, would you be kind enough to explain = what, in your understanding, wouldn't work in 4rd-U? >>=20 >> Without that, your statement might be understood as an attempt at = biasing people's understanding just before a vote (which I suppose you = didn't want). >>=20 >> one doesn't write too much in cockfighting mails !=3D he/she doesn't = think, listen, and analyze. on the other hand, i understand the = statement (no matter oral or written) in the venue is also considered as = IETF contribution. >>=20 >> do you think your statement on "no identified flaws left", ignoring = the fact that competent contributors keep arguing, is not an attempt at = biasing people's understanding in the venue?=20 >>=20 >> - maoke=20 >> =20 >>=20 >> Thanks, >> RD >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-24-898056923 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
2012-04-04  12:39, Maoke :
...
Even after the last mail exchanges, and although some others think differently, I honestly think that none of the alleged 4rd-u flaws is effective in real world, and that any of these would prevent 4rd-U deployments to be useful and flawless.


"not effective in real world" must be verified in practices. as we have pointed out "DF=1/MF=1" is not effective in the real world and we have the statistics from multiple sources.

Maoke,

You lost me!
- My assertion is that, in 4rd-u-06, none of the identified flaws is "effective in real-world".
- You then answer that (in your opinion) the DF=MF=1 issue, which is *a MAP-T-limitation issue*, isn't effective in real world.
- I don't share this opinion, in particular because a Murphy's law says that what can fail will fail, BUT ABOVE ALL this isn't the subject: the subject is only alleged flaws of 4rd-U.


Regards,
RD

 

 

regards,
maoke
 
Regards,
RD




if the draft -06 or -07 limits the scope of 4rd-u with at least the following constrainsts, i guess it could be better with less flaws. 
- the domain having IPv6 firewalls or filters or IP/ICMP integrity varification mechanism between CE and BR is out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is out of scope 
- simultaneously supporting single translation with using IPv4-mapped address for native IPv6-only networks/nodes is out of scope
- supporting L4 protocol that not yet supported by NAT44 is out of scope (even for the case where NAT44 is bypassed, like 1:1 address mapping)
- the IPv4 option transparency is out of scope, even for temporary end-to-end usage for some reason like experiments. 

were 4rd-u-06 updated with the above constraints, it is still have some technical inconsistency. i'd love to point them out when i have seen the scope clarification made by the authors. because the problem impact would change when the scope is changed. (well, it is another problem if people would like to have such a so-limited stuff)


Since you have AFAIK made no previous contribution on the mailing list to justify such an assertion, would you be kind enough to explain what, in your understanding, wouldn't work in 4rd-U?

Without that, your statement might be understood as an attempt at biasing people's understanding just before a vote (which I suppose you didn't want).

one doesn't write too much in cockfighting mails != he/she doesn't think, listen, and analyze. on the other hand, i understand the statement (no matter oral or written) in the venue is also considered as IETF contribution.

do you think your statement on "no identified flaws left", ignoring the fact that competent contributors keep arguing, is not an attempt at biasing people's understanding in the venue? 

- maoke 
 

Thanks,
RD

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




--Apple-Mail-24-898056923-- From marc.blanchet@viagenie.ca Wed Apr 4 06:00:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459BC21F85E4 for ; Wed, 4 Apr 2012 06:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfMariaNuTxj for ; Wed, 4 Apr 2012 05:59:59 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D9FF921F8592 for ; Wed, 4 Apr 2012 05:59:59 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 194D1400B1; Wed, 4 Apr 2012 08:59:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CBB12E3-E388-4E88-8572-90ED953274F0" From: Marc Blanchet In-Reply-To: Date: Wed, 4 Apr 2012 08:59:57 -0400 Message-Id: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> To: Maoke X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:00:00 -0000 --Apple-Mail=_0CBB12E3-E388-4E88-8572-90ED953274F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-03 =E0 22:25, Maoke a =E9crit : >=20 > a serious point not of the Apr-1 joke: as an IETF WG, we are obliged = to provide surely high-quality document to the market. even we believe = market choice, at least we have to publish what we ourselves have well = understood, carefully coded and well tested.=20 > otherwise, the market would see IETF more of a group of doc-makers = rather than technology-explorers. agreed. then what do we do in the absence of consensus? I proposed one = solution. Marc. --Apple-Mail=_0CBB12E3-E388-4E88-8572-90ED953274F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

a serious point not of the Apr-1 = joke: as an IETF WG, we are obliged to provide surely high-quality = document to the market. even we believe market choice, at least we have = to publish what we ourselves have well understood, carefully coded = and well tested. 
otherwise, the market would see IETF more of a group = of doc-makers rather than = technology-explorers.

agreed. then = what do we do in the absence of consensus? I proposed one = solution.

Marc.


= --Apple-Mail=_0CBB12E3-E388-4E88-8572-90ED953274F0-- From sarikaya2012@gmail.com Wed Apr 4 08:36:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36C821F85AA; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs9PE1uZOnR2; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0421F859A; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) Received: by iazz13 with SMTP id z13so596447iaz.31 for ; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=0IFHs7OmCVojInDug3WkMb1WhOQO6LcSt1FccI8v8WM=; b=ZtGzpL97wafhTgK7TgxNeafQaQWMC8Fd1jslNFzqc1sjmK6tDKcbMp+G4ah4cm85+/ A5IEbZG2GW9doGIukrio1pvu8rCvve8/kUs1+McxTPDHr5iAignkaqJsJJZLipErpRn2 RVVoqJVDXT0k4kv7lzfANvO2Dw7KUe+kDetTpFQ7x8J27G8huJPvLXt7F4tec7WF8E20 /3ZTHMXzqevehKm1RsWuXKfOFVYU3M9mWghwtn9qhAYC0jCY+yvrkpn1/EEItI3ESM5H ABHR44rDzxAbl9QLOKJNFhfoXOSBRDm0gJSdZp8S0ZUjFcCMPH02JiOHq+y/+RJ6YOhq ZoxQ== MIME-Version: 1.0 Received: by 10.50.222.131 with SMTP id qm3mr2023195igc.66.1333553800886; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) Received: by 10.231.8.99 with HTTP; Wed, 4 Apr 2012 08:36:40 -0700 (PDT) Date: Wed, 4 Apr 2012 10:36:40 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area , v6ops@ietf.org, Softwires-wg , netext@ietf.org, dmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Dirk.von-Hugo@telekom.de Subject: [Softwires] Announcing fmc mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:36:42 -0000 A new list has been created for fixed mobile convergence (FMC) discussions, fmc@ietf.org. If interested, please subscribe the list using this link: https://www.ietf.org/mailman/listinfo/fmc Regards, Behcet & Dirk From marc.blanchet@viagenie.ca Wed Apr 4 08:41:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262221F858A; Wed, 4 Apr 2012 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wuzBGjVL9VC; Wed, 4 Apr 2012 08:41:30 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63721F8589; Wed, 4 Apr 2012 08:41:30 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A1731400B4; Wed, 4 Apr 2012 11:41:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D" From: Marc Blanchet In-Reply-To: Date: Wed, 4 Apr 2012 11:41:27 -0400 Message-Id: <0012EA6C-65E9-4B1C-8411-86C2B4ABCC24@viagenie.ca> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, Internet Area , netext@ietf.org, dmm@ietf.org, Dirk.von-Hugo@telekom.de, Softwires-wg Subject: Re: [Softwires] [Int-area] Announcing fmc mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:41:31 -0000 --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, the description of the mailing list says: " serving access to = multi-interface terminals". Looks like MIF to me. - how is this different from MIF? - why did the MIF ML was not part of the "multicast"? Marc. Le 2012-04-04 =E0 11:36, Behcet Sarikaya a =E9crit : > A new list has been created for fixed mobile convergence (FMC) > discussions, fmc@ietf.org. >=20 > If interested, please subscribe the list using this link: >=20 > https://www.ietf.org/mailman/listinfo/fmc >=20 > Regards, >=20 > Behcet & Dirk > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1  serving access to multi-interface terminals".  Looks = like MIF to me.
- how is this different from = MIF?
- why did the MIF ML was not part = of the "multicast"?

Marc.

Le 2012-04-04 =E0 11:36, Behcet = Sarikaya a =E9crit :

A new = list has been created for fixed mobile convergence (FMC)
discussions, = fmc@ietf.org.

If interested, = please subscribe the list using this link:

https://www.ietf.org/ma= ilman/listinfo/fmc

Regards,

Behcet & = Dirk
_______________________________________________
Int-area = mailing = list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-are= a

= --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D-- From despres.remi@laposte.net Wed Apr 4 09:24:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC8B21F866C for ; Wed, 4 Apr 2012 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRsrduy86PbS for ; Wed, 4 Apr 2012 09:24:52 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id E155821F8834 for ; Wed, 4 Apr 2012 09:24:51 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id tsQo1i00A37Y3f403sQohk; Wed, 04 Apr 2012 18:24:49 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> Date: Wed, 4 Apr 2012 18:24:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <916E30DF-B113-4D26-B564-AE6DD7C2A943@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> To: Alain Durand , Yong Cui , Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:24:53 -0000 2012-04-03 18:32, Marc Blanchet : > I don't see a way out of this thread.=20 >=20 > my suggestion: > - published both as experimental > - let the market decide > - come back later to move one or the other standard track. +1 RD >=20 > Above all, I think having a stable specification (i.e. RFC) that = implementers can code against and providers to require is what is = needed first.=20 >=20 > Marc. >=20 > Le 2012-04-03 =E0 11:14, Jan Zorz @ go6.si a =E9crit : >=20 >> Dear Softwires WG chairs. >>=20 >> For how long will you leave this useless cockfight go on instead of = steering the working group into a direction, that may enable us to = decide on something and chose the direction? >>=20 >> We are running in circles here and just amplificating the noise, = coming from certain usual suspects. >>=20 >> Cheers, Jan >>=20 >> P.S: I too enjoy observing the roosters fight, but I don't think we = have time for this now. :) >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From adurand@juniper.net Wed Apr 4 14:14:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4411E8110 for ; Wed, 4 Apr 2012 14:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzTYO0Wdo6fu for ; Wed, 4 Apr 2012 14:14:44 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 80F0311E8112 for ; Wed, 4 Apr 2012 14:14:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT3y5ulmXWGTv9P8daRh2Hu3FbB8WQiOS@postini.com; Wed, 04 Apr 2012 14:14:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 4 Apr 2012 14:14:10 -0700 From: Alain Durand To: "softwires@ietf.org WG" Date: Wed, 4 Apr 2012 14:14:08 -0700 Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbg== Message-ID: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:14:45 -0000 Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) and 4rd-U. We got very strong feedback that we needed to select one solution to cover that full stateless case, not two, and that we should mak= e this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Your full name, your affiliation, your choice: YES or NO ---------------------------------------------------------------------------= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Your full name, your affiliation, your choice: 4rd-U or MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please fill out the following form and reply to the list by Wednesday 4/10 5pm EDT. Note: Use this thread ONLY for expressing your support to one OR the other, and redirect any discussions to other threads. That would help up gauge consensus. Alain & Yong.= From fibrib@gmail.com Wed Apr 4 17:52:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9283511E8086 for ; Wed, 4 Apr 2012 17:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ31CwejxfYt for ; Wed, 4 Apr 2012 17:52:58 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id F1DDB11E8074 for ; Wed, 4 Apr 2012 17:52:57 -0700 (PDT) Received: by qafi31 with SMTP id i31so948340qaf.15 for ; Wed, 04 Apr 2012 17:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6NzeUQbMaWfUgi2oNzW7hJreFGhZv1I8BDQ7sFie1aM=; b=R8vZPHwgTdf+MDx4cwcV4aqOCR1XS54MB0Y48WSmySoOA0DSZEdAXa3eWlnWw2lOBz 6SyE+5pjj7n3OzoiaX7HLvF1SJi4Gas436J90UNDvv75iHramZ850PEEhwfij1414D1b dgMoUZXbdKV6/zMtn55YF2jXahfZfsULQqFbfCYFcoo7ikFL8sQY0FCLKt779Lg1SiBU whYVdy2oGz7u6dTJW+UJO+s+DA63QivHp3dgyHQSVC6ESHA+OJ+o3A5QSp1dncji3utf LDhqMq+MA4Z+5yErp8lrrGeOGqKGeJLOiZvGe3QNqUqrZi2/nBJfxelHNHOAGbc5TiUK U5iA== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr1539594qab.36.1333587177421; Wed, 04 Apr 2012 17:52:57 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 4 Apr 2012 17:52:57 -0700 (PDT) In-Reply-To: References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> Date: Thu, 5 Apr 2012 00:52:57 +0000 Message-ID: From: Maoke To: Marc Blanchet Content-Type: multipart/alternative; boundary=20cf300faff5fcbccc04bce3f54b Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 00:52:58 -0000 --20cf300faff5fcbccc04bce3f54b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/4 Marc Blanchet > Le 2012-04-03 =E0 22:25, Maoke a =E9crit : > > > a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to > provide surely high-quality document to the market. even we believe marke= t > choice, at least we have to publish what we ourselves have well > understood, carefully coded and well tested. > > otherwise, the market would see IETF more of a group of doc-makers rather > than technology-explorers. > > > agreed. then what do we do in the absence of consensus? I proposed one > solution. > i propose another, maybe closer to the chairs' opinion: let's do the vote and decide with the game rule of "majority wins", stopping the endless vote. ;-) - maoke > > Marc. > > > --20cf300faff5fcbccc04bce3f54b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/4 Marc Blanchet <marc.blanchet@viagenie.ca= >
Le 2012-04-03 =E0 22:25, Maok= e a =E9crit :

a serious point not of the Apr-1 jok= e: as an IETF WG, we are obliged to provide surely high-quality document to= the market. even we believe market choice, at least we have to publish wha= t we ourselves have well understood,=A0carefully coded and well tested.=A0<= /div>
otherwise, the market would see= IETF more of a group of doc-makers rather than technology-explorers.
=

agreed. then what do we do in the ab= sence of consensus? I proposed one solution.

i propose another, maybe close= r to the chairs' opinion: let's do the vote and decide with the gam= e rule of "majority wins", stopping the endless vote. ;-) - maoke=
=A0

Marc.



--20cf300faff5fcbccc04bce3f54b-- From rdroms.ietf@gmail.com Wed Apr 4 19:12:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B930E11E8073 for ; Wed, 4 Apr 2012 19:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTaua+gnKUnW for ; Wed, 4 Apr 2012 19:12:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86011E8074 for ; Wed, 4 Apr 2012 19:12:29 -0700 (PDT) Received: by ghbg16 with SMTP id g16so595887ghb.31 for ; Wed, 04 Apr 2012 19:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Kvk6dRSKPftERLhEF8/u2W4G4ssPjVUSNcF6XAOIxvg=; b=pthom1SirKlYzzDpzVlB3Tp0Lf3/hVcaKM1sr1oNLsEMquRlYKTh69Ph0uCL5zabun 2HyBctf5uuJc6UrnC9S/YKxOnxV4yuvbat7GX5Rak/rU5ZvZTv3N8Y09L1jM4jugufEW ywOFKEOyC7wRLtj5YqRil8C/drlQ5aPz7MuFwEBbP0yUtJtKtnQzJYsKt8d5HJjbqyNE J7kaBrsEOvYyStzgAFzRp8Vk3Y9CjvkDDkGLpPW5veLtG+RTnq59AS6kthkRYI7DS9y0 MupSbzZdc/qVUO4IVgVXKKDljDLPTxbc0V8b/1niXxcC8OUOaYaDmh6Q52PBxTfU+z3R 8vJQ== Received: by 10.236.79.234 with SMTP id i70mr555106yhe.88.1333591948729; Wed, 04 Apr 2012 19:12:28 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:9448:19b3:88a:4186? ([2001:420:2481:20:9448:19b3:88a:4186]) by mx.google.com with ESMTPS id e8sm9311766yhk.0.2012.04.04.19.12.25 (version=SSLv3 cipher=OTHER); Wed, 04 Apr 2012 19:12:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Wed, 4 Apr 2012 22:12:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54202333-DEDF-482F-8BFA-4A0C72D7387C@gmail.com> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> <33A20928-A934-44AD-BEC2-E0A72EE35C71@laposte.net> <4F7B13D1.9040702@go6.si> <8FBB0771-DBC6-4C30-8DE4-35A67224496E@viagenie.ca> <083DE005-6700-42A9-AA79-80D33B384F79@viagenie.ca> To: Maoke X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 02:12:39 -0000 Here's the situation. There was no clear consensus in the WG meeting in = Paris. But the IETF conducts its business on the mailing list, so - as = we always do - the chairs asked for feedback on the two questions asked = in Paris. We'll use the responses to assess if there is consensus for = the choices in each of those questions. - Ralph On Apr 4, 2012, at 8:52 PM 4/4/12, Maoke wrote: >=20 >=20 > 2012/4/4 Marc Blanchet > Le 2012-04-03 =E0 22:25, Maoke a =E9crit : >>=20 >> a serious point not of the Apr-1 joke: as an IETF WG, we are obliged = to provide surely high-quality document to the market. even we believe = market choice, at least we have to publish what we ourselves have well = understood, carefully coded and well tested.=20 >> otherwise, the market would see IETF more of a group of doc-makers = rather than technology-explorers. >=20 > agreed. then what do we do in the absence of consensus? I proposed one = solution. >=20 > i propose another, maybe closer to the chairs' opinion: let's do the = vote and decide with the game rule of "majority wins", stopping the = endless vote. ;-) - maoke > =20 >=20 > Marc. >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Wed Apr 4 22:55:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96E11E80E7 for ; Wed, 4 Apr 2012 22:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExTUj7G1nWnl for ; Wed, 4 Apr 2012 22:55:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8CB11E80DC for ; Wed, 4 Apr 2012 22:55:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 33D8F22C523; Thu, 5 Apr 2012 07:55:46 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1838C238048; Thu, 5 Apr 2012 07:55:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 5 Apr 2012 07:55:45 +0200 From: To: Alain Durand , "softwires@ietf.org WG" Date: Thu, 5 Apr 2012 07:55:44 +0200 Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgASJDTA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806A5C@PUEXCB1B.nanterre.francetelecom.fr> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 05:55:48 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Mohamed BOUCADAIR, France Telecom: YES ---------------------------------------------------------------------------= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Mohamed BOUCADAIR, France Telecom: MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= From satoru.matsushima@gmail.com Wed Apr 4 23:21:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D952811E80DC for ; Wed, 4 Apr 2012 23:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GjtCeja09Rr for ; Wed, 4 Apr 2012 23:21:10 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E811E8079 for ; Wed, 4 Apr 2012 23:21:09 -0700 (PDT) Received: by dady13 with SMTP id y13so1654266dad.27 for ; Wed, 04 Apr 2012 23:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NQD+cNLDtjfyg0kk0ABAM96OTPvJdwjvP55TpTk+UQk=; b=xnXKgwdMzeEiQ5sl+L7Wp2mdNm7B38p3zee0U0pP5E6aCGe3O/YB3BnOAls1xUqdL2 l7hCquFa6XYRaHEFsfPJ7QM8m+nBY0NFBhn7j5v0LzwQSmpqIDXLh3/dM4oeZfUT8MDW 3HB4l6ZifOB+i7b3bY9aGBEuPjNVSmstwSvKOHe1JygUPXgA00hIMs51+OZ5Jgrjfq9g 6sEMd2vFPHJElPMEILk3knSp+WhPQbZ4oBPfxAGdD/9Zh6ZtXUB/TbSX8z2lZ0t4MMEh 0BRkhvCcaVyf0sYO7nn9DDGvy+xOLBitaRaFroubObP1xdFqXLzqBlUQJIdqkdq7/rNw Plqg== Received: by 10.68.194.40 with SMTP id ht8mr4153341pbc.122.1333606869074; Wed, 04 Apr 2012 23:21:09 -0700 (PDT) Received: from [10.201.82.174] ([202.45.12.141]) by mx.google.com with ESMTPS id b10sm2351863pbr.46.2012.04.04.23.21.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 23:21:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 15:21:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4848E1-0696-4D2A-88ED-D656CEA243E1@gmail.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 06:21:11 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as = standard track. Answering NO to this question means you want to see both advance on the = standard track. = --------------------------------------------------------------------------= -- Satoru Matsushima, Softbank Telecom: YES = --------------------------------------------------------------------------= -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? = --------------------------------------------------------------------------= ---- Satoru Matsushima, Softbank Telecom: MAP = --------------------------------------------------------------------------= ----= From chunfa.sun@g.softbank.co.jp Wed Apr 4 23:24:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6011E8079 for ; Wed, 4 Apr 2012 23:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFkRtfpLDwCD for ; Wed, 4 Apr 2012 23:24:28 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id CA6B821F8771 for ; Wed, 4 Apr 2012 23:24:27 -0700 (PDT) Received: from mail-wg0-f52.google.com ([74.125.82.52]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT306m0r2fUebBOzS8fo2GwN+dXRjatnN@postini.com; Wed, 04 Apr 2012 23:24:28 PDT Received: by wgbgn7 with SMTP id gn7so1061075wgb.9 for ; Wed, 04 Apr 2012 23:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ty84xY4XFgMCCeLbSPUJvydNMYIJ3CPv5vmEptxS2n4=; b=o6/nxWE0B21tW4s0vcJNkT+McwFuZm7ZDHlpoVzHLM04/w/scbb3wMXVyBvRPM94Vf j3FpJogZcpo0YeSD3sO12ZvftHnzHTgsu34t9libyJntaB+t/C4jumf0YV3QXaNe7R47 RJ4WlgrRErEWoDElMhJvypdWlH8k6De7CnosM2xGXdXaor87TR7W2GHBOd4gSxSxjccO W3p861Gl6AWn/+CmhiU3uMQ2cyaResyTz9K/3iE6hUD1Z5/bXXk+ZbBW7YNopdLOa3Bz 0S77b88Tk+NLr3Cdv3vJ3qNs/3UW2ZKAj7s4xD+OkPy3dGT++1OUTCay8/ULSDiUJzx7 rj4g== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr2042062wib.3.1333607065577; Wed, 04 Apr 2012 23:24:25 -0700 (PDT) Received: by 10.223.126.80 with HTTP; Wed, 4 Apr 2012 23:24:25 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 15:24:25 +0900 Message-ID: From: =?UTF-8?B?5a2rIOaYpeeZuu+8iOODjeODg+ODiOODr+ODvOOCr+acrOmDqO+8iS0gU3VuIENodW5mYSAt?= To: Alain Durand Content-Type: multipart/alternative; boundary=f46d0444ee2d69e8ff04bce897b3 X-Gm-Message-State: ALoCoQmyyTlQZl3b6/LMr4RQK+m92MqfQXT/dHw9dLGD/zIc97X8CRhs7zp7UQ6+OSv06Ic8qFD9 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 06:24:29 -0000 --f46d0444ee2d69e8ff04bce897b3 Content-Type: text/plain; charset=UTF-8 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Chunfa SUN, Softbank BB: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Chunfa SUN, Softbank BB: MAP ------------------------------------------------------------ ------------------ 2012/4/5 Alain Durand > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d0444ee2d69e8ff04bce897b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR M= AP (as a whole) on the standard track,
the other being published as expe= rimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both a= dvance on the standard track.

--------------------------------------= --------------------------------------
Chunfa SUN, Softbank BB: YES
--------------------------------------------= --------------------------------

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track= :
4rd-U or MAP?

-------------------------------------------------= -----------------------------
Chunfa SUN, Softbank BB:= MAP
--------------------------------------------= ----------------------------------=C2=A0

<= div class=3D"gmail_quote">2012/4/5 Alain Durand <adurand@juniper.net>
Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) =C2=A0and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should mak= e this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

---------------------------------------------------------------------------= -
Your full name, your affiliation, your choice: YES or NO
---------------------------------------------------------------------------= -


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

---------------------------------------------------------------------------= ---
Your full name, your affiliation, your choice: 4rd-U or MAP
---------------------------------------------------------------------------= ---

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d0444ee2d69e8ff04bce897b3-- From shuwang@cisco.com Wed Apr 4 23:33:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269AF21F879C for ; Wed, 4 Apr 2012 23:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDb-mJKuFqDY for ; Wed, 4 Apr 2012 23:33:06 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7448F21F8775 for ; Wed, 4 Apr 2012 23:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shuwang@cisco.com; l=2907; q=dns/txt; s=iport; t=1333607585; x=1334817185; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hYaMXqZcztI+l+DcQJehAEtoRnL126zZxZWei5EjjIc=; b=P9iRyAPmtWqWp3ck9DNc8IvA7lApuaeBW2I7I3kf56w5MzKTuXolmkzQ JSQa2IpSx7P1bHB2gfjMUpTOmfPfsbjLm1MOKJcKzJaFr8Bif8269mUQu KhbiaUtGZDVqIKLwxw62NLY4/1hrfnES4kOspZr7Mwa5I0oeRaz9hvcf0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHk7fU9Io8UY/2dsb2JhbABFhW+zcoIJAQEBBAEBAQ8BHT4LDAQCAQYCDgMEAQEFBgYXAQQCASYfCQgBAQQBEggTB4dsC5s9jQIIhAGGEog8BIErhGKJJjljBIhXm1uBaYJ0 X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="9326710" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Apr 2012 06:33:03 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q356WYAe006779; Thu, 5 Apr 2012 06:33:03 GMT Received: from xmb-hkg-417.apac.cisco.com ([64.104.123.89]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 14:33:00 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 14:33:00 +0800 Message-ID: <2A8093F1B7F25A4B80531FEB55B885D702A09FBD@xmb-hkg-417.apac.cisco.com> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgATfCjw References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> From: "Shu Wang (shuwang)" To: "Alain Durand" , X-OriginalArrivalTime: 05 Apr 2012 06:33:00.0826 (UTC) FILETIME=[F27E3FA0:01CD12F5] Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 06:33:07 -0000 -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On = Behalf Of Alain Durand Sent: 2012=C4=EA4=D4=C25=C8=D5 5:14 To: softwires@ietf.org WG Cc: int-ads@tools.ietf.org; Softwire Chairs Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U = vs MAP Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and 4rd-U. We got very strong feedback that we needed to = select one solution to cover that full stateless case, not two, and that = we should make this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask = the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track, the other being published as = experimental or informational. Answering YES to this question means you agree we cannot publish both as = standard track. Answering NO to this question means you want to see both advance on the = standard track. -------------------------------------------------------------------------= --- Your full name, your affiliation, your choice: YES or NO -------------------------------------------------------------------------= --- Shu Wang, Cisco, Yes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? -------------------------------------------------------------------------= ----- Your full name, your affiliation, your choice: 4rd-U or MAP -------------------------------------------------------------------------= ----- Shu Wang, Cisco, MAP.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please fill out the following form and reply to the list by Wednesday = 4/10 5pm EDT. Note: Use this thread ONLY for expressing your support to one OR the = other, and redirect any discussions to other threads. That would help up gauge consensus. Alain & Yong. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Apr 5 00:08:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A011E80AB for ; Thu, 5 Apr 2012 00:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kYwJI0ErsU6 for ; Thu, 5 Apr 2012 00:08:38 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1920A11E80C0 for ; Thu, 5 Apr 2012 00:08:37 -0700 (PDT) Received: by qaea16 with SMTP id a16so719817qae.10 for ; Thu, 05 Apr 2012 00:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+zQ94Tond/IHtY+zolatJKyMkXVjZfmC0IlElrK1OFo=; b=klTwZLlzmVT/31oCvxbe+5X5B+and04eUZvdZgnY4zYVO45A2+bUSnTzmIyp5ACHlV 5LOur5YVzNMumKVoaVZ1yJcgmrVGs75IAfJ+UPwo1baHYlxf0DFgi1loP+aAywLg9+IF IlCU8zchB8eWCgwcyMNxJ/54pcd7/osK9h6+MJbIr3HIKsjDO6zA3EhWRyJm9+TBlA7p 8qM6+eAoW7te8TWj1EtHd4e03uZeSzLe67bUv+M/cPEKxSZGmNvpkgGwNXeD7ltdKVU+ PfvHGjNvOXycitRASlAt7+KfdpDqjwokO/hUKNZnl5HasImuZp04YemyMFl0xv6AkrKg gm4g== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr2597698qao.23.1333609717555; Thu, 05 Apr 2012 00:08:37 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 5 Apr 2012 00:08:37 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 07:08:37 +0000 Message-ID: From: Maoke To: Alain Durand Content-Type: multipart/alternative; boundary=20cf3074b41a7be30004bce93525 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:08:39 -0000 --20cf3074b41a7be30004bce93525 Content-Type: text/plain; charset=ISO-8859-1 2012/4/4 Alain Durand > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > ---------------------------------------------------------------------------- Maoke CHEN, FreeBit, choice: YES ---------------------------------------------------------------------------- > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ Maoke CHEN, FreeBit, choice: MAP ------------------------------------------------------------------------------ > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b41a7be30004bce93525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/4 Alain Durand = <adurand@juniper.net>
Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) =A0and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should mak= e this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

--------------------------= --------------------------------------------------
=A0Maoke CHEN, FreeBi= t, choice: YES
---------------------------------------------------------------------------= -
=A0
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

-----------------------------------------------------= -------------------------
=A0Maoke CHEN, FreeBit, choice: MAP
---------------------------------------------------------------------------= ---
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b41a7be30004bce93525-- From christian.jacquenet@orange.com Thu Apr 5 00:30:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFDB21F8697 for ; Thu, 5 Apr 2012 00:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW80-gJYTJ7t for ; Thu, 5 Apr 2012 00:30:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BBB4021F8694 for ; Thu, 5 Apr 2012 00:30:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id DDE522DC111; Thu, 5 Apr 2012 09:30:05 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AB2B6238067; Thu, 5 Apr 2012 09:30:05 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 5 Apr 2012 09:30:05 +0200 From: To: Alain Durand , "softwires@ietf.org WG" Date: Thu, 5 Apr 2012 09:27:09 +0200 Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgAVWvUw Message-ID: <17168_1333611005_4F7D49FD_17168_1411_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793DA5CE0@PUEXCB1C.nanterre.francetelecom.fr> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:30:08 -0000 Hi, [snip] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or i= nformational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------- Christian Jacquenet, France Telecom: YES ---------------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Christian Jacquenet, France Telecom: MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hide@fnsc.co.jp Thu Apr 5 00:53:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21A21F86EA for ; Thu, 5 Apr 2012 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcZP63QCFojg for ; Thu, 5 Apr 2012 00:53:27 -0700 (PDT) Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id A225321F85F7 for ; Thu, 5 Apr 2012 00:53:27 -0700 (PDT) Received: from ([192.52.122.75]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.823456; Thu, 05 Apr 2012 16:53:22 +0900 Received: from osim.fnsc.co.jp (osim [192.52.122.100]) by mailserv.fnsc.co.jp (Postfix) with ESMTP id 4C9CB49011; Thu, 5 Apr 2012 16:53:22 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by osim.fnsc.co.jp (2008/8.13.6) with SMTP id q357rL6Q020191; Thu, 5 Apr 2012 16:53:21 +0900 (JST) Received: from eagle.inf.fnsc.co.jp (eagle.inf.fnsc.co.jp [158.202.238.138] (may be forged)) by osim.fnsc.co.jp (2008/8.13.6) with ESMTP id q357rBlr020159; Thu, 5 Apr 2012 16:53:12 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Hideaki HAYASHI In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 16:53:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:53:28 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as = standard track. Answering NO to this question means you want to see both advance on the = standard track. = --------------------------------------------------------------------------= -- Hideaki HAYASHI, FURUKAWA NETWORK SOLUTION: YES = --------------------------------------------------------------------------= -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? = --------------------------------------------------------------------------= ---- Hideaki HAYASHI, FURUKAWA NETWORK SOLUTION: MAP = --------------------------------------------------------------------------= ----= From despres.remi@laposte.net Thu Apr 5 01:07:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3638D21F8697 for ; Thu, 5 Apr 2012 01:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo6yTdsj4Dhj for ; Thu, 5 Apr 2012 01:07:38 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 442C121F8694 for ; Thu, 5 Apr 2012 01:07:37 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id u87Z1i00737Y3f40387ZkQ; Thu, 05 Apr 2012 10:07:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 10:07:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand , Yong Cui , Ralph Droms , Brian Haberman X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:07:39 -0000 Hi, Alain, Yiong, Ralph, Brian, 1. In view of the lack of sufficient consensus at the Softwire meeting for = a choice between MAP-T+E and 4rd-U, several suggested, at the end of = the meeting and after on the ML, to publish MAP-T+E and 4rd-U as = experimental, with the expectation to select one later on.=20 As a matter of fact, this is in substance what Alain had proposed before = IETF 83 if, during the meeting, there would be no consensus for one = standard track and the other(s) informational. No such consensus having = emerged, that would be the natural outcome.=20 In the mean time, a vendor having announced on the ML its intention to = "implement 4rd-u and do operational tests", it is clear that better = understanding of issues will be possible to enlighten the WG before a = final decision on what deserves standard track. =20 2. Question 1 below (*) formally excludes, independently from received = responses, any possibility that both solutions be published as = experimental (Yes =3D> One on standard track; No =3D> both on standard = track.) I therefore note that this procedure, in addition to be confused (who = may answer, with which conclusion process), is illegitimate.=20 Taking this procedure as conclusive would therefore lead to an = application of RFC2026 sec 6.5.1 (Working Group Disputes). OTOH, publishing now MAP-T+E and 4rd-U as WG documents on the = experimental track would be indisputable. Regards, RD Le 2012-04-04 =E0 23:14, Alain Durand a =E9crit : > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we = should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 (*) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. > = --------------------------------------------------------------------------= -- > Your full name, your affiliation, your choice: YES or NO > = --------------------------------------------------------------------------= -- >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 > = --------------------------------------------------------------------------= ---- > Your full name, your affiliation, your choice: 4rd-U or MAP > = --------------------------------------------------------------------------= ---- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jan@go6.si Thu Apr 5 01:19:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8790D21F87AF for ; Thu, 5 Apr 2012 01:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id widNkaJORVfc for ; Thu, 5 Apr 2012 01:19:12 -0700 (PDT) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id 888C521F87ED for ; Thu, 5 Apr 2012 01:19:11 -0700 (PDT) Received: from jan-mac.simobil.si (unknown [IPv6:2a00:1a20:0:9:4cf2:84cd:6c6d:3002]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 6B05E22B4069 for ; Thu, 5 Apr 2012 10:19:08 +0200 (CEST) Message-ID: <4F7D557C.1000503@go6.si> Date: Thu, 05 Apr 2012 10:19:08 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:19:13 -0000 On 4/4/12 11:14 PM, Alain Durand wrote: > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- Jan Žorž, Go6 Institute: YES > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ Jan Žorž, Go6 Institute: MAP Hope we get this decision asap (one way or another). Cheers, Jan From prvs=34421dc401=edwin.mallette@bhnis.com Thu Apr 5 01:27:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F021F85D4 for ; Thu, 5 Apr 2012 01:27:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP47Hy4Zzn2C for ; Thu, 5 Apr 2012 01:27:42 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3D30221F85D2 for ; Thu, 5 Apr 2012 01:27:42 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id q358P0CL004299; Thu, 5 Apr 2012 04:27:40 -0400 Received: from cnedcex1.corp.local ([10.225.5.11]) by mx3.mybrighthouse.com with ESMTP id 1411gpherf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 05 Apr 2012 04:27:40 -0400 Received: from CNEDCEX3.corp.local ([fe80::ac6f:a581:866a:5f86]) by CNEDCEX1.corp.local ([::1]) with mapi id 14.02.0247.003; Thu, 5 Apr 2012 04:27:40 -0400 From: "Mallette, Edwin J." To: Alain Durand , "softwires@ietf.org WG" Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgAkF7aA Date: Thu, 5 Apr 2012 08:27:40 +0000 Message-ID: In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.225.1.248] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1203120001 definitions=main-1204050016 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:27:42 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. --------------------------------------------------------------------------- - Edwin Mallette, Bright House Networks YES --------------------------------------------------------------------------- - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? --------------------------------------------------------------------------- --- Edwin Mallette, Bright House Networks MAP --------------------------------------------------------------------------- --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From junxu2@cisco.com Thu Apr 5 02:14:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6121F8692 for ; Thu, 5 Apr 2012 02:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSln005K9BuX for ; Thu, 5 Apr 2012 02:14:20 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id B008821F8691 for ; Thu, 5 Apr 2012 02:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=junxu2@cisco.com; l=2807; q=dns/txt; s=iport; t=1333617260; x=1334826860; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8rDX8PVVitLGKXWnudkS7p7+5WfFniATLWdJ0uzNAzQ=; b=fzV3zsNbn5OcKJbQQnsbnZfB4H2xJCgONbRXui3wOBaNu/iShi6oGG++ VRFfuVaJiX6WIVS5927dZaDKVyQnJLqNWE698x5/Q7YPfKUNNQPcM+0YG u3zjQN1VTH0L9HSn6NcSFjCwH1klSD3SOl7j3FcgJt3mWtm7DIYYqlndT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADRifU9Io8UY/2dsb2JhbABFuW+CCQEBAQMBAQEBDwEnNAsFCwtGJzAGARIbB4dnBQubR5ELhiOIPASGDopMBIhXjRSOS4FpgnQ X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="9351735" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 05 Apr 2012 09:14:10 +0000 Received: from dhcp-10-140-1-56.cisco.com (dhcp-10-140-1-56.cisco.com [10.140.1.56]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q359E8Qp017928; Thu, 5 Apr 2012 09:14:09 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jun Xu In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 5 Apr 2012 17:14:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6640F5BB-5A14-4117-8DDA-96293512642B@cisco.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: "softwires@ietf.org WG" , int-ads@tools.ietf.org, Softwire Chairs X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:14:21 -0000 Hi,=20 On Apr 5, 2012, at 5:14 AM, Alain Durand wrote: > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we = should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. >=20 > = --------------------------------------------------------------------------= -- > Your full name, your affiliation, your choice: YES or NO > = --------------------------------------------------------------------------= -- Jun Xu, Cisco, Choice: YES >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 > = --------------------------------------------------------------------------= ---- > Your full name, your affiliation, your choice: 4rd-U or MAP > = --------------------------------------------------------------------------= ---- Jun Xu, Cisco, Choice: MAP >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires Jun Xu=20 From prvs=144210f422=jordi.palet@consulintel.es Thu Apr 5 02:29:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE80E21F8711 for ; Thu, 5 Apr 2012 02:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsDvXcfyERy2 for ; Thu, 5 Apr 2012 02:29:10 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65A21F8709 for ; Thu, 5 Apr 2012 02:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1333617964; x=1334222764; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=itdkNLPpIV5ONIHnDLduZRF9B6RbyL9xRa07J3PO62E=; b=Xlg f0K3+omx1p6gmFt9YYky+ykMOQ3FmU9E7JfCHx+ev5uWpSJ2oPEMGhKgnYVAWgVd dWPnFBliKtj+ml0JUZSBglPGx3QxqPyGbNsBilZeybrQICCxMEQjoNF7UOVk58lw c7Iy5c2bwO2t9ThZT06CMtf1tbdZgmfUxjnU9bI0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=YmjwA6Bi3aZD8qqptt87nUwJ3QZv7MgwdgYqD5fbZU6yw1V0HhNpfcYoiL+D TDB9Z5kZUXKcV+8g3OoDDejGqfrsz0CVWvRqNcnxOEavTZdt/cBsIcriZ Mn8q6OHbzR6H1WY9WZKYyaZaBIeO9V8Vwr6W35FO9NW0O0B99Lltwg=; X-MDAV-Processed: consulintel.es, Thu, 05 Apr 2012 11:26:04 +0200 Received: from [10.10.10.169] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50004139397.msg for ; Thu, 05 Apr 2012 11:26:03 +0200 X-Spam-Processed: consulintel.es, Thu, 05 Apr 2012 11:26:03 +0200 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:120405:md50004139397::VFfq0MbOqzivefcJ:000015Ef X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=144210f422=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: softwires@ietf.org User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 05 Apr 2012 11:28:56 +0200 From: JORDI PALET MARTINEZ To: "softwires@ietf.org WG" , , Softwire Chairs Message-ID: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP In-Reply-To: <6640F5BB-5A14-4117-8DDA-96293512642B@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:29:10 -0000 I'm sorry, but I think the first question is wrong if we don't have one more question at the end. My understanding is that it is up to the WG to decide if, in case one solution is accepted for standards track, the other one need to be withdraw from the WG instead of going to experimental or informational. I don't think this decision can be taken by the chairs or ADs, and it must be done now, otherwise it may be appealed later, so we will have extra work, a new consensus poll, etc. Another point. In IETF we act as individuals, so why should we indicate our affiliation ? The right question set must be: Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental, informational or abandon by the WG. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. Your full name, your affiliation, your choice: YES or NO Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? Your full name, your choice: 4rd-U or MAP Question 3: The remaining solution (the one NOT accepted by the consensus of the WG) should be published as experimental, informational, or abandon by the WG (so the authors can take other paths if they believe so). Your full name, your choice: experimental, informational or abandon. Regards, Jordi -----Mensaje original----- De: Jun Xu Responder a: Fecha: Thu, 5 Apr 2012 17:14:08 +0800 Para: "softwires@ietf.org WG" , , Softwire Chairs Asunto: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP >Hi, > >On Apr 5, 2012, at 5:14 AM, Alain Durand wrote: > >> Dear Softwire wg members: >> >> At the Paris IETF Softwire meeting, we had presentations on MAP (taken >>as a whole) and >> 4rd-U. We got very strong feedback that we needed to select one >> solution to cover that full stateless case, not two, and that we should >>make this >> decision relatively quickly. >> >> During Paris meeting, we asked the following additional question: >> Do you prefer MAP or 4rd-U? >> We got about 1/3 support for 4rd-U and 2/3 for MAP. >> >> The real gauge of consensus is the mailing list, so we would like >> to ask the same questions to the list. >> >> ===================================================================== >> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as >>a whole) on the standard track, >> the other being published as experimental or informational. >> Answering YES to this question means you agree we cannot publish both >>as standard track. >> Answering NO to this question means you want to see both advance on the >>standard track. >> >> >>------------------------------------------------------------------------- >>--- >> Your full name, your affiliation, your choice: YES or NO >> >>------------------------------------------------------------------------- >>--- >Jun Xu, Cisco, Choice: YES >> >> >> ===================================================================== >> >> Questions 2: Which one do you want to see placed on the Standards Track: >> 4rd-U or MAP? >> >> >>------------------------------------------------------------------------- >>----- >> Your full name, your affiliation, your choice: 4rd-U or MAP >> >>------------------------------------------------------------------------- >>----- >Jun Xu, Cisco, Choice: MAP >> >> ===================================================================== >> >> >> >> >> Please fill out the following form and reply to the list >> by Wednesday 4/10 5pm EDT. >> >> Note: Use this thread ONLY for expressing your support to >> one OR the other, and redirect any discussions to other threads. >> That would help up gauge consensus. >> >> Alain & Yong. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >Jun Xu > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From prvs=144210f422=jordi.palet@consulintel.es Thu Apr 5 02:42:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D040E21F8701 for ; Thu, 5 Apr 2012 02:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YE3LWb8V+5v for ; Thu, 5 Apr 2012 02:42:26 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4696221F86EB for ; Thu, 5 Apr 2012 02:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1333618764; x=1334223564; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=k/lG0ODYe9QPsrTTBmDBz1onwJpE2BeOYOH2UaW1bCE=; b=jgG NeHOrdDC3xoyphZ/h8rgnGheUSg0JCHpofSYdrFisYKLTIc6K+uYGv859uTpdAD1 AiCITQ7dsOJCpjR+D6BRKN3gn+0hyNQ7/9PH337YVLXQkC2F6MUaFEJryjeIiTxA PY1qE5tlLJqBbrFeqxAdO8Re+K+lwh26WKfalIyI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=C7Hmewjo5adBKvcTWv0MgqRtk+B/3rs92ug5vMdoyStZQ13D2Y3VIW7/6COA PUytjQutCK3pZgdSrCSXw9IcphEg3M/iByWlNfbW2tf2EthyIoFkynsvt jmkpGpUELhsqk8QVdn4oVUan8yN1S9YoxOtJd3vm89uBaUqH43tNbk=; X-MDAV-Processed: consulintel.es, Thu, 05 Apr 2012 11:39:24 +0200 Received: from [10.10.10.169] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50004139404.msg for ; Thu, 05 Apr 2012 11:39:23 +0200 X-Spam-Processed: consulintel.es, Thu, 05 Apr 2012 11:39:23 +0200 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:120405:md50004139404::rIz+LKLV2RNr4P2E:00000AZK X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=144210f422=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: softwires@ietf.org User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 05 Apr 2012 11:42:01 +0200 From: JORDI PALET MARTINEZ To: "softwires@ietf.org WG" , , Softwire Chairs Message-ID: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:42:27 -0000 Yes, but this is a key aspect of the decision, so the WG should decide, nobody else. Being asked for the affiliation is already telling the folks to say so. It should not be asked. Regards, Jordi -----Mensaje original----- De: Wojciech Dec Responder a: Fecha: Thu, 5 Apr 2012 11:36:23 +0200 Para: Jordi Palet Martinez , Softwire Chairs Asunto: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP >RFC2418 says: >" >The Working Group Chair is concerned with making forward progress > through a fair and open process, and has wide discretion in the > conduct of WG business." > >Also, it does not appear that you're forced to state your affiliation, if >you don't want to. > >-Woj. > >On 5 April 2012 11:28, JORDI PALET MARTINEZ >wrote: > >I'm sorry, but I think the first question is wrong if we don't have one >more question at the end. > >My understanding is that it is up to the WG to decide if, in case one >solution is accepted for standards track, the other one need to be >withdraw from the WG instead of going to experimental or informational. I >don't think this decision can be taken by the chairs or ADs, and it must >be done now, otherwise it may be appealed later, so we will have extra >work, a new consensus poll, etc. > >Another point. In IETF we act as individuals, so why should we indicate >our affiliation ? > >The right question set must be: > >Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a >whole) on the standard track, > >the other being published as experimental, informational or abandon by the >WG. >Answering YES to this question means you agree we cannot publish both as >standard track. >Answering NO to this question means you want to see both advance on the >standard track. > > >Your full name, your affiliation, your choice: YES or NO > > > > >Questions 2: Which one do you want to see placed on the Standards Track: >4rd-U or MAP? > > > >Your full name, your choice: 4rd-U or MAP > >Question 3: The remaining solution (the one NOT accepted by the consensus >of the WG) should be published as experimental, informational, or abandon >by the WG (so the authors can take other paths if they believe so). > > >Your full name, your choice: experimental, informational or abandon. > > > > >Regards, >Jordi > > > > > > >-----Mensaje original----- >De: Jun Xu >Responder a: >Fecha: Thu, 5 Apr 2012 17:14:08 +0800 >Para: "softwires@ietf.org WG" , >, Softwire Chairs >Asunto: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U >vs MAP > >>Hi, >> >>On Apr 5, 2012, at 5:14 AM, Alain Durand wrote: >> >>> Dear Softwire wg members: >>> >>> At the Paris IETF Softwire meeting, we had presentations on MAP (taken >>>as a whole) and >>> 4rd-U. We got very strong feedback that we needed to select one >>> solution to cover that full stateless case, not two, and that we should >>>make this >>> decision relatively quickly. >>> >>> During Paris meeting, we asked the following additional question: >>> Do you prefer MAP or 4rd-U? >>> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>> >>> The real gauge of consensus is the mailing list, so we would like >>> to ask the same questions to the list. >>> >>> ===================================================================== >>> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as >>>a whole) on the standard track, >>> the other being published as experimental or informational. >>> Answering YES to this question means you agree we cannot publish both >>>as standard track. >>> Answering NO to this question means you want to see both advance on the >>>standard track. >>> >>> >>>------------------------------------------------------------------------ >>>- >>>--- >>> Your full name, your affiliation, your choice: YES or NO >>> >>>------------------------------------------------------------------------ >>>- >>>--- >>Jun Xu, Cisco, Choice: YES >>> >>> >>> ===================================================================== >>> >>> Questions 2: Which one do you want to see placed on the Standards >>>Track: >>> 4rd-U or MAP? >>> >>> >>>------------------------------------------------------------------------ >>>- >>>----- >>> Your full name, your affiliation, your choice: 4rd-U or MAP >>> >>>------------------------------------------------------------------------ >>>- >>>----- >>Jun Xu, Cisco, Choice: MAP >>> >>> ===================================================================== >>> >>> >>> >>> >>> Please fill out the following form and reply to the list >>> by Wednesday 4/10 5pm EDT. >>> >>> Note: Use this thread ONLY for expressing your support to >>> one OR the other, and redirect any discussions to other threads. >>> That would help up gauge consensus. >>> >>> Alain & Yong. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >>Jun Xu >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. > > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nanchen@cisco.com Thu Apr 5 02:42:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E374421F8687 for ; Thu, 5 Apr 2012 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG3FEp5SfCi6 for ; Thu, 5 Apr 2012 02:42:59 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id B75A321F871E for ; Thu, 5 Apr 2012 02:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nanchen@cisco.com; l=1782; q=dns/txt; s=iport; t=1333618979; x=1334828579; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=CtzYYXp6T8sxqUwnqs6Mnx+ypIyKx7VuWo6seU9JHBY=; b=GIzFjgWd+pi0T6SM/I/PdefcfEk5nRzUdDtWSf43XfjXdE/48Z4Bepyn CEM//bQRDOcsseYPqLhaf1d6ZFkkwbi45txYkwdbtVRdxKyi6NsAq9gbi Ue03kfiDskCek+whcmiqPT5cy/esH/b2v417TyqI3zyY66quxUX0bt99x E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAE1ofU9Io8UY/2dsb2JhbABFuW+CCgEBBAEBAQ8BJzQbC0YnMAYBEiKHbAubOJ9tBI93YwSIV40UjkuBaYJ0 X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="9355851" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Apr 2012 09:42:55 +0000 Received: from dhcp-10-140-16-227.cisco.com (dhcp-10-140-16-227.cisco.com [10.140.16.227]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q359gqgU023062; Thu, 5 Apr 2012 09:42:53 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Nan Chen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28806A5C@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 5 Apr 2012 17:42:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <94C682931C08B048B7A8645303FDC9F36E28806A5C@PUEXCB1B.nanterre.francetelecom.fr> To: "mohamed.boucadair@orange.com> , "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:43:00 -0000 On Apr 5, 2012, at 1:55 PM, = wrote: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. >=20 >=20 = --------------------------------------------------------------------------= -- Nan CHEN, Cisco, YES = --------------------------------------------------------------------------= -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 >=20 = --------------------------------------------------------------------------= -- Nan CHEN, Cisco, MAP = --------------------------------------------------------------------------= -- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tomasz.mrugalski@gmail.com Thu Apr 5 05:38:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19A21F87AD for ; Thu, 5 Apr 2012 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epoxc2y-Q4XO for ; Thu, 5 Apr 2012 05:38:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC221F87A9 for ; Thu, 5 Apr 2012 05:38:23 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1388006bku.31 for ; Thu, 05 Apr 2012 05:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=izy/0mBbU8Wv4s+WAgwUcCUZypkwvxFJ8SrHPSetCmA=; b=h34LK3TbGOmQ9K1vgDEUWEErIKzUiwDuefV+cXcxnHp8G2y95dV7AaMT44Zk4iFrcB xYdhZboXfR+dVMYquvi/Zwyu8+tMz7I9X5BjNQUV2Eez6Kp1AzHwEwOWV7AvpaB3Y1LA zkaU+V8SFwn/9LfHxRUbhviRpgW0gYxoDxdTKsXhOiAxmyS7hS4O+xbyTXcY+ETG6UJl SI0KXMpp4jFwP2hXvF1SONOcRwCSt7ao6zjDU+W0B82xtoXBgIt2ZZiC4fpmhp93exDX Y7fb+beLVfSxovIwGFXH43CkKG5g/qdls+04YBhDO2jw0CeGS+qrbthCOxYQne/f5vzu /FRw== Received: by 10.204.143.151 with SMTP id v23mr1115699bku.63.1333629502435; Thu, 05 Apr 2012 05:38:22 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id cy11sm8598378bkb.7.2012.04.05.05.38.21 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 05:38:21 -0700 (PDT) Message-ID: <4F7D9239.7080008@gmail.com> Date: Thu, 05 Apr 2012 14:38:17 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: softwires@ietf.org References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-TagToolbar-Keys: D20120405143817952 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:38:24 -0000 On 04.04.2012 23:14, Alain Durand wrote: > Dear Softwire wg members: > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > ---------------------------------------------------------------------------- Tomasz Mrugalski, Internet Systems Consortium, YES ---------------------------------------------------------------------------- > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > ------------------------------------------------------------------------------ Tomasz Mrugalski, Internet Systems Consortium, MAP ------------------------------------------------------------------------------ Cheers, Tomek From rdroms@cisco.com Thu Apr 5 06:02:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EB921F87FE for ; Thu, 5 Apr 2012 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of0CSY8HC5KN for ; Thu, 5 Apr 2012 06:02:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 099BD21F87D8 for ; Thu, 5 Apr 2012 06:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=6008; q=dns/txt; s=iport; t=1333630938; x=1334840538; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PUdIDSmN66pLbVktGbd0yVgPUxyJldDMbmp7JO8ZGl4=; b=Fe0giNF9hIlTtqAO7TP/ZCKfcfJmw8uDMXPCXvRVWzBTHTns5Y4868GN 9UjRIZrgVEXRd9nQiK1gx55P4zU0GLdB1NgU9gQGjBKAatJ19fitBQgle CRhHZVzeQBmC9PAlHbIMt81NNiIMDCqPVutH1Uww7wi9ncvjM/e2LzsYl A=; X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="72326358" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 05 Apr 2012 13:02:17 +0000 Received: from rtp-rdroms-8912.cisco.com (rtp-rdroms-8912.cisco.com [10.116.164.51]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q35D2GXV014909; Thu, 5 Apr 2012 13:02:17 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Thu, 5 Apr 2012 09:02:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:02:19 -0000 On Apr 5, 2012, at 4:07 AM 4/5/12, R=E9mi Despr=E9s wrote: > Hi, Alain, Yiong, Ralph, Brian, >=20 > 1. > In view of the lack of sufficient consensus at the Softwire meeting = for a choice between MAP-T+E and 4rd-U, several suggested, at the end = of the meeting and after on the ML, to publish MAP-T+E and 4rd-U as = experimental, with the expectation to select one later on.=20 Assessment of the consensus in the WG meeting is informative but not = final. As is usual IETF practice, the chairs are now assessing WG = consensus on the mailing list. Therefore, it is too early to make a = decision to publish both specifications as Experimental. > As a matter of fact, this is in substance what Alain had proposed = before IETF 83 if, during the meeting, there would be no consensus for = one standard track and the other(s) informational. No such consensus = having emerged, that would be the natural outcome.=20 >=20 > In the mean time, a vendor having announced on the ML its intention to = "implement 4rd-u and do operational tests", it is clear that better = understanding of issues will be possible to enlighten the WG before a = final decision on what deserves standard track. You raise an issue that, to my memory, has not been explored in any = great detail. The MAP specification documents have been published and = stable (with, I think, one minor exception) since January, while 4 = revisions of the 4rd-u document have been published, with what appear to = be major revisions, in that same time period. My understanding is that = there is running code for the MAP specification (both transport = variants). We've already delayed progress on the "stateless" = specification since you announced the first versions of 4rd-u. Now you = are asking us to wait to make a decision for a vendor who has "announced = on the ML its intention to "implement 4rd-u and do operational tests"". = The present state of the maturity and experience with MAP and 4rd-u = should be considered at this point in time as the WG expresses its = preference for a way forward. > 2. > Question 1 below (*) formally excludes, independently from received = responses, any possibility that both solutions be published as = experimental (Yes =3D> One on standard track; No =3D> both on standard = track.) This question about "both Experimental" only needs to be asked if there = is no clear consensus to support publication of one specification. > I therefore note that this procedure, in addition to be confused (who = may answer, with which conclusion process), is illegitimate.=20 > Taking this procedure as conclusive would therefore lead to an = application of RFC2026 sec 6.5.1 (Working Group Disputes). >=20 > OTOH, publishing now MAP-T+E and 4rd-U as WG documents on the = experimental track would be indisputable. I disagree. That decision would be premature prior to assessment of WG = consensus to publish one or the other. - Ralph >=20 > Regards, > RD >=20 >=20 > Le 2012-04-04 =E0 23:14, Alain Durand a =E9crit : >=20 >> Dear Softwire wg members: >>=20 >> At the Paris IETF Softwire meeting, we had presentations on MAP = (taken as a whole) and >> 4rd-U. We got very strong feedback that we needed to select one >> solution to cover that full stateless case, not two, and that we = should make this >> decision relatively quickly. >>=20 >> During Paris meeting, we asked the following additional question: >> Do you prefer MAP or 4rd-U? >> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>=20 >> The real gauge of consensus is the mailing list, so we would like >> to ask the same questions to the list. >>=20 >=20 > (*) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, >> the other being published as experimental or informational. >> Answering YES to this question means you agree we cannot publish both = as standard track. >> Answering NO to this question means you want to see both advance on = the standard track. >=20 >=20 >=20 >> = --------------------------------------------------------------------------= -- >> Your full name, your affiliation, your choice: YES or NO >> = --------------------------------------------------------------------------= -- >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Questions 2: Which one do you want to see placed on the Standards = Track: >> 4rd-U or MAP? >>=20 >> = --------------------------------------------------------------------------= ---- >> Your full name, your affiliation, your choice: 4rd-U or MAP >> = --------------------------------------------------------------------------= ---- >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >> Please fill out the following form and reply to the list >> by Wednesday 4/10 5pm EDT. >>=20 >> Note: Use this thread ONLY for expressing your support to >> one OR the other, and redirect any discussions to other threads. >> That would help up gauge consensus. >>=20 >> Alain & Yong. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ssenthil@cisco.com Thu Apr 5 06:07:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328021F881E for ; Thu, 5 Apr 2012 06:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL0bAYaRKi5d for ; Thu, 5 Apr 2012 06:07:34 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2B21F87F4 for ; Thu, 5 Apr 2012 06:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=3236; q=dns/txt; s=iport; t=1333631254; x=1334840854; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=bgGdwN4bd0XGeLZACO4LdIQEljtycBJ1pktrH9lCqk8=; b=GzQeeIlQuuTGUHMDuBF/YP0ZADl7OEz4iKJUhAMzo87ktLOhLjmWF8+V uM8HIrlcDaxP4q6PPt06ZEGXXGpY/t2VG9YW7Ro7uVi1lrtJjMPlbMOWU bvSHxvhsVo/Dxse0SjuF5CBKtqY5gkivzUYZ9fgalN0rKFmcohNw6jcSn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANaYfU+rRDoJ/2dsb2JhbABCuHmBB4IJAQEBAwEBAQEPAScCATELBQ0BCAkFXzABAQQBDQUbB4dnBAELn1qRC4YzVASGDopMBI4Fh2aOS4FpgwM X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="39197056" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 05 Apr 2012 13:07:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q35D7FpU020741; Thu, 5 Apr 2012 13:07:15 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 06:07:15 -0700 Received: from 10.117.198.135 ([10.117.198.135]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Apr 2012 13:07:14 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Thu, 05 Apr 2012 09:07:13 -0400 From: ssenthil To: Alain Durand , "softwires@ietf.org WG" Message-ID: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgAhSOG9 In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Apr 2012 13:07:15.0015 (UTC) FILETIME=[057D0D70:01CD132D] Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:07:35 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Senthil Sivakumar, Cisco: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------- -- Senthil Sivakumar, Cisco: MAP ---------------------------------------------------------------------------- -- Senthil On 4/4/12 5:14 PM, "Alain Durand" wrote: > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a > whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make > this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From simon.perreault@viagenie.ca Thu Apr 5 06:39:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4F21F8828 for ; Thu, 5 Apr 2012 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BAEu8ScKzVm for ; Thu, 5 Apr 2012 06:39:53 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1C21F881D for ; Thu, 5 Apr 2012 06:39:53 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:dd47:cdbf:bea2:5e9e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 962D340E04 for ; Thu, 5 Apr 2012 09:39:52 -0400 (EDT) Message-ID: <4F7DA0A7.2030102@viagenie.ca> Date: Thu, 05 Apr 2012 09:39:51 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:39:54 -0000 On 2012-04-04 17:14, Alain Durand wrote: > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. Simon Perreault, Viagénie, YES (*) (*) That's assuming we can reach a consensus. Otherwise both as experimental sounds like the obvious way out. > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? Simon Perreault, Viagénie, 4rd-U Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jaqueline.queiroz@orange.com Thu Apr 5 07:06:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D321F86B9 for ; Thu, 5 Apr 2012 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-6r+OFtQIrj for ; Thu, 5 Apr 2012 07:06:48 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0A97521F86B7 for ; Thu, 5 Apr 2012 07:06:48 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BAD83E3037A; Thu, 5 Apr 2012 16:08:27 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B3298E30375; Thu, 5 Apr 2012 16:08:27 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 16:06:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 16:06:46 +0200 Message-ID: <355A518BC0575547B2A3D6773AAF8EEF020C0A87@ftrdmel1> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgAjROiw References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> From: To: , X-OriginalArrivalTime: 05 Apr 2012 14:06:47.0268 (UTC) FILETIME=[56B79A40:01CD1335] Cc: int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:06:48 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ------------------------------------------------------------------------ ---- Jaqueline QUEIROZ, France Telecom: YES ------------------------------------------------------------------------ ---- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------ ------ Jaqueline QUEIROZ, France Telecom: MAP ------------------------------------------------------------------------ ------ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Rgds, Jaqueline Queiroz=20 From despres.remi@laposte.net Thu Apr 5 07:22:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65621F8749 for ; Thu, 5 Apr 2012 07:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLkxv6sJ1946 for ; Thu, 5 Apr 2012 07:22:10 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2D00521F8776 for ; Thu, 5 Apr 2012 07:22:09 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id uEN61i00937Y3f403EN6cb; Thu, 05 Apr 2012 16:22:08 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> Date: Thu, 5 Apr 2012 16:22:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Brian Haberman , Yong Cui Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:22:12 -0000 Hi, Ralph, More comments in line. 2012-04-05 15:02, Ralph Droms: >=20 > On Apr 5, 2012, at 4:07 AM 4/5/12, R=E9mi Despr=E9s wrote: >=20 >> Hi, Alain, Yiong, Ralph, Brian, >>=20 >> 1. >> In view of the lack of sufficient consensus at the Softwire meeting = for a choice between MAP-T+E and 4rd-U, several suggested, at the end = of the meeting and after on the ML, to publish MAP-T+E and 4rd-U as = experimental, with the expectation to select one later on.=20 >=20 > Assessment of the consensus in the WG meeting is informative but not = final. As is usual IETF practice, the chairs are now assessing WG = consensus on the mailing list. Therefore, it is too early to make a = decision to publish both specifications as Experimental. >=20 >> As a matter of fact, this is in substance what Alain had proposed = before IETF 83 if, during the meeting, there would be no consensus for = one standard track and the other(s) informational. No such consensus = having emerged, that would be the natural outcome.=20 >>=20 >> In the mean time, a vendor having announced on the ML its intention = to "implement 4rd-u and do operational tests", it is clear that better = understanding of issues will be possible to enlighten the WG before a = final decision on what deserves standard track. >=20 > You raise an issue that, to my memory, has not been explored in any = great detail. =20 > The MAP specification documents have been published and stable (with, = I think, one minor exception) since January, (*) No revision has been seen since January for 3 of them, yes, but this is = despite the need to correct them, AT LEAST concerning the following = acknowledged points: - MAP-A+P says "Each MAP node in the domain has the same set of rules", = in contradiction with MAP-T - MAP-T doesn't deal yet with the need of different packet IDs from = shared-address CEs - MAP-E needs a correction for BR hairpinning - MAP-DHCP needs to be updated, at least to add a topology parameter to = request hub and spoke=20 In other words, stable yes, but because bugs remained uncorrected.=20 > while 4 revisions of the 4rd-u document have been published, with what = appear to be major revisions, in that same time period. After January, the first revision included 3 co-authors including one = ISP, another included one more co-author from a mobile operator, the = latter was to deal with two valid remarks made on the mailing list.=20 Anything wrong with that? On the opposite, concerning MAP team operation: a) There is no visibility on how the MAP team worked (no archives). b) The presented list of team members included names of some individuals = who clearly don't agree with what was presented on their behalf. c) One wonders why such an efficient team hasn't corrected identified = bugs (is it to pretend work was completed?) d) The "MAP team report" presented in Paris included a grossly erroneous = list of 4rd-U features while, by the chair's decision, discussion on = 4rd-U was to take place in the WG itself. This was NOT a work item to = be discussed internal to the MAP team. =20 > My understanding is that there is running code for the MAP = specification (both transport variants). =20 Partial running code and partial test, sure, but the fact is that = repeated requests that tested scenarios be documented with their mapping = rules remained unanswered.=20 > We've already delayed progress on the "stateless" specification since = you announced the first versions of 4rd-u. Now you are asking us to = wait to make a decision for a vendor who has "announced on the ML its = intention to "implement 4rd-u and do operational tests"". The present = state of the maturity and experience with MAP and 4rd-u should be = considered at this point in time as the WG expresses its preference for = a way forward. >=20 >> 2. >> Question 1 below (*) formally excludes, independently from received = responses, any possibility that both solutions be published as = experimental (Yes =3D> One on standard track; No =3D> both on standard = track.) >=20 > This question about "both Experimental" only needs to be asked if = there is no clear consensus to support publication of one specification. Absence of clear consensus was clear in Paris. Mailing list is AFAIK appropriate to confirm a consensus, not to quickly = mask a lack of consensus by means of a weird voting procedure. >> I therefore note that this procedure, in addition to be confused (who = may answer, with which conclusion process), is illegitimate.=20 >> Taking this procedure as conclusive would therefore lead to an = application of RFC2026 sec 6.5.1 (Working Group Disputes). >>=20 >> OTOH, publishing now MAP-T+E and 4rd-U as WG documents on the = experimental track would be indisputable. >=20 > I disagree. > =20 > That decision would be premature prior to assessment of WG consensus = to publish one or the other. Trying now to turn around the lack of consensus in IETF 83, using for = this a highly criticizable procedure, remains unacceptable, sorry for = that. If nothing else, your current ignorance of the real state of MAP = documents (see (*) above) would justify to let passion to settle down. To conclude, I like agreements and consensus, and do regret to have to = make the above points. Yet, too much would be too much, and would justify to apply 6.5.1 of RFC = 2026, with whoever will join.=20 Regards, RD >=20 > - Ralph >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >> Le 2012-04-04 =E0 23:14, Alain Durand a =E9crit : >>=20 >>> Dear Softwire wg members: >>>=20 >>> At the Paris IETF Softwire meeting, we had presentations on MAP = (taken as a whole) and >>> 4rd-U. We got very strong feedback that we needed to select one >>> solution to cover that full stateless case, not two, and that we = should make this >>> decision relatively quickly. >>>=20 >>> During Paris meeting, we asked the following additional question: >>> Do you prefer MAP or 4rd-U? >>> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>>=20 >>> The real gauge of consensus is the mailing list, so we would like >>> to ask the same questions to the list. >>>=20 >>=20 >> (*) >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, >>> the other being published as experimental or informational. >>> Answering YES to this question means you agree we cannot publish = both as standard track. >>> Answering NO to this question means you want to see both advance on = the standard track. >>=20 >>=20 >>=20 >>> = --------------------------------------------------------------------------= -- >>> Your full name, your affiliation, your choice: YES or NO >>> = --------------------------------------------------------------------------= -- >>>=20 >>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Questions 2: Which one do you want to see placed on the Standards = Track: >>> 4rd-U or MAP? >>>=20 >>> = --------------------------------------------------------------------------= ---- >>> Your full name, your affiliation, your choice: 4rd-U or MAP >>> = --------------------------------------------------------------------------= ---- >>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>>=20 >>>=20 >>> Please fill out the following form and reply to the list >>> by Wednesday 4/10 5pm EDT. >>>=20 >>> Note: Use this thread ONLY for expressing your support to >>> one OR the other, and redirect any discussions to other threads. >>> That would help up gauge consensus. >>>=20 >>> Alain & Yong. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From rajiva@cisco.com Thu Apr 5 07:26:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7FF21F8468 for ; Thu, 5 Apr 2012 07:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRY2x7fxt5GU for ; Thu, 5 Apr 2012 07:26:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D577E21F845F for ; Thu, 5 Apr 2012 07:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3103; q=dns/txt; s=iport; t=1333635982; x=1334845582; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=bVASnT9KPn6x4pUmV/rlTsj/PGNerBmp4sT+sAc5+pk=; b=IebpMJ8PbvVT1v0NMrmgvSZBlu9bemZTaZyO2tScmWgGjFVJM4G3r5B1 qlRll+OrVj080pSLgCvdJtPpZRnezQuaJ3u3HAepC9oySxwM7R+KubIAa gsp46KfDAKu69gGjkt0FGGpwbniyrALqVPn1IcAHOSY6IlBRiBZl+yx25 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP2qfU+tJV2b/2dsb2JhbABFuGyBB4IJAQEBBAEBAQ8BHQo0CwwGAQgOAwQBAQsGFwEHJh8JCQEEARIIEweHbAubGpELhi2IPASGDolpYwSIWZtdgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="72354511" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 05 Apr 2012 14:26:22 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q35EQMsd009824; Thu, 5 Apr 2012 14:26:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 09:26:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 09:26:21 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07E37513@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgAj9xIw From: "Rajiv Asati (rajiva)" To: "Alain Durand" , X-OriginalArrivalTime: 05 Apr 2012 14:26:22.0079 (UTC) FILETIME=[12F588F0:01CD1338] Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:26:23 -0000 1. Rajiv Asati, Cisco: Yes 2. Rajiv Asati, Cisco: MAP Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Alain Durand > Sent: Wednesday, April 04, 2012 5:14 PM > To: softwires@ietf.org WG > Cc: int-ads@tools.ietf.org; Softwire Chairs > Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP >=20 > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a > whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. >=20 > ------------------------------------------------------------------------ ---- > Your full name, your affiliation, your choice: YES or NO > ------------------------------------------------------------------------ ---- >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? >=20 > ------------------------------------------------------------------------ ------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------ ------ >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Sun Mar 25 06:38:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9F21F84BD for ; Sun, 25 Mar 2012 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrbFbdLStxs2 for ; Sun, 25 Mar 2012 06:38:23 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 1616821F84B5 for ; Sun, 25 Mar 2012 06:38:21 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id ppeH1i00337Y3f403peHgK; Sun, 25 Mar 2012 15:38:19 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-40681264 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sun, 25 Mar 2012 15:38:03 +0200 Message-Id: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> References: To: Maoke X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 05 Apr 2012 08:13:53 -0700 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:38:26 -0000 --Apple-Mail-12-40681264 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-25 =C3=A0 14:08, Maoke a =C3=A9crit : >=20 >=20 > 2012/3/25 R=C3=A9mi Despr=C3=A9s >=20 > Le 2012-03-25 =C3=A0 05:34, Maoke a =C3=A9crit : >=20 >> dear Remi, >> 2012/3/24 R=C3=A9mi Despr=C3=A9s >>=20 >> Le 2012-03-22 =C3=A0 15:40, Maoke a =C3=A9crit : >>=20 >>> dear Alain, Yong, Ralph and all, >>>=20 >>> in program, the effort of the MAP team should be respected. The = formation of the MAP team was also the consensus of our meeting in = beijing and we have seen the the team is working with clear progress. I = don't think it is correct now to insert 4rd-u into a sort of exclusive = decision of choice. And 4rd-u also has the address format elements = abondoned by the MAP design team. I believe the MAP format reflects that = the common understanding concludes the insignificance of those features. = Sorry but the chair's questions a little confused me: if we need to go = back to the stage before the works of the MAP design team? =20 >>>=20 >>> The MAP series have reached running codes >>=20 >>> and the collective understanding of the community. >>=20 >> Here are some issues among those remaining before reaching = "collective understanding": >> =20 >> =20 >> some issues remaining not yet reaching collective undertanding is not = a reason of making things over. the collective understanding has been = reached for the major part of the >> 1) MAP address format and the corresponding algorithms >> 2) encapsulation and translation modes being supported by MAP format = and the existing header processing standards=20 >> 3) DHCP extensions as a way of distributing rules. >> =20 >> the above big picture are what i call "collective understanding". the = correct way is: making these already gained approaches as bases, = continuing discussion or even dabate on the details. i don't think it is = a correct way of action to disrespect a team's work. 4rd-u's problem is = even its big picture is still fuzzy. >=20 > Not more fuzzy than MAP (actually less fuzzy IMHO). > Debate on details is possible for U as wall as for T+E. > =20 > =20 > you may argue that MAP is much more fuzzy. but as i said, nobody knows = exactly what the "4rd-u tunnel" is. > you said it is just a reversible header mapping that is not tunnel I rather say that reversible header mapping implements a "tunnel" = variant. =20 > nor translation path section. > then what does the "reversible header mapping" provides to the = architecture of transition? you never clearly state this.=20 The draft is AFAIK not ambiguous. I tried to answer all your questions on this point I barely understand = (neither an implementation nor an operation issue) End of this point for me, if there is nothing significantly new. >> a) T operation in hub&spoke (hasn't been so far answered in an = understandable way). >> =20 >> i doubt i understand what you mean. may you please specify the = question in details? >=20 > Is a DHCPv6 parameter needed, yes or no? > =20 > =20 > i am not sure i know about the details of what you mean. Today, there is no DHCPv6 parameter to require H&S, right? My question is then: "is it sufficient to have none, or is it needed to = add a new parameter". Looking at more details would be premature for me until you have = answered this question. > do you mean the feature of R-2.C? if so, i happen to have following = questions: > 1) why hub&spoke topology should be announced to the CE? (IMHO, if a = CE is informed with the FMR involving other CEs, it works as mesh; if = only BMR and DMR is informed, surely it is hub&spoke. i think this has = been clarified in MAP Section 5.) > 2) to this parameter issue, what is the difference between T and E? None AFAIK. > look forward to your further clarification/discussions! if you mean = not the hub&spoke mode indicator, please specify your question further. > =20 > =20 >> b) IDs from shared-address CEs. T currently has so far no solution = while both U and E include one.=20 >> =20 >> =20 >> what do you mean with the IDs? or do you mean interface IDs? i don't = see "IDs from shared-address CEs" in U too. please teach! >=20 > Sec 4.5.3. is "Packet Identifications from Shared-Address CEs". > Did you read the complete draft? > =20 > =20 > execuse me. it is my fault. i read it but i didn't realize you mean = the datagram identification here. it is a good point, and not only this = but also the issue of how BR deals with fragments of the same datagram = where only the first fragment has the port number. for this point, i = think MAP-T also needs to consider this problem described in the MAP-E = Section 7, last 2 paragraphs. thanks a lot! (*) End of this subject. >> c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 >> =20 >> =20 >> first of all, they are not conflicting logically. >=20 > ??? >=20 >> second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. >=20 > This is not the point. > Separate documents can be consistent, but they aren't on this point. >=20 > One of the two assertions must be changed.=20 > Remaining question: which one? > =20 > =20 > well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an unknown = destination CE. I am not aware that a CE might receive some of the MAP DHCPv6 parameters = but not all due to lost packets. Clarification on this will be welcome. > the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear = enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i = may partly agree with you that one could be further clarified). > =20 >=20 > =20 >> but it doesn't mean one doc is definitely reflecting "collective = understanding" better than multiple. >> =20 >> =20 >> d) Whether T can work with a single mapping rule (as was, I think, = the case for IVI). So far DMR and BMR seem exclusive, and there is no = way to distinguish them in MAP-dhcp. >> =20 >> =20 >> single mapping rule for a domain !=3D single mapping rule for the = IPv4 world. >=20 > ??? >=20 >> the IVI (RFC6052/6145/6219) practice does the latter. the latter = doesn't need DHCP to distribute the mapping rule. in the MAP, i don't = think DMR and BMR being exclusive is a problem. >=20 > How many MAP mapping rules do you see for the equivalent of the IVI = use case in a MAP domain?=20 > =20 > =20 > if you mean the single mapping rule in IVI case, the answer is NONE, = surely. IVI uses RFC6052 address format rather than the MAP, without the = business of MAP. OK (In this respect at least, IVI significantly differs from a running = version of MAP-T). > =20 > if you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. Saying that there is no mapping rule in IVI is sufficient an answer. > None?=20 > If one, is it a DMR or a BMR? > If two, what are they? >=20 >=20 >> The fact that no-one involved in the MAP design raised any of these = issues is AFAIK sign that MAP has NOT reached "collective understanding = of the community". >> (Note that, concerning stateless v4/v6 solutions, I think I should be = considered part of this community. Right? ). >> =20 >> =20 >> well, "collective understanding" was mentioned by Sally Floyd to the = community of Internet researchers, and i borrowed her term. but i = understand: no matter it is research or engineering, collective = understanding is the understanding on the problems and the architecture = rather than the detailed technical solutions. the MAP architecture has = been reflected in the works of the draft suite. on the other hand, the = community is not the softwires wg but the whole Internet engineering = circle. >> =20 >> =20 >>=20 >> Maoke, clarifications on these points will be welcome. >>=20 >>=20 >>> =46rom a view of a middle-sized ISP and cloud service provider, we = do support to accept MAP series into standard track in order we can = utilize it into business as soon as possible.=20 >>>=20 >>> in technology, first of all, MAP now has approached address mapping = algorithm and that enough to make the series a unified solution. In our = practice, we need to use either encapsulation or translation according = to the actual needs and environment. >>=20 >> Note: This excludes ISPs that would like to offer full IPv4 = transparency with some IPv6-only middles boxes. >> Right? >> =20 >> =20 >> i cannot follow your "full IPv4 transparency" with "some" IPv6-only = middle boxes. what does the "transparency" mean for the middle boxes? i = understand, when we talk about the Internet transparency, we refer to = the "end-to-end transparency". please specify your question concretely. >=20 > OK, could have been clearer. > Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. > =20 > =20 > ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); 1) A statistic at a given time, and in a given place, isn't a proof that = the same ratio will be found later and somewhere else. 2) Those that happen to be in the sacrificed minority, be it small, may = not like their situation. Solving the problem, be it only for them, is = progress. > 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? AFAIK, not weird to those who are open to accept that it is very simple. >>> The most important is, both the building blocks of transition = architecture: virtual link (supported by encapsulation/tunneling) and = participant of the delivery path (supported by translation), have their = suitable use cases. And their advantages and limitations have been well = investigated and understood by the community.=20 >>>=20 >>> second, i deeply discussed and explored 4rd-u, but i found its = attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable = to define what building block it really is. >>=20 >> Such an operator would know it uses 4rd-U.=20 >> =20 >> =20 >> well, this is what i mean the uncertainty of 4rd-U in the = architecture to the common understanding. as a analogy, one of Mr. E and = Mr. T said, "i give you a horse", while the other said "i give you a = donkey". then people well understand when they need a horse when they = need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". = there would be 2 possible results, not certain right now: >> A. donkorse is just another sort of donkey, somehow good but somehow = flawed. >> B. donkorse is just donkorse, and people, taking a long time to = understand it, and finally find it either a flawed or a quite good = hybrid, like mule, useful in some cases. >> =20 >> no matter if the future result is A or B, now Mr. O understand what = he needs for his business is either a horse and a donkey, with their = well-known characteristics. Mr. MAP provides a wheeled car as the common = instrument, while Mr. O needs a standard suite for the wheeled-car, the = horse-driving and donkey-driving methods and the way of feeding the = horse and donkey. this is the task of our wg, right now. =20 >> =20 >> Mr. U said you must have another type of wheel and drive it with my = donkorse --- and when Mr. O asked him, what your donkorse is, he = answered: you will know it is donkorse, having both the advantages of = the horse and the advantages of the donkey. however, Mr. O doubts = donkorse hasn't also the disadvantages of horse and the disadvantages of = donkey and some flaws not yet documented. why not? >> =20 >> =20 >> This doesn't seem to justify any FUD from co-authors from broadband = and mobile operators (or from product vendors). >>=20 >>> It is stated as tunneling but actually behaves like tunnel in some = aspects while like translation in some other aspects. >>=20 >> Yes indeed, thus achieving the best of both worlds without making it = more complex. Actually making it clearly less complex than supporting = both T and E. >> =20 >> =20 >> i don't think those who made out mule expected the mule could replace = horse and donkey and achieving a better world without horse and donkey = but only mule. surely mule-only world is simpler. >=20 > Comparison is not reason (French proverb). > =20 > =20 > i just try to understand what the 4rd-u reversible header mapping = really is, in the term of architecture. this analogy is written as = problem understanding rather than a reason of anything. =20 > =20 > =20 >=20 >> =20 >>> (I have pointed out in the 4rd-u discussion thread). >>=20 >>> We see it only a yet-another-translation that try to solve some = corner problems but introduces new, possibly major flaws (also pointed = out in the technical threads on 4rd.) >>=20 >> "Possibly major flaws" isn't an identified point on which U would do = less than what it has been designed to do (unified replacement of T + = E). >> =20 >> =20 >> i believe they are major flaws but i was gently argued with the = "possibly" because i respected that maybe others didn't think so = critically like me. >=20 > I have still to understand where you see "major flaws". > Just asserting they exist, without explanation although others who = read the specification don't see them isn't enough. > =20 > =20 > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are = major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. If a host is IPv6 only, it isn't a 4rd-U host.=20 For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20 A new solution for this isn't needed.=20 > Saying that E+T is better because its current inconsistencies are = "details" isn't enough either (IMHO). > =20 > =20 > different problems. E + T is actually not only the MAP-E and MAP-T, = but the utilization of existing, already mature E and T with the new MAP = format. =20 >> IMPORTANT: =20 >> - The essential characterization of U (vs T and E) is its Reversible = header mapping (as replacement of both Double RFC6145 translation and = Encapsulation). >> =20 >> =20 >> yet-another-translation, with some issues still in debates. > =20 > You can call it as you wish, but the point remains that, with U, one = doesn't need both E and T. > =20 > =20 > no. U has changed the layered model of Internet protocol stack. > an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. Different understanding. An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. Open to look at it. =20 > on the other hand, an operator needs the translation to encourage = transition and mutual communications between IPv4 and IPv6 and double = translation is included in such an environment. T has specifications for = this working BIH does the job with single translation. Where U applies, both ends are IPv4, T has AFAIK no operational = superiority while U is more transparent. > but U needs still discussion T too. See, for example, (*) above. > and running code approval. it cannot replace T at least this moment. Understanding how U's header mapping works doesn't need great expertise. Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. Running code as soon couldn't be done yet, but isn't a big deal at all = (see (**) below) >> - Other features of U that differ from MAP (V-octet, CNP), or are = complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this = respect. Each of these features could be abandoned in U, or, if the WG = appreciates what they offer, added to MAP. >> =20 >> =20 >> MAP team has concluded V-octet and CNP are not necessary. do we need = to debate again? i doubt people have unlimited time. >=20 > I made the point many times that the right to analyze problems didn't = stop after a majority decision obtained during an improvised meeting. > Many MAP contributors were absents, and no time was given to correct = invalid objections that had been made just before during a WG meeting. >=20 > =20 > the reason is simple, > MAP can work even without the V-octet and CNP, at least in significant = cases. Not a valid reason to stop progress, especially if easy to understand. At least Med suggested to look at V octet even in the context of MAP (if = chosen for standard track). > if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. (**) When we discussed in Taipei, you first said you might code 4rd-U so that = it could be tested for real. You didn't do it for reasons that I = perfectly respect. Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. Regards, RD =20 > =20 > - maoke > =20 > Note that several co-authors of the U proposal have been MAP = contributors. =20 > =20 > =20 >=20 >=20 >> - For this, community acceptance to listen to explanations, would be = the normal process. I will be available this week for this. >> =20 >> =20 >> i think we are all open to listen to and to discuss on any = explorations but it doesn't mean we should stop standardization of our = wheeled-car/horse-driving/donkey-driving/feeding suite with an = expectation of a "better world" with only donkorse and the = donkorse-specific wheeled car. >=20 > Your stand is clear, but comparison isn't reason. >=20 > RD >=20 >=20 >=20 >=20 >> regards, >> maoke >> =20 >> =20 >>=20 >> Cheers, >> RD >>=20 >>=20 >>> In either the term of architectural philosophy or technical details, = introducing 4rd-u into standards would be harmful.=20 >>>=20 >>> personally, i respect the exploration of the author(s), and the = discussion between me and the author encouraged me to comprehensively = review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward.=20 >>>=20 >>> regarding the chair's questions, my answer is: MAP, MAP-E/T, = MAP-DHCP are of a whole suite needing to be put into standard track. = Question is not about T, E or U.=20 >>>=20 >>> best regards, >>> Maoke >>>=20 >>> =E5=9C=A8 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C= =EF=BC=8CAlain Durand =E5=86=99=E9=81=93=EF=BC=9A >>> Dear wg, >>>=20 >>> After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >>>=20 >>> 1) There is an observation that all the solutions on the table E, T = & U actually solve the stateless problem we started with. >>> There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation >>> proposals, U is an hybrid unifying solution. >>>=20 >>> 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those >>> documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >>>=20 >>> We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). >>> Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >>>=20 >>> Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask >>> and their sequence. >>>=20 >>> Q1: Without pre-supposing which one will be selected, do you agree = to publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >>>=20 >>> If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. >>> If the answer is YES, we move to the next question. >>>=20 >>>=20 >>> Q2: Do you believe that the WG should publish U as the one Standards = Track document? >>>=20 >>> If the answer is YES, the process stop, we put U on the Standard = Track and publish E & T as Informational. >>> If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational) >>>=20 >>>=20 >>> Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >>>=20 >>> If there is a clear outcome from this question, we would publish = that proposal on the Standard Track and the other one as Informational. >>> If there is no clear consensus on this question, we will publish = both E & T as Experimental. >>>=20 >>> In the meantime, we would like to encourage discussion on the = mailing list to foster our common understanding of the various = technologies and how they relate to each other. >>>=20 >>> Alain & Yong, wg co-chairs. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 --Apple-Mail-12-40681264 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


2012/3/25 R=C3=A9mi = Despr=C3=A9s <despres.remi@laposte.net><= /span>

Le 2012-03-25 =C3=A0 = 05:34, Maoke a =C3=A9crit :

dear Remi,
2012/3/24 R=C3=A9mi= Despr=C3=A9s <despres.remi@laposte.net>

Le 2012-03-22 =C3=A0 = 15:40, Maoke a =C3=A9crit :

dear = Alain, Yong, Ralph and all,

in program, the effort of = the MAP team should be respected. The formation of the MAP team was also = the consensus of our meeting in beijing and we have seen the the team is = working with clear progress. I don't think it is correct now to insert = 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has = the address format elements abondoned by the MAP design team. I believe = the MAP format reflects that the common understanding concludes the = insignificance of those features. Sorry but the chair's questions =  a little confused me: if we need to go back to the stage before = the works of the MAP design team?  

The MAP series have reached running codes =

and the collective = understanding of the = community.

Here are some = issues among those remaining before reaching "collective = understanding":
 
 
some = issues remaining not yet reaching collective undertanding is not a = reason of making things over. the collective understanding has been = reached for the major part of the
1) MAP address format and the corresponding algorithms
2) = encapsulation and translation modes being supported by MAP format = and the existing header processing standards 
3) = DHCP extensions as a way of distributing rules.
 
the above big picture are what i call = "collective understanding". the correct way is: making these = already gained approaches as bases, continuing discussion or even = dabate on the details. i don't think it is a correct way of action to = disrespect a team's work. 4rd-u's problem is even its big picture = is still fuzzy.

Not more fuzzy than MAP = (actually less fuzzy IMHO).
Debate on details is possible for = U as wall as for = T+E.
 
 
= you may argue that MAP is much more fuzzy. but as i said, nobody knows = exactly what the "4rd-u tunnel" is. =

you said it is just a reversible header = mapping that is not tunnel

I = rather say that reversible header mapping implements a "tunnel" = variant.
 
nor translation path section. =

then what does the "reversible header = mapping" provides to the architecture of transition? you never clearly = state this.

The draft is AFAIK = not ambiguous.
I tried to answer all your questions on this = point I barely understand (neither an implementation nor an operation = issue)

End of this point for me, if there is = nothing significantly new.


a) T operation in hub&spoke (hasn't been so far answered in an = understandable = way).
 
i doubt i = understand what you mean. may you please specify the question in = details?

Is a DHCPv6 parameter needed, = yes or = no?
 
 
i am = not sure i know about the details of what you mean. =

Today, there is no DHCPv6 = parameter to require H&S, right?
My question is then: "is = it sufficient to have none, or is it needed to add a new = parameter".
Looking at more details would be premature for me = until you have answered this = question.


do you mean the feature of R-2.C? if so, i = happen to have following questions:
1) why hub&spoke topology should be announced to the CE? (IMHO, = if a  CE is informed with the FMR involving other CEs, it works as = mesh; if only BMR and DMR is informed, surely it is hub&spoke. i = think this has been clarified in MAP Section 5.)
2) to this parameter issue, what is the difference between T and E? =

None = AFAIK.


look forward to your further = clarification/discussions! if you mean not the hub&spoke mode = indicator, please specify your question further.
 
 
b) IDs from shared-address CEs.  T currently has so = far no solution while both U and E include = one. 
 
 
what do you mean with the IDs? or do you mean interface = IDs? i don't see "IDs from shared-address CEs" in U too. = please teach!

Sec 4.5.3. is "Packet = Identifications from Shared-Address CEs".
Did you read the = complete = draft?
 
 
execuse me. it is my fault. i read it but i didn't realize you mean the = datagram identification here. it is a good point, and not only this but = also the issue of how BR deals with fragments of the same datagram where = only the first fragment has the port number. for this point, i = think MAP-T also needs to consider this problem described in the MAP-E = Section 7, last 2 paragraphs. thanks a = lot!

(*)
End of = this subject.


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean one doc is superior than = multiple with better consistency in writing, i could agree.

This is not the = point.
Separate documents can be consistent, but they aren't = on this point.

One of the two assertions must = be changed. 
Remaining question: which = one?
 
 
well. = this is why i said they are not conflict in logic. as a definition of = the MAP rule, right, each MAP node in the domain SHOULD have the same = set of rules. however, in practice of operation, it is possible that = this MAY not strictly achieved due to some information losses (which is = often happens in the Internet environment), MAP-T defines the CE working = as it were in hub&spokes mode for an unknown destination = CE.

I am not aware that a CE = might receive some of the MAP DHCPv6 parameters but not all due to lost = packets.
Clarification on this will be = welcome.


the text of Sec 8.2 of MAP-T and that of Sec = 8.2 of MAP-E are clear enough to me. no one among = MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with = you that one could be further clarified).
 

 
but it doesn't mean one doc is definitely = reflecting "collective understanding" better than multiple.
 
 
d) Whether T can work with a single mapping rule (as was, I think, = the case for IVI). So far DMR and BMR seem exclusive, and there is no = way to distinguish them in = MAP-dhcp.
 
 
single mapping rule for a domain !=3D single = mapping rule for the IPv4 world. =

???

the IVI (RFC6052/6145/6219) practice does the latter. the latter = doesn't need DHCP to distribute the mapping rule. in the MAP, i don't = think DMR and BMR being exclusive is a problem. =

How many MAP mapping rules do you see for the = equivalent of the IVI use case in a MAP = domain? 
 
 

if you mean the single mapping rule in IVI = case, the answer is NONE, surely. IVI uses RFC6052 address format rather = than the MAP, without the business of MAP. =

OK
(In this = respect at least, IVI significantly differs from a running version of = MAP-T).

 
if you mean using the MAP for the single = translation as we did in IVI (though actually we have IVI working for = both single and double translations simultaneously), MAP-T Sec 8.3 = has answered your question. =

Saying that there is no mapping = rule in IVI is sufficient an = answer.


None? 
If one, is it a DMR or a BMR?
If = two, what are they?


The fact that no-one involved in the = MAP design raised any of these issues is AFAIK sign that MAP has NOT = reached "collective understanding of the community".
(Note that, concerning stateless v4/v6 solutions, I think I should = be considered part of this community. Right? ).
 
 
well, = "collective understanding" was mentioned by Sally Floyd to the community = of Internet researchers, and i borrowed her term. but i understand: = no matter it is research or engineering, collective understanding is the = understanding on the problems and the architecture rather than the = detailed technical solutions. the MAP architecture has been reflected in = the works of the draft suite. on the other hand, the community is not = the softwires wg but the whole Internet engineering circle.
 
 

Maoke, clarifications on these points will be = welcome.


=46rom a view of a middle-sized ISP and cloud service = provider, we do support to accept MAP series into standard track in = order we can utilize it into business as soon as possible. 

in technology, first of all, MAP now has approached = address mapping algorithm and that enough to make the series a unified = solution. In our practice, we need to use either encapsulation or = translation according to the actual needs and environment.

Note: This excludes ISPs that = would like to offer full IPv4 transparency with some IPv6-only middles = boxes.
Right?
 
&nbs= p;
i cannot follow your "full IPv4 transparency" with "some" = IPv6-only middle boxes. what does the "transparency" mean for the middle = boxes? i understand, when we talk about the Internet transparency, we = refer to the "end-to-end transparency". please specify your question = concretely.

OK, could have been = clearer.
Yet, I think you understand that with U, = one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports.
 
 
ok. then = may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a = given time, and in a given place, isn't a proof that the same ratio will = be found later and somewhere else.
2) Those that happen to be = in the sacrificed minority, be it small, may not like their situation. = Solving the problem, be it only for them, is = progress.

2) with introducing #1. weird definition of = the fragment header of IPv6; #2 weird packet of IPv6 carrying ICMPv4 = messages?

AFAIK, not weird to = those who are open to accept that it is very = simple.


The most important is, both the building blocks of transition = architecture: virtual link (supported by encapsulation/tunneling) and = participant of the delivery path (supported by translation), have their = suitable use cases. And their advantages and limitations have been well = investigated and understood by the community. 

second, i deeply discussed and explored 4rd-u, but i = found its attempting of mixing the tunneling and translation, if = accepted as standard, may trap the operators into a harsh situation of = being unable to define what building block it really is.

Such an operator would know it = uses = 4rd-U. 
 
 
well, this is what i mean the uncertainty of 4rd-U in = the architecture to the common understanding. as a analogy, one of = Mr. E and Mr. T said, "i give you a horse", while the = other said "i give you a donkey". then people well understand when = they need a horse when they need a donkey. now Mr. U said "wow, i give = you a fantastic donkorse!". there would be 2 possible results, not = certain right now:
A. donkorse is just another sort of donkey, somehow good but = somehow flawed.
B. donkorse is just donkorse, and people, = taking a long time to understand it, and finally find it either a flawed = or a quite good hybrid, like mule, useful in some cases.
 
no matter if the future result is A or B, now Mr. = O understand what he needs for his business is either a horse and a = donkey, with their well-known characteristics. Mr. MAP provides a = wheeled car as the common instrument, while Mr. O needs a standard = suite for the wheeled-car, the horse-driving and donkey-driving methods = and the way of feeding the horse and donkey. this is the task = of our wg, right now.  
 
Mr. U said you must have another type of wheel and = drive it with my donkorse --- and when Mr. O asked him, what your = donkorse is, he answered: you will know it is donkorse, having both the = advantages of the horse and the advantages of the donkey. however, Mr. O = doubts donkorse hasn't also the disadvantages of horse and the = disadvantages of donkey and some flaws not yet documented. why not? =
 
 
This doesn't seem to justify any FUD from co-authors from = broadband and mobile operators (or from product = vendors).

It is stated as = tunneling but actually behaves like tunnel in some aspects while like = translation in some other aspects.

Yes indeed, thus achieving the = best of both worlds without making it more complex. Actually making it = clearly less complex than supporting both T and = E.
 
 
i don't think those who made out mule = expected the mule could replace horse and donkey and achieving a better = world without horse and donkey but only mule. surely mule-only world is = simpler.

Comparison is not reason = (French = proverb).
 
 
=
i just try to understand what the 4rd-u reversible header mapping = really is, in the term of architecture. this analogy is = written as problem understanding rather than a reason of = anything.  
 
 

 
(I have pointed out in the 4rd-u = discussion thread).
We see it only a yet-another-translation that try to = solve some corner problems but introduces new, possibly major flaws = (also pointed out in the technical threads on 4rd.)

"Possibly major flaws" isn't an = identified point on which U would do less than what it has been designed = to do (unified replacement of T + E).
 
 
i believe they are major flaws but i = was gently argued with the "possibly" because i respected that maybe = others didn't think so critically like me. =

I have still to understand where you see "major = flaws".
Just asserting they exist, without explanation = although others who read the specification don't see them isn't = enough.
 
 
well, i = mostly argue that the ICMPv4 being carried by IPv6 and CNP are = major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues.

ICMPv4 payloads in = IPv6 packets appear only during domain traversal, where they don't hurt = anyone.

If a host is IPv6 only, it isn't a = 4rd-U host. 
For communication between IPv4-only = applications of DS hosts and IPv6-only hosts, there are already = workable RFCs. 
BIH in DS hosts is AFAIK particularly = powerful, and IMHO sufficient. 
A new solution for this = isn't needed. 


Saying that E+T is better because its current inconsistencies are = "details" isn't enough either (IMHO).
 
 
di= fferent problems. E + T is actually not only the MAP-E and MAP-T, but = the utilization of existing, already mature E and T with the = new MAP format.  
IMPORTANT:  
- The essential characterization = of U (vs T and E) is its Reversible header mapping (as replacement of = both Double RFC6145 translation and Encapsulation).
=
 
 
yet-anothe= r-translation, with some issues still in debates. =
 
You can call it as = you wish, but the point remains that, with U, one doesn't need both E = and T.
 
 
no. U = has changed the layered model of Internet protocol stack. =

an operator definitely needs the = encapsulation as a fully featured virtual link (underlay = infrastructure) in real O&A for IPv4 communications over IPv6 = infrastructure. U cannot replace E at all. =

Different = understanding.
An detailed E use case that cannot be supported = by U (if it exists) would give substance to this = claim.
Open to look at it.  

on the other hand, an = operator needs the translation to encourage transition and mutual = communications between IPv4 and IPv6 and double translation is included = in such an environment. T has specifications for this = working

BIH does the job with = single translation.
Where U applies, both ends are IPv4, T = has AFAIK no operational superiority while U is more = transparent.


but U needs still discussion =

T too.
See, for = example, (*) above.

and running code approval. it cannot replace = T at least this moment. =

Understanding how U's = header mapping works doesn't need great expertise.
Co-autors = readily understood it, with origins as varied as router-and-host vendor, = software vendor, broadband operator, mobile = operator.

Running code as soon couldn't be done = yet, but isn't a big deal at all (see (**) = below)


- Other features of U that differ from MAP (V-octet, = CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are = secondary in this respect. Each of these features could be = abandoned in U, or, if the WG appreciates what they offer, added to = MAP.
 
 
MAP team = has concluded V-octet and CNP are not necessary. do we need to debate = again? i doubt people have unlimited time. =

I made the point many times that the right to analyze problems = didn't stop after a majority decision obtained during an improvised = meeting.
Many MAP contributors were absents, and no time was = given to correct invalid objections that had been made just before = during a WG meeting.

 
the reason = is simple,

MAP can work even without the V-octet and = CNP, at least in significant = cases.

Not a valid reason to stop = progress, especially if easy to understand.
At least Med = suggested to look at V octet even in the context of MAP (if chosen for = standard track).

 if we have the standard of MAP, = we can immediately deploy it into practice through applying = MAP rules into the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format. =

(**)
When we = discussed in Taipei, you first said you might code 4rd-U so that it = could be tested for real. You didn't do it for reasons that I perfectly = respect.
Yet, modifying T code to support header mapping = remains quite simple (you even call it a translation variant). Starting = from E code, it's simple too.
When this is done, all = verifications can be easily done that what analysis says is right is = also right with running = code.


Regards,
RD
<= div>


 

 
- maoke
 
Note that several co-authors of the U proposal have = been MAP contributors. =  
 
 


- For this, community = acceptance to listen to explanations, would be the normal process. = I will be available this week for = this.
 
 
i think we are all open to listen to and to = discuss on any explorations but it doesn't mean we should stop = standardization of our wheeled-car/horse-driving/donkey-driving/feeding = suite with an expectation of a "better world" with only donkorse and the = donkorse-specific wheeled car.

Your stand is clear, but = comparison isn't reason.

RD




regards,
maoke
 
=
 

C= heers,
RD


In either the term of architectural philosophy or = technical details, introducing 4rd-u into standards would be = harmful. 

personally, i respect the exploration of the = author(s), and the discussion between me and the author encouraged me to = comprehensively review E and T, and the result is: i bacame much more = confident of the correctness of the MAP track. We should move = forward. 

regarding the chair's questions, my answer = is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be = put into standard track. Question is not about T, E or = U. 

best regards,
Maoke

=E5=9C=A8 = 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF=BC=8CAlai= n Durand =E5=86=99=E9=81=93=EF=BC=9A
Dear wg,

After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, = T & U actually solve the stateless  problem we started = with.
   There are differences, but it is unclear if those = differences are really significant. E and T are the original = Encapsulation and Translation
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those
   documents have at IETF. In particular, do we want to = publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation.

Then, we, chairs, would like to ask a series of questions to the working = group. In order to make this process transparent, here is the list of = questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards = Track document?

If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)?

If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E = & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires





= --Apple-Mail-12-40681264-- From despres.remi@laposte.net Tue Apr 3 06:13:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27811E8083 for ; Tue, 3 Apr 2012 06:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxx3TKdQ5i+W for ; Tue, 3 Apr 2012 06:13:15 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0B621F86B3 for ; Tue, 3 Apr 2012 06:13:13 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id tRDC1i00337Y3f403RDC73; Tue, 03 Apr 2012 15:13:13 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-816790218 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 15:13:11 +0200 Message-Id: <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> To: guoliang han X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 05 Apr 2012 08:14:15 -0700 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:13:17 -0000 --Apple-Mail-6-816790218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-04-03 =C3=A0 14:43, guoliang han a =C3=A9crit : > Hi, Remi: > =20 > I don't think my case illustrates MAP-T needs to remain experimental, = my comments are below: > =20 > =20 > 2012/4/3 R=C3=A9mi Despr=C3=A9s > Hi, Guoliang, >=20 > Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution. >=20 > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. > =20 > =20 > RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is that = "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can = be administered in compliance with Section 4.3.1 of [RFC4890]", the = second approach is to change PTB MTU value to 1280 in case PTB<1280 and = set DF bit to 0 in case the packet is less than or equal to 1280 bytes, = if the requirements of the first approach can't be met. It doesn't mean = the administrator can refuse to take the second approach according to = his will.=20 > =20 >=20 > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to work. > =20 > Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could traverse current IPv6 firewalls = successfully. Typical use cases of 4rd-U have no firewall between BRs and CEs. If some would exist, they should be configured to let ICMPv4 payloads go = through (Protocol =3D 1) This is like configuring them to accept IPv4 headers in IPv6 payloads = (Protocol =3D 4) > 3. > Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T. > =20 > See Section 6 of RFC6145. This isn't in RFC6145, simply a reference to (*) below. If I misunderstood, please explain what. > When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. >=20 >=20 > In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. > =20 > Regards, > RD > =20 > In fact, MAP-T is clear enough to be deployed without any problems, if = you read RFC6145 carefully. Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided for = IPv4 PMTU discovery to work. Still waiting for a clarification on this issue. Regards, RD > =20 > regards, > Guoliang > =20 > =20 >=20 >=20 > Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit : >=20 >> +1. >> =20 >> As a follower of MAP team, I participated much in developing and = deploying=20 >> double-translation in CERNET. As far as I am concerned, in the = translation scenario, >> 4rd-U only solved some corner cases but missed some other cases = simultaneously. >> =20 >> As an example, I suppose one fragmentation case as following: >> =20 >> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host >> =20 >> The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4=20 >> network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 >> with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 >> could traverse the IPv6 access network, but will be blocked in the = IPv4 network.=20 (*) >> In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, >> instead of preserving the original IPv4 DF bit. >> =20 >> In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet=20 >> whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve >> the DF bit, the sender will always believe the path MTU is 1280, = which will certainly lead to=20 >> a black hole. >> =20 >> This is only one deployment problem, and we don't know how many = issues will be encountered >> in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 >> it's a bit early to propose it as an Informational/Standards Track = Document. >> =20 >> The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 >> =20 >> regards,=20 >> Guoliang >>=20 >> =20 >> 2012/3/26 Maoke >> hi Remi,=20 >>=20 >> let me remove those you have marked as "end". they are fine to me = too. only one point: no implementation nor operation trouble !=3D it is = safe to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all).=20 >>=20 >> 2012/3/25 R=C3=A9mi Despr=C3=A9s >>=20 >>=20 >>>> c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 >>>> =20 >>>> =20 >>>> first of all, they are not conflicting logically. >>>=20 >>> ??? >>>=20 >>>> second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. >>>=20 >>> This is not the point. >>> Separate documents can be consistent, but they aren't on this point. >>>=20 >>> One of the two assertions must be changed.=20 >>> Remaining question: which one? >>> =20 >>> =20 >>> well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an unknown = destination CE. >>=20 >> I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets. >> Clarification on this will be welcome. >>=20 >> my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!) >>=20 >> if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues.=20 >> =20 >>=20 >>> if you mean the single mapping rule in IVI case, the answer is NONE, = surely. IVI uses RFC6052 address format rather than the MAP, without the = business of MAP. >>=20 >> OK >> (In this respect at least, IVI significantly differs from a running = version of MAP-T). >>=20 >> well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules.=20 >> =20 >>=20 >>> =20 >>> if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. >>=20 >> Saying that there is no mapping rule in IVI is sufficient an answer. >>=20 >> then there is no more "not reaching collective understanding" for = this point. End of this topic for me.=20 >> =20 >>=20 >>> None?=20 >>> If one, is it a DMR or a BMR? >>> If two, what are they? >>> ... >>> OK, could have been clearer. >>> Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. >>> =20 >>> =20 >>> ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); >>=20 >> 1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else. >> 2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress. >>=20 >> 1) not only one statistics. i did it at Tsinghua University. prof. = Bao and others did it at CERNET. other guys did it in Europe and = published in IMC'07. and if you carefully read that paper, you may found = that case was very abnormal.=20 >> 2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty.=20 >> =20 >>=20 >>> 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? >>=20 >> AFAIK, not weird to those who are open to accept that it is very = simple. >>=20 >> AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have = #2 well discussed with the ICMP designers before concluding they are = "not weird"! i am not so open. to those who are open to accept this, i = think they should be also open to the following propositions (that are = wrong to me): >>=20 >> *1. IPv6 option header, as long as there are reverved or not-yet-used = or padding bits, could be redefined as we like. >> *2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message.=20 >> *3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it.=20 >> *4. IPv4 header checksum is actually useless.=20 >>=20 >> if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community! >>=20 >>> ...=20 >>> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP = are major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. >>=20 >> ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. >>=20 >> see above.=20 >> =20 >>=20 >> If a host is IPv6 only, it isn't a 4rd-U host.=20 >> For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 >>=20 >> common understanding, including RFC6052/RFC6145/RFC6146 but surely = not limited to these.=20 >> =20 >> BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20= >> A new solution for this isn't needed.=20 >>=20 >> BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations.=20 >> =20 >>=20 >>> an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. >>=20 >> Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. >> Open to look at it. =20 >>=20 >> in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >>=20 >> first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >> =20 >> second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >> \ = / >> \ = / >> +------------ CE ----(Another, IPv4 = domain)----------+ >>=20 >> third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >>=20 >> MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.)=20 >>=20 >>=20 >>=20 >>> but U needs still discussion >>=20 >> T too. >> See, for example, (*) above. >>=20 >> you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both.=20 >> =20 >>=20 >>> and running code approval. it cannot replace T at least this moment. >>=20 >> Understanding how U's header mapping works doesn't need great = expertise. >> Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. >>=20 >> well, it works just like another translator, surely it doesn't need = great expertise.=20 >> =20 >>=20 >> Running code as soon couldn't be done yet, but isn't a big deal at = all (see (**) below) >>=20 >> ...=20 >>=20 >>> MAP can work even without the V-octet and CNP, at least in = significant cases. >>=20 >> Not a valid reason to stop progress, especially if easy to = understand. >> At least Med suggested to look at V octet even in the context of MAP = (if chosen for standard track). >>=20 >> no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary.=20 >> =20 >>=20 >>> if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. >>=20 >> (**) >> When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect. >>=20 >> yes but i also mentioned the prerequisite: "when i fully understand = it and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the necessity.=20 >>=20 >> thanks, >> - maoke >> =20 >> Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. >> When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-6-816790218 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, Remi:
 
I don't think my case illustrates MAP-T needs to remain = experimental, my comments are below:
 
 
2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T = needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280.= It specifies two behaviors, one that does this, and one that doesn't. = Which one to choose isn't AFAIK specified in the MAP-T draft.
 
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach = is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network = firewalls can be administered in compliance with Section 4.3.1 of = [RFC4890]", the second approach is to change PTB MTU value to 1280 in = case PTB<1280 and set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, if the requirements of the first = approach can't be met. It doesn't mean the administrator can refuse = to take the second approach according to his will. 
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to = work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could  traverse current IPv6 firewalls = successfully.

Typical use cases = of 4rd-U have no firewall between BRs and CEs.
If some would = exist, they should be configured to let ICMPv4 payloads go through = (Protocol =3D 1)
This is like configuring them to accept IPv4 = headers in IPv6 payloads (Protocol =3D = 4)


3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T.
 
See Section 6 of = RFC6145.

This isn't in RFC6145, = simply a reference to (*) below.
If I misunderstood, please = explain what.

When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments.
   
    Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 = carefully.

Replacing = IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided = for IPv4 PMTU discovery to work.
Still waiting for a = clarification on this = issue.

Regards,
RD

=



 
regards,
Guoliang
 
 


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network. =
<= div>
(*)
In= this case, BR(Core Translator) must set DF to 0 when translating from = IPv6 back to IPv4,
instead of preserving the original IPv4 DF = bit.
<= div>

 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang

 
2012/3/26 Maoke <fibrib@gmail.com>
hi Remi, 

let me remove those you have marked as "end". they are fine to me = too. only one point: no implementation nor operation trouble !=3D it is = safe to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all). 

2012/3/25 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..."  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree.

This is not the point.
Separate documents can be consistent, but they aren't on this = point.

One of the two assertions must be changed. 
Remaining question: which one?
 
 
well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an = unknown destination CE.

I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets.
Clarification on this will be = welcome.

my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!)

if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues. 
 

if you mean the single mapping rule in IVI case, the answer is = NONE, surely. IVI uses RFC6052 address format rather than the MAP, = without the business of MAP.

OK
(In this respect at least, IVI significantly differs from a running = version of MAP-T).

well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules. 
 

 
if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your = question.

Saying that there is no mapping rule in IVI is = sufficient an answer.

then there is no more "not reaching collective understanding" for = this point. End of this topic for me. 
 

None? 
If one, is it a DMR or a BMR?
If two, what are they?
...
OK, could have been clearer.
Yet, I think you understand that with U, = one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports.
 
 
ok. then may i conclude, for the major part of U, that 1) U, = as a stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else.
2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress.

1) not only one statistics. i did it at Tsinghua University. prof. = Bao and others did it at CERNET. other guys did it in Europe and = published in IMC'07. and if you carefully read that paper, you may found = that case was very abnormal. 
2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty. 
 

2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? =

AFAIK, not weird to those who are open to accept = that it is very simple.

AFAIK, you'd better to have #1 accepted by the IPv6 protocol and = have #2 well discussed with the ICMP designers before concluding they = are "not weird"! i am not so open. to those who are open to accept this, = i think they should be also open to the following propositions (that are = wrong to me):

*1. IPv6 option header, as long as there are reverved or = not-yet-used or padding bits, could be redefined as we like.
*2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message. 
*3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it. 
*4. IPv4 header checksum is actually useless. 

if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community!

... 
well, i mostly argue that the ICMPv4 being carried by IPv6 and = CNP are major flaws (as we discussed so much, i was not convinced at = all). i don't think others who read the specification don't see them and = other issues.

ICMPv4 payloads in IPv6 packets appear only during domain = traversal, where they don't hurt = anyone.

see above. 
 

If a host is IPv6 only, it isn't a 4rd-U host. 
For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable = RFCs. 

common understanding, including RFC6052/RFC6145/RFC6146 but surely = not limited to these. 
 
BIH in DS hosts is AFAIK particularly powerful, and IMHO = sufficient. 
A new solution for this isn't = needed. 

BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations. 
 

an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. =

Different understanding.
An detailed E use case that cannot be supported by U (if it = exists) would give substance to this claim.
Open to look at it.  

in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 customer network plays BGP over IPv4 = with the provider, through the BGP session between CE and BR, a virtual = link is desired. 

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
                  =                   =  
second example, there are dynamic routing protocols like RIP = running in the following (multihoming) topology for IPv4 routing. the = operator may want to treat the CE-BR as a single hop in order the = virtual link is considered the distance vector calculation.

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
               \   =                     =                     =              /
                \   =                     =                     =            /
                =  +------------ CE ----(Another, IPv4 domain)----------+

third example, same topology as above but OSPF are applied, and = OSPF TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt. 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.) 



but U needs still discussion

T too.
See, for example, (*) above.

you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both. 
 

and running code approval. it cannot replace T at least this = moment.

Understanding how U's header mapping works doesn't need great = expertise.
Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator.

well, it works just like another translator, surely it doesn't need = great expertise. 
 

Running code as soon couldn't be done yet, but isn't a big deal at = all (see (**) below)

... 

MAP can work even without the V-octet and CNP, at least in = significant cases.

Not a valid reason to stop progress, especially if = easy to understand.
At least Med suggested to look at V octet even in the context of = MAP (if chosen for standard track).

no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary. 
 

 if we have the standard of MAP, we can = immediately deploy it into practice through applying MAP rules into = the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format.

(**)
When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect.

yes but i also mentioned the prerequisite: "when i fully understand = it and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the = necessity. 

thanks,
- maoke
 
Yet, modifying T code to support header mapping remains quite = simple (you even call it a translation variant). Starting from E code, = it's simple too.
When this is done, all verifications can be easily done that what = analysis says is right is also right with running code.


Regards,
=
RD


________________= _______________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

_______________________________________________=
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-6-816790218-- From despres.remi@laposte.net Tue Apr 3 07:49:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77921F8595 for ; Tue, 3 Apr 2012 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVUE8aoZ+yeT for ; Tue, 3 Apr 2012 07:49:11 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 403F021F8513 for ; Tue, 3 Apr 2012 07:49:08 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A41A0940141; Tue, 3 Apr 2012 16:49:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-822537544 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 16:48:59 +0200 Message-Id: <83D82FDF-C851-43E5-B8A4-46EEC4EF2B38@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> <2703125B-6C36-48EA-A7DF-118F1E3C3C00@laposte.net> To: guoliang han X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 05 Apr 2012 08:14:15 -0700 Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_Mor?= =?windows-1252?q?e_MAP-T_experiment_needed?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:49:13 -0000 --Apple-Mail-18-822537544 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-04-03 =C3=A0 15:41, Guoliang a =C3=A9crit : > Hi, Remi: > =20 > Pls read my comments below. >=20 > 2012/4/3 R=C3=A9mi Despr=C3=A9s >=20 > Le 2012-04-03 =C3=A0 14:43, guoliang han a =C3=A9crit : >=20 >> Hi, Remi: >> =20 >> I don't think my case illustrates MAP-T needs to remain experimental, = my comments are below: >> =20 >> =20 >> 2012/4/3 R=C3=A9mi Despr=C3=A9s >> Hi, Guoliang, >>=20 >> Interesting enough, the example you give illustrates that MAP-T needs = to remain experimental, more than any other solution. >>=20 >> 1. >> RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280. It = specifies two behaviors, one that does this, and one that doesn't. Which = one to choose isn't AFAIK specified in the MAP-T draft. >> =20 >> =20 >> RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach is that = "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can = be administered in compliance with Section 4.3.1 of [RFC4890]", the = second approach is to change PTB MTU value to 1280 in case PTB<1280 and = set DF bit to 0 in case the packet is less than or equal to 1280 bytes, = if the requirements of the first approach can't be met. It doesn't mean = the administrator can refuse to take the second approach according to = his will.=20 >> =20 >>=20 >> 2. >> With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to work. >> =20 >> Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could traverse current IPv6 firewalls = successfully. >=20 > Typical use cases of 4rd-U have no firewall between BRs and CEs. > If some would exist, they should be configured to let ICMPv4 payloads = go through (Protocol =3D 1) > This is like configuring them to accept IPv4 headers in IPv6 payloads = (Protocol =3D 4) > =20 > Hope so. Still anticipating experimental results proving that yet. > =20 >=20 >=20 >> 3. >> Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T. >> =20 >> See Section 6 of RFC6145. >=20 > This isn't in RFC6145, simply a reference to (*) below. > If I misunderstood, please explain what. > =20 > You surely misunderstood that. I mentioned "in that case", instead of = replacing DF=3D1 by DF=3D0 in all cases. Replacing DF bit only occurs in = the case that incoming packet size is less that 1280 bytes, which is = exactly the requirement of RFC6145. The so called "corner case" where RFC6145 looses the DF=3D1 is when a = packet with DF=3D1 is already fragmented by its source.=20 In this case, because there are several fragments, translates back to = IPv4 with DF=3D0. In the example you give, RFC6145 doesn't add a fragment header, in the = IPv4 to IPv6 translation because the packet has DF=3D1 and isn't = fragmented (sec 4). The inverse translation, seeing no fragment header, the DF bit is = normally set to 1 (sec 5.1). (A configuration option is mentioned so = that the node MAY set it to 0 in some conditions, but MAP-T makes clear = this must not be the case: "the IPv4 packets with DF=3D1 will be = translated to IPv6 packets without fragmentation header and will be = translated back to IPv4 packets with DF=3D1".) >> When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose. >>=20 >>=20 >> In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments. >> =20 >> Regards, >> RD >> =20 >> In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 carefully. >=20 > Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 should AFAIK be avoided for = IPv4 PMTU discovery to work. > Still waiting for a clarification on this issue. > =20 > If the translator set DF bit to 0 in case the packet is less than or = equal to 1280 bytes, and replace PTB<1280 by PTB=3D1280, there are no = problems on the data path, whether in single/double translation.=20 In any case, not a MAP-T feature. RD > =20 > Regards, > Guoliang > =20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 >> =20 >> regards, >> Guoliang >> =20 >> =20 >>=20 >>=20 >> Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = : >>=20 >>> +1. >>> =20 >>> As a follower of MAP team, I participated much in developing and = deploying=20 >>> double-translation in CERNET. As far as I am concerned, in the = translation scenario, >>> 4rd-U only solved some corner cases but missed some other cases = simultaneously. >>> =20 >>> As an example, I suppose one fragmentation case as following: >>> =20 >>> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host >>> =20 >>> The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4=20 >>> network on the right side is 800. Now an IPv4 host on the left side = sends a packet=20 >>> with length set to 1200 and MTU set to 1, to the IPv4 host in the = right side. The packet=20 >>> could traverse the IPv6 access network, but will be blocked in the = IPv4 network.=20 >=20 > (*) >=20 >>> In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4, >>> instead of preserving the original IPv4 DF bit. >=20 >=20 >>> =20 >>> In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet=20 >>> whose indicating MTU is less than 1280 bytes, it will change it to = 1280. So if the BR preserve >>> the DF bit, the sender will always believe the path MTU is 1280, = which will certainly lead to=20 >>> a black hole. >>> =20 >>> This is only one deployment problem, and we don't know how many = issues will be encountered >>> in the future. So my point is that 4rd-U still needs examination in = the actual deployment, and=20 >>> it's a bit early to propose it as an Informational/Standards Track = Document. >>> =20 >>> The mail sent yesterday seemed to encounter some problems. So if you = see this mail twice, sorry for that.=20 >>> =20 >>> regards,=20 >>> Guoliang >>>=20 >>> =20 >>> 2012/3/26 Maoke >>> hi Remi,=20 >>>=20 >>> let me remove those you have marked as "end". they are fine to me = too. only one point: no implementation nor operation trouble !=3D it is = safe to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all).=20 >>>=20 >>> 2012/3/25 R=C3=A9mi Despr=C3=A9s >>>=20 >>>=20 >>>>> c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 >>>>> =20 >>>>> =20 >>>>> first of all, they are not conflicting logically. >>>>=20 >>>> ??? >>>>=20 >>>>> second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. >>>>=20 >>>> This is not the point. >>>> Separate documents can be consistent, but they aren't on this = point. >>>>=20 >>>> One of the two assertions must be changed.=20 >>>> Remaining question: which one? >>>> =20 >>>> =20 >>>> well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an unknown = destination CE. >>>=20 >>> I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets. >>> Clarification on this will be welcome. >>>=20 >>> my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!) >>>=20 >>> if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues.=20 >>> =20 >>>=20 >>>> if you mean the single mapping rule in IVI case, the answer is = NONE, surely. IVI uses RFC6052 address format rather than the MAP, = without the business of MAP. >>>=20 >>> OK >>> (In this respect at least, IVI significantly differs from a running = version of MAP-T). >>>=20 >>> well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules.=20 >>> =20 >>>=20 >>>> =20 >>>> if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. >>>=20 >>> Saying that there is no mapping rule in IVI is sufficient an answer. >>>=20 >>> then there is no more "not reaching collective understanding" for = this point. End of this topic for me.=20 >>> =20 >>>=20 >>>> None?=20 >>>> If one, is it a DMR or a BMR? >>>> If two, what are they? >>>> ... >>>> OK, could have been clearer. >>>> Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. >>>> =20 >>>> =20 >>>> ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); >>>=20 >>> 1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else. >>> 2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress. >>>=20 >>> 1) not only one statistics. i did it at Tsinghua University. prof. = Bao and others did it at CERNET. other guys did it in Europe and = published in IMC'07. and if you carefully read that paper, you may found = that case was very abnormal.=20 >>> 2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty.=20 >>> =20 >>>=20 >>>> 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? >>>=20 >>> AFAIK, not weird to those who are open to accept that it is very = simple. >>>=20 >>> AFAIK, you'd better to have #1 accepted by the IPv6 protocol and = have #2 well discussed with the ICMP designers before concluding they = are "not weird"! i am not so open. to those who are open to accept this, = i think they should be also open to the following propositions (that are = wrong to me): >>>=20 >>> *1. IPv6 option header, as long as there are reverved or = not-yet-used or padding bits, could be redefined as we like. >>> *2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message.=20 >>> *3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it.=20 >>> *4. IPv4 header checksum is actually useless.=20 >>>=20 >>> if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community! >>>=20 >>>> ...=20 >>>> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP = are major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. >>>=20 >>> ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. >>>=20 >>> see above.=20 >>> =20 >>>=20 >>> If a host is IPv6 only, it isn't a 4rd-U host.=20 >>> For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 >>>=20 >>> common understanding, including RFC6052/RFC6145/RFC6146 but surely = not limited to these.=20 >>> =20 >>> BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20= >>> A new solution for this isn't needed.=20 >>>=20 >>> BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations.=20 >>> =20 >>>=20 >>>> an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. >>>=20 >>> Different understanding. >>> An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. >>> Open to look at it. =20 >>>=20 >>> in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >>>=20 >>> first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >>>=20 >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >>> =20 >>> second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >>>=20 >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >>> \ = / >>> \ = / >>> +------------ CE ----(Another, IPv4 = domain)----------+ >>>=20 >>> third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >>>=20 >>> MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.)=20 >>>=20 >>>=20 >>>=20 >>>> but U needs still discussion >>>=20 >>> T too. >>> See, for example, (*) above. >>>=20 >>> you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both.=20 >>> =20 >>>=20 >>>> and running code approval. it cannot replace T at least this = moment. >>>=20 >>> Understanding how U's header mapping works doesn't need great = expertise. >>> Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. >>>=20 >>> well, it works just like another translator, surely it doesn't need = great expertise.=20 >>> =20 >>>=20 >>> Running code as soon couldn't be done yet, but isn't a big deal at = all (see (**) below) >>>=20 >>> ...=20 >>>=20 >>>> MAP can work even without the V-octet and CNP, at least in = significant cases. >>>=20 >>> Not a valid reason to stop progress, especially if easy to = understand. >>> At least Med suggested to look at V octet even in the context of MAP = (if chosen for standard track). >>>=20 >>> no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary.=20 >>> =20 >>>=20 >>>> if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. >>>=20 >>> (**) >>> When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect. >>>=20 >>> yes but i also mentioned the prerequisite: "when i fully understand = it and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the necessity.=20 >>>=20 >>> thanks, >>> - maoke >>> =20 >>> Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. >>> When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. >>>=20 >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail-18-822537544 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, Remi:
 
Pls read my comments below.

2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>

Le 2012-04-03 =C3=A0 14:43, guoliang han a =C3=A9crit :

Hi, Remi:
 
I don't think my case illustrates MAP-T needs to remain = experimental, my comments are below:
 
 
2012/4/3 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>
Hi, Guoliang,=20

Interesting enough, the example you give illustrates that MAP-T = needs to remain experimental, more than any other solution.

1.
RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=3D1280.= It specifies two behaviors, one that does this, and one that doesn't. = Which one to choose isn't AFAIK specified in the MAP-T draft.
 
 
RFC6145 says in Section 6: "It SHOULD be possible to configure a = translator for either of the two approaches", the first approach = is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network = firewalls can be administered in compliance with Section 4.3.1 of = [RFC4890]", the second approach is to change PTB MTU value to 1280 in = case PTB<1280 and set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, if the requirements of the first = approach can't be met. It doesn't mean the administrator can refuse = to take the second approach according to his will. 
 

2.
With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination = unchanged. This is exactly what is necessary for PMTU discovery to = work.
 
Actually, what I worry about is whether IPv6 packets of 4rd-U = embedding ICMPv4 packets could  traverse current IPv6 firewalls = successfully.

Typical use cases of 4rd-U have no firewall between BRs = and CEs.
If some would exist, they should be configured to let ICMPv4 = payloads go through (Protocol =3D 1)
This is like configuring them to accept IPv4 headers in IPv6 = payloads (Protocol =3D 4)
 
Hope so. Still anticipating experimental results proving that = yet.
 


3.
Now, you suggest to replace DF=3D1 by DF=3D0 in BRs. This differs = AFAIK from RFC6145, and therefore from MAP-T.
 
See Section 6 of RFC6145.

This isn't in RFC6145, simply a reference to (*) = below.
If I misunderstood, please explain what.
 
You surely misunderstood that. I mentioned "in that = case", instead of replacing DF=3D1 by DF=3D0 in all cases. = Replacing DF bit only occurs in the case that incoming packet size = is less that 1280 bytes, which is exactly the requirement of = RFC6145.

The so called = "corner case" where RFC6145 looses the DF=3D1 is when a packet with DF=3D1= is already fragmented by its source. 
In this case, = because there are several fragments, translates back to IPv4 with = DF=3D0.

In the example you give, RFC6145 = doesn't add a fragment header, in the IPv4 to IPv6 translation because = the packet has DF=3D1 and isn't fragmented (sec 4).
The = inverse translation, seeing no fragment header, the DF bit is normally = set to 1 (sec 5.1). (A configuration option is mentioned so that the = node MAY set it to 0 in some conditions, but MAP-T makes clear this must = not be the case: "the IPv4 packets with DF=3D1 will be translated to = IPv6 packets without fragmentation header and will be translated back to = IPv4 packets with DF=3D1".)


When we have a detailed report on which parts of MAP-T have been = validated, with which options of RFC6145, it will be easier to analyze = scenarios like the one you propose.


In any case, thanks for providing one more evidence that the MAP-T = specification isn't as clear as claimed to all those who support it, and = in particular to some also criticize 4rd-U with invalid arguments.
   
    Regards,
RD
 
In fact, MAP-T is clear enough to be deployed without any problems, = if you read RFC6145 carefully.

Replacing IPv4 PTB<1280 by IPv4 PTB=3D1280 = should AFAIK be avoided for IPv4 PMTU discovery to work.
Still waiting for a clarification on this = issue.
 
If the translator set DF bit to 0 in case the packet is = less than or equal to 1280 bytes, and replace PTB<1280 by PTB=3D1280, = there are no problems on the data path, whether in single/double = translation. 

In any = case, not a MAP-T = feature.

RD


 
Regards,
Guoliang
 

Regards,
RD




 
regards,
Guoliang
 
 


Le 2012-04-03 =C3=A0 05:26, =E9=9F=A9=E5=9B=BD=E6=A2=81 a =C3=A9crit = :

+1.
 
As a follower of MAP team, I participated much in developing and = deploying
double-translation in CERNET. As far as I am concerned, in = the translation scenario,
4rd-U only solved some corner cases but = missed some other cases simultaneously.
 
As an example, I suppose one fragmentation case as = following:
 
(IPv4 customer network)--CE---(IPv6 access network)--BR(Core = Translator)--(IPv4 network)---IPv4 host
 
The minumum MTU of IPv6 access network is 1400, and the minimum MTU = of IPv4
network on the right side is 800. Now an IPv4 host on the = left side sends a packet
with length set to 1200 and MTU set to 1, = to the IPv4 host in the right side. The packet
could traverse the IPv6 access network, but will be blocked in the IPv4 = network. =

(*)=20

In this case, BR(Core Translator) must set DF to 0 when translating = from IPv6 back to IPv4,
instead of preserving the original IPv4 DF = bit.


 
In fact, according to RFC6145, if BR(Core Translator) receives an = ICMP Packet Too Big packet
whose indicating MTU is less than 1280 = bytes, it will change it to 1280. So if the BR preserve
the DF bit, = the sender will always believe the path MTU is 1280, which will = certainly lead to
a black hole.
 
This is only one deployment problem, and we don't know how many = issues will be encountered
in the future. So my point is that 4rd-U = still needs examination in the actual deployment, and
it's a bit = early to propose it as an Informational/Standards Track Document.
 
The mail sent yesterday seemed to encounter some problems. So if = you see this mail twice, sorry for that. 
 
regards,
Guoliang

 
2012/3/26 Maoke <fibrib@gmail.com>
hi Remi, 

let me remove those you have marked as "end". they are fine to me = too. only one point: no implementation nor operation trouble !=3D it is = safe to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, due to not providing virtual = links; while you insist it not a translation at all). 

2012/3/25 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..."  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree.

This is not the point.
Separate documents can be consistent, but they aren't on this = point.

One of the two assertions must be changed. 
Remaining question: which one?
 
 
well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an = unknown destination CE.

I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets.
Clarification on this will be = welcome.

my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!)

if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues. 
 

if you mean the single mapping rule in IVI case, the answer is = NONE, surely. IVI uses RFC6052 address format rather than the MAP, = without the business of MAP.

OK
(In this respect at least, IVI significantly differs from a running = version of MAP-T).

well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules. 
 

 
if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your = question.

Saying that there is no mapping rule in IVI is = sufficient an answer.

then there is no more "not reaching collective understanding" for = this point. End of this topic for me. 
 

None? 
If one, is it a DMR or a BMR?
If two, what are they?
...
OK, could have been clearer.
Yet, I think you understand that with U, = one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports.
 
 
ok. then may i conclude, for the major part of U, that 1) U, = as a stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else.
2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress.

1) not only one statistics. i did it at Tsinghua University. prof. = Bao and others did it at CERNET. other guys did it in Europe and = published in IMC'07. and if you carefully read that paper, you may found = that case was very abnormal. 
2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty. 
 

2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? =

AFAIK, not weird to those who are open to accept = that it is very simple.

AFAIK, you'd better to have #1 accepted by the IPv6 protocol and = have #2 well discussed with the ICMP designers before concluding they = are "not weird"! i am not so open. to those who are open to accept this, = i think they should be also open to the following propositions (that are = wrong to me):

*1. IPv6 option header, as long as there are reverved or = not-yet-used or padding bits, could be redefined as we like.
*2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message. 
*3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it. 
*4. IPv4 header checksum is actually useless. 

if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community!

... 
well, i mostly argue that the ICMPv4 being carried by IPv6 and = CNP are major flaws (as we discussed so much, i was not convinced at = all). i don't think others who read the specification don't see them and = other issues.

ICMPv4 payloads in IPv6 packets appear only during domain = traversal, where they don't hurt = anyone.

see above. 
 

If a host is IPv6 only, it isn't a 4rd-U host. 
For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable = RFCs. 

common understanding, including RFC6052/RFC6145/RFC6146 but surely = not limited to these. 
 
BIH in DS hosts is AFAIK particularly powerful, and IMHO = sufficient. 
A new solution for this isn't = needed. 

BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations. 
 

an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. =

Different understanding.
An detailed E use case that cannot be supported by U (if it = exists) would give substance to this claim.
Open to look at it.  

in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 customer network plays BGP over IPv4 = with the provider, through the BGP session between CE and BR, a virtual = link is desired. 

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
                  =                   =  
second example, there are dynamic routing protocols like RIP = running in the following (multihoming) topology for IPv4 routing. the = operator may want to treat the CE-BR as a single hop in order the = virtual link is considered the distance vector calculation.

    (IPv4 customer network)--- CE ----(IPv6-only = domain)----- BR ----(IPv4 world) 
               \   =                     =                     =              /
                \   =                     =                     =            /
                =  +------------ CE ----(Another, IPv4 domain)----------+

third example, same topology as above but OSPF are applied, and = OSPF TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt. 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. with at least the above three = examples, i conclude "U cannot replace E at all"! (btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.) 



but U needs still discussion

T too.
See, for example, (*) above.

you have ended that subject. fine to me. people have known the = difference between the "needs discussions" for the both. 
 

and running code approval. it cannot replace T at least this = moment.

Understanding how U's header mapping works doesn't need great = expertise.
Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator.

well, it works just like another translator, surely it doesn't need = great expertise. 
 

Running code as soon couldn't be done yet, but isn't a big deal at = all (see (**) below)

... 

MAP can work even without the V-octet and CNP, at least in = significant cases.

Not a valid reason to stop progress, especially if = easy to understand.
At least Med suggested to look at V octet even in the context of = MAP (if chosen for standard track).

no problem if you keep debate in/with the MAP design team. just our = current understanding is: it is not necessary. 
 

 if we have the standard of MAP, we can = immediately deploy it into practice through applying MAP rules into = the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format.

(**)
When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect.

yes but i also mentioned the prerequisite: "when i fully understand = it and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the = necessity. 

thanks,
- maoke
 
Yet, modifying T code to support header mapping remains quite = simple (you even call it a translation variant). Starting from E code, = it's simple too.
When this is done, all verifications can be easily done that what = analysis says is right is also right with running code.


Regards,
=
RD


________________= _______________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

_______________________________________________=
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=






= --Apple-Mail-18-822537544-- From adurand@juniper.net Thu Apr 5 08:52:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4221F86D0 for ; Thu, 5 Apr 2012 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-+QuV7AStH6 for ; Thu, 5 Apr 2012 08:52:08 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id AD8A121F8674 for ; Thu, 5 Apr 2012 08:52:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT32/n7kB/wSzMk7F5iZHM8draT7t3jI+@postini.com; Thu, 05 Apr 2012 08:52:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 5 Apr 2012 08:48:46 -0700 From: Alain Durand To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 5 Apr 2012 08:48:45 -0700 Thread-Topic: [Softwires] Publish MAP and 4rd-U on experimental track Thread-Index: Ac0TQ5W326imqsFnSGKyQJG3GhKHqg== Message-ID: <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> In-Reply-To: <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:52:08 -0000 On Apr 5, 2012, at 10:22 AM, R=E9mi Despr=E9s wrote: >=20 > Absence of clear consensus was clear in Paris. > Mailing list is AFAIK appropriate to confirm a consensus, not to quickly = mask a lack of consensus by means of a weird voting procedure. Remi, You are correct there was a clear lack of consensus in the Paris meeting. H= owever, the gauge to enable us to formally declare consensus (or lack there= of) is not the meeting, but the mailing list. Thus, we are asking the very = same questions we asked during the Paris meeting on the mailing list. This = is NOT a formal vote. This is just a way for us, chairs, to confirm the con= sensus (or lack thereof) we saw in Paris. If the situation on the mailing remains the same as it was in Paris, we wil= l then decide what the next appropriate steps are. - Alain, wg co-chair.= From raghuramgangi@gmail.com Thu Apr 5 09:48:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7146621F86B5 for ; Thu, 5 Apr 2012 09:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABJ+awq2GOb6 for ; Thu, 5 Apr 2012 09:48:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02621F86B3 for ; Thu, 5 Apr 2012 09:48:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1028489wgb.13 for ; Thu, 05 Apr 2012 09:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BJ4hnJP88PLHrYhRPgSAYUwe8MizkIhYG0jdM3LM870=; b=YjcUy+zcqGohsH48nQKEbUE+2CuPSlQisyOEm96y3Ul/d4OD7S0jwAWWs8fhz6UTk7 8rCT4NHBmQ08W3JioUzBPBNZzOTICQDwxvGl1UYLtHEUjPPZTSLBAbP0uaW/bxtyC3Ul f7iPZJqiXlP9kq1Ih3shZq6SyDwIKn8cBDB9KpMcqlL1E9CcH/lYermGe2tNf9dPU7r7 KRhZrepw9D1otGFcw9bo5sUASVoYzdgLeL4cHkUmBaIahuGRtSqLUMskexplBCaL+1cr E8i5cVsXYZBG7nr8J87yQ3MSlJqdcMOrw0t8mAOvFq8RhrsbeBNTgUVN/SE+7sLTSdP6 WAWA== MIME-Version: 1.0 Received: by 10.180.102.129 with SMTP id fo1mr6434703wib.6.1333644512225; Thu, 05 Apr 2012 09:48:32 -0700 (PDT) Received: by 10.180.77.130 with HTTP; Thu, 5 Apr 2012 09:48:32 -0700 (PDT) Date: Thu, 5 Apr 2012 09:48:32 -0700 Message-ID: From: Raghu Ram To: "softwires@ietf.org WG" Content-Type: multipart/alternative; boundary=f46d0444814968692904bcf14fee Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:48:35 -0000 --f46d0444814968692904bcf14fee Content-Type: text/plain; charset=ISO-8859-1 > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- Raghu, IPInfusion, YES ---------------------------------------------------------------------------- > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ---------------------------------------------------------------------------- Raghu, IPInfusion, MAP >======================================================================== Thanks Raghu >> >>> Dear Softwire wg members: >>> >>> At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a whole) and >>> 4rd-U. We got very strong feedback that we needed to select one >>> solution to cover that full stateless case, not two, and that we should make this >>> decision relatively quickly. >>> >>> During Paris meeting, we asked the following additional question: >>> Do you prefer MAP or 4rd-U? >>> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>> >>> The real gauge of consensus is the mailing list, so we would like >>> to ask the same questions to the list. >>> >> >> (*) >>> ===================================================================== >>> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, >>> the other being published as experimental or informational. >>> Answering YES to this question means you agree we cannot publish both as standard track. >>> Answering NO to this question means you want to see both advance on the standard track. >> >> >> >>> ------------------------------------------------------------ ---------------- >>> Your full name, your affiliation, your choice: YES or NO >>> ------------------------------------------------------------ ---------------- >>> >>> >>> ===================================================================== >>> >>> Questions 2: Which one do you want to see placed on the Standards Track: >>> 4rd-U or MAP? >>> >>> ------------------------------------------------------------ ------------------ >>> Your full name, your affiliation, your choice: 4rd-U or MAP >>> ------------------------------------------------------------ ------------------ >>> >>> ===================================================================== >>> >>> >>> >>> >>> Please fill out the following form and reply to the list >>> by Wednesday 4/10 5pm EDT. >>> >>> Note: Use this thread ONLY for expressing your support to >>> one OR the other, and redirect any discussions to other threads. >>> That would help up gauge consensus. >>> >>> Alain & Yong. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires --f46d0444814968692904bcf14fee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>= ; Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track,
> the other being published as experimental or informational= .
> Answering YES to this question means you= agree we cannot publish both as standard track.
> Answering NO to this question means you want to see both advance on = the standard track.
>
>
-----------------------------------------------------= -----------------------
Ragh= u, IPInfusion, YES
--------------------------------------------= --------------------------------

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Questions 2: Which one do= you want to see placed on the Standards Track:
> 4rd-U or MAP?
>
>
--------------------------------------------= --------------------------------
Raghu, IPInfusion, MAP
>= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks
= Raghu

>>
>>> Dear Softwire wg members:
>>>
>>> At the Pa= ris IETF Softwire meeting, we had presentations on MAP (taken as a whole) = =A0and
>>> 4rd-U. We got very strong f= eedback that we needed to select one
>>> solution to cover that full stateless case, not tw= o, and that we should make this
>>> de= cision relatively quickly.
>>><= br style> >>> During Paris meeting, we asked the following addit= ional question:
>>> Do you prefer MAP = or 4rd-U?
>>> We got about 1/3 support= for 4rd-U and 2/3 for MAP.
>>>
>>> The real = gauge of consensus is the mailing list, so we would like
>>> to ask the same questions to the list.
>>>
>>
>> (*)
>>> =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>> Question 1: Do you agree that the wg should put EI= THER 4rd-U OR MAP (as a whole) on the standard track,
>>> the other being published as experimental or informatio= nal.
>>> Answering YES to this question means you agree we = cannot publish both as standard track.
>>= > Answering NO to this question means you want to see both advance on th= e standard track.
>>
>>
<= span style>>>
>>> --------------= --------------------------------------------------------------
>>> Your full name, your affiliation, your choice: YES= or NO
>>> ---------------------------= -------------------------------------= ------------
>>>
>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Questions= 2: Which one do you want to see placed on the Standards Track:
>>> 4rd-U or MAP?
>= ;>>
>>> -------------------------------= ----------------------------------------------->>> Your full name, your affiliation, your cho= ice: 4rd-U or MAP
>>> -------------------------------= ----------------------------------------------->>>
>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>>>>>
>>>
>>> Please fill out the following form a= nd reply to the list
>>> by Wednesday 4/10 5pm EDT.
>>>
>>> Note: Use this t= hread ONLY for expressing your support to
>&= gt;> one OR the other, and redirect any discussions to other threads.
>>> That would help up gauge consensus.
>>>
>>> Alain &= amp; Yong.
>>> _______________________= ________________________
>>> Softwires mailing list
>>>=A0Softwire= s@ietf.org
>>>=A0https://= www.ietf.org/mailman/listinfo/softwires
>>
>> _________________= ______________________________
>> Softwires mailing list
>>=A0<= /span>Softwires@ietf.org >>=A0https://www.ietf.org/mailman/listinf= o/softwires --f46d0444814968692904bcf14fee-- From despres.remi@laposte.net Thu Apr 5 09:58:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBB21F8749 for ; Thu, 5 Apr 2012 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdnQybPeV58D for ; Thu, 5 Apr 2012 09:58:25 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6254E21F86D8 for ; Thu, 5 Apr 2012 09:58:25 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id uGyL1i00837Y3f403GyLWX; Thu, 05 Apr 2012 18:58:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> Date: Thu, 5 Apr 2012 18:58:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:58:26 -0000 Le 2012-04-05 =E0 17:48, Alain Durand a =E9crit : >=20 > On Apr 5, 2012, at 10:22 AM, R=E9mi Despr=E9s wrote: >>=20 >> Absence of clear consensus was clear in Paris. >> Mailing list is AFAIK appropriate to confirm a consensus, not to = quickly mask a lack of consensus by means of a weird voting procedure. >=20 > Remi, >=20 > You are correct there was a clear lack of consensus in the Paris = meeting. However, the gauge to enable us to formally declare consensus = (or lack thereof) is not the meeting, but the mailing list. =46rom Scott Bradner to IETF newcomers at IETF 72: "final decisions must be VERIFIED on mailing list, to ensure those not = present are included, but taking into account face-to-face discussion" = (upper-case added). > Thus, we are asking the very same questions we asked during the Paris = meeting on the mailing list. This is NOT a formal vote. This is just a = way for us, chairs, to confirm the consensus (or lack thereof) we saw in = Paris. I can't agree that the lack of consensus was dubious in the face-to-face = meeting Paris, in particular because, before being urged to mitigate his = statement, a neutral observer spontaneously wrote "I have not been = involved in this work, but did observe at the meeting a show of hands = for 4rd-U at least as numerous as that for MAP. For whatever reason, the = WG at large does not seem prepared to commit to a single solution." Now, one question, assuming for a second that the new procedure would = confirms what we had in the face-to-face meeting, yes to Q1, no = consensus to Q2, what is your current plan? RD but taking into account face-to-face discussion =20 > If the situation on the mailing remains the same as it was in Paris, = we will then decide what the next appropriate steps are. >=20 > - Alain, wg co-chair. From adurand@juniper.net Thu Apr 5 10:20:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8569721F879B for ; Thu, 5 Apr 2012 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgOqqhg4wjcB for ; Thu, 5 Apr 2012 10:20:56 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE521F879A for ; Thu, 5 Apr 2012 10:20:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT33UcFwTM33WahYfXHzefx/Kth5GfdPJ@postini.com; Thu, 05 Apr 2012 10:20:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 5 Apr 2012 10:20:34 -0700 From: Alain Durand To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 5 Apr 2012 10:20:33 -0700 Thread-Topic: [Softwires] Publish MAP and 4rd-U on experimental track Thread-Index: Ac0TUGjEYtW0NNkBScupKkUc2D7sHg== Message-ID: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 17:20:56 -0000 On Apr 5, 2012, at 12:58 PM, R=E9mi Despr=E9s wrote: >=20 > Now, one question, assuming for a second that the new procedure would con= firms what we had in the face-to-face meeting, yes to Q1, no consensus to = Q2, what is your current plan? >=20 > RD There are a number of possibilities, but I do not want to go into the detai= ls before we see the results of the current consensus call. Alain.= From despres.remi@laposte.net Thu Apr 5 10:32:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D128D21F8766 for ; Thu, 5 Apr 2012 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSSeluFUqYzi for ; Thu, 5 Apr 2012 10:32:06 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71A21F875D for ; Thu, 5 Apr 2012 10:32:05 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id uHY11i00G37Y3f403HY100; Thu, 05 Apr 2012 19:32:04 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 5 Apr 2012 19:32:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 17:32:06 -0000 Le 2012-04-05 =E0 19:20, Alain Durand a =E9crit : >=20 > On Apr 5, 2012, at 12:58 PM, R=E9mi Despr=E9s wrote: >>=20 >> Now, one question, assuming for a second that the new procedure would = confirms what we had in the face-to-face meeting, yes to Q1, no = consensus to Q2, what is your current plan? >>=20 >> RD >=20 > There are a number of possibilities, but I do not want to go into the = details before we see the results of the current consensus call. So: 1. There an attempt at negating the clear absence of consensus in Paris = (this BTW despite 45 min to present MAP and only 15 min to present = 4rd-U). 2. The WG cannot be informed of what happens if the this lack of = consensus is maintained. Sorry, but I must disagree that his is normal process in IETF. RD =20 >=20 > Alain. From brian@innovationslab.net Thu Apr 5 11:43:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD021F86B4 for ; Thu, 5 Apr 2012 11:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYJaj68W0Fx0 for ; Thu, 5 Apr 2012 11:43:34 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3D56521F86A7 for ; Thu, 5 Apr 2012 11:43:34 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 26DB088117; Thu, 5 Apr 2012 11:43:34 -0700 (PDT) Received: from clemson.wireless.jhu.edu (unknown [128.220.159.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C36B130017; Thu, 5 Apr 2012 11:43:33 -0700 (PDT) Message-ID: <4F7DE7D4.6000703@innovationslab.net> Date: Thu, 05 Apr 2012 14:43:32 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 05 Apr 2012 11:51:15 -0700 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:43:34 -0000 On 4/5/12 12:58 PM, Rémi Després wrote: > >> >> You are correct there was a clear lack of consensus in the Paris >> meeting. However, the gauge to enable us to formally declare >> consensus (or lack thereof) is not the meeting, but the mailing >> list. > > From Scott Bradner to IETF newcomers at IETF 72: "final decisions > must be VERIFIED on mailing list, to ensure those not present are > included, but taking into account face-to-face discussion" > (upper-case added). > From RFC 2418: In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list. From Tetsuya.Murakami@ipinfusion.com Thu Apr 5 14:16:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B6121F8642 for ; Thu, 5 Apr 2012 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y54C2ER8LsFY for ; Thu, 5 Apr 2012 14:16:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 82B6C21F863C for ; Thu, 5 Apr 2012 14:16:41 -0700 (PDT) Received: from mail126-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 21:16:40 +0000 Received: from mail126-ch1 (localhost [127.0.0.1]) by mail126-ch1-R.bigfish.com (Postfix) with ESMTP id E6A7F20438; Thu, 5 Apr 2012 21:16:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail126-ch1: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1 (MessageSwitch) id 1333660598281763_32415; Thu, 5 Apr 2012 21:16:38 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail126-ch1.bigfish.com (Postfix) with ESMTP id 35E422C035E; Thu, 5 Apr 2012 21:16:38 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 21:16:37 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.250]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 21:16:36 +0000 From: Tetsuya Murakami To: Alain Durand Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: AQHNE3Fi94bkVkbkhUmujsqkVIB8Rg== Date: Thu, 5 Apr 2012 21:16:36 +0000 Message-ID: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <75E934C2C224314DAA33D6A918915BD0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT001.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT001.namprd05.prod.outlook.com X-FOPE-CRA-Verdict: 157.56.244.213$juniper.net%12218%4%ipinfusion.com%False%False%0$ X-OriginatorOrg: ipinfusion.com Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:16:42 -0000 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as = standard track. > Answering NO to this question means you want to see both advance on the s= tandard track. ---------------------------------------------------------------------------= - Tetsuya Murakami, IP Infusion: YES ---------------------------------------------------------------------------= - > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? ---------------------------------------------------------------------------= - Tetsuya Murakami, IP Infusion: MAP ---------------------------------------------------------------------------= - From moreiras@nic.br Thu Apr 5 15:34:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC9B21F863E for ; Thu, 5 Apr 2012 15:34:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI92KY8tiYae for ; Thu, 5 Apr 2012 15:34:34 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08E21F8638 for ; Thu, 5 Apr 2012 15:34:34 -0700 (PDT) Received: from [200.160.5.96] (5.96.net.registro.br [200.160.5.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 760DD20801BC; Thu, 5 Apr 2012 19:34:33 -0300 (BRT) Message-ID: <4F7E1DF9.9000907@nic.br> Date: Thu, 05 Apr 2012 19:34:33 -0300 From: "Antonio M. Moreiras" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Alain Durand , "softwires@ietf.org WG" References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-Enigmail-Version: 1.4 OpenPGP: id=18627EC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 22:34:35 -0000 > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Antonio M. Moreiras, NIC.br: YES ---------------------------------------------------------------------------- > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? ------------------------------------------------------------------------------ Antonio M. Moreiras, NIC.br: MAP ------------------------------------------------------------------------------ From shtsuchi@cisco.com Thu Apr 5 17:51:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26A21F852B for ; Thu, 5 Apr 2012 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux5QVs2gEHUO for ; Thu, 5 Apr 2012 17:51:29 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id E256121F8527 for ; Thu, 5 Apr 2012 17:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2630; q=dns/txt; s=iport; t=1333673489; x=1334883089; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6kgqn1TIEUPshL579vBBJgFd5CxxLjBLn/JoaAUtxd0=; b=OtV2orjI9M206N9ekotpLJCY+MuvNpFqRtQ1piFxsLQoqhGwJ6y4oO+G MwZ7bk6m0lcmhF5XFqLWelIHjSaFYCCH832Mb6tt3LF1wQftdTGhK7Az8 yyfu2Vn6NcOZiWlcKsm8Ey8VUHAKBcEPeJFir7lABGN5hhUtGe5uvBVso I=; X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="9422385" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 06 Apr 2012 00:51:17 +0000 Received: from [64.104.52.81] (dhcp-tmt-wirelessdata-64-104-52-81.cisco.com [64.104.52.81]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q360pFWj031625; Fri, 6 Apr 2012 00:51:16 GMT Message-ID: <4F7E3E03.6060303@cisco.com> Date: Fri, 06 Apr 2012 09:51:15 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adurand@juniper.net References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:51:30 -0000 (2012/04/05 6:14), Alain Durand wrote: > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- Shishio Tsuchiya, Cisco Systems G.K. , YES ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ > > ===================================================================== ---------------------------------------------------------------------------- Shishio Tsuchiya, Cisco Systems G.K. ,MAP ---------------------------------------------------------------------------- > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From sakiyama@cisco.com Thu Apr 5 18:38:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655E211E8088 for ; Thu, 5 Apr 2012 18:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boXQibapQC-2 for ; Thu, 5 Apr 2012 18:38:35 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF611E8080 for ; Thu, 5 Apr 2012 18:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sakiyama@cisco.com; l=1696; q=dns/txt; s=iport; t=1333676315; x=1334885915; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dZFg4Q7iEaJ5GyijFToDtl+lZCSbqW9ThxzdLYUzKHc=; b=P5fkzR5tu42oCPKjo8s1nUhMnfnlhh+E+r6OTsvEOdnIyPz3Ua3gCmKq M11Ha3lG1ESGhj9fUlPn66Djd449syI0Uia4AVwTm0iJa23WCSpQYYhh8 a8gtcDcqqZRU0YNVJzOftzADno0S3LXiOpqrJPEaimoeqiOLXFT5YzqMC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEBIfk9Io8UY/2dsb2JhbABFugqCCgEBBAEBAQ8BJTYKARALDhMWDwkDAgECARUwBg0BBQIBARcHh2wLmkqfZASQSwSIV40UjkuBaYJ2gU0 X-IronPort-AV: E=Sophos;i="4.75,379,1330905600"; d="scan'208";a="9424206" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Apr 2012 01:38:33 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q361cWb5006714; Fri, 6 Apr 2012 01:38:33 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 09:38:32 +0800 Received: from tky-sakiyama-8912.cisco.com ([10.71.47.195]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 09:38:32 +0800 Message-ID: <4F7E4917.2000105@cisco.com> Date: Fri, 06 Apr 2012 10:38:31 +0900 From: Shigeru Akiyama User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alain Durand References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2012 01:38:32.0161 (UTC) FILETIME=[F98FAD10:01CD1395] Cc: softwires@ietf.org, int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:38:36 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Shigeru Akiyama, Cisco Systems G.K.: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Shigeru Akiyama, Cisco Systems G.K.: MAP ------------------------------------------------------------------------------ > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- --------------------------------------- Shigeru Akiyama Customer Solution Architect CCIE#5841 SP AP CTO HQ Cisco Systems G.K. TEL: 03-6434-2316 FAX: 03-6434-6242 Email: sakiyama@cisco.com --------------------------------------- From KoheiO@ipinfusion.com Thu Apr 5 18:57:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25FF21F8609 for ; Thu, 5 Apr 2012 18:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksUdBotOE1dC for ; Thu, 5 Apr 2012 18:57:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81B21F8603 for ; Thu, 5 Apr 2012 18:57:42 -0700 (PDT) Received: from mail10-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 01:57:41 +0000 Received: from mail10-ch1 (localhost [127.0.0.1]) by mail10-ch1-R.bigfish.com (Postfix) with ESMTP id AA7A0C04B1; Fri, 6 Apr 2012 01:57:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail10-ch1: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=KoheiO@ipinfusion.com; helo=CH1PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail10-ch1 (localhost.localdomain [127.0.0.1]) by mail10-ch1 (MessageSwitch) id 1333677459753655_23117; Fri, 6 Apr 2012 01:57:39 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail10-ch1.bigfish.com (Postfix) with ESMTP id A84F42C0043; Fri, 6 Apr 2012 01:57:39 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 01:57:39 +0000 Received: from CH1PRD0510MB380.namprd05.prod.outlook.com ([169.254.9.206]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0135.002; Fri, 6 Apr 2012 01:57:38 +0000 From: Kohei Ono To: Alain Durand , "softwires@ietf.org WG" Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgA7/oUg Date: Fri, 6 Apr 2012 01:57:38 +0000 Message-ID: <1F7D038A913A064AA0521A0FCAD3CA7B0E5CD8DB@CH1PRD0510MB380.namprd05.prod.outlook.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.119.252.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT004.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT004.namprd05.prod.outlook.com X-FOPE-CRA-Verdict: 157.56.244.213$juniper.net%12218%4%ipinfusion.com%False%False%0$ X-OriginatorOrg: ipinfusion.com Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:57:43 -0000 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as > a whole) on the standard track, the other being published as experimental > or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. >=20 > ---------------------------------------------------------------------- > ------ > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------- > ------ Kohei ONO , IP Infusion Japan G.K. , YES >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? >=20 > ---------------------------------------------------------------------- > -------- > Your full name, your affiliation, your choice: 4rd-U or MAP > ---------------------------------------------------------------------- > -------- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 Kohei ONO, IP Infusion Japan G.K. , MAP Thanks, Kohei ONO From yu.guanghui@gmail.com Thu Apr 5 19:20:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88BF11E8086 for ; Thu, 5 Apr 2012 19:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I743lWbQJK+8 for ; Thu, 5 Apr 2012 19:20:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72CB811E808E for ; Thu, 5 Apr 2012 19:20:44 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1909474bku.31 for ; Thu, 05 Apr 2012 19:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O8bw5aJo+TOPTLdBlBBZBnaLtjNpus5XCcf8PGQmkNY=; b=qAjy3Tx6VmVqYiaqv1n+8iznrjAj6WXOKfeDfRJH0V+rklkItSIRnd5cluVCGS+tP1 LBHj8zuZtnz4JQgl/H1D9vKo/MU3JeFI0rm6Unh60QJxmqZXGPXYR1ogS+5o45Bq581N naPxD2dk479oFY7Ge23jexA9epbNsKZS9tFDvC8lCH6DZKDoAWlxdhSYDUDXGCRMLYsb qtzSJreceZndI16DTBbxXPK3YMeVecss8GuyMqFk6aNtJvm0ekRtpgDvWFjg+IbzR42B vyVVK/1urCIZRGiSXsugpdYFsnuW3Om41KxngrSnu/NEiMnRS4KB73tyvOjz2vrWwCUE gsIQ== MIME-Version: 1.0 Received: by 10.204.155.143 with SMTP id s15mr2306507bkw.44.1333678842755; Thu, 05 Apr 2012 19:20:42 -0700 (PDT) Received: by 10.204.187.3 with HTTP; Thu, 5 Apr 2012 19:20:42 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Fri, 6 Apr 2012 10:20:42 +0800 Message-ID: From: Guanghui Yu To: Alain Durand Content-Type: multipart/alternative; boundary=0015175deff6aaba1b04bcf94d3b Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 02:20:58 -0000 --0015175deff6aaba1b04bcf94d3b Content-Type: text/plain; charset=ISO-8859-1 ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > ---------------------------------------------------------------------------- > Yu Guanghui, Dalian University of Technology: YES > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > ------------------------------------------------------------------------------ Yu Guanghui, Dalian University of Technology: MAP > > ------------------------------------------------------------------------------ > > ===================================================================== > -- Yu Guanghui Network and Information Center Dalian University of Technology, China --0015175deff6aaba1b04bcf94d3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

---------------------------------------------------------------------------= -

Yu Guanghui, Dalian University of Technology:=A0= YES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

---------------------------------------------------------------------------= ---
Yu Guanghui, Dalian University of Technology: MAP
<= /div>
---------------------------------------------------------------------------= ---

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



--
Yu Guanghui <yg= h at dlut.edu.cn>
Network and Information Center
Dalian University of Tech= nology, China


--0015175deff6aaba1b04bcf94d3b-- From wzk@synet.edu.cn Thu Apr 5 19:27:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0613C11E8073 for ; Thu, 5 Apr 2012 19:27:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2XzuzYhmmHU for ; Thu, 5 Apr 2012 19:27:35 -0700 (PDT) Received: from mail.synet.edu.cn (unknown [IPv6:2001:da8:a8:ffd:20c:29ff:fe9f:8138]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFDB11E8086 for ; Thu, 5 Apr 2012 19:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.synet.edu.cn (Postfix) with ESMTP id 49D5960F96; Fri, 6 Apr 2012 10:25:46 +0800 (CST) X-Virus-Scanned: amavisd-new at synet.edu.cn Received: from mail.synet.edu.cn ([127.0.0.1]) by localhost (mail.synet.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk6VnNvz80fz; Fri, 6 Apr 2012 10:25:40 +0800 (CST) Received: from mail.synet.edu.cn (mail.synet.edu.cn [202.118.7.146]) by mail.synet.edu.cn (Postfix) with ESMTP id DEE2F60F95; Fri, 6 Apr 2012 10:25:40 +0800 (CST) Date: Fri, 6 Apr 2012 10:25:40 +0800 (CST) From: Zhankao WEN To: Alain Durand Message-ID: <1910673586.16263.1333679140700.JavaMail.root@mail.synet.edu.cn> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [202.118.0.200] X-Mailer: Zimbra 7.1.4_GA_2567 (ZimbraWebClient - FF3.0 (Win)/7.1.4_GA_2555) Cc: "softwires@ietf.org WG" , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 02:27:37 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Zhankao WEN, Networking Center of Northeastern University, YES ---------------------------------------------------------------------------= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Zhankao WEN, Networking Center of Northeastern University, MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best regards -- Name: Zhankao WEN(=E6=B8=A9=E5=8D=A0=E8=80=83) Email: wzk@synet.edu.cn wzk@mail.neu.edu.cn Tel&Fax: +86-24-83687240 Address: Networking Center Northeastern University Shenyang Liaoning Province P.R. China (110819) ----- Original Message ----- > From: "Alain Durand" > To: "softwires@ietf.org WG" > Cc: int-ads@tools.ietf.org, "Softwire Chairs" > Sent: Thursday, April 5, 2012 5:14:08 AM > Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs= MAP >=20 > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP > (taken as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we > should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP > (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both > as standard track. > Answering NO to this question means you want to see both advance on > the standard track. >=20 > -------------------------------------------------------------------------= --- > Your full name, your affiliation, your choice: YES or NO > -------------------------------------------------------------------------= --- >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards > Track: > 4rd-U or MAP? >=20 > -------------------------------------------------------------------------= ----- > Your full name, your affiliation, your choice: 4rd-U or MAP > -------------------------------------------------------------------------= ----- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From ChisatoK@ipinfusion.com Thu Apr 5 19:39:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE88B11E8086 for ; Thu, 5 Apr 2012 19:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwhGsZOb64Lp for ; Thu, 5 Apr 2012 19:39:46 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF811E8073 for ; Thu, 5 Apr 2012 19:39:45 -0700 (PDT) Received: from mail35-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 02:39:44 +0000 Received: from mail35-va3 (localhost [127.0.0.1]) by mail35-va3-R.bigfish.com (Postfix) with ESMTP id 8A876220424; Fri, 6 Apr 2012 02:39:44 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzc85fhzz1202hzz8275bhz2fh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail35-va3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=ChisatoK@ipinfusion.com; helo=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail35-va3 (localhost.localdomain [127.0.0.1]) by mail35-va3 (MessageSwitch) id 1333679982305167_8324; Fri, 6 Apr 2012 02:39:42 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.236]) by mail35-va3.bigfish.com (Postfix) with ESMTP id 3A4204A004B; Fri, 6 Apr 2012 02:39:42 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 02:39:41 +0000 Received: from CH1PRD0510MB379.namprd05.prod.outlook.com ([169.254.6.3]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0135.002; Fri, 6 Apr 2012 02:39:40 +0000 From: Chisato Kashiwagi To: Alain Durand Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: AQHNE56D94bkVkbkhUmujsqkVIB8Rg== Date: Fri, 6 Apr 2012 02:39:39 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_FB4A26512F164B7DBF4EB5FDC4B39A61ipinfusioncom_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT002.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT002.namprd05.prod.outlook.com X-FOPE-CRA-Verdict: 157.56.244.213$juniper.net%12218%4%ipinfusion.com%False%False%0$ X-OriginatorOrg: ipinfusion.com Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 02:45:41 -0000 --_000_FB4A26512F164B7DBF4EB5FDC4B39A61ipinfusioncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Chisato Kashiwagi, IP Infusion Japan G.K. , Yes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Chisato Kashiwagi, IP Infusion Japan G.K. , MAP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IP Infusion Japan G.K. Inc. TEL +81-3-6661-9231 FAX +81-3-6661-9232 Chisato Kashiwagi --_000_FB4A26512F164B7DBF4EB5FDC4B39A61ipinfusioncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <404ED0AA7A94A642AD1937F2B14DA1FB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

---------------------------------------------------------------------------= -
Chisato Kashiwagi, IP Infusion Japan G.K. , Yes

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

---------------------------------------------------------------------------= ---
Chisato Kashiwagi, IP Infusion Japan G.K. , MAP

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IP Infusion Japan G.K. Inc.
TEL +81-3-6661-9231
FAX +81-3-6661-9232
                    =                     &nbs= p;  Chisato Kashiwagi

--_000_FB4A26512F164B7DBF4EB5FDC4B39A61ipinfusioncom_-- From PengL@ipinfusion.com Thu Apr 5 20:00:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597B911E8099 for ; Thu, 5 Apr 2012 20:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYihdpLOSce9 for ; Thu, 5 Apr 2012 20:00:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8756711E8073 for ; Thu, 5 Apr 2012 20:00:07 -0700 (PDT) Received: from mail170-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 03:00:07 +0000 Received: from mail170-ch1 (localhost [127.0.0.1]) by mail170-ch1-R.bigfish.com (Postfix) with ESMTP id 1DA614602F0; Fri, 6 Apr 2012 03:00:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail170-ch1: domain of ipinfusion.com designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=PengL@ipinfusion.com; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail170-ch1 (localhost.localdomain [127.0.0.1]) by mail170-ch1 (MessageSwitch) id 1333681205650180_23426; Fri, 6 Apr 2012 03:00:05 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail170-ch1.bigfish.com (Postfix) with ESMTP id 9916A1A0048; Fri, 6 Apr 2012 03:00:05 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 03:00:05 +0000 Received: from BL2PRD0510MB373.namprd05.prod.outlook.com ([169.254.1.180]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0135.002; Fri, 6 Apr 2012 03:00:04 +0000 From: Peng Liu To: "softwires@ietf.org" Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0ToV0sgS7jAuSQSN21AW2v5iH4pQ== Date: Fri, 6 Apr 2012 03:00:03 +0000 Message-ID: <744108BC9CE15345A38745772B1592F60321DF@BL2PRD0510MB373.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.119.252.32] Content-Type: multipart/alternative; boundary="_000_744108BC9CE15345A38745772B1592F60321DFBL2PRD0510MB373na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0510HT001.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0510HT001.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: "int-ads@tools.ietf.org" , "softwire-chairs@tools.ietf.org" Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 03:00:08 -0000 --_000_744108BC9CE15345A38745772B1592F60321DFBL2PRD0510MB373na_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Peng Liu, IP Infusion Japan G.K. , Yes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Peng Liu, IP Infusion Japan G.K. , MAP --_000_744108BC9CE15345A38745772B1592F60321DFBL2PRD0510MB373na_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Peng Liu, IP Infus= ion Japan G.K. , Yes

Peng Liu, IP Infus= ion Japan G.K. , MAP


--_000_744108BC9CE15345A38745772B1592F60321DFBL2PRD0510MB373na_-- From xiechf01@gmail.com Thu Apr 5 22:29:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B06621F8568 for ; Thu, 5 Apr 2012 22:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf5PGFtM+mYw for ; Thu, 5 Apr 2012 22:29:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A378921F853C for ; Thu, 5 Apr 2012 22:29:01 -0700 (PDT) Received: by iazz13 with SMTP id z13so3214787iaz.31 for ; Thu, 05 Apr 2012 22:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=mFIBCYl9CKhcUhCTG8ct2yTYzS2UnYFtWSJIyK1KR1U=; b=HYfMNDnrkt+qTVoJIxFuYEoh2GR1xpbXXJB6clfOsOIAVyeLiFlFni4ZyPlI3pQzEJ HgaRja/svSnGdr/AmxxGLdyzZd19mS0dKx3rx0YEuSBPm6JAyOmFatxbdQRY/vMEdQqY YWDBYhB9aBgw2aNyyKZUaLaBkac3YyZgSU5pM0wMK4kWK/D/OO76xzZ9cMrc6+Sk4rrc 4O/Nb6IvMuxp2UGSirKte5widFJN6sPqL5YsJMs7CtU8jZ+P6LrGesuGy+mGMI/Quo8u lgpegg6wzVBAFzqQQD/bG5hB9RZ7pUC9tGelzjTrylyianUbwmKuxm02UPR/bNUreOKG ScDA== Received: by 10.50.222.233 with SMTP id qp9mr4631995igc.58.1333690141101; Thu, 05 Apr 2012 22:29:01 -0700 (PDT) Received: from xiechf-PC ([219.142.69.75]) by mx.google.com with ESMTPS id l9sm3880342iga.6.2012.04.05.22.28.56 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 22:28:59 -0700 (PDT) Date: Fri, 6 Apr 2012 13:28:50 +0800 From: xiechf01 To: "softwires@ietf.org WG" References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.87[cn] Mime-Version: 1.0 Message-ID: <201204061328433117761@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart300648347476_=----" Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 05:29:02 -0000 This is a multi-part message in MIME format. ------=_001_NextPart300648347476_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpRdWVzdGlvbiAxOiBEbyB5b3UgYWdyZWUgdGhhdCB0aGUgd2cg c2hvdWxkIHB1dCBFSVRIRVIgNHJkLVUgT1IgTUFQIChhcyBhIHdob2xlKSBvbiB0aGUgc3RhbmRh cmQgdHJhY2ssDQp0aGUgb3RoZXIgYmVpbmcgcHVibGlzaGVkIGFzIGV4cGVyaW1lbnRhbCBvciBp bmZvcm1hdGlvbmFsLg0KQW5zd2VyaW5nIFlFUyB0byB0aGlzIHF1ZXN0aW9uIG1lYW5zIHlvdSBh Z3JlZSB3ZSBjYW5ub3QgcHVibGlzaCBib3RoIGFzIHN0YW5kYXJkIHRyYWNrLg0KQW5zd2VyaW5n IE5PIHRvIHRoaXMgcXVlc3Rpb24gbWVhbnMgeW91IHdhbnQgdG8gc2VlIGJvdGggYWR2YW5jZSBv biB0aGUgc3RhbmRhcmQgdHJhY2suDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpYaWUgQ2hvbmdmZW5n LCAgQ2hpbmEgVGVsZWNvbSwgIFlFUw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUXVlc3Rpb25zIDI6IFdoaWNoIG9uZSBkbyB5b3Ugd2FudCB0byBzZWUgcGxhY2VkIG9u IHRoZSBTdGFuZGFyZHMgVHJhY2s6DQo0cmQtVSBvciBNQVA/DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClhpZSBDaG9uZ2ZlbmcsICBDaGluYSBUZWxlY29tLCAgTUFQDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KVGhhbmtzDQpDaG9uZ2Zlbmc= ------=_001_NextPart300648347476_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (= as a=20 whole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both= as=20 standard track.
Answering NO to this question means you want to see both advance on t= he=20 standard track.
---------------------------------------------------------------------= -------
Xie Chongfeng,  China Telecom,  YES
---------------------------------------------------------------------= -------
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questions 2: Which one do you want to see placed on the Standards=20 Track:
4rd-U or MAP?
---------------------------------------------------------------------= ---------
Xie Chongfeng,  China Telecom,  MAP
---------------------------------------------------------------------= ---------
 
Thanks
Chongfeng
------=_001_NextPart300648347476_=------ From bupthgl@gmail.com Thu Apr 5 22:29:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1409911E8072 for ; Thu, 5 Apr 2012 22:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=2.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njJiq5FK4iBA for ; Thu, 5 Apr 2012 22:29:50 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5133D21F853C for ; Thu, 5 Apr 2012 22:29:50 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1477653qcs.31 for ; Thu, 05 Apr 2012 22:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=knoTWsUB64GJdnVE3f+VN85Rm/E8eeD4XWTri6QPZ3U=; b=GRdp+ITMPcBcpVp5RaJYn2EbG/O9DEBXbT9U1HFZQ2OaUEyqU2lzyt3HZvJoY46O/G 6sGIWpd9Hi+aZFHvM9Z0u70Yri5cO8LmT6w5OY9OP2RpU6FKmtNrC8iQ14uBrFqECoTM kJFAA9HvZZTpP8mytRgWAEpt0PnpRqzgbk4518CyhnxnoK59zihrns1s25LaPJOtUEoz UvwLvTtYFzwreHRdr80I9bXk/4cJdeO7VUS9n5urcMq4GlIKH+GsQbI1RCJutSfXOKws uO9M3yGfCcH6vTB846jvTdy3zSnmwUTfWG+5hwlwDd42KEX+0z9mCCRHFSMgJQiXllZJ Q80Q== MIME-Version: 1.0 Received: by 10.224.32.12 with SMTP id a12mr7852309qad.0.1333690189705; Thu, 05 Apr 2012 22:29:49 -0700 (PDT) Received: by 10.229.158.195 with HTTP; Thu, 5 Apr 2012 22:29:49 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Fri, 6 Apr 2012 13:29:49 +0800 Message-ID: From: Guoliang To: Alain Durand Content-Type: multipart/alternative; boundary=20cf306f72faff73f304bcfbf1f4 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 05:29:51 -0000 --20cf306f72faff73f304bcfbf1f4 Content-Type: text/plain; charset=ISO-8859-1 2012/4/5 Alain Durand > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > ---------------------------------------------------------- Guoliang Han, Tsinghua University, my choice: YES ---------------------------------------------------------- > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > ----------------------------------------------------------- Guoliang Han, Tsinghua University, my choice: MAP ----------------------------------------------------------- > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf306f72faff73f304bcfbf1f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/5 Alain Durand = <adurand@juniper.net>
Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) =A0and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should mak= e this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

=A0
----------------------------------------------= ------------
Guoliang Han, Tsinghua University, my choice: YES
------= ----------------------------------------------------



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?
=A0
--------------------------------------------------= ---------
Guoliang Han, Tsinghua University, my choice: MAP
---------= --------------------------------------------------


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



--20cf306f72faff73f304bcfbf1f4-- From despres.remi@laposte.net Fri Apr 6 00:42:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD621F8644 for ; Fri, 6 Apr 2012 00:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVIROPa5rtqQ for ; Fri, 6 Apr 2012 00:42:39 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62F21F85E3 for ; Fri, 6 Apr 2012 00:42:38 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id uXia1i00E37Y3f403Xibmu; Fri, 06 Apr 2012 09:42:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F7DE7D4.6000703@innovationslab.net> Date: Fri, 6 Apr 2012 09:42:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:42:40 -0000 Hi, Brian,=20 First, welcome as new Internet-area AD. Also, thanks for the reference and the quote. Note however that, in this particular instance, this quote will not be = of any help because it concerns "issues which have not been discussed on = the mailing list". On the contrary, RFC 2418 says:=20 "There are two different cases where a working group may be trying to = understand the level of consensus via a mailing list ...=20 - In the case where a consensus which HAS BEEN REACHED during a = face-to-face meeting is being verified on a mailing list ...=20 - The other case is where the discussion has been held ENTIRELY over the = mailing list" (upper cases added). Facts are that: - No consensus has been reached during the face-to-face meeting. - There has been extensive discussion on the mailing list. - The only action that has been announced in absence of consensus was = publication of all specifications as experimental. There is therefore no justification I know to further delay publication = of ALL specifications as WG drafts, on experimental track. - As I already said to the chairs, I am ready to do it as soon as = authorized. - I understand that MAP-E+T drafts will also be treated the same, and = that's obviously fair. As already said too said, if procedures continue to be distorted, I = will have no other choice than referring to RFC 2026 section 6.5.1, and = signal, on behalf of co-authors of the 4rd-U proposal, "a difficulty = with Working Group process", with an "appeal to the IESG as a whole". King regards, RD Le 2012-04-05 =E0 20:43, Brian Haberman a =E9crit : > On 4/5/12 12:58 PM, R=E9mi Despr=E9s wrote: >>=20 >>>=20 >>> You are correct there was a clear lack of consensus in the Paris >>> meeting. However, the gauge to enable us to formally declare >>> consensus (or lack thereof) is not the meeting, but the mailing >>> list. >>=20 >> =46rom Scott Bradner to IETF newcomers at IETF 72: "final decisions >> must be VERIFIED on mailing list, to ensure those not present are >> included, but taking into account face-to-face discussion" >> (upper-case added). >>=20 >=20 > =46rom RFC 2418: >=20 > In determining the balance, the WG must ensure that > its process does not serve to exclude contribution by email-only > participants. Decisions reached during a face-to-face meeting about > topics or issues which have not been discussed on the mailing list, > or are significantly different from previously arrived mailing list > consensus MUST be reviewed on the mailing list. >=20 From prvs=436a95490=yanghq@neusoft.com Fri Apr 6 00:43:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2521F8319 for ; Fri, 6 Apr 2012 00:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAJnErHvA6Q4 for ; Fri, 6 Apr 2012 00:43:39 -0700 (PDT) Received: from mailgate.neusoft.com (mailgate.neusoft.com [210.83.25.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9291521F8621 for ; Fri, 6 Apr 2012 00:43:38 -0700 (PDT) Received: from unknown (HELO mailgate8.neusoft.com) ([192.168.1.132]) by mailgate.neusoft.com with ESMTP/TLS/DES-CBC3-SHA; 06 Apr 2012 15:43:31 +0800 Received: from unknown (HELO smtp.neusoft.com) ([192.168.2.145]) by mailgate8.neusoft.com with ESMTP/TLS/AES128-SHA; 06 Apr 2012 15:43:31 +0800 Received: from MPS-SYMBX02.neusoft.internal ([fe80::6dd8:2143:53a0:28d8]) by MPS-SYHUB05.neusoft.internal ([192.168.2.145]) with mapi id 14.02.0247.003; Fri, 6 Apr 2012 15:43:31 +0800 From: "yanghq@neusoft.com" To: "softwires@ietf.org" Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0TyPZQ9fqsG1yDSS6gdiXLVoh2hA== Date: Fri, 6 Apr 2012 07:43:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.118.7.147] Content-Type: multipart/alternative; boundary="_000_EDF530B5C272B448BB273EE368A6A34E1D22353DMPSSYMBX02neuso_" MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , "softwire-chairs@tools.ietf.org" Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:54:45 -0000 --_000_EDF530B5C272B448BB273EE368A6A34E1D22353DMPSSYMBX02neuso_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpRdWVzdGlvbiAxOiBEbyB5b3UgYWdyZWUgdGhhdCB0aGUgd2cgc2hvdWxk IHB1dCBFSVRIRVIgNHJkLVUgT1IgTUFQIChhcyBhIHdob2xlKSBvbiB0aGUgc3RhbmRhcmQgdHJh Y2ssDQp0aGUgb3RoZXIgYmVpbmcgcHVibGlzaGVkIGFzIGV4cGVyaW1lbnRhbCBvciBpbmZvcm1h dGlvbmFsLg0KQW5zd2VyaW5nIFlFUyB0byB0aGlzIHF1ZXN0aW9uIG1lYW5zIHlvdSBhZ3JlZSB3 ZSBjYW5ub3QgcHVibGlzaCBib3RoIGFzIHN0YW5kYXJkIHRyYWNrLg0KQW5zd2VyaW5nIE5PIHRv IHRoaXMgcXVlc3Rpb24gbWVhbnMgeW91IHdhbnQgdG8gc2VlIGJvdGggYWR2YW5jZSBvbiB0aGUg c3RhbmRhcmQgdHJhY2suDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhhaXF1YW4gWUFORywgTmV1 c29mdCwgWUVTDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClF1ZXN0 aW9ucyAyOiBXaGljaCBvbmUgZG8geW91IHdhbnQgdG8gc2VlIHBsYWNlZCBvbiB0aGUgU3RhbmRh cmRzIFRyYWNrOg0KNHJkLVUgb3IgTUFQPw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhhaXF1 YW4gWUFORywgTmV1c29mdCwgTUFQDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLS0NCkhhaXF1 YW4gWUFORw0KDQpOZXVzb2Z0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KQ29uZmlkZW50aWFsaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIGUtbWFpbCBhbmQgYW55IGFjY29tcGFueWluZyBhdHRhY2htZW50KHMpIAppcyBpbnRl bmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYW5kIG1heSBi ZSBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgb2YgCk5ldXNvZnQgQ29ycG9yYXRpb24s IGl0cyBzdWJzaWRpYXJpZXMgYW5kL29yIGl0cyBhZmZpbGlhdGVzLiBJZiBhbnkgcmVhZGVyIG9m IHRoaXMgY29tbXVuaWNhdGlvbiBpcyAKbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHVuYXV0 aG9yaXplZCB1c2UsIGZvcndhcmRpbmcsIHByaW50aW5nLCAgc3RvcmluZywgZGlzY2xvc3VyZSBv ciBjb3B5aW5nIAppcyBzdHJpY3RseSBwcm9oaWJpdGVkLCBhbmQgbWF5IGJlIHVubGF3ZnVsLklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvcixwbGVhc2UgCmlt bWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGFsbCBjb3BpZXMgZnJvbSAKeW91ciBzeXN0ZW0uIFRo YW5rIHlvdS4gCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo= --_000_EDF530B5C272B448BB273EE368A6A34E1D22353DMPSSYMBX02neuso_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9Z2IyMzEyIj4KPHN0eWxlIHR5cGU9InRleHQvY3Nz IiBpZD0ib3dhUGFyYVN0eWxlIj48L3N0eWxlPgo8L2hlYWQ+Cjxib2R5IGZwc3R5bGU9IjEiIG9j c2k9IjAiPgo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTogVGFob21hO2Nv bG9yOiAjMDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KUXVlc3Rpb24g MTogRG8geW91IGFncmVlIHRoYXQgdGhlIHdnIHNob3VsZCBwdXQgRUlUSEVSIDRyZC1VIE9SIE1B UCAoYXMgYSB3aG9sZSkgb24gdGhlIHN0YW5kYXJkIHRyYWNrLDxicj4KdGhlIG90aGVyIGJlaW5n IHB1Ymxpc2hlZCBhcyBleHBlcmltZW50YWwgb3IgaW5mb3JtYXRpb25hbC48YnI+CkFuc3dlcmlu ZyBZRVMgdG8gdGhpcyBxdWVzdGlvbiBtZWFucyB5b3UgYWdyZWUgd2UgY2Fubm90IHB1Ymxpc2gg Ym90aCBhcyBzdGFuZGFyZCB0cmFjay48YnI+CkFuc3dlcmluZyBOTyB0byB0aGlzIHF1ZXN0aW9u IG1lYW5zIHlvdSB3YW50IHRvIHNlZSBib3RoIGFkdmFuY2Ugb24gdGhlIHN0YW5kYXJkIHRyYWNr Ljxicj4KPGJyPgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPgpIYWlxdWFuIFlBTkcsIE5ldXNvZnQs IFlFUzxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4KPGJyPgo8YnI+Cj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4KPGJyPgpRdWVzdGlvbnMgMjogV2hpY2ggb25lIGRvIHlvdSB3YW50IHRvIHNlZSBwbGFjZWQg b24gdGhlIFN0YW5kYXJkcyBUcmFjazo8YnI+CjRyZC1VIG9yIE1BUD88YnI+Cjxicj4KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPgpIYWlxdWFuIFlBTkcsIE5ldXNvZnQsJm5ic3A7TUFQPGJyPgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2Pi0tPC9kaXY+CjxkaXY+ SGFpcXVhbiBZQU5HPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj5OZXVzb2Z0PC9kaXY+Cjwv ZGl2Pgo8bGluayByZWw9InN0eWxlc2hlZXQiIHR5cGU9InRleHQvY3NzIiBocmVmPSJkYXRhOnRl eHQvY3NzLCI+Cjxmb250IGZhY2U9Im1vbm9zcGFjZSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPgpDb25maWRlbnRpYWxpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYWNjb21wYW55aW5nIGF0dGFj aG1lbnQocykgPGJyPgppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgYW5kIG1heSBiZSBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgb2Yg PGJyPgpOZXVzb2Z0IENvcnBvcmF0aW9uLCBpdHMgc3Vic2lkaWFyaWVzIGFuZC9vciBpdHMgYWZm aWxpYXRlcy4gSWYgYW55IHJlYWRlciBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgPGJyPgpub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgdW5hdXRob3JpemVkIHVzZSwgZm9yd2FyZGluZywgcHJp bnRpbmcsJm5ic3A7IHN0b3JpbmcsIGRpc2Nsb3N1cmUgb3IgY29weWluZyA8YnI+CmlzIHN0cmlj dGx5IHByb2hpYml0ZWQsIGFuZCBtYXkgYmUgdW5sYXdmdWwuSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLHBsZWFzZSA8YnI+CmltbWVkaWF0ZWx5IG5vdGlm eSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1l c3NhZ2UgYW5kIGFsbCBjb3BpZXMgZnJvbSA8YnI+CnlvdXIgc3lzdGVtLiBUaGFuayB5b3UuIDxi cj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250PjwvYm9k eT4KPC9odG1sPgo= --_000_EDF530B5C272B448BB273EE368A6A34E1D22353DMPSSYMBX02neuso_-- From leo.liubing@huawei.com Fri Apr 6 03:01:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248321F858F for ; Fri, 6 Apr 2012 03:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+Q6bDo8TEQH for ; Fri, 6 Apr 2012 03:01:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C728F21F846F for ; Fri, 6 Apr 2012 03:01:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ91740; Fri, 06 Apr 2012 06:01:57 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 03:00:54 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 03:00:52 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 18:00:44 +0800 From: "Liubing (Leo)" To: Simon Perreault , "softwires@ietf.org" Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=85_4rd-U_as_tr?= =?Windows-1252?Q?ansparent_as_MAP-E?= Thread-Index: AQHNEXk8+CVpYFmEyUKz61RcLPeucpaIUpaAgAArbwCABQ72gA== Date: Fri, 6 Apr 2012 10:00:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> <997BE447-F329-4C56-AE62-DF9F310B432C@laposte.net> <1944C890-1A05-4E57-A382-8D7FC7FB747C@laposte.net> <07893A7C-9F16-469D-86A3-2A2A58EA5FF1@laposte.net> <5C98F2AD-727C-4D01-A34E-6581DAD4EF60@employees.org> <4F79E627.4080305@gmail.com> <7BBF5502-9795-4365-885B-EDDEDF359660@gmail.com> <4F7AEA04.2060106@viagenie.ca> In-Reply-To: <4F7AEA04.2060106@viagenie.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 10:01:58 -0000 +1 I've read the endless discussion, and found that is seems the MAP also has = not fully convinced the ISP operation guys. Since there's explicit controversy, why not just publish them both as exper= imental. why we must chose one as a "standard track"? Being a standard trac= k can eliminate operators' misgiving? If the technology is really appropriate, I don't think the "experimental" s= tatus would be a issue for the operators to adopt. Just let the operator de= cide by themselves.=20 I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp WG= , suggested we publish both of them as experimental, and that was exactly h= ow they handle the similar situation in their WG. I think his suggestion is= reasonable to be considered. (To Joel: Pardon me if I improperly quoted yo= ur comment, or I just misunderstood your suggestion ).=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Tuesday, April 03, 2012 8:16 PM > To: softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=85 4rd-U as transp= arent > as MAP-E >=20 > On 2012-04-03 05:40, Ole Tr=F8an wrote: > > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hu= b > and spoke mode with a separate > > mapping rule per subscriber. in this mode e.g only ports could be > embedded in the address. this is not > > possible in a translation solution like 4rd-U. >=20 > This mode of operation was suggested last week during the SD-NAT > presentation. There seemed to be consensus among operators that it was > not practically feasible. >=20 > > 2) a node inside the network will treat translated packets different fr= om > encapsulated ones. > > e.g. for the purposes of counting or for applying features. for an > encapsulated packet both the complete > > IPv4 datagram and the IPv6 header is available, and different featu= res > can be applied to both. >=20 > In practice, the contents of encapsulated packets are rarely inspected > by firewalls and other such devices. >=20 >=20 > IMHO at this point we should let the market decide. Publish both as > experimental. Let's work on something else now. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wentaoshang@gmail.com Fri Apr 6 04:16:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7221F859F for ; Fri, 6 Apr 2012 04:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9YUXyRQh8Qc for ; Fri, 6 Apr 2012 04:16:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D821621F858F for ; Fri, 6 Apr 2012 04:16:50 -0700 (PDT) Received: by werb10 with SMTP id b10so1658189wer.31 for ; Fri, 06 Apr 2012 04:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M2Jn09A5xi5PWpwUbROZnZWW8RfVcjg8RCrzHhp283I=; b=vJvTD/2qoZqcWG2wElD2/fhEMpS9itiineKfSlZ317jQxnWNSFEj8mgKV4jfpmVMDJ EM9wcP26JOCfshXCX647Oay76I5wTNMsQ1OQ6prIYkcbXFzfpWDxPJRf8x25Q7MVsaT0 PoNcWRr7JF0eBq9R7NhEdAlkxMQSu6ZrM0q+8v5mqqMvh21X+A7F/zhoon+vuXZMrB9Y 29AASE+uBcv7IuLERGC1dCGhYqN7GbdOk5EFNoUgHgdDZTxW69MZtaI9eaeTA3GboN4K 3mYKCf4T4hefllQlMcJu6aKubeRGEUyXSvlcCYajgbDR5I2xLnK49tT8VRkjm//koFur 1kyQ== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr11043106wib.20.1333711009888; Fri, 06 Apr 2012 04:16:49 -0700 (PDT) Received: by 10.180.94.105 with HTTP; Fri, 6 Apr 2012 04:16:49 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Fri, 6 Apr 2012 19:16:49 +0800 Message-ID: From: Wentao Shang To: Alain Durand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:16:52 -0000 2012/4/5 Alain Durand : > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as= a whole) =C2=A0and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should m= ake this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as = standard track. > Answering NO to this question means you want to see both advance on the s= tandard track. > ---------------------------------------------------------------------------= - Wentao SHANG, Tsinghua University, choice: YES ---------------------------------------------------------------------------= - > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > ---------------------------------------------------------------------------= --- Wentao SHANG, Tsinghua University, choice: MAP ---------------------------------------------------------------------------= --- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From dxhbupt@gmail.com Fri Apr 6 05:10:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D990821F85A3 for ; Fri, 6 Apr 2012 05:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAGR8om1rsui for ; Fri, 6 Apr 2012 05:10:13 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8808F21F85D7 for ; Fri, 6 Apr 2012 05:10:13 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so396331wib.13 for ; Fri, 06 Apr 2012 05:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pqx2eXXsfhymq65dOW/aWsIVJZH+Q7gYar642U9hFRQ=; b=s1ddr/tDElonKHuMCKXFg9rv6xj44FDpwaRGOouv92XvQRVURyEgW+U+wn5mia1yxu ssL+maJxhxlnxjbu42vTMeb9cjytdf82pFtTQGNGM/Ow/H9sgRcgWH9RtD1Y5d4/khyO R08ZQyxKz0TpoLZvtbdPWPZ12enCqecvOBrvlFxziuZhbwvoIx0QXsCL9fY7PrxvjLg5 nLadCX8atlGz/naPgu0dNoaZHR1JfxOtc3mi4Zuiq71H7Gdd84V1gaDK+i+HYb0lvHF3 dVa+FuNkkb+BWPj+Bc1UvSPw9XliLqTvWL3nlI1hS32clSXa7XNRFkic7EtoXxp8CJIS fANA== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr19378143wiy.12.1333714212794; Fri, 06 Apr 2012 05:10:12 -0700 (PDT) Received: by 10.180.99.134 with HTTP; Fri, 6 Apr 2012 05:10:12 -0700 (PDT) Date: Fri, 6 Apr 2012 20:10:12 +0800 Message-ID: From: Xiaohong Deng To: adurand@juniper.net, Softwires-wg Content-Type: multipart/alternative; boundary=f46d0443066ce2b2c004bd0189d4 Cc: int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:10:19 -0000 --f46d0443066ce2b2c004bd0189d4 Content-Type: text/plain; charset=ISO-8859-1 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Xiaohong DENG, France Telecom: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Xiaohong DENG, France Telecom: MAP ------------------------------------------------------------------------------ ===================================================================== --f46d0443066ce2b2c004bd0189d4 Content-Type: text/html; charset=ISO-8859-1 
=====================================================================
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as standard track.
Answering NO to this question means you want to see both advance on the standard track.

----------------------------------------------------------------------------
Xiaohong DENG, France Telecom: YES
----------------------------------------------------------------------------

=====================================================================

Questions 2: Which one do you want to see placed on the Standards Track:
4rd-U or MAP?

------------------------------------------------------------------------------
Xiaohong DENG, France Telecom: MAP
------------------------------------------------------------------------------

=====================================================================
--f46d0443066ce2b2c004bd0189d4-- From buptnoc@gmail.com Fri Apr 6 06:04:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9BB21F85C6 for ; Fri, 6 Apr 2012 06:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uF2TKkAsie7 for ; Fri, 6 Apr 2012 06:04:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2121F857A for ; Fri, 6 Apr 2012 06:04:55 -0700 (PDT) Received: by lagj5 with SMTP id j5so985502lag.31 for ; Fri, 06 Apr 2012 06:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f8Lk+GWaXU8z37RyQgDhEBhFQsSU0wlrwBeH2I4vsVM=; b=K96nVxqv8qSHrr2hMuA3GTafCw+PxcRTNDeLxHwx3/2bZUx2+Osb04M+hSuI/enYX3 1wAvMJS7B7Ax0Ts+Zw2H9JWLzqL9fcmXtmu2KDDmlFsPyYA2Pbmbb/bMNXbAqhDT4u/g cbFafe1IxZjPk2tnAcNCduDat7fU98r91W9QqKD+PpBsungI14gJv+mfvevnAucjNQ1l gCmPmOYlU9S0ttMWbI9GBibX25qQPU+3xcQK9cCJxkU3Q5T1OPT4xbXPy02Ao79QewGi dECT4bu9v9tgtVLyHlOgaZnn8gRQA03+WeYpJfrFkwzKWz5hqb6XtywXWi5/i4nGu+lW DG1g== MIME-Version: 1.0 Received: by 10.152.113.229 with SMTP id jb5mr8471531lab.45.1333717494764; Fri, 06 Apr 2012 06:04:54 -0700 (PDT) Received: by 10.112.81.33 with HTTP; Fri, 6 Apr 2012 06:04:54 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Fri, 6 Apr 2012 21:04:54 +0800 Message-ID: From: =?GB2312?B?1dTH1Q==?= To: Alain Durand Content-Type: multipart/alternative; boundary=f46d04088d8b81963b04bd024d26 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:04:57 -0000 --f46d04088d8b81963b04bd024d26 Content-Type: text/plain; charset=ISO-8859-1 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Zhao Qin, BUPT: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Zhao Qin, BUPT: MAP ------------------------------------------------------------------------------ 2012/4/5 Alain Durand > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d04088d8b81963b04bd024d26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Question 1: Do you agree that the wg should put EITHER 4rd-U = OR MAP (as a whole) on the standard track, the other being published as exp= erimental or informational.
Answering YES to this question means you agree we cannot publish both = as standard track.
Answering NO to this question means you want t= o see both advance on the standard track.

--------= --------------------------------------------------------------------
Zhao Qin, BUPT: YES
----------------------------------------= ------------------------------------


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the= Standards Track:
4rd-U or MAP?

--------= ----------------------------------------------------------------------
Zhao Qin, BUPT: MAP
----------------------------------------= --------------------------------------

= 2012/4/5 Alain Durand <adurand@juniper.net>
Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) =A0and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should mak= e this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

---------------------------------------------------------------------------= -
Your full name, your affiliation, your choice: YES or NO
---------------------------------------------------------------------------= -


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

---------------------------------------------------------------------------= ---
Your full name, your affiliation, your choice: 4rd-U or MAP
---------------------------------------------------------------------------= ---

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d04088d8b81963b04bd024d26-- From Francis.Dupont@fdupont.fr Fri Apr 6 06:26:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467E021F8566 for ; Fri, 6 Apr 2012 06:26:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItqYh1HlIZ67 for ; Fri, 6 Apr 2012 06:26:47 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 7688E21F8559 for ; Fri, 6 Apr 2012 06:26:47 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q36DQiYo011177; Fri, 6 Apr 2012 15:26:44 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204061326.q36DQiYo011177@givry.fdupont.fr> From: Francis Dupont To: Alain Durand In-reply-to: Your message of Wed, 04 Apr 2012 14:14:08 PDT. <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Fri, 06 Apr 2012 15:26:44 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:26:48 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Francis Dupont, representing myself, YES ---------------------------------------------------------------------------- From yiu_lee@cable.comcast.com Fri Apr 6 07:48:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC5121F854F for ; Fri, 6 Apr 2012 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.597 X-Spam-Level: X-Spam-Status: No, score=-100.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QJoMZ1MsA-L for ; Fri, 6 Apr 2012 07:48:44 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3221F8501 for ; Fri, 6 Apr 2012 07:48:43 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.8424642; Fri, 06 Apr 2012 10:42:06 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 10:48:51 -0400 From: "Lee, Yiu" To: "Liubing (Leo)" , Simon Perreault , "softwires@ietf.org" Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=8A_4rd-U_as_tr?= =?Windows-1252?Q?ansparent_as_MAP-E?= Thread-Index: AQHNFARX+ApOlDFhYUaOfAXVly1N0Q== Date: Fri, 6 Apr 2012 14:48:33 +0000 Message-ID: In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416554112_321522" MIME-Version: 1.0 Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:48:44 -0000 --B_3416554112_321522 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I also followed the discussion. I appreciate both teams bought up the technical details for both designs. To be honest, I fail to see which one is better than other (yet). I like the fact that 4rd-u can do what MAP-T does w/o introducing any encap overhead. But I understand the concerns others brought up in the ML such as V-octet. For MAP-T, I like it not introducing any new requirement to the IPv6 header, but I need more published data to determine whether the double-translation would cause any transparent issue or not. For example: I would very appreciate if somebody who trial MAP can publish data such as what applications they have tested, what pass and what fail. This piece of work is very important because once we select it, this technology will stay for long time. I do not want to rush to make a decision and come back to regret in future. On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: >+1 > >I've read the endless discussion, and found that is seems the MAP also >has not fully convinced the ISP operation guys. >Since there's explicit controversy, why not just publish them both as >experimental. why we must chose one as a "standard track"? Being a >standard track can eliminate operators' misgiving? > >If the technology is really appropriate, I don't think the "experimental" >status would be a issue for the operators to adopt. Just let the operator >decide by themselves. > >I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp >WG, suggested we publish both of them as experimental, and that was >exactly how they handle the similar situation in their WG. I think his >suggestion is reasonable to be considered. (To Joel: Pardon me if I >improperly quoted your comment, or I just misunderstood your suggestion >).=20 > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Simon Perreault >> Sent: Tuesday, April 03, 2012 8:16 PM >> To: softwires@ietf.org >> Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as >>transparent >> as MAP-E >>=20 >> On 2012-04-03 05:40, Ole Tr=F8an wrote: >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using >>hub >> and spoke mode with a separate >> > mapping rule per subscriber. in this mode e.g only ports could be >> embedded in the address. this is not >> > possible in a translation solution like 4rd-U. >>=20 >> This mode of operation was suggested last week during the SD-NAT >> presentation. There seemed to be consensus among operators that it was >> not practically feasible. >>=20 >> > 2) a node inside the network will treat translated packets different >>from >> encapsulated ones. >> > e.g. for the purposes of counting or for applying features. for an >> encapsulated packet both the complete >> > IPv4 datagram and the IPv6 header is available, and different >>features >> can be applied to both. >>=20 >> In practice, the contents of encapsulated packets are rarely inspected >> by firewalls and other such devices. >>=20 >>=20 >> IMHO at this point we should let the market decide. Publish both as >> experimental. Let's work on something else now. >>=20 >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3416554112_321522 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTA6vNn VjOOSsoYm3F9+nyJmFPtnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDYxNDQ4MzBaMA0GCSqGSIb3DQEBAQUABIIBALaivyHgdXrS9dQL2fcoXa97 y2eOmS5zPl7PqgPjbPCXdM4xr4Mkx+6sjF7HU6c1zlje94sdoWFtn1IgNitnIQdioo2XPnCd x26dtCefvRE3Wm27EFx23T+VUnTh4b7Z9exwpNdPEgbgtvA09SW9uAConXGHEUPytd3GS04t 72wgdctB4i3a64KJ0zch1ET+DVnNCuQRNaZqSX2pdk98hZAD5tUp+eQX1CyUj9pXsAao2/Id F1ry+mGiYYTMtWDUCkPCc3chUzdkc4CjyT+ACGhD8KCaNXnN406fgRbampsc8iUzsXeToe3R 0Tk36B/B+bvG8BenBy7+Oewn58u8YGE= --B_3416554112_321522-- From brian@innovationslab.net Fri Apr 6 07:35:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4699B21F8552 for ; Fri, 6 Apr 2012 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QADZKBFs+AH1 for ; Fri, 6 Apr 2012 07:35:29 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A998821F8550 for ; Fri, 6 Apr 2012 07:35:29 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 259FA880A7; Fri, 6 Apr 2012 07:35:29 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3E74F140035; Fri, 6 Apr 2012 07:35:27 -0700 (PDT) Message-ID: <4F7EFF2E.7000701@innovationslab.net> Date: Fri, 06 Apr 2012 10:35:26 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 06 Apr 2012 07:53:06 -0700 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:35:30 -0000 On 4/6/12 3:42 AM, Rémi Després wrote: > Hi, Brian, > > First, welcome as new Internet-area AD. Also, thanks for the > reference and the quote. Thanks. > > Note however that, in this particular instance, this quote will not > be of any help because it concerns "issues which have not been > discussed on the mailing list". > > On the contrary, RFC 2418 says: "There are two different cases where > a working group may be trying to understand the level of consensus > via a mailing list ... - In the case where a consensus which HAS BEEN > REACHED during a face-to-face meeting is being verified on a mailing > list ... - The other case is where the discussion has been held > ENTIRELY over the mailing list" (upper cases added). > > Facts are that: - No consensus has been reached during the > face-to-face meeting. - There has been extensive discussion on the > mailing list. - The only action that has been announced in absence of > consensus was publication of all specifications as experimental. Would you agree that the outcome of the WG session in Paris is that there was not a clear consensus to choose either one of the options? I have not seen anyone dispute that there was not a clear consensus to choose one option over the other. Hence, everyone agrees there was not a consensus in the face-to-face meeting. In that situation, does it make sense to ask a broader audience (the entire mailing list) the same set of questions? > > There is therefore no justification I know to further delay > publication of ALL specifications as WG drafts, on experimental > track. - As I already said to the chairs, I am ready to do it as soon > as authorized. - I understand that MAP-E+T drafts will also be > treated the same, and that's obviously fair. > > As already said too said, if procedures continue to be distorted, I > will have no other choice than referring to RFC 2026 section 6.5.1, > and signal, on behalf of co-authors of the 4rd-U proposal, "a > difficulty with Working Group process", with an "appeal to the IESG > as a whole". That is your prerogative. Regards, Brian From despres.remi@laposte.net Fri Apr 6 08:04:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322421F8568 for ; Fri, 6 Apr 2012 08:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS7umYXm0P+b for ; Fri, 6 Apr 2012 08:04:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5421F84CE for ; Fri, 6 Apr 2012 08:04:47 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id uf4k1i00837Y3f403f4kSm; Fri, 06 Apr 2012 17:04:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F7EFF2E.7000701@innovationslab.net> Date: Fri, 6 Apr 2012 17:04:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> <4F7EFF2E.7000701@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:04:50 -0000 Le 2012-04-06 =E0 16:35, Brian Haberman a =E9crit : > On 4/6/12 3:42 AM, R=E9mi Despr=E9s wrote: >> Hi, Brian, >>=20 >> First, welcome as new Internet-area AD. Also, thanks for the >> reference and the quote. >=20 > Thanks. >=20 >>=20 >> Note however that, in this particular instance, this quote will not >> be of any help because it concerns "issues which have not been >> discussed on the mailing list". >>=20 >> On the contrary, RFC 2418 says: (*) >> "There are two different cases where >> a working group may be trying to understand the level of consensus >> via a mailing list ... - In the case where a consensus which HAS BEEN >> REACHED during a face-to-face meeting is being verified on a mailing >> list ... - The other case is where the discussion has been held >> ENTIRELY over the mailing list" (upper cases added). >>=20 >> Facts are that: - No consensus has been reached during the >> face-to-face meeting. - There has been extensive discussion on the >> mailing list. - The only action that has been announced in absence of >> consensus was publication of all specifications as experimental. >=20 > Would you agree that the outcome of the WG session in Paris is that = there was not a clear consensus to choose either one of the options? Yes. > I have not seen anyone dispute that there was not a clear consensus = to choose one option over the other. I haven't either. > Hence, everyone agrees there was not a consensus in the face-to-face = meeting. In that situation, does it make sense to ask a broader audience = (the entire mailing list) the same set of questions? Sorry to answer it is inappropriate: - The case isn't,in RFC2418, one of the two, "where a working group may = be trying to understand the level of consensus via a mailing list" (see = (*) above) - To make it worse, the chair, during the meeting itself, already tried = to change the result by asking a second time, after some had already = left, the same question about a preference between MAP and 4rd. The same = ratio between the two answers happens to have been obtained, but who = knows what would have been concluded otherwise? - Publishing all drafts on experimental track had been previously = announced as the (logical) result in case no single solution for = standard track would be agreed on.=20 =20 >> There is therefore no justification I know to further delay >> publication of ALL specifications as WG drafts, on experimental >> track. - As I already said to the chairs, I am ready to do it as soon >> as authorized. - I understand that MAP-E+T drafts will also be >> treated the same, and that's obviously fair. >>=20 >> As already said too said, if procedures continue to be distorted, I >> will have no other choice than referring to RFC 2026 section 6.5.1, >> and signal, on behalf of co-authors of the 4rd-U proposal, "a >> difficulty with Working Group process", with an "appeal to the IESG >> as a whole". >=20 > That is your prerogative. Yes, but, please be sure that we have a clear preference for not having = to use it. Trying by all means, including with a self-authorized procedure, to = prevent market-based decision should be avoided.=20 Thanks, RD >=20 > Regards, > Brian >=20 From rdroms@cisco.com Fri Apr 6 08:35:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFCE21F8592 for ; Fri, 6 Apr 2012 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOMyt-mEx74Y for ; Fri, 6 Apr 2012 08:35:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB5821F84B4 for ; Fri, 6 Apr 2012 08:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=4845; q=dns/txt; s=iport; t=1333726545; x=1334936145; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EInEipFWhG3hUywFKmpuAQkB+sTfP2YAHS8MkCapm8U=; b=F3aqyX4F2ImWTNNzLC9FN64YnRragyKbg0icUhqLJ6g1fMQBuQUaM0dB 1hN2hVQMOBtzoYNWYdBLskZ8RbBHHfGMD8egrMfwDIdqhCDZnrMfO8JD8 mCKiSVQDEJrMieTBLmfiwEcaPxKG299Vi6UEP2Jq0n3knEDaAzFQptu6p o=; X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="72657205" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 06 Apr 2012 15:35:44 +0000 Received: from [10.86.244.110] ([10.86.244.110]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q36FZhom006890; Fri, 6 Apr 2012 15:35:43 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> Date: Fri, 6 Apr 2012 11:36:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96ED37F2-80B3-415D-BD2E-0765A600FFE9@cisco.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> <4F7EFF2E.7000701@innovationslab.net> <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:35:46 -0000 On Apr 6, 2012, at 11:04 AM 4/6/12, R=E9mi Despr=E9s wrote: >=20 > Le 2012-04-06 =E0 16:35, Brian Haberman a =E9crit : >=20 >> On 4/6/12 3:42 AM, R=E9mi Despr=E9s wrote: >>> Hi, Brian, >>>=20 >>> First, welcome as new Internet-area AD. Also, thanks for the >>> reference and the quote. >>=20 >> Thanks. >>=20 >>>=20 >>> Note however that, in this particular instance, this quote will not >>> be of any help because it concerns "issues which have not been >>> discussed on the mailing list". >>>=20 >>> On the contrary, RFC 2418 says: >=20 > (*) >>> "There are two different cases where >>> a working group may be trying to understand the level of consensus >>> via a mailing list ... - In the case where a consensus which HAS = BEEN >>> REACHED during a face-to-face meeting is being verified on a mailing >>> list ... - The other case is where the discussion has been held >>> ENTIRELY over the mailing list" (upper cases added). >>>=20 >>> Facts are that: - No consensus has been reached during the >>> face-to-face meeting. - There has been extensive discussion on the >>> mailing list. - The only action that has been announced in absence = of >>> consensus was publication of all specifications as experimental. >>=20 >> Would you agree that the outcome of the WG session in Paris is that = there was not a clear consensus to choose either one of the options? >=20 > Yes. >> I have not seen anyone dispute that there was not a clear consensus = to choose one option over the other. >=20 > I haven't either. >=20 >> Hence, everyone agrees there was not a consensus in the face-to-face = meeting. In that situation, does it make sense to ask a broader audience = (the entire mailing list) the same set of questions? >=20 > Sorry to answer it is inappropriate: > - The case isn't,in RFC2418, one of the two, "where a working group = may be trying to understand the level of consensus via a mailing list" = (see (*) above) We may have to agree to disagree here. It is always the IETF practice = to hold the binding consensus call on the mailing list. That consensus = call is being conducted now. Any determination of WG consensus is = premature until the results of the consensus call are complete. > - To make it worse, the chair, during the meeting itself, already = tried to change the result > by asking a second time, after some had already left, the same = question about a preference between MAP and 4rd. This statement is wrong and makes an inappropriate implication about the = chairs' motives. The chairs asked for a second assessment of consensus = after asking those in the room to reconsider their position to see if = some consensus could be reached. > The same ratio between the two answers happens to have been obtained, = but who knows what would have been concluded otherwise? > - Publishing all drafts on experimental track had been previously = announced as the (logical) result in case no single solution for = standard track would be agreed on. I will repeat myself: until the consensus call on the WG mailing list is = complete, there is no determination of consensus or lack of consensus. = The correct action is to wait until the mailing list consensus is = assessed before making a determination about how to publish the various = documents. >>> There is therefore no justification I know to further delay >>> publication of ALL specifications as WG drafts, on experimental >>> track. - As I already said to the chairs, I am ready to do it as = soon >>> as authorized. - I understand that MAP-E+T drafts will also be >>> treated the same, and that's obviously fair. >>>=20 >>> As already said too said, if procedures continue to be distorted, I >>> will have no other choice than referring to RFC 2026 section 6.5.1, >>> and signal, on behalf of co-authors of the 4rd-U proposal, "a >>> difficulty with Working Group process", with an "appeal to the IESG >>> as a whole". >>=20 >> That is your prerogative. >=20 > Yes, but, please be sure that we have a clear preference for not = having to use it. > Trying by all means, including with a self-authorized procedure, to = prevent market-based decision should be avoided.=20 I object here as well to your implication that there is an effort "to = prevent market-based decision". The chairs are working hard to do their = due diligence in assessing and determining WG consensus about how to = proceed. You have one point of view, but that point of view does not = constitute WG consensus. - Ralph >=20 > Thanks, > RD >=20 >=20 >=20 >=20 >>=20 >> Regards, >> Brian >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rdroms@cisco.com Fri Apr 6 08:49:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B8621F85D7 for ; Fri, 6 Apr 2012 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+AVxiQXephU for ; Fri, 6 Apr 2012 08:49:40 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F363321F85D2 for ; Fri, 6 Apr 2012 08:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=426; q=dns/txt; s=iport; t=1333727379; x=1334936979; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=A2/1v3b9nos2Gi9qX6Zy4vm8Vyci8YxhYrv1klw+c0g=; b=ALK7f5zmd0sg/TkAc9TNnIxhIPKD9pUe49kTA/rkOFoIrVBIUhQm5oRw jvHQRn7FyzxetlVEMUhfGxlXbI3rrcHFeCYnrIyfntsIDg8MCBVQZ8Sle 2iw+QIgEtd14Mu9EPp7Rjq1ozQ9VWkCEI3cyzM8JBjE7EL4rrLy2JSSuz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAMUPf0+rRDoJ/2dsb2JhbABDgy21foEHgiIBJzSBSQE0h2uedZgRiyKES2MElWyFcohbgWmDA4FA X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="36271205" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 06 Apr 2012 15:49:39 +0000 Received: from [10.86.244.110] ([10.86.244.110]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q36FncuR002317; Fri, 6 Apr 2012 15:49:39 GMT From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 11:50:00 -0400 Message-Id: To: Softwires WG , int-ads@tools.ietf.org, Halpern Joel Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Softwires] Remi Despres and mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:49:40 -0000 I just followed up on my e-mail to the WG mailing list as a whole with = private e-mail to Remi to reassure him that Alain and Yong are = conducting a good process. I also told him that it is inappropriate to = imply that the chairs are trying to change WG decisions, delay = publication, or otherwise suggest that the chairs have motives, agendas = or other reasons behind their guidance of the WG process. - Ralph From despres.remi@laposte.net Fri Apr 6 09:34:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCCF21F85B8 for ; Fri, 6 Apr 2012 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucwrdjly+Jrm for ; Fri, 6 Apr 2012 09:34:46 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAF021F8568 for ; Fri, 6 Apr 2012 09:34:45 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id ugai1i00937Y3f403gaiWB; Fri, 06 Apr 2012 18:34:44 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <96ED37F2-80B3-415D-BD2E-0765A600FFE9@cisco.com> Date: Fri, 6 Apr 2012 18:34:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56A2FD3A-C68C-4362-B4E8-2D6BBA854681@laposte.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> <4F7EFF2E.7000701@innovationslab.net> <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> <96ED37F2-80B3-415D-BD2E-0765A600FFE9@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Brian Haberman , Yong Cui Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 16:34:47 -0000 Le 2012-04-06 =E0 17:36, Ralph Droms a =E9crit : >=20 > On Apr 6, 2012, at 11:04 AM 4/6/12, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-04-06 =E0 16:35, Brian Haberman a =E9crit : >>=20 >>> On 4/6/12 3:42 AM, R=E9mi Despr=E9s wrote: >>>> Hi, Brian, >>>>=20 >>>> First, welcome as new Internet-area AD. Also, thanks for the >>>> reference and the quote. >>>=20 >>> Thanks. >>>=20 >>>>=20 >>>> Note however that, in this particular instance, this quote will not >>>> be of any help because it concerns "issues which have not been >>>> discussed on the mailing list". >>>>=20 >>>> On the contrary, RFC 2418 says: >>=20 >> (*) >>>> "There are two different cases where >>>> a working group may be trying to understand the level of consensus >>>> via a mailing list ... - In the case where a consensus which HAS = BEEN >>>> REACHED during a face-to-face meeting is being verified on a = mailing >>>> list ... - The other case is where the discussion has been held >>>> ENTIRELY over the mailing list" (upper cases added). >>>>=20 >>>> Facts are that: - No consensus has been reached during the >>>> face-to-face meeting. - There has been extensive discussion on the >>>> mailing list. - The only action that has been announced in absence = of >>>> consensus was publication of all specifications as experimental. >>>=20 >>> Would you agree that the outcome of the WG session in Paris is that = there was not a clear consensus to choose either one of the options? >>=20 >> Yes. >>> I have not seen anyone dispute that there was not a clear consensus = to choose one option over the other. >>=20 >> I haven't either. >>=20 >>> Hence, everyone agrees there was not a consensus in the face-to-face = meeting. In that situation, does it make sense to ask a broader audience = (the entire mailing list) the same set of questions? >>=20 >> Sorry to answer it is inappropriate: >> - The case isn't,in RFC2418, one of the two, "where a working group = may be trying to understand the level of consensus via a mailing list" = (see (*) above) >=20 > We may have to agree to disagree here. =20 > It is always the IETF practice to hold the binding consensus call on = the mailing list. =20 Yes, this is the first case mentioned in RFC 2418 and copied above: = "case where a consensus HAS BEEN REACHED". But lack of consensus isn't a REACHED consensus. =20 > That consensus call is being conducted now. Any determination of WG = consensus is premature until the results of the consensus call are = complete. >=20 >> - To make it worse, the chair, during the meeting itself, already = tried to change the result >> by asking a second time, after some had already left, the same = question about a preference between MAP and 4rd. >=20 >=20 > This statement is wrong and makes an inappropriate implication about = the chairs' motives. The chairs asked for a second assessment of = consensus after asking those in the room to reconsider their position to = see if some consensus could be reached. Yet there were less people in the room, which makes it special. >> The same ratio between the two answers happens to have been obtained, = but who knows what would have been concluded otherwise? >> - Publishing all drafts on experimental track had been previously = announced as the (logical) result in case no single solution for = standard track would be agreed on. >=20 > I will repeat myself: until the consensus call on the WG mailing list = is complete, there is no determination of consensus or lack of = consensus. May I repeat myself too: that lack of consensus isn't a reached = consensus that, according to the rules, needs to be verified. > The correct action is to wait until the mailing list consensus is = assessed before making a determination about how to publish the various = documents. >=20 >>>> There is therefore no justification I know to further delay >>>> publication of ALL specifications as WG drafts, on experimental >>>> track. - As I already said to the chairs, I am ready to do it as = soon >>>> as authorized. - I understand that MAP-E+T drafts will also be >>>> treated the same, and that's obviously fair. >>>>=20 >>>> As already said too said, if procedures continue to be distorted, = I >>>> will have no other choice than referring to RFC 2026 section 6.5.1, >>>> and signal, on behalf of co-authors of the 4rd-U proposal, "a >>>> difficulty with Working Group process", with an "appeal to the IESG >>>> as a whole". >>>=20 >>> That is your prerogative. >>=20 >> Yes, but, please be sure that we have a clear preference for not = having to use it. >> Trying by all means, including with a self-authorized procedure, to = prevent market-based decision should be avoided.=20 >=20 > I object here as well to your implication that there is an effort "to = prevent market-based decision". Suspicion is at least justified, by the chair being listed as member of = the MAP team (Ole's slide). > The chairs are working hard to do their due diligence in assessing = and determining WG consensus about how to proceed. =20 > You have one point of view, but that point of view does not constitute = WG consensus. Well aware of that. Yet, both MAP-T+E and 4rd-U on experimental track is the less = criticizable approach at this point, and permits "market-based = decision". RD >=20 > - Ralph >=20 >>=20 >> Thanks, >> RD >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>> Brian >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From rdroms.ietf@gmail.com Fri Apr 6 09:57:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB84121F858D for ; Fri, 6 Apr 2012 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w59WDD06Zqq for ; Fri, 6 Apr 2012 09:57:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7196421F8565 for ; Fri, 6 Apr 2012 09:57:47 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1779047qcs.31 for ; Fri, 06 Apr 2012 09:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=12sLT3Fwd9GwhrRY2EOlrxOBhosryxvn5+mCV8HxZus=; b=lfK0xO1118H1WJouS5Ud1WbR1p+FXwzM1XN0A3+LZ7VTA1n+xkWOKpBwIUnBCq10Hc A4p1Ae72Wyqs2Rsd3rQ6kIuYyjSfOUOtEC46Upki4OUxro6cyGpEGt+3XRbYL0LnMXhn FLA4bnTrDMkWM0AuwAd+q4DI5E8uEDp1rEPOX1i9/3ze4b3W/3kUTER0SmAleN6H3p/+ pPxY/DCFmSfJtg0LeO6tEXUCkdGx5xkteYbgkEhFMA1abZkckf+Pu81mOoGJJq7pT755 UbahpPPLsdEuWLDeVi9EiCUfKI/0172Vt46EHdzWbCUy/oAwEWDygDvlQ/L0H6TmzVZa LPeg== Received: by 10.224.42.16 with SMTP id q16mr10130050qae.70.1333731467005; Fri, 06 Apr 2012 09:57:47 -0700 (PDT) Received: from [10.27.20.6] (mobile-198-228-193-235.mycingular.net. [198.228.193.235]) by mx.google.com with ESMTPS id gg5sm6663313qab.7.2012.04.06.09.57.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 09:57:46 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <40A679FF-56ED-4E64-9DD9-BB355AB925BD@gmail.com> X-Mailer: iPhone Mail (9B176) From: Ralph Droms Date: Fri, 6 Apr 2012 12:57:39 -0400 To: Ralph Droms Cc: Softwires WG , "int-ads@tools.ietf.org" Subject: Re: [Softwires] Remi Despres and mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 16:57:48 -0000 I just mistakenly sent e-mail intended for the softwire WG chairs. However,= the content turns out to be appropriate for the mailing list as a whole: * the chairs are running a good process * there will be differing opinions about technical issues * implying any motives or agendas behind the chairs' actions is inappropriat= e and unhelpful - Ralph From jan@go6.si Fri Apr 6 12:01:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1C21F84D8 for ; Fri, 6 Apr 2012 12:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKD7iwsyeViY for ; Fri, 6 Apr 2012 12:01:10 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34121F84EE for ; Fri, 6 Apr 2012 12:01:10 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id C0B6B22BC002; Fri, 6 Apr 2012 21:01:05 +0200 (CEST) Message-ID: <4F7F3D72.3070904@go6.si> Date: Fri, 06 Apr 2012 21:01:06 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> <4F7EFF2E.7000701@innovationslab.net> <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> <96ED37F2-80B3-415D-BD2E-0765A600FFE9@cisco.com> <56A2FD3A-C68C-4362-B4E8-2D6BBA854681@laposte.net> In-Reply-To: <56A2FD3A-C68C-4362-B4E8-2D6BBA854681@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires WG , Brian Haberman , Yong Cui , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:01:11 -0000 On 4/6/12 6:34 PM, Rémi Després wrote: > Yet, both MAP-T+E and 4rd-U on experimental track is the less > criticizable approach at this point, and permits "market-based > decision". Hi, Strongly disagree. In this case stateless A+P (E,T or U) gets abandoned by vendors and CGN wins. Ask the vendors and please stop presuming. Huawey is the only one who stated until now that they are willing to experiment with 4rd-U. Others are waiting for decision and standard, regardless if their employees are co-authors of E,T or U. Repeating myself: A+P "standardization" process lasted for 2,5 years and was unnecessary (politically) pushed away and blocked for at least 1 year. Then, when stateless flavors of A+P started to emerge additional delay was introduced with request to write motivation document. Ok, was not happy, but was not complaining too publicly and too loud. Now, when we have an option to make a decision and we have mature and proven with running code solutions, effort is dropped and/or watered down with experimental track, so vendors are equally confused what to do. Come on... we need to lower the noise level and make a decision. Cheers, Jan From satoru.matsushima@gmail.com Fri Apr 6 19:19:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345F021F8569 for ; Fri, 6 Apr 2012 19:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=1.957, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N91SX-PBBi19 for ; Fri, 6 Apr 2012 19:19:24 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04021F8568 for ; Fri, 6 Apr 2012 19:19:24 -0700 (PDT) Received: by dady13 with SMTP id y13so4552330dad.27 for ; Fri, 06 Apr 2012 19:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/fOVQa9TRKeDNpM4Fiu7BwPQq8UQ1nAJmM5BkpAJd98=; b=bxc0u8PaJB6GDCq8x/CkPoGWviJ/hDCKbUbyW2zMiW4JnyvB1w58F4S0oK7z2eXxmv jRAm7ximIyaHosft1iVVbixym5VP0gvF4yMCpP07OcHkS5BHPztu5ZQ1rEFUsOrz4+IK 6wXYQXZFEvvQispjVTcAhbGBhWl18kJQzcm1zzppQQFRMDLo/2qFqJeY0tGSZ/azlv6X QzBG02HxDYNUdnf7Rimus3f6UyLBY8Shywj6bOiG9at8FhHSYKcATUB5MVeVeap/jHYe iHmynwlnb66ZngvQaoB5YyzDytuVTNV6Pn1utfH2ofVupXR9hvvqvc5qKUSjzhJAAsd3 Jbeg== Received: by 10.68.218.72 with SMTP id pe8mr230813pbc.45.1333765163926; Fri, 06 Apr 2012 19:19:23 -0700 (PDT) Received: from [192.168.3.11] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id o9sm7835891pbe.60.2012.04.06.19.19.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 19:19:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <4F7F3D72.3070904@go6.si> Date: Sat, 7 Apr 2012 11:19:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0AEB0A82-B304-466D-800A-3FF110586031@gmail.com> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> <93C782BC-F41F-4E0E-9039-DAA98CF7F446@cisco.com> <63113747-F9C5-436A-AF08-782B00F0CBAF@laposte.net> <6F905639-538E-4652-8A9B-14B92B980E79@juniper.net> <4F7DE7D4.6000703@innovationslab.net> <4F7EFF2E.7000701@innovationslab.net> <49177E75-DF01-4799-A9D0-6651E10A371F@laposte.net> <96ED37F2-80B3-415D-BD2E-0765A600FFE9@cisco.com> <56A2FD3A-C68C-4362-B4E8-2D6BBA854681@laposte.net> <4F7F3D72.3070904@go6.si> To: "Jan Zorz @ go6.si" , Softwires WG X-Mailer: Apple Mail (2.1257) Cc: Yong Cui , Brian Haberman , Ralph Droms Subject: Re: [Softwires] Publish MAP and 4rd-U on experimental track X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 02:19:25 -0000 On 2012/04/07, at 4:01, Jan Zorz @ go6.si wrote: > On 4/6/12 6:34 PM, R=E9mi Despr=E9s wrote: >> Yet, both MAP-T+E and 4rd-U on experimental track is the less >> criticizable approach at this point, and permits "market-based >> decision". >=20 > Hi, >=20 > Strongly disagree. In this case stateless A+P (E,T or U) gets = abandoned by vendors and CGN wins. Ask the vendors and please stop = presuming. >=20 > Huawey is the only one who stated until now that they are willing to = experiment with 4rd-U. Others are waiting for decision and standard, = regardless if their employees are co-authors of E,T or U. >=20 > Repeating myself: A+P "standardization" process lasted for 2,5 years = and was unnecessary (politically) pushed away and blocked for at least 1 = year. Then, when stateless flavors of A+P started to emerge additional = delay was introduced with request to write motivation document. Ok, was = not happy, but was not complaining too publicly and too loud. Now, when = we have an option to make a decision and we have mature and proven with = running code solutions, effort is dropped and/or watered down with = experimental track, so vendors are equally confused what to do. >=20 > Come on... we need to lower the noise level and make a decision. >=20 > Cheers, Jan +1 shara, aplusp, now we're at stateless. this is final. --satoru= From lipf@cernet.edu.cn Fri Apr 6 22:35:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8821F8510 for ; Fri, 6 Apr 2012 22:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUMRFvcWvUBN for ; Fri, 6 Apr 2012 22:35:05 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id B2FF921F850F for ; Fri, 6 Apr 2012 22:35:04 -0700 (PDT) Received: from lipfmatoMacBook-Air.local (unknown [112.115.106.163]) by centos (Coremail) with SMTP id AQAAf3CbhgUV0X9P2YsBAA--.6197S2; Sat, 07 Apr 2012 13:31:34 +0800 (CST) Message-ID: <4F7FD1DD.3030207@cernet.edu.cn> Date: Sat, 07 Apr 2012 13:34:21 +0800 From: Li pengfei User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Alain Durand References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CbhgUV0X9P2YsBAA--.6197S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw1Dur45KrWUtr1fZF1kXwb_yoW8Ww4Dpr nxJryxGr1UJryUJw1UJr1UJr1UAr1UJr1UJr1rJr18AryUAr1UJr1UJr1rJryUGry5Ar1U Jr1UGr1UJr1UArUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUsIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC2z280aV AFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x0 82IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1lOx 8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK 82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWw C2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE42xK8VAvwI8IcIk0rVWr Zr1j6s0DYxBIdaVFxhVjvjDU0xZFpf9x07jUGYLUUUUU= X-CM-SenderInfo: holswqxfhu0vvwohv3gofq/ Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 05:35:06 -0000 于 12-4-5 上午5:14, Alain Durand 写道: > Dear Softwire wg members: > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- Li Pengfei, CERNET NOC, YES > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ Li Pengfei, CERNET NOC, MAP > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain& Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- Li Pengfei CERNET NOC lipf@cernet.edu.cn 010-62784048 From james@ustc.edu.cn Fri Apr 6 23:48:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5729F21F8504 for ; Fri, 6 Apr 2012 23:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smQk6YrqsWT9 for ; Fri, 6 Apr 2012 23:48:25 -0700 (PDT) Received: from ustc.edu.cn (unknown [IPv6:2001:da8:d800:f001:215:17ff:fea0:97b8]) by ietfa.amsl.com (Postfix) with SMTP id 1DBF821F84EA for ; Fri, 6 Apr 2012 23:48:23 -0700 (PDT) Received: from james ( [202.38.64.143] ) by ajax-webmail-mailweb (Coremail) ; Sat, 7 Apr 2012 14:48:18 +0800 (CST) Date: Sat, 7 Apr 2012 14:48:18 +0800 (CST) From: "Zhang Huanjie" To: "Alain Durand" Message-ID: <19756100.105001333781298233.JavaMail.coremail@mailweb> In-Reply-To: <4F7FD1DD.3030207@cernet.edu.cn> References: <4F7FD1DD.3030207@cernet.edu.cn> <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [202.38.64.143] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT_U3b build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn ustccn X-CM-TRANSID: yia_0ZCbjQUy439PgI1bAA--.6067W X-CM-SenderInfo: 5mdpv2w6xv3uoohg3hdfq/1tbiAQQRB0qSNgNDgwABs- X-Coremail-Antispam: 1U50xBIdaVrnn0S07vEb7Iv0xC_Cr1lV2xY67kC6x804xJvcS sGvfC2KfnxnUU== Cc: WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 06:48:26 -0000 12-4-5 5:14, Alain Durand Wrote: > Dear Softwire wg members: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as = standard track. > Answering NO to this question means you want to see both advance on the s= tandard track. ---------------------------------------------------------------------------= - Zhang Huanjie, University of Science and Technology of China NOC, YES ---------------------------------------------------------------------------= - > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? ---------------------------------------------------------------------------= --- Zhang Huanjie, University of Science and Technology of China NOC, MAP ---------------------------------------------------------------------------= --- -- Zhang Huanjie=C2=A0 E-mail/msn: james@ustc.edu.cn=C2=A0=C2=A0=C2=A0 USTC NOC Mobile: +86-13505693311=C2=A0=C2=A0 Tel: +86-551-3601897 From huangyj@me.com Sat Apr 7 01:23:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC021F84FE for ; Sat, 7 Apr 2012 01:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeSkvvWDfCET for ; Sat, 7 Apr 2012 01:23:24 -0700 (PDT) Received: from nk11p00mm-asmtp007.mac.com (nk11p00mm-asmtp007.mac.com [17.158.161.6]) by ietfa.amsl.com (Postfix) with ESMTP id A6EFC21F84F5 for ; Sat, 7 Apr 2012 01:23:15 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fzdlBvfryb2VWrXfFLXtkA)" Received: from nk11p00mm-spool003.mac.com ([17.158.161.71]) by nk11p00mm-asmtp007.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M230020LOMQB200@nk11p00mm-asmtp007.mac.com> for softwires@ietf.org; Sat, 07 Apr 2012 08:23:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-07_01:2012-04-05, 2012-04-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1204070019 Received: from localhost ([17.158.232.222]) by nk11p00mm-spool003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M23000XTOMQTD50@nk11p00mm-spool003.mac.com> for softwires@ietf.org; Sat, 07 Apr 2012 08:23:14 +0000 (GMT) To: softwires@ietf.org From: =?utf-8?B?5Y+L5L+KIOm7hA==?= Date: Sat, 07 Apr 2012 08:23:05 +0000 (GMT) X-Mailer: MobileMe Mail (1I09.7849) X-Originating-IP: [123.112.74.216] Message-id: Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 08:23:25 -0000 --Boundary_(ID_fzdlBvfryb2VWrXfFLXtkA) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a = whole) on the standard track, the other being published as experimental or= informational. Answering YES to this question means you agree we cannot publish both as s= tandard track. Answering NO to this question means you want to see both advance on the st= andard track. =20 --------------------------------------------------------------------------= -- Huang Youjun, CERNET CORPORATION: YES ----------------------------------------------=EF=BB=BF-------------------= ----------- =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? =20 --------------------------------------------------------------------------= ---- Huang Youjun, CERNET CORPORATION: MAP --------------------------------------------------------------------------= ----= --Boundary_(ID_fzdlBvfryb2VWrXfFLXtkA) Content-type: multipart/related; boundary="Boundary_(ID_wxsOtvgxf1R3hCdNjmTKaw)"; type="text/html" --Boundary_(ID_wxsOtvgxf1R3hCdNjmTKaw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 
Question 1: Do you agree that the wg sh=
ould put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other=
 being published as experimental or informational.
Answering YES to this question means you agree we cannot publis=
h both as standard track.
Answering NO t=
o this question means you want to see both advance on the standard track.<=
/span>
 
-------------------------------------------------------------------------=
---
Huang Youjun, CERNET CORPORATION: YES=

----------------------------------------------=
------------------------------
 
 
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Questions 2: Which=
 one do you want to see placed on the Standards Track:
4rd-U or MAP?
 
--------------------------------------------=
----------------------------------
Huang=
 Youjun, CERNET CORPORATION: MAP
-------------=
-----------------------------------------------------------------
= --Boundary_(ID_wxsOtvgxf1R3hCdNjmTKaw)-- --Boundary_(ID_fzdlBvfryb2VWrXfFLXtkA)-- From bingxuere@gmail.com Sat Apr 7 01:37:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FBA21F84FE for ; Sat, 7 Apr 2012 01:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV1ZmZMuclNn for ; Sat, 7 Apr 2012 01:37:35 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C20CC21F84B4 for ; Sat, 7 Apr 2012 01:37:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so4736959iaz.31 for ; Sat, 07 Apr 2012 01:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3bSEhSAeuqF2M3wvzT62lV6wFOdMLd4NpYrEmv+wAYw=; b=F0i03Md4AdKeohP22ejyftmoUJsQnoKhNQABmnnOYzLm9el7zQLqKJrzaj7c+A4Bu+ 7yqPpC77Hpk98iaSCL3rx01hXxFdfCk66/eybZrtkKvMBsdtd3jEgWoZbCidE781TLXc 83P3Bjlc9CrXkJ3RhXa+JJTBSzZCWUeqEX7A0Fnel9jAbUfK7qoDiT9IDj1m2+0PSJQY 2pThDzbCHUXPREzUb50LftjmEx84Lr/LqFGgudHQkKYG+PERWK+rKwBRR2V99h1D7zRI 7yNUy/1Hu4YFueA3aiDhMyJthzd0tJjr0bsoJ7k5L9snTxneJGCW60z05yJTR3vJBfQw h/Dg== Received: by 10.42.97.194 with SMTP id p2mr406768icn.36.1333787850974; Sat, 07 Apr 2012 01:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Sat, 7 Apr 2012 01:36:50 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Sat, 7 Apr 2012 16:36:50 +0800 Message-ID: To: Durand Alain Content-Type: multipart/alternative; boundary=20cf303bf94e10265204bd12afa8 Cc: softwires@ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 08:37:35 -0000 --20cf303bf94e10265204bd12afa8 Content-Type: text/plain; charset=UTF-8 Hi all, ===================================================================== > > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. > > Answering YES to this question means you agree we cannot publish both as standard track. > > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- Qiong Sun, China Telecom: YES ---------------------------------------------------------------------------- > > > > ===================================================================== > > > > Questions 2: Which one do you want to see placed on the Standards Track: > > 4rd-U or MAP? > > > > ------------------------------------------------------------------------------ Qiong Sun, China Telecom: MAP ------------------------------------------------------------------------------ Best wishes Qiong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf303bf94e10265204bd12afa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,

<= div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U O=
R MAP (as a whole) on the standard track, the other being published as expe=
rimental or informational.
Answering YES to this question means you agree we cannot publi=
sh both as standard track.
Answering NO to this qu=
estion means you want to see both advance on the standard track.
=C2=A0
--------------------=
--------------------------------------------------------
=C2=A0Qiong Sun, China Telecom: YES= 
--------------------------------------------------------------=
--------------
=C2=A0
=
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0
Questions 2: Which one do you want to see placed on the Standa=
rds Track:
4rd-U or MAP?
=C2=A0
=C2=A0<= div>
-----------------------------------=
-------------------------------------------<=
/span>
=C2=A0Qiong Sun, China= Telecom: MAP

-------------------------------------------------------------------=
-----------

Best wishes
Qiong

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--20cf303bf94e10265204bd12afa8-- From huangyoujun1@gmail.com Sun Apr 8 01:26:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0321F8577 for ; Sun, 8 Apr 2012 01:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u835io9oSKUE for ; Sun, 8 Apr 2012 01:26:29 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3521F857F for ; Sun, 8 Apr 2012 01:26:28 -0700 (PDT) Received: by iazz13 with SMTP id z13so5692024iaz.31 for ; Sun, 08 Apr 2012 01:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xXAXYsPreJrHljDxaN/bOK6i5vJTWHepIcg3NmDK03E=; b=Emqzr/wI2dwdWEeiky3zP0N/He+syFP6yCf/J78Ndn9JGhIEyU+ytjWgEifcMsJbn0 Q/ymnfs+M/4LZJqkylO984yyPlxvqjZnQXmnoZe9kXkfMeLoMreZtlMvBDnMq32kilYs wE2PwOXt983r9CDHsjmkyJbKmJuktTsRY3xoPEzOUl/n6GF9M1RjGTBwUk+k3RUaAQpi OtInnRHI/eqVunlnr/cXZr/UondKFfBBXmhtkjmzkqnXRl0d6CSip3s7+E3xZ3LBBJA+ ZbxpckCu0O0XTYzditA7bjJdCYtvu1SYiDHB41MGAayN9CDAK/5q6q3rJZc5H9VySGl6 h06A== MIME-Version: 1.0 Received: by 10.43.54.143 with SMTP id vu15mr2224280icb.40.1333873588286; Sun, 08 Apr 2012 01:26:28 -0700 (PDT) Received: by 10.43.125.202 with HTTP; Sun, 8 Apr 2012 01:26:28 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Apr 2012 16:26:28 +0800 Message-ID: From: youjun huang To: softwires@ietf.org Content-Type: multipart/alternative; boundary=bcaec51b1c9f67b47304bd26a592 Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 08:26:29 -0000 --bcaec51b1c9f67b47304bd26a592 Content-Type: text/plain; charset=ISO-8859-1 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Huang Youjun, CERNET CORPORATION: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Huang Youjun, CERNET CORPORATION: MAP ------------------------------------------------------------------------------ --bcaec51b1c9f67b47304bd26a592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should p=
ut EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being =
published as experimental or informational.
Answ=
ering YES to this question means you agree we cannot publish both as standa=
rd track.
Answering NO to this question means you want to see both =
advance on the standard track.
=A0<=
/span>
-------------------------------------------------------------------=
---------
Huan=
g Youjun, CERNET CORPORATION: YES
---------------------------------=
-------------------------------------------
=A0<=
/span>
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
=A0<=
/span>
Questions 2: Which one do you want to see placed on the Standards T=
rack:
4rd-=
U or MAP?
=A0
---------------------------------------------=
---------------------------------
Huan=
g Youjun, CERNET CORPORATION: MAP
---------------------------------=
---------------------------------------------


--bcaec51b1c9f67b47304bd26a592-- From futaidong@gmail.com Sun Apr 8 18:10:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510F721F853B for ; Sun, 8 Apr 2012 18:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.452 X-Spam-Level: * X-Spam-Status: No, score=1.452 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ng2AfMjJg5C for ; Sun, 8 Apr 2012 18:10:31 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45BDA21F8523 for ; Sun, 8 Apr 2012 18:10:31 -0700 (PDT) Received: by lagj5 with SMTP id j5so1919661lag.31 for ; Sun, 08 Apr 2012 18:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=on4gt7F6z3Vg7KHRj4wikOr67EtGtQTHKPguIMJmjTY=; b=FXe7Q1A+JGiGeTWUzihobgIyhjXyifHEba9POiB7MxHHX1P7fIIyTZ7ZsKNtUsr3EA I49oK4ZRrYI7rCH5I6+u+fOs29JUb4U6JBUPSTagdCU9ugkGZRUISIFJMWfalGFT1LXP lk3w3IOjwf486TCbF9VKTN2ET3cu9sWC5o4NmeRYu0KDLjWlEpu0Bd1T2V9ZkOWx1DoX DjY9JnUl4igZ5fVanSt8s5W6lOVBOAkwA8plExHryjhctUqPoqipauWpjpiGPjdykikL za3WpL96WfpIxb1s1NxF4SoPnqNJzXS7Mdxr8g8irD+2dI2bz45GpmZhK1NLOwXEG26L QTQA== MIME-Version: 1.0 Received: by 10.152.114.35 with SMTP id jd3mr8850512lab.18.1333933830287; Sun, 08 Apr 2012 18:10:30 -0700 (PDT) Received: by 10.152.22.193 with HTTP; Sun, 8 Apr 2012 18:10:30 -0700 (PDT) Date: Mon, 9 Apr 2012 09:10:30 +0800 Message-ID: From: fu taidong To: softwires@ietf.org Content-Type: multipart/alternative; boundary=f46d04083be91bb2a104bd34ac5c Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 01:10:32 -0000 --f46d04083be91bb2a104bd34ac5c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------= - Your full name, your affiliation, your choice: YES or NO ---------------------------------------------------------------------------= - Futaidong Network and Information Center of JiLin University , China. YES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Your full name, your affiliation, your choice: 4rd-U or MAP ---------------------------------------------------------------------------= --- Futaidong Network and Information Center of JiLin University , China. MAP. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name=A3=BAFu taidong=A3=A8=B7=FB=CC=AB=B6=AB=A3=A9 E-Mail=A3=BAeagle@jlu.edu.cn Address=A3=BANetwork and Information Center of JiLin University , China Tel: +86 0431 85166443 --f46d04083be91bb2a104bd34ac5c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the w= g should put EITHER 4rd-U OR MAP (as&nbs= p;a whole) on the standard track,
the other being published as experimental&nbs= p;or informational.
Answering YES to this question means you=  agree we cannot publish both as standar= d track.
Answering NO to this question means you&= nbsp;want to see both advance on the sta= ndard track.
----------------------------------------------------------------------= ------
Your full name, your affiliation, your c= hoice: YES or NO
----------------------------------------------------------------------= ------
 
Futaidong  Network and Information Center of JiLin University , China. YES
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questions 2: Which one do you want = to see placed on the Standards Track:
4rd-U or MAP?
----------------------------------------------------------------------= --------
Your full name, your affiliation, your c= hoice: 4rd-U or MAP
----------------------------------------------------------------------= --------
 
 
Futaidong  Network and Information Center of JiLin University , China. MAP.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
Name=A3=BAFu taidong=A3=A8=B7= =FB=CC=AB=B6=AB=A3=A9
E-Mail=A3=BAeagle@jlu.edu.cn
Address=A3=BANetwork and Info= rmation Center of JiLin&nbs= p;University , China
Tel: +86 0431 85166443
=
--f46d04083be91bb2a104bd34ac5c-- From tomosann@gmail.com Sun Apr 8 21:28:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE421F8634 for ; Sun, 8 Apr 2012 21:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55UFo0R02xCH for ; Sun, 8 Apr 2012 21:28:26 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3F21F862B for ; Sun, 8 Apr 2012 21:28:25 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3314019bku.31 for ; Sun, 08 Apr 2012 21:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=viYaO1rHCPfo3QYpcg3QtKuuin/KgWzbKHb7bD4oU6M=; b=c0s83Wvm44IMuoxleFjG0942RQJvKIiEibNvGVVvvJaUej2Kg4w387IQBuaLERnVQV lClrwOZS6M5b6QpKUm9yi1p9+xsdkHErQ9tbCLV1o9R3qKH1STa4wlD7hO93Y1yifxrT azT23jaekCIYdMRY/eBvKwFxxPRqBE1FnuslK6NZ5Y7y3dgx2QPzZfzxSqNgJ37ZZVV7 sSEuujx9WXZJnXX4E2+48fGto5uomn/Olt6SRC26EI7Zp2ofgCWzTk0BGqJgB9Fk2HL0 3xM4SRYf2l3v4eatYK+XjtwFYY/yxuqWXIb9bOQrsWpfZ+EfGGSbfoJyezhKVlzJZvLQ LVaQ== MIME-Version: 1.0 Received: by 10.204.154.202 with SMTP id p10mr2487567bkw.79.1333945704876; Sun, 08 Apr 2012 21:28:24 -0700 (PDT) Received: by 10.204.153.194 with HTTP; Sun, 8 Apr 2012 21:28:24 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Mon, 9 Apr 2012 13:28:24 +0900 Message-ID: From: Tomoyuki Sahara To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 04:28:26 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Tomoyuki Sahara, Internet Initiative Japan: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Tomoyuki Sahara, Internet Initiative Japan: MAP ------------------------------------------------------------------------------ ===================================================================== From cx.cernet@gmail.com Sun Apr 8 22:24:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08621F85E6 for ; Sun, 8 Apr 2012 22:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOLkc9JwSwAD for ; Sun, 8 Apr 2012 22:24:24 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB4D21F85DB for ; Sun, 8 Apr 2012 22:24:24 -0700 (PDT) Received: by dady13 with SMTP id y13so6696533dad.27 for ; Sun, 08 Apr 2012 22:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=urODiFlL2lIyxqFQEf/lPBcYL8TqV/TmPA55klk0cYw=; b=mVdO1v02Rs8VASVoenROzIgNnmM2+Giw+jy1fzgybn/OcPHHLhKK/rOmVZ8+jQDe2J nWHAZa6cVXr6Dr1RXy3lAIDHL6zH50t2PsHsWKOHV6OOgG0Z1I2u0cR/1afLaHjO9k9I sZ5zv7ELfbVBZl3z9CT7Awquv1YuBNtDBtzROqr/sBqhZEBA6TZcg3gCpFmkpKRmBEK2 eYtJXIJnTZ33EWiQLiV47xP0Av1RW0tASsHLd2t88fmQxRHO+yMq8LxH5/U+h5Hry+7C 2VokbHXYte5nlkrPmCZSkk8l4vxc/WMURNqZ0F5vNLLCyaLigIDsMEVHIcuYPgWK6Bvy zFKg== MIME-Version: 1.0 Received: by 10.68.212.163 with SMTP id nl3mr4110979pbc.112.1333949064335; Sun, 08 Apr 2012 22:24:24 -0700 (PDT) Received: by 10.142.105.20 with HTTP; Sun, 8 Apr 2012 22:24:24 -0700 (PDT) In-Reply-To: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Mon, 9 Apr 2012 13:24:24 +0800 Message-ID: From: Congxiao Bao To: Alain Durand , "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Content-Type: multipart/alternative; boundary=e89a8ff1c82a20d1d704bd383830 Cc: Congxiao Bao Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 05:24:25 -0000 --e89a8ff1c82a20d1d704bd383830 Content-Type: text/plain; charset=ISO-8859-1 > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > ---------------------------------------------------------------------------- > Congxiao Bao, Tsinghua University, your choice: YES > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > ------------------------------------------------------------------------------ > Congxiao Bao, Tsinghua University, your choice: MAP > > ------------------------------------------------------------------------------ > > ===================================================================== > --e89a8ff1c82a20d1d704bd383830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental o= r informational.
Answering YES to this question means you agree we canno= t publish both as standard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

--------------------------------------------------------= --------------------
Congxiao Bao, Tsinghua University, your choice: YES= =A0

------------------------------------------= ----------------------------------


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Qu= estions 2: Which one do you want to see placed on the Standards Track:
4= rd-U or MAP?

--------------------------------------------------------= ----------------------
Congxiao Bao, Tsinghua University, your choice: MAP
--------------------= ----------------------------------------------------------

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--e89a8ff1c82a20d1d704bd383830-- From cx.cernet@gmail.com Sun Apr 8 22:41:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C921F861D for ; Sun, 8 Apr 2012 22:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyet3uitKGX6 for ; Sun, 8 Apr 2012 22:41:06 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 93C2D21F8616 for ; Sun, 8 Apr 2012 22:41:06 -0700 (PDT) Received: by dady13 with SMTP id y13so6712856dad.27 for ; Sun, 08 Apr 2012 22:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CynFQSS3hcCwIjQo9Q0UDSglHLfm0uAs9t6WENKC7k0=; b=wFQkcdAY2/d1bX8TZcvRFTjoYhRHoxFnC12/0iA+62QnFr6kSIOYcDMyqJE+H2Y012 wBDmU60TWMWypcgaGKcms3Jccyevmpa6K/TJcPHS2q90R4tNg48HSIDgYyfhtzmrqD7O ZH385QvAYvK2BI1yOHMm9fhzs9ydhEg3KOlFLMEvQpzSVGisYpi7BFwlWwCcrCpgylto 2IOi1cxoxMSDBX5mVJ3LLPW2fVYfEOEPp3dlLAX5gI/pq3awQ+dPaQD2CYMSWNo0Pe+D uM9W56PulLozu8/fRBXKt0qsSCQzXsnZaq9FR3EhJR52n2U4Sr8U7Xt4sKFmn3FAsMuJ 7Vvw== MIME-Version: 1.0 Received: by 10.68.212.163 with SMTP id nl3mr4207993pbc.112.1333950066188; Sun, 08 Apr 2012 22:41:06 -0700 (PDT) Received: by 10.142.105.20 with HTTP; Sun, 8 Apr 2012 22:41:06 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> Date: Mon, 9 Apr 2012 13:41:06 +0800 Message-ID: From: Congxiao Bao To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=e89a8ff1c82ad7e24a04bd38738f Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 05:41:08 -0000 --e89a8ff1c82ad7e24a04bd38738f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, MAP-T has been tested in CERNET2 and we have tested applications such as http, telnet, ssh=EF=BC=8Cftp, icmp echo request/reply, qq, skype, msn, vi= deo (for example: youku.com, xunlei.com, etc) without any problem. Congxiao 2012/4/6 Lee, Yiu > I also followed the discussion. I appreciate both teams bought up the > technical details for both designs. To be honest, I fail to see which one > is better than other (yet). I like the fact that 4rd-u can do what MAP-T > does w/o introducing any encap overhead. But I understand the concerns > others brought up in the ML such as V-octet. For MAP-T, I like it not > introducing any new requirement to the IPv6 header, but I need more > published data to determine whether the double-translation would cause an= y > transparent issue or not. For example: I would very appreciate if somebod= y > who trial MAP can publish data such as what applications they have tested= , > what pass and what fail. > > This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future. > > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > >+1 > > > >I've read the endless discussion, and found that is seems the MAP also > >has not fully convinced the ISP operation guys. > >Since there's explicit controversy, why not just publish them both as > >experimental. why we must chose one as a "standard track"? Being a > >standard track can eliminate operators' misgiving? > > > >If the technology is really appropriate, I don't think the "experimental= " > >status would be a issue for the operators to adopt. Just let the operato= r > >decide by themselves. > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp > >WG, suggested we publish both of them as experimental, and that was > >exactly how they handle the similar situation in their WG. I think his > >suggestion is reasonable to be considered. (To Joel: Pardon me if I > >improperly quoted your comment, or I just misunderstood your suggestion > >). > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > >> Behalf Of Simon Perreault > >> Sent: Tuesday, April 03, 2012 8:16 PM > >> To: softwires@ietf.org > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > >>transparent > >> as MAP-E > >> > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using > >>hub > >> and spoke mode with a separate > >> > mapping rule per subscriber. in this mode e.g only ports could b= e > >> embedded in the address. this is not > >> > possible in a translation solution like 4rd-U. > >> > >> This mode of operation was suggested last week during the SD-NAT > >> presentation. There seemed to be consensus among operators that it was > >> not practically feasible. > >> > >> > 2) a node inside the network will treat translated packets different > >>from > >> encapsulated ones. > >> > e.g. for the purposes of counting or for applying features. for = an > >> encapsulated packet both the complete > >> > IPv4 datagram and the IPv6 header is available, and different > >>features > >> can be applied to both. > >> > >> In practice, the contents of encapsulated packets are rarely inspected > >> by firewalls and other such devices. > >> > >> > >> IMHO at this point we should let the market decide. Publish both as > >> experimental. Let's work on something else now. > >> > >> Simon > >> -- > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --e89a8ff1c82ad7e24a04bd38738f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
MAP-T has been tested in CERNET2 and we= have tested applications such as http, telnet, ssh=EF=BC=8Cftp, icmp echo = request/reply, qq, skype, msn,=C2=A0 video (for example: youku.com, xunlei.com, etc= )=C2=A0 without any problem.
=C2=A0
Congxiao
=C2=A0
2012/4/6 Lee, Yiu <Yiu_Lee@cable.comcast.com>
I also followed the discussion. I appreciate both teams bought up the
technical details for both designs. To be honest, I fail to see which one is better than other (yet). I like the fact that 4rd-u can do what MAP-T does w/o introducing any encap overhead. But I understand the concerns
others brought up in the ML such as V-octet. For MAP-T, I like it not
introducing any new requirement to the IPv6 header, but I need more
published data to determine whether the double-translation would cause any<= br> transparent issue or not. For example: I would very appreciate if somebody<= br> who trial MAP can publish data such as what applications they have tested,<= br> what pass and what fail.

This piece of work is very important because once we select it, this
technology will stay for long time. I do not want to rush to make a
decision and come back to regret in future.


On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:

>+1
>
>I've read the endless discussion, and found that is seems the MAP a= lso
>has not fully convinced the ISP operation guys.
>Since there's explicit controversy, why not just publish them both = as
>experimental. why we must chose one as a "standard track"? Be= ing a
>standard track can eliminate operators' misgiving?
>
>If the technology is really appropriate, I don't think the "ex= perimental"
>status would be a issue for the operators to adopt. Just let the operat= or
>decide by themselves.
>
>I remembered in the meeting venue, Joel Halpern who chairs Karp and lis= p
>WG, suggested we publish both of them as experimental, and that was
>exactly how they handle the similar situation in their WG. I think his<= br> >suggestion is reasonable to be considered. (To Joel: Pardon me if I
>improperly quoted your comment, or I just misunderstood your suggestion=
>).
>
>> -----Original Message-----
>> From: softwires-boun= ces@ietf.org [mailto:soft= wires-bounces@ietf.org] On
>> Behalf Of Simon Perreault
>> Sent: Tuesday, April 03, 2012 8:16 PM
>> To: softwires@ietf.org >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U= as
>>transparent
>> as MAP-E
>>
>> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
>> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. b= y using
>>hub
>> and spoke mode with a separate
>> > =C2=A0 =C2=A0 mapping rule per subscriber. in this mode e.g o= nly ports could be
>> embedded in the address. this is not
>> > =C2=A0 =C2=A0 possible in a translation solution like 4rd-U.<= br> >>
>> This mode of operation was suggested last week during the SD-NAT >> presentation. There seemed to be consensus among operators that it= was
>> not practically feasible.
>>
>> > 2) a node inside the network will treat translated packets di= fferent
>>from
>> encapsulated ones.
>> > =C2=A0 =C2=A0 e.g. for the purposes of counting or for applyi= ng features. for an
>> encapsulated packet both the complete
>> > =C2=A0 =C2=A0 IPv4 datagram and the IPv6 header is available,= and different
>>features
>> can be applied to both.
>>
>> In practice, the contents of encapsulated packets are rarely inspe= cted
>> by firewalls and other such devices.
>>
>>
>> IMHO at this point we should let the market decide. Publish both a= s
>> experimental. Let's work on something else now.
>>
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.c= a
>> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = --> http://numb.vi= agenie.ca
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--e89a8ff1c82ad7e24a04bd38738f-- From jiangsheng@huawei.com Sun Apr 8 23:19:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9511E8073 for ; Sun, 8 Apr 2012 23:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyBCk0X0B0SI for ; Sun, 8 Apr 2012 23:19:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 44E7A21F864A for ; Sun, 8 Apr 2012 23:19:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB35041; Mon, 09 Apr 2012 02:19:34 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Apr 2012 23:17:55 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Apr 2012 23:17:56 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 14:17:43 +0800 From: Sheng Jiang To: "Lee, Yiu" , "Liubing (Leo)" , Simon Perreault , "softwires@ietf.org" Thread-Topic: =?windows-1257?Q?[Softwires]_Path_to_move_forward_with_4rd=D0_4rd-U_as_tr?= =?windows-1257?Q?ansparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg Date: Mon, 9 Apr 2012 06:17:42 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?windows-1257?q?Path_to_move_forward_with_4rd=D0_4rd?= =?windows-1257?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 06:19:36 -0000 > I also followed the discussion. I appreciate both teams bought up the > technical details for both designs. To be honest, I fail to see which > one is better than other (yet). I like the fact that 4rd-u can do what > MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I like > it not introducing any new requirement to the IPv6 header, but I need > more published data to determine whether the double-translation would > cause any transparent issue or not. For example: I would very > appreciate if somebody who trial MAP can publish data such as what > applications they have tested, what pass and what fail. >=20 > This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future. We would like to see both solution published. So that, operators can choose= according to their own networks and preference. There are enormous number = of operators, who do not come to IETF meeting or do not participate in ML e= ither. They also need to choose IPv6 transition mechanisms. They should be = provided enough technical supports. That's the response of IETF, in our und= erstanding. =20 > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: >=20 > >+1 > > > >I've read the endless discussion, and found that is seems the MAP also > >has not fully convinced the ISP operation guys. > >Since there's explicit controversy, why not just publish them both as > >experimental. why we must chose one as a "standard track"? Being a > >standard track can eliminate operators' misgiving? > > > >If the technology is really appropriate, I don't think the > "experimental" > >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves. > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > >lisp WG, suggested we publish both of them as experimental, and that > >was exactly how they handle the similar situation in their WG. I think > >his suggestion is reasonable to be considered. (To Joel: Pardon me if > I > >improperly quoted your comment, or I just misunderstood your > suggestion > >). > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > >>On Behalf Of Simon Perreault > >> Sent: Tuesday, April 03, 2012 8:16 PM > >> To: softwires@ietf.org > >> Subject: Re: [Softwires] Path to move forward with 4rd=D0 4rd-U as > >>transparent as MAP-E > >> > >> On 2012-04-03 05:40, Ole Tr=B8an wrote: > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > >> > using > >>hub > >> and spoke mode with a separate > >> > mapping rule per subscriber. in this mode e.g only ports could > >> > be > >> embedded in the address. this is not > >> > possible in a translation solution like 4rd-U. > >> > >> This mode of operation was suggested last week during the SD-NAT > >> presentation. There seemed to be consensus among operators that it > >> was not practically feasible. > >> > >> > 2) a node inside the network will treat translated packets > >> > different > >>from > >> encapsulated ones. > >> > e.g. for the purposes of counting or for applying features. > for > >> > an > >> encapsulated packet both the complete > >> > IPv4 datagram and the IPv6 header is available, and different > >>features > >> can be applied to both. > >> > >> In practice, the contents of encapsulated packets are rarely > >> inspected by firewalls and other such devices. > >> > >> > >> IMHO at this point we should let the market decide. Publish both as > >> experimental. Let's work on something else now. > >> > >> Simon > >> -- > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Mon Apr 9 00:24:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D5821F8443 for ; Mon, 9 Apr 2012 00:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt+0pYF-JrQs for ; Mon, 9 Apr 2012 00:24:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDBA621F8441 for ; Mon, 9 Apr 2012 00:24:30 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2738784qcs.31 for ; Mon, 09 Apr 2012 00:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z/KcL6x/kuSU17EieYjM061PF3GCE24Rqo2kWqHdm7w=; b=X+/7eBIjFG058N0L2fq2iclFSaXdND5RIoV9hASKO8OWeUSluOfAlgkQyOQ+N+6dnN qRogNHHCd4m8H7Tuv79ZMRWAYPn3rSqgZt4mCnxhb73gWaZs+NUfJVzCGbPqn2m7vSQ6 OaUCu65HcPtYBHfq6j9Kaeszbj2Nj7eCkLueAwOc3lDWihEQOo6nHvgaPsozXylfRLI4 CuNxUbKszeVXRwe73pHb/PJ7DKDRmtHdgpjGMLW35P+CA6n3DTjFM5Vfh7n41BnQ9LOL 9t3csSWUFxIwLZWStYVwe+7tJGvRaveSBZUeGM61qysd54foy4rOSnXGbmnKsymQ40aa dStg== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr8044295qab.36.1333956270283; Mon, 09 Apr 2012 00:24:30 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Mon, 9 Apr 2012 00:24:30 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> Date: Mon, 9 Apr 2012 07:24:30 +0000 Message-ID: From: Maoke To: Sheng Jiang Content-Type: multipart/alternative; boundary=20cf300faff5a2db3904bd39e5db Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:24:32 -0000 --20cf300faff5a2db3904bd39e5db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi Yiu and others, 1. "both published" does surely conflict with the design goal of 4rd-U itself: unification of multiple standards. politically speaking, the 4rd-u authors' positition is now quite confusing. 2. operators surely need to choose IPv6 transition mechanisms but such a choice is based on their demand and understanding to the existing and well-tested, well-practiced building blocks. i don't think any operators are waiting for an option of choice they never see and never understand. and the "enough technical supports" is now still "a check without signature". i do suggest the 4rd-u authors and supporters say that after making something real. on the other hand, 4rd-u makes a tight coupling between the address format and its own header mapping mechanism. this makes an operator unable to have different choices of transition mechanism as long as it chooses 4rd-u. if you concern the choice of IPv6 transition mechanism, i do recommend MAP, as either encapsulation or translation is operatable with MAP address/port mapping without difficulty. 3. surely MAP still has room of improvement but i don't think there are architectural uncertainty as 4rd-U has. request on more testing data is surely appreciated but please think it over again if it is a correct way to require further data of a counterpart in order to defense a solution without any data. 4. even there were no MAP at all, current level of 4rd-U is far premature to be talked about any working group acception. the authors and supporters will be appreciated if they talk about the acception after their coding and testing and refinement on the document according to their practical experiences, and understanding the problem again and again. thanks, maoke 2012/4/9 Sheng Jiang > > I also followed the discussion. I appreciate both teams bought up the > > technical details for both designs. To be honest, I fail to see which > > one is better than other (yet). I like the fact that 4rd-u can do what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I like > > it not introducing any new requirement to the IPv6 header, but I need > > more published data to determine whether the double-translation would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. > > We would like to see both solution published. So that, operators can > choose according to their own networks and preference. There are enormous > number of operators, who do not come to IETF meeting or do not participat= e > in ML either. They also need to choose IPv6 transition mechanisms. They > should be provided enough technical supports. That's the response of IETF= , > in our understanding. > > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and that > > >was exactly how they handle the similar situation in their WG. I think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf300faff5a2db3904bd39e5db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi Yiu and others,=C2=A0

1. "both publis= hed" does surely conflict with the design goal of 4rd-U itself:=C2=A0<= br>
=C2=A0 =C2=A0unification of multiple standards.=C2=A0politica= lly speaking, the 4rd-u authors'
=C2=A0 =C2=A0positition is now quite confusing.=C2=A0

2. operators surely need to choose IPv6 transition mechanisms but = such a choice=C2=A0
=C2=A0 =C2=A0is based on their demand and und= erstanding to the existing and well-tested,=C2=A0
=C2=A0 =C2=A0well-practiced building blocks. i don't think any ope= rators are waiting for=C2=A0
=C2=A0 =C2=A0an option of choice the= y never see and never understand. and the "enough=C2=A0
=C2= =A0 =C2=A0technical supports" is now still "a check without signa= ture". i do suggest=C2=A0
=C2=A0 =C2=A0the 4rd-u authors and supporters say that after making so= mething real.=C2=A0

=C2=A0 =C2=A0on the other hand= , 4rd-u makes a tight coupling between the address format=C2=A0
= =C2=A0 =C2=A0and its own header mapping mechanism. this makes an operator u= nable to have=C2=A0
=C2=A0 =C2=A0different choices of transition mechanism as long as it c= hooses 4rd-u. if=C2=A0
=C2=A0 =C2=A0you concern the choice of IPv= 6 transition mechanism, i do recommend MAP, as=C2=A0
=C2=A0 =C2= =A0either encapsulation or translation is operatable with MAP address/port= =C2=A0
=C2=A0 =C2=A0mapping without difficulty.=C2=A0

3. surely MAP still has room of improvement but i don't think there a= re=C2=A0
=C2=A0 =C2=A0architectural uncertainty as 4rd-U has. req= uest on more testing data is=C2=A0
=C2=A0 =C2=A0surely appreciated but please think it over again if it i= s a correct way=C2=A0
=C2=A0 =C2=A0to require further data of a c= ounterpart in order to defense a solution=C2=A0
=C2=A0 =C2=A0with= out any data.=C2=A0

4. even there were no MAP at all, current level of 4rd-U is far premature t= o be=C2=A0
=C2=A0 =C2=A0talked about any working group acception.=

the authors and supporters will be appreciated if= they talk about the acception=C2=A0
after their coding and testing and refinement on the document accordin= g to their=C2=A0
practical experiences, and understanding the pro= blem again and again.=C2=A0

thanks,=C2=A0
maoke

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>
> I also followed the discussion. I appreciate both te= ams bought up the
> technical details for both designs. To be honest, I fail to see which<= br> > one is better than other (yet). I like the fact that 4rd-u can do what=
> MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e
> it not introducing any new requirement to the IPv6 header, but I need<= br> > more published data to determine whether the double-translation would<= br> > cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future.

We would like to see both solution published. So that, operators can = choose according to their own networks and preference. There are enormous n= umber of operators, who do not come to IETF meeting or do not participate i= n ML either. They also need to choose IPv6 transition mechanisms. They shou= ld be provided enough technical supports. That's the response of IETF, = in our understanding.

> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"= ;? Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp an= d
> >lisp WG, suggested we publish both of them as experimental, and th= at
> >was exactly how they handle the similar situation in their WG. I t= hink
> >his suggestion is reasonable to be considered. (To Joel: Pardon me= if
> I
> >improperly quoted your comment, or I just misunderstood your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires= -bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On =C2=A0Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: softwires@ietf.org<= /a>
> >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 = 4rd-U as
> >>transparent =C2=A0as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 addressi= ng. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> > =C2=A0 =C2=A0 mapping rule per subscriber. in this mode = e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> > =C2=A0 =C2=A0 possible in a translation solution like 4r= d-U.
> >>
> >> This mode of operation was suggested last week during the SD-= NAT
> >> presentation. There seemed to be consensus among operators th= at it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated packe= ts
> >> > different
> >>from
> >> encapsulated ones.
> >> > =C2=A0 =C2=A0 e.g. for the purposes of counting or for a= pplying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> > =C2=A0 =C2=A0 IPv4 datagram and the IPv6 header is avail= able, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are rarely<= br> > >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. Publish b= oth as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca<= br> > >> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagen= ie.ca
> >> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --> http://= numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org<= br> > >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf300faff5a2db3904bd39e5db-- From jan@go6.si Mon Apr 9 00:50:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632D621F8650 for ; Mon, 9 Apr 2012 00:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXDm22xOVtfs for ; Mon, 9 Apr 2012 00:50:04 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD72921F864E for ; Mon, 9 Apr 2012 00:50:04 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 3548323780C2 for ; Mon, 9 Apr 2012 09:50:01 +0200 (CEST) Message-ID: <4F8294B4.5030905@go6.si> Date: Mon, 09 Apr 2012 09:50:12 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1257?q?Path_to_move_forward_with_4rd=D0_4rd?= =?windows-1257?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:50:05 -0000 On 4/9/12 8:17 AM, Sheng Jiang wrote: > We would like to see both solution published. So that, operators can > choose according to their own networks and preference. Disagree. This would hypothetically be nice for operators to have a choice, but vendors (looks like) will not implement two slightly different solutions in same hardware. On the other hand, who will make operators understand, what the difference really is and what are the dangers deploying one or another? Cheers, Jan From jan@go6.si Mon Apr 9 00:52:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815E721F854B for ; Mon, 9 Apr 2012 00:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXK1IWqrR6E5 for ; Mon, 9 Apr 2012 00:52:04 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11F21F84F3 for ; Mon, 9 Apr 2012 00:52:04 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 9B41A23780BC for ; Mon, 9 Apr 2012 09:52:02 +0200 (CEST) Message-ID: <4F82952E.9070109@go6.si> Date: Mon, 09 Apr 2012 09:52:14 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:52:05 -0000 On 4/9/12 9:24 AM, Maoke wrote: > hi Yiu and others, > > 1. "both published" does surely conflict with the design goal of 4rd-U > itself: > unification of multiple standards. politically speaking, the 4rd-u > authors' > positition is now quite confusing. > > 2. operators surely need to choose IPv6 transition mechanisms but such a > choice > is based on their demand and understanding to the existing and > well-tested, > well-practiced building blocks. i don't think any operators are > waiting for > an option of choice they never see and never understand. and the > "enough > technical supports" is now still "a check without signature". i do > suggest > the 4rd-u authors and supporters say that after making something real. > > on the other hand, 4rd-u makes a tight coupling between the address > format > and its own header mapping mechanism. this makes an operator unable > to have > different choices of transition mechanism as long as it chooses > 4rd-u. if > you concern the choice of IPv6 transition mechanism, i do recommend > MAP, as > either encapsulation or translation is operatable with MAP address/port > mapping without difficulty. +1 Agree. Cheers, Jan From jiangsheng@huawei.com Mon Apr 9 00:58:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB721F865C for ; Mon, 9 Apr 2012 00:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qOluVPOGR0A for ; Mon, 9 Apr 2012 00:58:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 93BAC21F8650 for ; Mon, 9 Apr 2012 00:58:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB40358; Mon, 09 Apr 2012 03:58:03 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 00:56:11 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 00:56:10 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 15:56:01 +0800 From: Sheng Jiang To: Maoke Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg//+RWQCAAIj4IA== Date: Mon, 9 Apr 2012 07:56:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B0w8 DQSA DdUM HWSy IrXe JiCW K81N Mxpt PnsI RcRI S7Ze X003 d6NF faVk iGNF kPqa; 4; ZgBpAGIAcgBpAGIAQABnAG0AYQBpAGwALgBjAG8AbQA7AHMAaQBtAG8AbgAuAHAAZQByAHIAZQBhAHUAbAB0AEAAdgBpAGEAZwBlAG4AaQBlAC4AYwBhADsAcwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcAOwB5AGkAdQBfAGwAZQBlAEAAYwBhAGIAbABlAC4AYwBvAG0AYwBhAHMAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {EC4B1E7C-039B-4283-B3B2-96EA75EAC1D7}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 09 Apr 2012 07:55:55 GMT; UgBFADoAIABbAFMAbwBmAHQAdwBpAHIAZQBzAF0AIABQAGEAdABoACAAdABvACAAbQBvAHYAZQAgAGYAbwByAHcAYQByAGQAIAB3AGkAdABoACAANAByAGQAYAEgADQAcgBkAC0AVQAgAGEAcwAgAHQAcgBhAG4AcwBwAGEAcgBlAG4AdAAgAGEAcwAgAE0AQQBQAC0ARQA= x-cr-puzzleid: {EC4B1E7C-039B-4283-B3B2-96EA75EAC1D7} x-originating-ip: [10.108.4.115] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B921E48364FSZXEML506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:58:05 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B921E48364FSZXEML506MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGFsbG93IG1lIHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBvcnQgYm90aCBNQVAgYW5k IDRyZC11Lg0KDQpNQVAgaGFzIGJlZW4gYSBnb29kIGVmZm9ydCB3aXRoIG1hbnkgZXhwZXJ0cyB0 b2dldGhlciBpbiBJUHY0L0lQdjYgdHJhbnNpdGlvbiBhcmVhIGFuZCBoYXMgYmVlbiBwcm92ZWQg YnkgcnVubmluZyBjb2RlLiBJdCBhbHNvIG5lZWQgdG8gaW1wcm92ZSBpdHNlbGYgYmVmb3JlIGJl aW5nIHB1Ymxpc2hlZCBhcyBhIFJGQyBsYXRlci4gVGhpcyBwcm9jZXNzIHdpbGwgdGFrZSBzZXZl cmFsIG1vbnRocy4NCg0KUGVyc29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQg YmVoaW5kIE1BUCBpbiBtYXR1cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LCBpdCBpcyBvbmx5IG1h dHRlciBvZiB0aW1lLiBUaGUgYXV0aG9ycyBoYXZlIGFncmVlZCB0byByZW1vdmUgdGhlIGFyY2hp dGVjdHVyYWwgY29uZmxpY3QsIGlmIHRoZXJlIHdhcyBhbnkuIFdlIGhhdmUgb2ZmZXJlZCB0byBo ZWxwIG9uIHRoZSBpbXByb3ZlbWVudCBieSBpbXBsZW1lbnRhdGlvbi4NCg0KR2l2aW5nIHRpbWUs IGJvdGggc29sdXRpb24gY2FuIGJlIG1hdHVyZSBlbm91Z2ggZm9yIG9wZXJhdGlvbnMuIElFVEYg ZG9lcyBub3QgaGF2ZSB0byBjaG9vc2Ugb25lIGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRp b25zIGFyZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGEgc2FtZSBwYWNlLg0KDQpCZXN0IHJlZ2FyZHMs DQoNClNoZW5nDQoNCkZyb206IE1hb2tlIFttYWlsdG86ZmlicmliQGdtYWlsLmNvbV0NClNlbnQ6 IE1vbmRheSwgQXByaWwgMDksIDIwMTIgMzoyNCBQTQ0KVG86IFNoZW5nIEppYW5nDQpDYzogTGVl LCBZaXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTF oCA0cmQtVSBhcyB0cmFuc3BhcmVudCBhcyBNQVAtRQ0KDQpoaSBZaXUgYW5kIG90aGVycywNCg0K MS4gImJvdGggcHVibGlzaGVkIiBkb2VzIHN1cmVseSBjb25mbGljdCB3aXRoIHRoZSBkZXNpZ24g Z29hbCBvZiA0cmQtVSBpdHNlbGY6DQogICB1bmlmaWNhdGlvbiBvZiBtdWx0aXBsZSBzdGFuZGFy ZHMuIHBvbGl0aWNhbGx5IHNwZWFraW5nLCB0aGUgNHJkLXUgYXV0aG9ycycNCiAgIHBvc2l0aXRp b24gaXMgbm93IHF1aXRlIGNvbmZ1c2luZy4NCg0KMi4gb3BlcmF0b3JzIHN1cmVseSBuZWVkIHRv IGNob29zZSBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcyBidXQgc3VjaCBhIGNob2ljZQ0KICAg aXMgYmFzZWQgb24gdGhlaXIgZGVtYW5kIGFuZCB1bmRlcnN0YW5kaW5nIHRvIHRoZSBleGlzdGlu ZyBhbmQgd2VsbC10ZXN0ZWQsDQogICB3ZWxsLXByYWN0aWNlZCBidWlsZGluZyBibG9ja3MuIGkg ZG9uJ3QgdGhpbmsgYW55IG9wZXJhdG9ycyBhcmUgd2FpdGluZyBmb3INCiAgIGFuIG9wdGlvbiBv ZiBjaG9pY2UgdGhleSBuZXZlciBzZWUgYW5kIG5ldmVyIHVuZGVyc3RhbmQuIGFuZCB0aGUgImVu b3VnaA0KICAgdGVjaG5pY2FsIHN1cHBvcnRzIiBpcyBub3cgc3RpbGwgImEgY2hlY2sgd2l0aG91 dCBzaWduYXR1cmUiLiBpIGRvIHN1Z2dlc3QNCiAgIHRoZSA0cmQtdSBhdXRob3JzIGFuZCBzdXBw b3J0ZXJzIHNheSB0aGF0IGFmdGVyIG1ha2luZyBzb21ldGhpbmcgcmVhbC4NCg0KICAgb24gdGhl IG90aGVyIGhhbmQsIDRyZC11IG1ha2VzIGEgdGlnaHQgY291cGxpbmcgYmV0d2VlbiB0aGUgYWRk cmVzcyBmb3JtYXQNCiAgIGFuZCBpdHMgb3duIGhlYWRlciBtYXBwaW5nIG1lY2hhbmlzbS4gdGhp cyBtYWtlcyBhbiBvcGVyYXRvciB1bmFibGUgdG8gaGF2ZQ0KICAgZGlmZmVyZW50IGNob2ljZXMg b2YgdHJhbnNpdGlvbiBtZWNoYW5pc20gYXMgbG9uZyBhcyBpdCBjaG9vc2VzIDRyZC11LiBpZg0K ICAgeW91IGNvbmNlcm4gdGhlIGNob2ljZSBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtLCBp IGRvIHJlY29tbWVuZCBNQVAsIGFzDQogICBlaXRoZXIgZW5jYXBzdWxhdGlvbiBvciB0cmFuc2xh dGlvbiBpcyBvcGVyYXRhYmxlIHdpdGggTUFQIGFkZHJlc3MvcG9ydA0KICAgbWFwcGluZyB3aXRo b3V0IGRpZmZpY3VsdHkuDQoNCjMuIHN1cmVseSBNQVAgc3RpbGwgaGFzIHJvb20gb2YgaW1wcm92 ZW1lbnQgYnV0IGkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlDQogICBhcmNoaXRlY3R1cmFsIHVuY2Vy dGFpbnR5IGFzIDRyZC1VIGhhcy4gcmVxdWVzdCBvbiBtb3JlIHRlc3RpbmcgZGF0YSBpcw0KICAg c3VyZWx5IGFwcHJlY2lhdGVkIGJ1dCBwbGVhc2UgdGhpbmsgaXQgb3ZlciBhZ2FpbiBpZiBpdCBp cyBhIGNvcnJlY3Qgd2F5DQogICB0byByZXF1aXJlIGZ1cnRoZXIgZGF0YSBvZiBhIGNvdW50ZXJw YXJ0IGluIG9yZGVyIHRvIGRlZmVuc2UgYSBzb2x1dGlvbg0KICAgd2l0aG91dCBhbnkgZGF0YS4N Cg0KNC4gZXZlbiB0aGVyZSB3ZXJlIG5vIE1BUCBhdCBhbGwsIGN1cnJlbnQgbGV2ZWwgb2YgNHJk LVUgaXMgZmFyIHByZW1hdHVyZSB0byBiZQ0KICAgdGFsa2VkIGFib3V0IGFueSB3b3JraW5nIGdy b3VwIGFjY2VwdGlvbi4NCg0KdGhlIGF1dGhvcnMgYW5kIHN1cHBvcnRlcnMgd2lsbCBiZSBhcHBy ZWNpYXRlZCBpZiB0aGV5IHRhbGsgYWJvdXQgdGhlIGFjY2VwdGlvbg0KYWZ0ZXIgdGhlaXIgY29k aW5nIGFuZCB0ZXN0aW5nIGFuZCByZWZpbmVtZW50IG9uIHRoZSBkb2N1bWVudCBhY2NvcmRpbmcg dG8gdGhlaXINCnByYWN0aWNhbCBleHBlcmllbmNlcywgYW5kIHVuZGVyc3RhbmRpbmcgdGhlIHBy b2JsZW0gYWdhaW4gYW5kIGFnYWluLg0KDQp0aGFua3MsDQptYW9rZQ0KDQoyMDEyLzQvOSBTaGVu ZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5j b20+Pg0KPiBJIGFsc28gZm9sbG93ZWQgdGhlIGRpc2N1c3Npb24uIEkgYXBwcmVjaWF0ZSBib3Ro IHRlYW1zIGJvdWdodCB1cCB0aGUNCj4gdGVjaG5pY2FsIGRldGFpbHMgZm9yIGJvdGggZGVzaWdu cy4gVG8gYmUgaG9uZXN0LCBJIGZhaWwgdG8gc2VlIHdoaWNoDQo+IG9uZSBpcyBiZXR0ZXIgdGhh biBvdGhlciAoeWV0KS4gSSBsaWtlIHRoZSBmYWN0IHRoYXQgNHJkLXUgY2FuIGRvIHdoYXQNCj4g TUFQLVQgZG9lcyB3L28gaW50cm9kdWNpbmcgYW55IGVuY2FwIG92ZXJoZWFkLiBCdXQgSSB1bmRl cnN0YW5kIHRoZQ0KPiBjb25jZXJucyBvdGhlcnMgYnJvdWdodCB1cCBpbiB0aGUgTUwgc3VjaCBh cyBWLW9jdGV0LiBGb3IgTUFQLVQsIEkgbGlrZQ0KPiBpdCBub3QgaW50cm9kdWNpbmcgYW55IG5l dyByZXF1aXJlbWVudCB0byB0aGUgSVB2NiBoZWFkZXIsIGJ1dCBJIG5lZWQNCj4gbW9yZSBwdWJs aXNoZWQgZGF0YSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG91YmxlLXRyYW5zbGF0aW9uIHdv dWxkDQo+IGNhdXNlIGFueSB0cmFuc3BhcmVudCBpc3N1ZSBvciBub3QuIEZvciBleGFtcGxlOiBJ IHdvdWxkIHZlcnkNCj4gYXBwcmVjaWF0ZSBpZiBzb21lYm9keSB3aG8gdHJpYWwgTUFQIGNhbiBw dWJsaXNoIGRhdGEgc3VjaCBhcyB3aGF0DQo+IGFwcGxpY2F0aW9ucyB0aGV5IGhhdmUgdGVzdGVk LCB3aGF0IHBhc3MgYW5kIHdoYXQgZmFpbC4NCj4NCj4gVGhpcyBwaWVjZSBvZiB3b3JrIGlzIHZl cnkgaW1wb3J0YW50IGJlY2F1c2Ugb25jZSB3ZSBzZWxlY3QgaXQsIHRoaXMNCj4gdGVjaG5vbG9n eSB3aWxsIHN0YXkgZm9yIGxvbmcgdGltZS4gSSBkbyBub3Qgd2FudCB0byBydXNoIHRvIG1ha2Ug YQ0KPiBkZWNpc2lvbiBhbmQgY29tZSBiYWNrIHRvIHJlZ3JldCBpbiBmdXR1cmUuDQpXZSB3b3Vs ZCBsaWtlIHRvIHNlZSBib3RoIHNvbHV0aW9uIHB1Ymxpc2hlZC4gU28gdGhhdCwgb3BlcmF0b3Jz IGNhbiBjaG9vc2UgYWNjb3JkaW5nIHRvIHRoZWlyIG93biBuZXR3b3JrcyBhbmQgcHJlZmVyZW5j ZS4gVGhlcmUgYXJlIGVub3Jtb3VzIG51bWJlciBvZiBvcGVyYXRvcnMsIHdobyBkbyBub3QgY29t ZSB0byBJRVRGIG1lZXRpbmcgb3IgZG8gbm90IHBhcnRpY2lwYXRlIGluIE1MIGVpdGhlci4gVGhl eSBhbHNvIG5lZWQgdG8gY2hvb3NlIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc21zLiBUaGV5IHNo b3VsZCBiZSBwcm92aWRlZCBlbm91Z2ggdGVjaG5pY2FsIHN1cHBvcnRzLiBUaGF0J3MgdGhlIHJl c3BvbnNlIG9mIElFVEYsIGluIG91ciB1bmRlcnN0YW5kaW5nLg0KDQo+IE9uIDQvNi8xMiA2OjAw IEFNLCAiTGl1YmluZyAoTGVvKSIgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFpbHRvOmxlby5s aXViaW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gPisxDQo+ID4NCj4gPkkndmUgcmVhZCB0 aGUgZW5kbGVzcyBkaXNjdXNzaW9uLCBhbmQgZm91bmQgdGhhdCBpcyBzZWVtcyB0aGUgTUFQIGFs c28NCj4gPmhhcyBub3QgZnVsbHkgY29udmluY2VkIHRoZSBJU1Agb3BlcmF0aW9uIGd1eXMuDQo+ ID5TaW5jZSB0aGVyZSdzIGV4cGxpY2l0IGNvbnRyb3ZlcnN5LCB3aHkgbm90IGp1c3QgcHVibGlz aCB0aGVtIGJvdGggYXMNCj4gPmV4cGVyaW1lbnRhbC4gd2h5IHdlIG11c3QgY2hvc2Ugb25lIGFz IGEgInN0YW5kYXJkIHRyYWNrIj8gQmVpbmcgYQ0KPiA+c3RhbmRhcmQgdHJhY2sgY2FuIGVsaW1p bmF0ZSBvcGVyYXRvcnMnIG1pc2dpdmluZz8NCj4gPg0KPiA+SWYgdGhlIHRlY2hub2xvZ3kgaXMg cmVhbGx5IGFwcHJvcHJpYXRlLCBJIGRvbid0IHRoaW5rIHRoZQ0KPiAiZXhwZXJpbWVudGFsIg0K PiA+c3RhdHVzIHdvdWxkIGJlIGEgaXNzdWUgZm9yIHRoZSBvcGVyYXRvcnMgdG8gYWRvcHQuIEp1 c3QgbGV0IHRoZQ0KPiA+b3BlcmF0b3IgZGVjaWRlIGJ5IHRoZW1zZWx2ZXMuDQo+ID4NCj4gPkkg cmVtZW1iZXJlZCBpbiB0aGUgbWVldGluZyB2ZW51ZSwgSm9lbCBIYWxwZXJuIHdobyBjaGFpcnMg S2FycCBhbmQNCj4gPmxpc3AgV0csIHN1Z2dlc3RlZCB3ZSBwdWJsaXNoIGJvdGggb2YgdGhlbSBh cyBleHBlcmltZW50YWwsIGFuZCB0aGF0DQo+ID53YXMgZXhhY3RseSBob3cgdGhleSBoYW5kbGUg dGhlIHNpbWlsYXIgc2l0dWF0aW9uIGluIHRoZWlyIFdHLiBJIHRoaW5rDQo+ID5oaXMgc3VnZ2Vz dGlvbiBpcyByZWFzb25hYmxlIHRvIGJlIGNvbnNpZGVyZWQuIChUbyBKb2VsOiBQYXJkb24gbWUg aWYNCj4gSQ0KPiA+aW1wcm9wZXJseSBxdW90ZWQgeW91ciBjb21tZW50LCBvciBJIGp1c3QgbWlz dW5kZXJzdG9vZCB5b3VyDQo+IHN1Z2dlc3Rpb24NCj4gPikuDQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZz5dDQo+ID4+T24g IEJlaGFsZiBPZiBTaW1vbiBQZXJyZWF1bHQNCj4gPj4gU2VudDogVHVlc2RheSwgQXByaWwgMDMs IDIwMTIgODoxNiBQTQ0KPiA+PiBUbzogc29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2ly ZXNAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUg Zm9yd2FyZCB3aXRoIDRyZMWgIDRyZC1VIGFzDQo+ID4+dHJhbnNwYXJlbnQgIGFzIE1BUC1FDQo+ ID4+DQo+ID4+IE9uIDIwMTItMDQtMDMgMDU6NDAsIE9sZSBUcsO4YW4gd3JvdGU6DQo+ID4+ID4g MSkgTUFQLUUgc3VwcG9ydHMgaW5kZXBlbmRlbmNlIG9mIElQdjQgYW5kIElQdjYgYWRkcmVzc2lu Zy4gYnkNCj4gPj4gPiB1c2luZw0KPiA+Pmh1Yg0KPiA+PiBhbmQgc3Bva2UgbW9kZSB3aXRoIGEg c2VwYXJhdGUNCj4gPj4gPiAgICAgbWFwcGluZyBydWxlIHBlciBzdWJzY3JpYmVyLiBpbiB0aGlz IG1vZGUgZS5nIG9ubHkgcG9ydHMgY291bGQNCj4gPj4gPiBiZQ0KPiA+PiBlbWJlZGRlZCBpbiB0 aGUgYWRkcmVzcy4gdGhpcyBpcyBub3QNCj4gPj4gPiAgICAgcG9zc2libGUgaW4gYSB0cmFuc2xh dGlvbiBzb2x1dGlvbiBsaWtlIDRyZC1VLg0KPiA+Pg0KPiA+PiBUaGlzIG1vZGUgb2Ygb3BlcmF0 aW9uIHdhcyBzdWdnZXN0ZWQgbGFzdCB3ZWVrIGR1cmluZyB0aGUgU0QtTkFUDQo+ID4+IHByZXNl bnRhdGlvbi4gVGhlcmUgc2VlbWVkIHRvIGJlIGNvbnNlbnN1cyBhbW9uZyBvcGVyYXRvcnMgdGhh dCBpdA0KPiA+PiB3YXMgbm90IHByYWN0aWNhbGx5IGZlYXNpYmxlLg0KPiA+Pg0KPiA+PiA+IDIp IGEgbm9kZSBpbnNpZGUgdGhlIG5ldHdvcmsgd2lsbCB0cmVhdCB0cmFuc2xhdGVkIHBhY2tldHMN Cj4gPj4gPiBkaWZmZXJlbnQNCj4gPj5mcm9tDQo+ID4+IGVuY2Fwc3VsYXRlZCBvbmVzLg0KPiA+ PiA+ICAgICBlLmcuIGZvciB0aGUgcHVycG9zZXMgb2YgY291bnRpbmcgb3IgZm9yIGFwcGx5aW5n IGZlYXR1cmVzLg0KPiBmb3INCj4gPj4gPiBhbg0KPiA+PiBlbmNhcHN1bGF0ZWQgcGFja2V0IGJv dGggdGhlIGNvbXBsZXRlDQo+ID4+ID4gICAgIElQdjQgZGF0YWdyYW0gYW5kIHRoZSBJUHY2IGhl YWRlciBpcyBhdmFpbGFibGUsIGFuZCBkaWZmZXJlbnQNCj4gPj5mZWF0dXJlcw0KPiA+PiBjYW4g YmUgYXBwbGllZCB0byBib3RoLg0KPiA+Pg0KPiA+PiBJbiBwcmFjdGljZSwgdGhlIGNvbnRlbnRz IG9mIGVuY2Fwc3VsYXRlZCBwYWNrZXRzIGFyZSByYXJlbHkNCj4gPj4gaW5zcGVjdGVkIGJ5IGZp cmV3YWxscyBhbmQgb3RoZXIgc3VjaCBkZXZpY2VzLg0KPiA+Pg0KPiA+Pg0KPiA+PiBJTUhPIGF0 IHRoaXMgcG9pbnQgd2Ugc2hvdWxkIGxldCB0aGUgbWFya2V0IGRlY2lkZS4gUHVibGlzaCBib3Ro IGFzDQo+ID4+IGV4cGVyaW1lbnRhbC4gTGV0J3Mgd29yayBvbiBzb21ldGhpbmcgZWxzZSBub3cu DQo+ID4+DQo+ID4+IFNpbW9uDQo+ID4+IC0tDQo+ID4+IERUTiBtYWRlIGVhc3ksIGxlYW4sIGFu ZCBzbWFydCAtLT4gaHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYQ0KPiA+PiBOQVQ2NC9E TlM2NCBvcGVuLXNvdXJjZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhDQo+ ID4+IFNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlhZ2Vu aWUuY2ENCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+PiBTb2Z0d2lyZXNAaWV0Zi5vcmc8 bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ID5Tb2Z0d2ly ZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCj4gPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdp cmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B921E48364FSZXEML506MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q bGVhc2UgYWxsb3cgbWUgdG8gY2xhcmlmeSBteXNlbGY6IEkgc3VwcG9ydCBib3RoIE1BUCBhbmQg NHJkLXUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NQVAgaGFzIGJlZW4gYSBnb29kIGVmZm9ydCB3aXRoIG1hbnkgZXhw ZXJ0cyB0b2dldGhlciBpbiBJUHY0L0lQdjYgdHJhbnNpdGlvbiBhcmVhIGFuZCBoYXMgYmVlbiBw cm92ZWQgYnkgcnVubmluZyBjb2RlLiBJdCBhbHNvIG5lZWQgdG8gaW1wcm92ZSBpdHNlbGYgYmVm b3JlDQogYmVpbmcgcHVibGlzaGVkIGFzIGEgUkZDIGxhdGVyLiBUaGlzIHByb2Nlc3Mgd2lsbCB0 YWtlIHNldmVyYWwgbW9udGhzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVyc29uYWxseSwgSSB0aGluayA0cmQtdSBp cyBhIGxpdHRsZSBiaXQgYmVoaW5kIE1BUCBpbiBtYXR1cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0 LCBpdCBpcyBvbmx5IG1hdHRlciBvZiB0aW1lLiBUaGUgYXV0aG9ycyBoYXZlIGFncmVlZCB0byBy ZW1vdmUgdGhlIGFyY2hpdGVjdHVyYWwNCiBjb25mbGljdCwgaWYgdGhlcmUgd2FzIGFueS4gV2Ug aGF2ZSBvZmZlcmVkIHRvIGhlbHAgb24gdGhlIGltcHJvdmVtZW50IGJ5IGltcGxlbWVudGF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+R2l2aW5nIHRpbWUsIGJvdGggc29sdXRpb24gY2FuIGJlIG1hdHVyZSBlbm91 Z2ggZm9yIG9wZXJhdGlvbnMuIElFVEYgZG9lcyBub3QgaGF2ZSB0byBjaG9vc2Ugb25lIGJ5IG5v dy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25zIGFyZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGENCiBz YW1lIHBhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGVuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW9rZSBbbWFpbHRvOmZpYnJp YkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiAz OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4gTGVlLCBZ aXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3 aXRoIDRyZMWgIDRyZC1VIGFzIHRyYW5zcGFyZW50IGFzIE1BUC1FPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhpIFlpdSBhbmQgb3RoZXJzLCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xLiAmcXVvdDtib3RoIHB1Ymxpc2hlZCZxdW90OyBkb2VzIHN1cmVseSBjb25mbGljdCB3aXRo IHRoZSBkZXNpZ24gZ29hbCBvZiA0cmQtVSBpdHNlbGY6Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dW5pZmljYXRp b24gb2YgbXVsdGlwbGUgc3RhbmRhcmRzLiZuYnNwO3BvbGl0aWNhbGx5IHNwZWFraW5nLCB0aGUg NHJkLXUgYXV0aG9ycycNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Bvc2l0aXRpb24gaXMgbm93IHF1aXRlIGNvbmZ1c2lu Zy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Mi4gb3BlcmF0b3JzIHN1cmVseSBuZWVkIHRvIGNob29zZSBJUHY2IHRyYW5zaXRpb24g bWVjaGFuaXNtcyBidXQgc3VjaCBhIGNob2ljZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2lzIGJhc2VkIG9uIHRo ZWlyIGRlbWFuZCBhbmQgdW5kZXJzdGFuZGluZyB0byB0aGUgZXhpc3RpbmcgYW5kIHdlbGwtdGVz dGVkLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO3dlbGwtcHJhY3RpY2VkIGJ1aWxkaW5nIGJsb2Nrcy4gaSBkb24n dCB0aGluayBhbnkgb3BlcmF0b3JzIGFyZSB3YWl0aW5nIGZvciZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FuIG9w dGlvbiBvZiBjaG9pY2UgdGhleSBuZXZlciBzZWUgYW5kIG5ldmVyIHVuZGVyc3RhbmQuIGFuZCB0 aGUgJnF1b3Q7ZW5vdWdoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGVjaG5pY2FsIHN1cHBvcnRzJnF1b3Q7IGlz IG5vdyBzdGlsbCAmcXVvdDthIGNoZWNrIHdpdGhvdXQgc2lnbmF0dXJlJnF1b3Q7LiBpIGRvIHN1 Z2dlc3QmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDt0aGUgNHJkLXUgYXV0aG9ycyBhbmQgc3VwcG9ydGVycyBzYXkg dGhhdCBhZnRlciBtYWtpbmcgc29tZXRoaW5nIHJlYWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtvbiB0aGUg b3RoZXIgaGFuZCwgNHJkLXUgbWFrZXMgYSB0aWdodCBjb3VwbGluZyBiZXR3ZWVuIHRoZSBhZGRy ZXNzIGZvcm1hdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FuZCBpdHMgb3duIGhlYWRlciBtYXBwaW5nIG1lY2hh bmlzbS4gdGhpcyBtYWtlcyBhbiBvcGVyYXRvciB1bmFibGUgdG8gaGF2ZSZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O2RpZmZlcmVudCBjaG9pY2VzIG9mIHRyYW5zaXRpb24gbWVjaGFuaXNtIGFzIGxvbmcgYXMgaXQg Y2hvb3NlcyA0cmQtdS4gaWYmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt5b3UgY29uY2VybiB0aGUgY2hvaWNlIG9m IElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc20sIGkgZG8gcmVjb21tZW5kIE1BUCwgYXMmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDtlaXRoZXIgZW5jYXBzdWxhdGlvbiBvciB0cmFuc2xhdGlvbiBpcyBvcGVyYXRhYmxl IHdpdGggTUFQIGFkZHJlc3MvcG9ydCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO21hcHBpbmcgd2l0aG91dCBkaWZm aWN1bHR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4zLiBzdXJlbHkgTUFQIHN0aWxsIGhhcyByb29tIG9mIGltcHJvdmVtZW50IGJ1 dCBpIGRvbid0IHRoaW5rIHRoZXJlIGFyZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FyY2hpdGVjdHVyYWwgdW5j ZXJ0YWludHkgYXMgNHJkLVUgaGFzLiByZXF1ZXN0IG9uIG1vcmUgdGVzdGluZyBkYXRhIGlzJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7c3VyZWx5IGFwcHJlY2lhdGVkIGJ1dCBwbGVhc2UgdGhpbmsgaXQgb3ZlciBh Z2FpbiBpZiBpdCBpcyBhIGNvcnJlY3Qgd2F5Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dG8gcmVxdWlyZSBmdXJ0 aGVyIGRhdGEgb2YgYSBjb3VudGVycGFydCBpbiBvcmRlciB0byBkZWZlbnNlIGEgc29sdXRpb24m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt3aXRob3V0IGFueSBkYXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBldmVuIHRoZXJlIHdlcmUgbm8g TUFQIGF0IGFsbCwgY3VycmVudCBsZXZlbCBvZiA0cmQtVSBpcyBmYXIgcHJlbWF0dXJlIHRvIGJl Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7dGFsa2VkIGFib3V0IGFueSB3b3JraW5nIGdyb3VwIGFjY2VwdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhl IGF1dGhvcnMgYW5kIHN1cHBvcnRlcnMgd2lsbCBiZSBhcHByZWNpYXRlZCBpZiB0aGV5IHRhbGsg YWJvdXQgdGhlIGFjY2VwdGlvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YWZ0ZXIgdGhlaXIgY29kaW5nIGFuZCB0ZXN0aW5nIGFuZCBy ZWZpbmVtZW50IG9uIHRoZSBkb2N1bWVudCBhY2NvcmRpbmcgdG8gdGhlaXImbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByYWN0aWNhbCBl eHBlcmllbmNlcywgYW5kIHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0gYWdhaW4gYW5kIGFnYWlu LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj50aGFua3MsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5tYW9rZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4yMDEyLzQvOSBTaGVuZyBKaWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmppYW5nc2hlbmdAaHVhd2VpLmNvbSI+amlhbmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZndDsgSSBhbHNvIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uLiBJIGFwcHJl Y2lhdGUgYm90aCB0ZWFtcyBib3VnaHQgdXAgdGhlPGJyPg0KJmd0OyB0ZWNobmljYWwgZGV0YWls cyBmb3IgYm90aCBkZXNpZ25zLiBUbyBiZSBob25lc3QsIEkgZmFpbCB0byBzZWUgd2hpY2g8YnI+ DQomZ3Q7IG9uZSBpcyBiZXR0ZXIgdGhhbiBvdGhlciAoeWV0KS4gSSBsaWtlIHRoZSBmYWN0IHRo YXQgNHJkLXUgY2FuIGRvIHdoYXQ8YnI+DQomZ3Q7IE1BUC1UIGRvZXMgdy9vIGludHJvZHVjaW5n IGFueSBlbmNhcCBvdmVyaGVhZC4gQnV0IEkgdW5kZXJzdGFuZCB0aGU8YnI+DQomZ3Q7IGNvbmNl cm5zIG90aGVycyBicm91Z2h0IHVwIGluIHRoZSBNTCBzdWNoIGFzIFYtb2N0ZXQuIEZvciBNQVAt VCwgSSBsaWtlPGJyPg0KJmd0OyBpdCBub3QgaW50cm9kdWNpbmcgYW55IG5ldyByZXF1aXJlbWVu dCB0byB0aGUgSVB2NiBoZWFkZXIsIGJ1dCBJIG5lZWQ8YnI+DQomZ3Q7IG1vcmUgcHVibGlzaGVk IGRhdGEgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGRvdWJsZS10cmFuc2xhdGlvbiB3b3VsZDxi cj4NCiZndDsgY2F1c2UgYW55IHRyYW5zcGFyZW50IGlzc3VlIG9yIG5vdC4gRm9yIGV4YW1wbGU6 IEkgd291bGQgdmVyeTxicj4NCiZndDsgYXBwcmVjaWF0ZSBpZiBzb21lYm9keSB3aG8gdHJpYWwg TUFQIGNhbiBwdWJsaXNoIGRhdGEgc3VjaCBhcyB3aGF0PGJyPg0KJmd0OyBhcHBsaWNhdGlvbnMg dGhleSBoYXZlIHRlc3RlZCwgd2hhdCBwYXNzIGFuZCB3aGF0IGZhaWwuPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhpcyBwaWVjZSBvZiB3b3JrIGlzIHZlcnkgaW1wb3J0YW50IGJlY2F1c2Ugb25jZSB3 ZSBzZWxlY3QgaXQsIHRoaXM8YnI+DQomZ3Q7IHRlY2hub2xvZ3kgd2lsbCBzdGF5IGZvciBsb25n IHRpbWUuIEkgZG8gbm90IHdhbnQgdG8gcnVzaCB0byBtYWtlIGE8YnI+DQomZ3Q7IGRlY2lzaW9u IGFuZCBjb21lIGJhY2sgdG8gcmVncmV0IGluIGZ1dHVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd291bGQgbGlrZSB0byBzZWUgYm90aCBzb2x1dGlv biBwdWJsaXNoZWQuIFNvIHRoYXQsIG9wZXJhdG9ycyBjYW4gY2hvb3NlIGFjY29yZGluZyB0byB0 aGVpciBvd24gbmV0d29ya3MgYW5kIHByZWZlcmVuY2UuIFRoZXJlIGFyZSBlbm9ybW91cyBudW1i ZXIgb2Ygb3BlcmF0b3JzLCB3aG8gZG8gbm90IGNvbWUgdG8gSUVURiBtZWV0aW5nIG9yIGRvIG5v dCBwYXJ0aWNpcGF0ZSBpbiBNTCBlaXRoZXIuIFRoZXkNCiBhbHNvIG5lZWQgdG8gY2hvb3NlIElQ djYgdHJhbnNpdGlvbiBtZWNoYW5pc21zLiBUaGV5IHNob3VsZCBiZSBwcm92aWRlZCBlbm91Z2gg dGVjaG5pY2FsIHN1cHBvcnRzLiBUaGF0J3MgdGhlIHJlc3BvbnNlIG9mIElFVEYsIGluIG91ciB1 bmRlcnN0YW5kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQomZ3Q7IE9uIDQvNi8xMiA2OjAwIEFNLCAmcXVvdDtMaXViaW5nIChMZW8p JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSI+bGVvLmxp dWJpbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsm IzQzOzE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtJJ3ZlIHJlYWQgdGhlIGVuZGxlc3Mg ZGlzY3Vzc2lvbiwgYW5kIGZvdW5kIHRoYXQgaXMgc2VlbXMgdGhlIE1BUCBhbHNvPGJyPg0KJmd0 OyAmZ3Q7aGFzIG5vdCBmdWxseSBjb252aW5jZWQgdGhlIElTUCBvcGVyYXRpb24gZ3V5cy48YnI+ DQomZ3Q7ICZndDtTaW5jZSB0aGVyZSdzIGV4cGxpY2l0IGNvbnRyb3ZlcnN5LCB3aHkgbm90IGp1 c3QgcHVibGlzaCB0aGVtIGJvdGggYXM8YnI+DQomZ3Q7ICZndDtleHBlcmltZW50YWwuIHdoeSB3 ZSBtdXN0IGNob3NlIG9uZSBhcyBhICZxdW90O3N0YW5kYXJkIHRyYWNrJnF1b3Q7PyBCZWluZyBh PGJyPg0KJmd0OyAmZ3Q7c3RhbmRhcmQgdHJhY2sgY2FuIGVsaW1pbmF0ZSBvcGVyYXRvcnMnIG1p c2dpdmluZz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtJZiB0aGUgdGVjaG5vbG9neSBp cyByZWFsbHkgYXBwcm9wcmlhdGUsIEkgZG9uJ3QgdGhpbmsgdGhlPGJyPg0KJmd0OyAmcXVvdDtl eHBlcmltZW50YWwmcXVvdDs8YnI+DQomZ3Q7ICZndDtzdGF0dXMgd291bGQgYmUgYSBpc3N1ZSBm b3IgdGhlIG9wZXJhdG9ycyB0byBhZG9wdC4gSnVzdCBsZXQgdGhlPGJyPg0KJmd0OyAmZ3Q7b3Bl cmF0b3IgZGVjaWRlIGJ5IHRoZW1zZWx2ZXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 SSByZW1lbWJlcmVkIGluIHRoZSBtZWV0aW5nIHZlbnVlLCBKb2VsIEhhbHBlcm4gd2hvIGNoYWly cyBLYXJwIGFuZDxicj4NCiZndDsgJmd0O2xpc3AgV0csIHN1Z2dlc3RlZCB3ZSBwdWJsaXNoIGJv dGggb2YgdGhlbSBhcyBleHBlcmltZW50YWwsIGFuZCB0aGF0PGJyPg0KJmd0OyAmZ3Q7d2FzIGV4 YWN0bHkgaG93IHRoZXkgaGFuZGxlIHRoZSBzaW1pbGFyIHNpdHVhdGlvbiBpbiB0aGVpciBXRy4g SSB0aGluazxicj4NCiZndDsgJmd0O2hpcyBzdWdnZXN0aW9uIGlzIHJlYXNvbmFibGUgdG8gYmUg Y29uc2lkZXJlZC4gKFRvIEpvZWw6IFBhcmRvbiBtZSBpZjxicj4NCiZndDsgSTxicj4NCiZndDsg Jmd0O2ltcHJvcGVybHkgcXVvdGVkIHlvdXIgY29tbWVudCwgb3IgSSBqdXN0IG1pc3VuZGVyc3Rv b2QgeW91cjxicj4NCiZndDsgc3VnZ2VzdGlvbjxicj4NCiZndDsgJmd0OykuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYu b3JnIj5zb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWls dG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmciPnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3Jn PC9hPl08YnI+DQomZ3Q7ICZndDsmZ3Q7T24gJm5ic3A7QmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVs dDxicj4NCiZndDsgJmd0OyZndDsgU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIwMTIgODoxNiBQ TTxicj4NCiZndDsgJmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5v cmciPnNvZnR3aXJlc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3aXRoIDRyZMWgIDRyZC1VIGFzPGJy Pg0KJmd0OyAmZ3Q7Jmd0O3RyYW5zcGFyZW50ICZuYnNwO2FzIE1BUC1FPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT24gMjAxMi0wNC0wMyAwNTo0MCwgT2xlIFRyw7hhbiB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgMSkgTUFQLUUgc3VwcG9ydHMgaW5kZXBlbmRl bmNlIG9mIElQdjQgYW5kIElQdjYgYWRkcmVzc2luZy4gYnk8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsgdXNpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7aHViPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgc3Bv a2UgbW9kZSB3aXRoIGEgc2VwYXJhdGU8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyBtYXBwaW5nIHJ1bGUgcGVyIHN1YnNjcmliZXIuIGluIHRoaXMgbW9kZSBlLmcgb25seSBw b3J0cyBjb3VsZDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBiZTxicj4NCiZndDsgJmd0OyZndDsg ZW1iZWRkZWQgaW4gdGhlIGFkZHJlc3MuIHRoaXMgaXMgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgcG9zc2libGUgaW4gYSB0cmFuc2xhdGlvbiBzb2x1dGlvbiBsaWtl IDRyZC1VLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoaXMgbW9kZSBv ZiBvcGVyYXRpb24gd2FzIHN1Z2dlc3RlZCBsYXN0IHdlZWsgZHVyaW5nIHRoZSBTRC1OQVQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7IHByZXNlbnRhdGlvbi4gVGhlcmUgc2VlbWVkIHRvIGJlIGNvbnNlbnN1 cyBhbW9uZyBvcGVyYXRvcnMgdGhhdCBpdDxicj4NCiZndDsgJmd0OyZndDsgd2FzIG5vdCBwcmFj dGljYWxseSBmZWFzaWJsZS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IDIpIGEgbm9kZSBpbnNpZGUgdGhlIG5ldHdvcmsgd2lsbCB0cmVhdCB0cmFuc2xhdGVkIHBh Y2tldHM8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgZGlmZmVyZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0 O2Zyb208YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuY2Fwc3VsYXRlZCBvbmVzLjxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IGUuZy4gZm9yIHRoZSBwdXJwb3NlcyBvZiBjb3VudGlu ZyBvciBmb3IgYXBwbHlpbmcgZmVhdHVyZXMuPGJyPg0KJmd0OyBmb3I8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsgYW48YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuY2Fwc3VsYXRlZCBwYWNrZXQgYm90aCB0 aGUgY29tcGxldGU8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJUHY0IGRh dGFncmFtIGFuZCB0aGUgSVB2NiBoZWFkZXIgaXMgYXZhaWxhYmxlLCBhbmQgZGlmZmVyZW50PGJy Pg0KJmd0OyAmZ3Q7Jmd0O2ZlYXR1cmVzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjYW4gYmUgYXBwbGll ZCB0byBib3RoLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEluIHByYWN0 aWNlLCB0aGUgY29udGVudHMgb2YgZW5jYXBzdWxhdGVkIHBhY2tldHMgYXJlIHJhcmVseTxicj4N CiZndDsgJmd0OyZndDsgaW5zcGVjdGVkIGJ5IGZpcmV3YWxscyBhbmQgb3RoZXIgc3VjaCBkZXZp Y2VzLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBJTUhPIGF0IHRoaXMgcG9pbnQgd2Ugc2hvdWxkIGxldCB0aGUgbWFya2V0IGRlY2lkZS4g UHVibGlzaCBib3RoIGFzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBleHBlcmltZW50YWwuIExldCdzIHdv cmsgb24gc29tZXRoaW5nIGVsc2Ugbm93Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IFNpbW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyZndDsgRFRO IG1hZGUgZWFzeSwgbGVhbiwgYW5kIHNtYXJ0IC0tJmd0OyA8YSBocmVmPSJodHRwOi8vcG9zdGVs bGF0aW9uLnZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vcG9zdGVsbGF0aW9u LnZpYWdlbmllLmNhPC9hPjxicj4NCiZndDsgJmd0OyZndDsgTkFUNjQvRE5TNjQgb3Blbi1zb3Vy Y2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9lY2R5 c2lzLnZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vZWNkeXNpcy52aWFnZW5p ZS5jYTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IFNUVU4vVFVSTiBzZXJ2ZXIgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tJmd0OyA8YSBocmVmPSJodHRw Oi8vbnVtYi52aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL251bWIudmlhZ2Vu aWUuY2E8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsgU29mdHdpcmVzIG1haWxpbmcg bGlzdDxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9y ZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48 YnI+DQomZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgJmd0O1NvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8 YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0 d2lyZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B921E48364FSZXEML506MBSchi_-- From jiangsheng@huawei.com Mon Apr 9 01:06:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB4121F864D for ; Mon, 9 Apr 2012 01:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LztsyYfyhpbK for ; Mon, 9 Apr 2012 01:06:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AD20121F861D for ; Mon, 9 Apr 2012 01:06:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET41138; Mon, 09 Apr 2012 04:06:17 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 01:04:28 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 01:04:29 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 16:04:21 +0800 From: Sheng Jiang To: "Jan Zorz @ go6.si" , "softwires@ietf.org" Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg//+YiACAAIiM4A== Date: Mon, 9 Apr 2012 08:04:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E48368C@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <4F8294B4.5030905@go6.si> In-Reply-To: <4F8294B4.5030905@go6.si> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:06:18 -0000 > On 4/9/12 8:17 AM, Sheng Jiang wrote: > > We would like to see both solution published. So that, operators can > > choose according to their own networks and preference. >=20 > Disagree. This would hypothetically be nice for operators to have a > choice, but vendors (looks like) will not implement two slightly > different solutions in same hardware. >=20 > On the other hand, who will make operators understand, what the > difference really is and what are the dangers deploying one or another? Operators have their own brains. They may listen to vendors, but they do th= ink by themselves and make decisions by themselves. Vendors would implement= whatever the operators order.=20 There are a large number of operators. There are very slim chance they will= all stick on a same transition mechanism. We all know there have no one-su= it-all solution for IPv4/IPv6 transition. IETF have produced many transitio= n mechanisms. Obviously, they are not "enough". That's why we are still her= e to discuss more. Sheng =20 > Cheers, Jan > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Apr 9 01:13:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E421F8609 for ; Mon, 9 Apr 2012 01:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhzxxQAGvJGJ for ; Mon, 9 Apr 2012 01:13:31 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2486C21F8608 for ; Mon, 9 Apr 2012 01:13:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id vkDN1i00437Y3f403kDNn8; Mon, 09 Apr 2012 10:13:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35--830283219 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> Date: Mon, 9 Apr 2012 10:13:22 +0200 Message-Id: <7C7B60C8-2E32-43DA-8AE4-C2645E376F70@laposte.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> To: Softwires WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:13:34 -0000 --Apple-Mail-35--830283219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-04-09 =E0 09:56, Sheng Jiang a =E9crit : > ... > Giving time, both solution can be mature enough for operations. IETF = does not have to choose one by now. +1 Besides, in view of the clear lack of WG consensus in Paris, that is the = only fair approach at this stage. Regards, RD > And, these two solutions are not necessary to be a same pace. > =20 > Best regards, > =20 > Sheng > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 3:24 PM > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E > =20 > hi Yiu and others,=20 > =20 > 1. "both published" does surely conflict with the design goal of 4rd-U = itself:=20 > unification of multiple standards. politically speaking, the 4rd-u = authors' > positition is now quite confusing.=20 > =20 > 2. operators surely need to choose IPv6 transition mechanisms but such = a choice=20 > is based on their demand and understanding to the existing and = well-tested,=20 > well-practiced building blocks. i don't think any operators are = waiting for=20 > an option of choice they never see and never understand. and the = "enough=20 > technical supports" is now still "a check without signature". i do = suggest=20 > the 4rd-u authors and supporters say that after making something = real.=20 > =20 > on the other hand, 4rd-u makes a tight coupling between the address = format=20 > and its own header mapping mechanism. this makes an operator unable = to have=20 > different choices of transition mechanism as long as it chooses = 4rd-u. if=20 > you concern the choice of IPv6 transition mechanism, i do recommend = MAP, as=20 > either encapsulation or translation is operatable with MAP = address/port=20 > mapping without difficulty.=20 > =20 > 3. surely MAP still has room of improvement but i don't think there = are=20 > architectural uncertainty as 4rd-U has. request on more testing = data is=20 > surely appreciated but please think it over again if it is a = correct way=20 > to require further data of a counterpart in order to defense a = solution=20 > without any data.=20 > =20 > 4. even there were no MAP at all, current level of 4rd-U is far = premature to be=20 > talked about any working group acception. > =20 > the authors and supporters will be appreciated if they talk about the = acception=20 > after their coding and testing and refinement on the document = according to their=20 > practical experiences, and understanding the problem again and again.=20= > =20 > thanks,=20 > maoke > =20 > 2012/4/9 Sheng Jiang > > I also followed the discussion. I appreciate both teams bought up = the > > technical details for both designs. To be honest, I fail to see = which > > one is better than other (yet). I like the fact that 4rd-u can do = what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I = like > > it not introducing any new requirement to the IPv6 header, but I = need > > more published data to determine whether the double-translation = would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. >=20 > We would like to see both solution published. So that, operators can = choose according to their own networks and preference. There are = enormous number of operators, who do not come to IETF meeting or do not = participate in ML either. They also need to choose IPv6 transition = mechanisms. They should be provided enough technical supports. That's = the response of IETF, in our understanding. >=20 > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP = also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both = as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and = that > > >was exactly how they handle the similar situation in their WG. I = think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me = if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=F8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports = could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that = it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and = different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both = as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> = http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > =20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-35--830283219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
...
Giving time, both solution can be = mature enough for operations. IETF does not have to choose one by now. =

+1
<= div>
Besides, in view of the clear lack of WG = consensus in Paris, that is the only fair approach at this = stage.

Regards,
RD

=


And, these two solutions = are not necessary to be a same pace.
Best = regards,
 Maoke = [mailto:fibrib@gmail.com] 
Sent: Monday, April 09, 2012 3:24 = PM
To: Sheng = Jiang
Cc: Lee,= Yiu; Liubing (Leo); Simon Perreault;  Re: [Softwires] Path to = move forward with 4rd=8A 4rd-U as transparent as = MAP-E
2012/4/9 Sheng Jiang <> I also followed the discussion. I = appreciate both teams bought up the
> technical details for both = designs. To be honest, I fail to see which
> one is better than = other (yet). I like the fact that 4rd-u can do what
> MAP-T does = w/o introducing any encap overhead. But I understand the
> = concerns others brought up in the ML such as V-octet. For MAP-T, I = like
> it not introducing any new requirement to the IPv6 header, = but I need
> more published data to determine whether the = double-translation would
> cause any transparent issue or not. For = example: I would very
> appreciate if somebody who trial MAP can = publish data such as what
> applications they have tested, what = pass and what fail.
>
> This piece of work is very important = because once we select it, this
> technology will stay for long = time. I do not want to rush to make a
> decision and come back to = regret in future.


> On 4/6/12 6:00 = AM, "Liubing (Leo)" <> >standard track can eliminate = operators' misgiving?
> >
> >If the technology is = really appropriate, I don't think the
> "experimental"
> = >status would be a issue for the operators to adopt. Just let = the
> >operator decide by themselves.
> >
> = >I remembered in the meeting venue, Joel Halpern who chairs Karp = and
> >lisp WG, suggested we publish both of them as = experimental, and that
> >was exactly how they handle the = similar situation in their WG. I think
> >his suggestion is = reasonable to be considered. (To Joel: Pardon me if
> I
> = >improperly quoted your comment, or I just misunderstood your
> = suggestion
> >).
> >
> >> -----Original = Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> = >>On  Behalf Of Simon Perreault
> >> Sent: = Tuesday, April 03, 2012 8:16 PM
> >> To: softwires@ietf.org
> >> = Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as
> >>transparent  as MAP-E
> >>
> = >> On 2012-04-03 05:40, Ole Tr=F8an wrote:
> >> > = 1) MAP-E supports independence of IPv4 and IPv6 addressing. by
> = >> > using
> >>hub
> >> and spoke mode = with a separate
> >> >     mapping rule per = subscriber. in this mode e.g only ports could
> >> > = be
> >> embedded in the address. this is not
> = >> >     possible in a translation solution like = 4rd-U.
> >>
> >> This mode of operation was = suggested last week during the SD-NAT
> >> presentation. = There seemed to be consensus among operators that it
> >> = was not practically feasible.
> >>
> >> > 2) = a node inside the network will treat translated packets
> >> = > different
> >>from
> >> encapsulated = ones.
> >> >     e.g. for the purposes of = counting or for applying features.
> for
> >> > = an
> >> encapsulated packet both the complete
> = >> >     IPv4 datagram and the IPv6 header is = available, and different
> >>features
> >> can = be applied to both.
> >>
> >> In practice, the = contents of encapsulated packets are rarely
> >> inspected = by firewalls and other such devices.
> >>
> = >>
> >> IMHO at this point we should let the market = decide. Publish both as
> >> experimental. Let's work on = something else now.
> >>
> >> Simon
> = >> --
> >> DTN made easy, lean, and smart -->   http://numb.viagenie.ca
> = >> _______________________________________________
> = >> Softwires mailing list
> >> Softwires@ietf.org
> = >> Softwires@ietf.org
> >Softwires@ietf.org
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Softwires] Mailing list question to gauge consensus on 4rd-Uvs MAP Thread-Index: Ac0WEQ9BrPyvXMz9RJS+uLQhh6C48gAF+8YA References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> From: "Bobby Li (bobbyli)" To: "Alain Durand" , X-OriginalArrivalTime: 09 Apr 2012 08:17:45.0011 (UTC) FILETIME=[3DCFC830:01CD1629] Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-Uvs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:17:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1629.27954CF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. =09 ------------------------------------------------------------------------ ---- Bobby Li, CISCO, your choice: YES=20 =09 ------------------------------------------------------------------------ ---- =09 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? =09 ------------------------------------------------------------------------ ------ Bobby Li, CISCO, your choice: MAP =09 ------------------------------------------------------------------------ ------ =20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01CD1629.27954CF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg = should put EITHER 4rd-U OR MAP (as a whole) on the standard = track,
the other being published as experimental or = informational.
Answering YES to this question means you agree we = cannot publish both as standard track.
Answering NO to this question = means you want to see both advance on the standard = track.

-------------------------------------------------= ---------------------------
Bobby = Li, CISCO, your choice: = YES 

----------------------------= ------------------------------------------------


=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q= uestions 2: Which one do you want to see placed on the Standards = Track:
4rd-U or = MAP?

---------------------------------------------------= ---------------------------
Bobby = Li, CISCO, your choice: = MAP
------------------------------------------------------------------= ------------

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01CD1629.27954CF3-- From usui@fnsc.co.jp Mon Apr 9 01:27:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0321F84FB for ; Mon, 9 Apr 2012 01:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBl9eudX9ooq for ; Mon, 9 Apr 2012 01:27:24 -0700 (PDT) Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id E4F9721F84D5 for ; Mon, 9 Apr 2012 01:27:23 -0700 (PDT) Received: from ([158.202.234.214]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.828253; Mon, 09 Apr 2012 17:27:17 +0900 Date: Mon, 09 Apr 2012 17:27:16 +0900 From: Satoshi Usui To: Alain Durand In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.068 Message-Id: <20120409172716.D090.1D0288C0@fnsc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.60.01 [ja] Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:27:25 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Satoshi Usui, Furukawa Network Solution, YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Satoshi Usui, Furukawa Network Solution, MAP ------------------------------------------------------------------------------ ===================================================================== From useryqli@gmail.com Mon Apr 9 01:29:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343CC21F8630 for ; Mon, 9 Apr 2012 01:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5ad7qxDa3Ob for ; Mon, 9 Apr 2012 01:29:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9233221F84FB for ; Mon, 9 Apr 2012 01:29:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so6770435iaz.31 for ; Mon, 09 Apr 2012 01:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type :content-transfer-encoding; bh=fnGqyRY41MCS2DFLia+eVoPKyLf8VZLUoPeT3bspJnw=; b=CnRy/F+CZv2W6hmadv/4sc9qXbke5R96KXEC1T7jVcryfPDpzxKBuUfNs0BZ+NBEy+ Jj9OUgE8cD7e0VJBoCsaTUU6m2pgOco692QCW2SUwOjSOU+oasVU0yP8jag9aoMqHS6p qXAsDTnCLS8Q1DKk526VAYyDeuXY1b0rFZ3aVlPB/9wMh3eVUu4tQa8cJapMPWsdvswi ZuWoBD8k4l1pjsqWuF8dTXOIyWhwJpoNHjnPTc6h6o8Od6WmNObP6628Z/f2qeESAzxb yZrVswMw+AU0RLOPZJaO8KBiwItphu10ZPIOhA3ezZn48YC5drJx2k+5tk2moKCLP9r1 M6Gg== Received: by 10.43.118.138 with SMTP id fq10mr3521387icc.12.1333960145217; Mon, 09 Apr 2012 01:29:05 -0700 (PDT) Received: from windows ([202.112.14.106]) by mx.google.com with ESMTPS id nq4sm34958994igc.5.2012.04.09.01.29.01 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 01:29:04 -0700 (PDT) Date: Mon, 9 Apr 2012 16:28:03 +0800 From: useryqli To: "Alain Durand" , "softwires@ietf.org WG" References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-Priority: 3 X-GUID: 4CDF558F-FCF1-4C26-810C-A63DCFE88104 X-Mailer: Foxmail 7.0.1.78[cn] Mime-Version: 1.0 Message-ID: <20120409162803066015134@gmail.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: useryqli List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:29:06 -0000 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpRdWVzdGlvbiAxOiBEbyB5b3UgYWdyZWUgdGhhdCB0aGUgd2cgc2hvdWxk IHB1dCBFSVRIRVIgNHJkLVUgT1IgTUFQIChhcyBhIHdob2xlKSBvbiB0aGUgc3RhbmRhcmQgdHJh Y2ssDQp0aGUgb3RoZXIgYmVpbmcgcHVibGlzaGVkIGFzIGV4cGVyaW1lbnRhbCBvciBpbmZvcm1h dGlvbmFsLg0KQW5zd2VyaW5nIFlFUyB0byB0aGlzIHF1ZXN0aW9uIG1lYW5zIHlvdSBhZ3JlZSB3 ZSBjYW5ub3QgcHVibGlzaCBib3RoIGFzIHN0YW5kYXJkIHRyYWNrLg0KQW5zd2VyaW5nIE5PIHRv IHRoaXMgcXVlc3Rpb24gbWVhbnMgeW91IHdhbnQgdG8gc2VlIGJvdGggYWR2YW5jZSBvbiB0aGUg c3RhbmRhcmQgdHJhY2suDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZdXFpYW5nIExpLCBVbml2ZXJz aXR5IG9mIEVsZWN0cm9uaWMgU2NpZW5jZSBhbmQgVGVjaG5vbG9neSBvZiBDaGluYSA6IFlFUw0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpRdWVzdGlvbnMgMjogV2hpY2ggb25l IGRvIHlvdSB3YW50IHRvIHNlZSBwbGFjZWQgb24gdGhlIFN0YW5kYXJkcyBUcmFjazoNCjRyZC1V IG9yIE1BUD8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWXVxaWFuZyBMaSwgVW5pdmVyc2l0eSBv ZiBFbGVjdHJvbmljIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kgb2YgQ2hpbmE6ICBNQVANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCg0KeXFsaSANCk5PQ6OsVUVT VEMNCg0KDQpTZW5kZXI6IEFsYWluIER1cmFuZA0KRGF0ZTogMjAxMi0wNC0wOSAxNjoxMTo1OA0K VG86IHNvZnR3aXJlc0BpZXRmLm9yZyBXRw0KQ0M6IGludC1hZHNAdG9vbHMuaWV0Zi5vcmc7IFNv ZnR3aXJlIENoYWlycw0KU3ViamVjdDogW1NvZnR3aXJlc10gTWFpbGluZyBsaXN0IHF1ZXN0aW9u IHRvIGdhdWdlIGNvbnNlbnN1cyBvbiA0cmQtVSB2cyBNQVANCkRlYXIgU29mdHdpcmUgd2cgbWVt YmVyczoNCg0KQXQgdGhlIFBhcmlzIElFVEYgU29mdHdpcmUgbWVldGluZywgd2UgaGFkIHByZXNl bnRhdGlvbnMgb24gTUFQICh0YWtlbiBhcyBhIHdob2xlKSAgYW5kDQo0cmQtVS4gV2UgZ290IHZl cnkgc3Ryb25nIGZlZWRiYWNrIHRoYXQgd2UgbmVlZGVkIHRvIHNlbGVjdCBvbmUNCnNvbHV0aW9u IHRvIGNvdmVyIHRoYXQgZnVsbCBzdGF0ZWxlc3MgY2FzZSwgbm90IHR3bywgYW5kIHRoYXQgd2Ug c2hvdWxkIG1ha2UgdGhpcw0KZGVjaXNpb24gcmVsYXRpdmVseSBxdWlja2x5Lg0KDQpEdXJpbmcg UGFyaXMgbWVldGluZywgd2UgYXNrZWQgdGhlIGZvbGxvd2luZyBhZGRpdGlvbmFsIHF1ZXN0aW9u Og0KRG8geW91IHByZWZlciBNQVAgb3IgNHJkLVU/DQpXZSBnb3QgYWJvdXQgMS8zIHN1cHBvcnQg Zm9yIDRyZC1VIGFuZCAyLzMgZm9yIE1BUC4NCg0KVGhlIHJlYWwgZ2F1Z2Ugb2YgY29uc2Vuc3Vz IGlzIHRoZSBtYWlsaW5nIGxpc3QsIHNvIHdlIHdvdWxkIGxpa2UNCnRvIGFzayB0aGUgc2FtZSBx dWVzdGlvbnMgdG8gdGhlIGxpc3QuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUXVlc3Rpb24gMTogRG8geW91 IGFncmVlIHRoYXQgdGhlIHdnIHNob3VsZCBwdXQgRUlUSEVSIDRyZC1VIE9SIE1BUCAoYXMgYSB3 aG9sZSkgb24gdGhlIHN0YW5kYXJkIHRyYWNrLA0KdGhlIG90aGVyIGJlaW5nIHB1Ymxpc2hlZCBh cyBleHBlcmltZW50YWwgb3IgaW5mb3JtYXRpb25hbC4NCkFuc3dlcmluZyBZRVMgdG8gdGhpcyBx dWVzdGlvbiBtZWFucyB5b3UgYWdyZWUgd2UgY2Fubm90IHB1Ymxpc2ggYm90aCBhcyBzdGFuZGFy ZCB0cmFjay4NCkFuc3dlcmluZyBOTyB0byB0aGlzIHF1ZXN0aW9uIG1lYW5zIHlvdSB3YW50IHRv IHNlZSBib3RoIGFkdmFuY2Ugb24gdGhlIHN0YW5kYXJkIHRyYWNrLg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpZb3VyIGZ1bGwgbmFtZSwgeW91ciBhZmZpbGlhdGlvbiwgeW91ciBjaG9pY2U6IFlF UyBvciBOTw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpRdWVzdGlv bnMgMjogV2hpY2ggb25lIGRvIHlvdSB3YW50IHRvIHNlZSBwbGFjZWQgb24gdGhlIFN0YW5kYXJk cyBUcmFjazoNCjRyZC1VIG9yIE1BUD8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3VyIGZ1 bGwgbmFtZSwgeW91ciBhZmZpbGlhdGlvbiwgeW91ciBjaG9pY2U6IDRyZC1VIG9yIE1BUA0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KDQpQbGVhc2UgZmlsbCBv dXQgdGhlIGZvbGxvd2luZyBmb3JtIGFuZCByZXBseSB0byB0aGUgbGlzdA0KYnkgV2VkbmVzZGF5 IDQvMTAgNXBtIEVEVC4NCg0KTm90ZTogVXNlIHRoaXMgdGhyZWFkIE9OTFkgZm9yIGV4cHJlc3Np bmcgeW91ciBzdXBwb3J0IHRvDQpvbmUgT1IgdGhlIG90aGVyLCBhbmQgcmVkaXJlY3QgYW55IGRp c2N1c3Npb25zIHRvIG90aGVyIHRocmVhZHMuDQpUaGF0IHdvdWxkIGhlbHAgdXAgZ2F1Z2UgY29u c2Vuc3VzLg0KDQpBbGFpbiAmIFlvbmcuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw== From clong_liu@hit.edu.cn Mon Apr 9 01:33:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D723B21F8657 for ; Mon, 9 Apr 2012 01:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.647 X-Spam-Level: *** X-Spam-Status: No, score=3.647 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CrAxEbVLCEo for ; Mon, 9 Apr 2012 01:33:41 -0700 (PDT) Received: from hit.edu.cn (unknown [IPv6:2001:da8:ab:253::233]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFC21F8659 for ; Mon, 9 Apr 2012 01:33:38 -0700 (PDT) Received: from clong_liu ( [202.118.243.16] ) by ajax-webmail-app3 (Coremail) ; Mon, 9 Apr 2012 16:33:40 +0800 (CST) Date: Mon, 9 Apr 2012 16:33:40 +0800 (CST) From: To: adurand@juniper.net Message-ID: <1a41b73.11bd.136963cab6c.Coremail.clong_liu@hit.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit X-Originating-IP: [202.118.243.16] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.0.4 build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn hit X-CM-TRANSID: qC2owJCL5DXknoJPgMPJAQ--.55930W X-CM-SenderInfo: xfor0wpbol3qxklwhvlgxou0/1tbiAQAmLkwrJkU6bAAIsT X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Cc: softwires@ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:33:41 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Your full name, your affiliation, your choice: YES or NO ---------------------------------------------------------------------------- changlong liu, Networking Center of Harbin Institute of Technology , YES ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Your full name, your affiliation, your choice: 4rd-U or MAP ------------------------------------------------------------------------------ changlong liu, Networking Center of Harbin Institute of Technology , MAP ===================================================================== Liu ChangLong Harbin Institute of Technology Network and Information Center,china From chengang@zzu.edu.cn Mon Apr 9 01:52:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293121F8625 for ; Mon, 9 Apr 2012 01:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.39 X-Spam-Level: ** X-Spam-Status: No, score=2.39 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gct7zJmMtyab for ; Mon, 9 Apr 2012 01:52:05 -0700 (PDT) Received: from mail.zzu.edu.cn (mx.zzu.cn [202.196.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 016EA21F85C5 for ; Mon, 9 Apr 2012 01:52:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zzu.edu.cn (tmailer) with ESMTP id 803032C6022D; Mon, 9 Apr 2012 16:22:55 +0800 (CST) Received: from mail.zzu.edu.cn ([127.0.0.1]) by localhost (mail3.zzu.edu.cn [127.0.0.1]) (theinterface-new, port 10024) with ESMTP id ImdwZh8bmY51; Mon, 9 Apr 2012 16:22:55 +0800 (CST) Received: from mail1.zzu.edu.cn (unknown [192.168.0.29]) by mail.zzu.edu.cn (tmailer) with ESMTP id F020D2C60222; Mon, 9 Apr 2012 16:22:54 +0800 (CST) Date: Mon, 9 Apr 2012 16:36:44 +0800 (CST) From: =?GBK?B?s8K41Q==?= To: Alain Durand Message-ID: <1780341769.91881.1333960604578.JavaMail.root@mail1.zzu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.0.32] Cc: WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] =?gbk?q?Mailing_list_question_to_gauge_consensus_on_4?= =?gbk?q?rd-U_vs_MAP?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:52:06 -0000 >>From Alain Durand Wrote: >>Dear Softwire wg members: >>At the Paris IETF Softwire meeting, we had presentations on MAP (taken as= a whole) and >>4rd-U. We got very strong feedback that we needed to select one >>solution to cover that full stateless case, not two, and that we should m= ake this >>decision relatively quickly. >>During Paris meeting, we asked the following additional question: >>Do you prefer MAP or 4rd-U? >>We got about 1/3 support for 4rd-U and 2/3 for MAP. >>The real gauge of consensus is the mailing list, so we would like >>to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Chen Gang, Zhengzhou University HERNET NOC : YES ---------------------------------------------------------------------------= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Chen Gang, Zhengzhou University HERNET NOC : MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chen Gang=20 NOC=A3=ACZZU HERNET NOC E-mail:chengang@zzu.edu.cn Phone:86-371-67767135 From moulchan@cisco.com Mon Apr 9 02:06:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39A21F867A for ; Mon, 9 Apr 2012 02:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pmr3oBwXxv9 for ; Mon, 9 Apr 2012 02:06:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50A21F8678 for ; Mon, 9 Apr 2012 02:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=4124; q=dns/txt; s=iport; t=1333962379; x=1335171979; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=YVp7NZzJ/7gOzrcAAESggqSkLNNRRhxF4BAvXH6XU+M=; b=Esoi7u1ioJA8mKS8qJjyMWpCfXAoNeHNa7XcapZCLCAH8IcUZAC6/SWX uyrohG98aIEj6JKEiCRCIzYJ3GhO577KeLZakjntRuX4OWe7hFuwjBzn2 FPcxzrLNXUOxYXyxfay2xTzSS8ZdqSFCLKBAEvJGbAagy2HjPzi6hoHN1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAGmgk+tJXHA/2dsb2JhbABCuT6BB4IJAQEBBAEBAQ8BHQo0CwwEAgEIDgMEAQELBhcBBgEmHwkIAQEEARIIEweHbAufAJENhXBUBIYQiWdjBIham1+BaYMF X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="73081868" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 09 Apr 2012 09:06:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3996Ib9024965; Mon, 9 Apr 2012 09:06:18 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 04:06:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Apr 2012 04:06:14 -0500 Message-ID: In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgDh+u+A References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> From: "Mouli Chandramouli (moulchan)" To: "Alain Durand" , X-OriginalArrivalTime: 09 Apr 2012 09:06:18.0131 (UTC) FILETIME=[062A9E30:01CD1630] Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:06:25 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ------------------------------------------------------------------------ ---- Mouli Chandramouli, Cisco Systems: YES ------------------------------------------------------------------------ ---- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------ ------ Mouli Chandramouli, Cisco Systems: MAP ------------------------------------------------------------------------ ------ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks Mouli =20 -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Alain Durand Sent: Thursday, April 05, 2012 2:44 AM To: softwires@ietf.org WG Cc: int-ads@tools.ietf.org; Softwire Chairs Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a whole) and 4rd-U. We got very strong feedback that we needed to select one solution to cover that full stateless case, not two, and that we should make this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ------------------------------------------------------------------------ ---- Your full name, your affiliation, your choice: YES or NO ------------------------------------------------------------------------ ---- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------ ------ Your full name, your affiliation, your choice: 4rd-U or MAP ------------------------------------------------------------------------ ------ Please fill out the following form and reply to the list by Wednesday 4/10 5pm EDT. Note: Use this thread ONLY for expressing your support to one OR the other, and redirect any discussions to other threads. That would help up gauge consensus. Alain & Yong. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From lawwy800130@hotmail.com Mon Apr 9 02:29:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3DF21F865C for ; Mon, 9 Apr 2012 02:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqGNp815IPLO for ; Mon, 9 Apr 2012 02:29:14 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id D379D21F8659 for ; Mon, 9 Apr 2012 02:29:13 -0700 (PDT) Received: from BLU149-W35 ([65.55.116.73]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 02:29:13 -0700 Message-ID: X-Originating-IP: [202.112.0.117] From: LIWei To: Date: Mon, 9 Apr 2012 17:29:12 +0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Apr 2012 09:29:13.0226 (UTC) FILETIME=[39C976A0:01CD1633] Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:29:14 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track=2C the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------= - Li Wei=2C 21Vianet Group=2C Inc : YES ---------------------------------------------------------------------------= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Li Wei=2C 21Vianet Group=2C Inc : MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Li Wei 21Vianet Group=2C Inc NOC Address: M5=2C 1 Jiuxianqiao East Road=2C Chaoyang District=2C Beijing PRC Post code: 100015 Tel: =A0+86 10 8456 2121=A0 Fax: +86 10 8456 2619 = From fibrib@gmail.com Mon Apr 9 02:38:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354B21F8675 for ; Mon, 9 Apr 2012 02:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWhwk7kNZqHe for ; Mon, 9 Apr 2012 02:38:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 518E921F84F1 for ; Mon, 9 Apr 2012 02:38:37 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2781530qcs.31 for ; Mon, 09 Apr 2012 02:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EmqVjvalX98YZ/EnWhNURVAGm8mkO2oQfKDe26sID+A=; b=xNtrfnUOj10dBkAyNv+B/uAV+cpg71Snk9tXPVE5O/+lxXcS8/RFx0BopjdxC1Vpzj Rfl79vFV5EZ1ixwykzsJRnjCYv6x+xQZLI8v4kZUgl14xjJ8Z1PAmUHq6PXXdP82mP3z pu0T5gzfDTAmcizrb5PvvUwkH6bU/RP/JkNj0hRSu+vcM/GPqv6+ZWwWPqFD1N1HOiU1 VPD1hLloFggZ5i71g3qRozXCsfWz/X7l5wdASdye7GQEPxvQg2TD6ibHPSdaKPUmbaOv CdjjfmVhiVMa07m/SULJ/kRV6ILAhZXZ+UenW+McbnTzRhFX8EO5mZQLamOYxg2Yi/ET ottw== MIME-Version: 1.0 Received: by 10.229.136.130 with SMTP id r2mr2483035qct.58.1333964316731; Mon, 09 Apr 2012 02:38:36 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Mon, 9 Apr 2012 02:38:36 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> Date: Mon, 9 Apr 2012 09:38:36 +0000 Message-ID: From: Maoke To: Sheng Jiang Content-Type: multipart/alternative; boundary=00248c768f923deb5d04bd3bc553 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:38:42 -0000 --00248c768f923deb5d04bd3bc553 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/4/9 Sheng Jiang > Please allow me to clarify myself: I support both MAP and 4rd-u. > > > > MAP has been a good effort with many experts together in IPv4/IPv6 > transition area and has been proved by running code. It also need to > improve itself before being published as a RFC later. This process will > take several months. > > > > Personally, I think 4rd-u is a little bit behind MAP in maturity aspect > for now. But, it is only matter of time. The authors have agreed to remov= e > the architectural conflict, if there was any. We have offered to help on > the improvement by implementation. > > > > Giving time, both solution can be mature enough for operations. IETF does > not have to choose one by now. And, these two solutions are not necessary > to be a same pace. > what if, giving time, people can be mature enough to identify 4rd-U is really a flawed donkorse? ;-) if the 4rd-u designers are so confident, why not do the real coding work first and then propose it as a replacement of MAP suite? i don't see any unfairness here. - maoke > > > Best regards, > > > > Sheng > > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 3:24 PM > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > hi Yiu and others, > > > > 1. "both published" does surely conflict with the design goal of 4rd-U > itself: > > unification of multiple standards. politically speaking, the 4rd-u > authors' > > positition is now quite confusing. > > > > 2. operators surely need to choose IPv6 transition mechanisms but such a > choice > > is based on their demand and understanding to the existing and > well-tested, > > well-practiced building blocks. i don't think any operators are waitin= g > for > > an option of choice they never see and never understand. and the > "enough > > technical supports" is now still "a check without signature". i do > suggest > > the 4rd-u authors and supporters say that after making something real. > > > > on the other hand, 4rd-u makes a tight coupling between the address > format > > and its own header mapping mechanism. this makes an operator unable to > have > > different choices of transition mechanism as long as it chooses 4rd-u. > if > > you concern the choice of IPv6 transition mechanism, i do recommend > MAP, as > > either encapsulation or translation is operatable with MAP address/por= t > > mapping without difficulty. > > > > 3. surely MAP still has room of improvement but i don't think there are > > architectural uncertainty as 4rd-U has. request on more testing data i= s > > surely appreciated but please think it over again if it is a correct > way > > to require further data of a counterpart in order to defense a solutio= n > > without any data. > > > > 4. even there were no MAP at all, current level of 4rd-U is far premature > to be > > talked about any working group acception. > > > > the authors and supporters will be appreciated if they talk about the > acception > > after their coding and testing and refinement on the document according t= o > their > > practical experiences, and understanding the problem again and again. > > > > thanks, > > maoke > > > > 2012/4/9 Sheng Jiang > > > I also followed the discussion. I appreciate both teams bought up the > > technical details for both designs. To be honest, I fail to see which > > one is better than other (yet). I like the fact that 4rd-u can do what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I like > > it not introducing any new requirement to the IPv6 header, but I need > > more published data to determine whether the double-translation would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. > > We would like to see both solution published. So that, operators can > choose according to their own networks and preference. There are enormous > number of operators, who do not come to IETF meeting or do not participat= e > in ML either. They also need to choose IPv6 transition mechanisms. They > should be provided enough technical supports. That's the response of IETF= , > in our understanding. > > > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and that > > >was exactly how they handle the similar situation in their WG. I think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --00248c768f923deb5d04bd3bc553 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2012/4/9 Sheng Jiang &= lt;jiangsheng@huawei.com>

Please allow me to clarif= y myself: I support both MAP and 4rd-u.

=C2=A0

MAP has been a good effor= t with many experts together in IPv4/IPv6 transition area and has been prov= ed by running code. It also need to improve itself before being published as a RFC later. This process will take several months.

=C2=A0

Personally, I think 4rd-u= is a little bit behind MAP in maturity aspect for now. But, it is only mat= ter of time. The authors have agreed to remove the architectural conflict, if there was any. We have offered to help on the improvement by = implementation.

=C2=A0

Giving time, both solutio= n can be mature enough for operations. IETF does not have to choose one by = now. And, these two solutions are not necessary to be a same pace.


what if,= giving time, people can be mature enough to identify 4rd-U is really a fla= wed donkorse? ;-) if the 4rd-u designers are so confident, why not do the r= eal coding work first and then propose it as a replacement of MAP suite? i = don't see any unfairness here. - maoke
=C2=A0

=C2=A0

Best regards,

=C2=A0

Sheng

=C2=A0

From: Maoke [m= ailto:fibrib@gmail.co= m]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org


Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

hi Yiu and others,=C2=A0

=C2=A0

1. "both published" does surely conflict w= ith the design goal of 4rd-U itself:=C2=A0

=C2=A0 =C2=A0unification of multiple standards.=C2= =A0politically speaking, the 4rd-u authors'

=C2=A0 =C2=A0positition is now quite confusing.=C2= =A0

=C2=A0

2. operators surely need to choose IPv6 transition m= echanisms but such a choice=C2=A0

=C2=A0 =C2=A0is based on their demand and understand= ing to the existing and well-tested,=C2=A0

=C2=A0 =C2=A0well-practiced building blocks. i don&#= 39;t think any operators are waiting for=C2=A0

=C2=A0 =C2=A0an option of choice they never see and = never understand. and the "enough=C2=A0

=C2=A0 =C2=A0technical supports" is now still &= quot;a check without signature". i do suggest=C2=A0

=C2=A0 =C2=A0the 4rd-u authors and supporters say th= at after making something real.=C2=A0

=C2=A0

=C2=A0 =C2=A0on the other hand, 4rd-u makes a tight = coupling between the address format=C2=A0

=C2=A0 =C2=A0and its own header mapping mechanism. t= his makes an operator unable to have=C2=A0

=C2=A0 =C2=A0different choices of transition mechani= sm as long as it chooses 4rd-u. if=C2=A0

=C2=A0 =C2=A0you concern the choice of IPv6 transiti= on mechanism, i do recommend MAP, as=C2=A0

=C2=A0 =C2=A0either encapsulation or translation is = operatable with MAP address/port=C2=A0

=C2=A0 =C2=A0mapping without difficulty.=C2=A0

=C2=A0

3. surely MAP still has room of improvement but i do= n't think there are=C2=A0

=C2=A0 =C2=A0architectural uncertainty as 4rd-U has.= request on more testing data is=C2=A0

=C2=A0 =C2=A0surely appreciated but please think it = over again if it is a correct way=C2=A0

=C2=A0 =C2=A0to require further data of a counterpar= t in order to defense a solution=C2=A0

=C2=A0 =C2=A0without any data.=C2=A0

=C2=A0

4. even there were no MAP at all, current level of 4= rd-U is far premature to be=C2=A0

=C2=A0 =C2=A0talked about any working group acceptio= n.

=C2=A0

the authors and supporters will be appreciated if th= ey talk about the acception=C2=A0

after their coding and testing and refinement on the= document according to their=C2=A0

practical experiences, and understanding the problem= again and again.=C2=A0

=C2=A0

thanks,=C2=A0

maoke

=C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

> I also followed = the discussion. I appreciate both teams bought up the
> technical details for both designs. To be honest, I fail to see which<= br> > one is better than other (yet). I like the fact that 4rd-u can do what=
> MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e
> it not introducing any new requirement to the IPv6 header, but I need<= br> > more published data to determine whether the double-translation would<= br> > cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future.

We would like to see both solution published. So tha= t, operators can choose according to their own networks and preference. The= re are enormous number of operators, who do not come to IETF meeting or do = not participate in ML either. They also need to choose IPv6 transition mechanisms. They should be provided en= ough technical supports. That's the response of IETF, in our understand= ing.


> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote= :
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"= ;? Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp an= d
> >lisp WG, suggested we publish both of them as experimental, and th= at
> >was exactly how they handle the similar situation in their WG. I t= hink
> >his suggestion is reasonable to be considered. (To Joel: Pardon me= if
> I
> >improperly quoted your comment, or I just misunderstood your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On =C2=A0Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: s= oftwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 = 4rd-U as
> >>transparent =C2=A0as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 addressi= ng. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> > =C2=A0 =C2=A0 mapping rule per subscriber. in this mode = e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> > =C2=A0 =C2=A0 possible in a translation solution like 4r= d-U.
> >>
> >> This mode of operation was suggested last week during the SD-= NAT
> >> presentation. There seemed to be consensus among operators th= at it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated packe= ts
> >> > different
> >>from
> >> encapsulated ones.
> >> > =C2=A0 =C2=A0 e.g. for the purposes of counting or for a= pplying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> > =C2=A0 =C2=A0 IPv4 datagram and the IPv6 header is avail= able, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are rarely<= br> > >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. Publish b= oth as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
> >> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softw= ires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@= ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

=C2=A0


--00248c768f923deb5d04bd3bc553-- From leo.liubing@huawei.com Mon Apr 9 02:40:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75CB21F867A for ; Mon, 9 Apr 2012 02:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2Ah3X95fzNr for ; Mon, 9 Apr 2012 02:40:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 62C7E21F8675 for ; Mon, 9 Apr 2012 02:40:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET46390; Mon, 09 Apr 2012 05:40:14 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 02:38:02 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 02:38:02 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 17:37:52 +0800 From: "Liubing (Leo)" To: Sheng Jiang , "Jan Zorz @ go6.si" , "softwires@ietf.org" Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: AQHNFARgdrlwXvWelEujVWMXb2t8PZaRgssAgAAZ2QCAAAPyAIAAkV+g Date: Mon, 9 Apr 2012 09:37:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A0383@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <4F8294B4.5030905@go6.si> <5D36713D8A4E7348A7E10DF7437A4B921E48368C@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48368C@SZXEML506-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:40:15 -0000 > > On 4/9/12 8:17 AM, Sheng Jiang wrote: ... > Operators have their own brains. They may listen to vendors, but they do = think > by themselves and make decisions by themselves. Vendors would implement > whatever the operators order. ... +1 I believe most of the time operators understand their own networks much bet= ter than other engineers.=20 Operators come to IETF with some requirements, if there're multiple solutio= ns offered, finally they should make the choice by themselves. "rough consensus and running code" maybe is not sufficient for operators to= have a decision of long-term deployment model, especially the "consensus" = seems not so strong so far. From fibrib@gmail.com Mon Apr 9 02:52:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3821F85CD for ; Mon, 9 Apr 2012 02:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2JhX9HWCG2P for ; Mon, 9 Apr 2012 02:52:13 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82B0D21F8469 for ; Mon, 9 Apr 2012 02:52:13 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2785936qcs.31 for ; Mon, 09 Apr 2012 02:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hmLalv/jz3hBBPOeoYBQzJFFeEkRTW9r0F8I6b+J6o8=; b=bUAELrc4OzOwuOj4L5+Qnh9/4SCEqZyaF6mcE5R6wy0QSqcm06I9JYifJyDt/yQjeC Nf2lW3MnHeMsgunWztKqnZfVYIY/Sl+FNhaGdy/pajXRkD3/CGxDXsSKPZrMin+rfp28 2LIpfw0rw/7jpR/xgaFJj08rizj1M9ES84AjLPZxdJswSEFfigo+8dJR0jXecb0blbxu tx0YceNPzeuAnk6pCg8MaNqjwDVLgBIlcOCZUsX29ZDWaP+3faWAAmwoOj/zmNSE2oaA IgBaXza251cKOPdDyOOj6Dd4Xtn1NIdxQuO+b5ZpllB+3PHGno9l1zZAxt/cAuyum7Tv 7hKw== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr8275176qao.23.1333965132799; Mon, 09 Apr 2012 02:52:12 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Mon, 9 Apr 2012 02:52:12 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> Date: Mon, 9 Apr 2012 09:52:12 +0000 Message-ID: From: Maoke To: Sheng Jiang Content-Type: multipart/alternative; boundary=20cf3074b41ae2207904bd3bf536 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:52:15 -0000 --20cf3074b41ae2207904bd3bf536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/4/9 Sheng Jiang > Without any objection to MAP, we just start to coding 4rd-u and help to > improve it. > fine. we'd love to see it out with good amount of data and good amount of feedback from testing operators. if you invite me to test, i'd love to provide challenging scenarios. ;-) but it doesn't mean we should postpone current process of standardization of MAP, because the result of 4rd-u is still unsure. - maoke > > > Multiple transition mechanisms would co-exist in the world. Neither MAP > nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution. > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 5:39 PM > > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > > > 2012/4/9 Sheng Jiang > > Please allow me to clarify myself: I support both MAP and 4rd-u. > > > > MAP has been a good effort with many experts together in IPv4/IPv6 > transition area and has been proved by running code. It also need to > improve itself before being published as a RFC later. This process will > take several months. > > > > Personally, I think 4rd-u is a little bit behind MAP in maturity aspect > for now. But, it is only matter of time. The authors have agreed to remov= e > the architectural conflict, if there was any. We have offered to help on > the improvement by implementation. > > > > Giving time, both solution can be mature enough for operations. IETF does > not have to choose one by now. And, these two solutions are not necessary > to be a same pace. > > > > what if, giving time, people can be mature enough to identify 4rd-U is > really a flawed donkorse? ;-) if the 4rd-u designers are so confident, wh= y > not do the real coding work first and then propose it as a replacement of > MAP suite? i don't see any unfairness here. - maoke > > > > > > Best regards, > > > > Sheng > > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 3:24 PM > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > > > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > hi Yiu and others, > > > > 1. "both published" does surely conflict with the design goal of 4rd-U > itself: > > unification of multiple standards. politically speaking, the 4rd-u > authors' > > positition is now quite confusing. > > > > 2. operators surely need to choose IPv6 transition mechanisms but such a > choice > > is based on their demand and understanding to the existing and > well-tested, > > well-practiced building blocks. i don't think any operators are waitin= g > for > > an option of choice they never see and never understand. and the > "enough > > technical supports" is now still "a check without signature". i do > suggest > > the 4rd-u authors and supporters say that after making something real. > > > > on the other hand, 4rd-u makes a tight coupling between the address > format > > and its own header mapping mechanism. this makes an operator unable to > have > > different choices of transition mechanism as long as it chooses 4rd-u. > if > > you concern the choice of IPv6 transition mechanism, i do recommend > MAP, as > > either encapsulation or translation is operatable with MAP address/por= t > > mapping without difficulty. > > > > 3. surely MAP still has room of improvement but i don't think there are > > architectural uncertainty as 4rd-U has. request on more testing data i= s > > surely appreciated but please think it over again if it is a correct > way > > to require further data of a counterpart in order to defense a solutio= n > > without any data. > > > > 4. even there were no MAP at all, current level of 4rd-U is far premature > to be > > talked about any working group acception. > > > > the authors and supporters will be appreciated if they talk about the > acception > > after their coding and testing and refinement on the document according t= o > their > > practical experiences, and understanding the problem again and again. > > > > thanks, > > maoke > > > > 2012/4/9 Sheng Jiang > > > I also followed the discussion. I appreciate both teams bought up the > > technical details for both designs. To be honest, I fail to see which > > one is better than other (yet). I like the fact that 4rd-u can do what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I like > > it not introducing any new requirement to the IPv6 header, but I need > > more published data to determine whether the double-translation would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. > > We would like to see both solution published. So that, operators can > choose according to their own networks and preference. There are enormous > number of operators, who do not come to IETF meeting or do not participat= e > in ML either. They also need to choose IPv6 transition mechanisms. They > should be provided enough technical supports. That's the response of IETF= , > in our understanding. > > > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and that > > >was exactly how they handle the similar situation in their WG. I think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > > > --20cf3074b41ae2207904bd3bf536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2012/4/9 Sheng Jiang &= lt;jiangsheng@huawei.com>

Without any objection to = MAP, we just start to coding 4rd-u and help to improve it.


fine. we'd love to see it out wi= th good amount of data and good amount of feedback from testing operators. = if you invite me to test, i'd love to provide challenging scenarios. ;-= ) but it doesn't mean we should postpone current process of standardiza= tion of MAP, because the result of 4rd-u is still unsure. - maoke=C2=A0
=C2=A0

=C2=A0

Multiple transition mecha= nisms would co-exist in the world. Neither MAP nor 4rd-U can replace 6rd an= d DS-Lite. There is no one-suit-all solution.=C2=A0

=C2=A0

From: Maoke [m= ailto:fibrib@gmail.co= m]
Sent: Monday, April 09, 2012 5:39 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

=C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

Please allow me to clarif= y myself: I support both MAP and 4rd-u.

=C2=A0

MAP has been a good effor= t with many experts together in IPv4/IPv6 transition area and has been prov= ed by running code. It also need to improve itself before being published as = a RFC later. This process will take several months.

=C2=A0

Personally, I think 4rd-u= is a little bit behind MAP in maturity aspect for now. But, it is only matter of time. The authors have agreed to remove the architectural confli= ct, if there was any. We have offered to help on the improvement by impleme= ntation.

=C2=A0

Giving time, both solutio= n can be mature enough for operations. IETF does not have to choose one by now. And, these two solutions are not necessary to be a same pace.

=C2=A0

what if, giving time, people can be mature enough to= identify 4rd-U is really a flawed donkorse? ;-) if the 4rd-u designers are= so confident, why not do the real coding work first and then propose it as= a replacement of MAP suite? i don't see any unfairness here. - maoke

=C2=A0

=C2=A0

Best regards,

=C2=A0

Sheng

=C2=A0

From: Maoke [m= ailto:fibrib@gmail.co= m]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org


Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

hi Yiu and others,=C2=A0

=C2=A0

1. "both published" does surely conflict w= ith the design goal of 4rd-U itself:=C2=A0

=C2=A0 =C2=A0unification of multiple standards.=C2= =A0politically speaking, the 4rd-u authors'

=C2=A0 =C2=A0positition is now quite confusing.=C2= =A0

=C2=A0

2. operators surely need to choose IPv6 transition m= echanisms but such a choice=C2=A0

=C2=A0 =C2=A0is based on their demand and understand= ing to the existing and well-tested,=C2=A0

=C2=A0 =C2=A0well-practiced building blocks. i don&#= 39;t think any operators are waiting for=C2=A0

=C2=A0 =C2=A0an option of choice they never see and = never understand. and the "enough=C2=A0

=C2=A0 =C2=A0technical supports" is now still &= quot;a check without signature". i do suggest=C2=A0

=C2=A0 =C2=A0the 4rd-u authors and supporters say th= at after making something real.=C2=A0

=C2=A0

=C2=A0 =C2=A0on the other hand, 4rd-u makes a tight = coupling between the address format=C2=A0

=C2=A0 =C2=A0and its own header mapping mechanism. t= his makes an operator unable to have=C2=A0

=C2=A0 =C2=A0different choices of transition mechani= sm as long as it chooses 4rd-u. if=C2=A0

=C2=A0 =C2=A0you concern the choice of IPv6 transiti= on mechanism, i do recommend MAP, as=C2=A0

=C2=A0 =C2=A0either encapsulation or translation is = operatable with MAP address/port=C2=A0

=C2=A0 =C2=A0mapping without difficulty.=C2=A0

=C2=A0

3. surely MAP still has room of improvement but i do= n't think there are=C2=A0

=C2=A0 =C2=A0architectural uncertainty as 4rd-U has.= request on more testing data is=C2=A0

=C2=A0 =C2=A0surely appreciated but please think it = over again if it is a correct way=C2=A0

=C2=A0 =C2=A0to require further data of a counterpar= t in order to defense a solution=C2=A0

=C2=A0 =C2=A0without any data.=C2=A0

=C2=A0

4. even there were no MAP at all, current level of 4= rd-U is far premature to be=C2=A0

=C2=A0 =C2=A0talked about any working group acceptio= n.

=C2=A0

the authors and supporters will be appreciated if th= ey talk about the acception=C2=A0

after their coding and testing and refinement on the= document according to their=C2=A0

practical experiences, and understanding the problem= again and again.=C2=A0

=C2=A0

thanks,=C2=A0

maoke

=C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

> I also followed = the discussion. I appreciate both teams bought up the
> technical details for both designs. To be honest, I fail to see which<= br> > one is better than other (yet). I like the fact that 4rd-u can do what=
> MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e
> it not introducing any new requirement to the IPv6 header, but I need<= br> > more published data to determine whether the double-translation would<= br> > cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future.

We would like to see both solution published. So tha= t, operators can choose according to their own networks and preference. The= re are enormous number of operators, who do not come to IETF meeting or do not participate in ML either. They also need to choo= se IPv6 transition mechanisms. They should be provided enough technical sup= ports. That's the response of IETF, in our understanding.


> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote= :
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"= ;? Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp an= d
> >lisp WG, suggested we publish both of them as experimental, and th= at
> >was exactly how they handle the similar situation in their WG. I t= hink
> >his suggestion is reasonable to be considered. (To Joel: Pardon me= if
> I
> >improperly quoted your comment, or I just misunderstood your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On =C2=A0Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: s= oftwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 = 4rd-U as
> >>transparent =C2=A0as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 addressi= ng. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> > =C2=A0 =C2=A0 mapping rule per subscriber. in this mode = e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> > =C2=A0 =C2=A0 possible in a translation solution like 4r= d-U.
> >>
> >> This mode of operation was suggested last week during the SD-= NAT
> >> presentation. There seemed to be consensus among operators th= at it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated packe= ts
> >> > different
> >>from
> >> encapsulated ones.
> >> > =C2=A0 =C2=A0 e.g. for the purposes of counting or for a= pplying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> > =C2=A0 =C2=A0 IPv4 datagram and the IPv6 header is avail= able, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are rarely<= br> > >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. Publish b= oth as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
> >> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softw= ires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@= ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

=C2=A0

=C2=A0


--20cf3074b41ae2207904bd3bf536-- From suukee@gmail.com Mon Apr 9 02:53:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556E821F8669 for ; Mon, 9 Apr 2012 02:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqWh5RHHP6df for ; Mon, 9 Apr 2012 02:53:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97F9D21F8658 for ; Mon, 9 Apr 2012 02:53:52 -0700 (PDT) Received: by iazz13 with SMTP id z13so6862062iaz.31 for ; Mon, 09 Apr 2012 02:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nFc9V2rHICs4apVInL/HfsXpZ8v+G+3lcI7qxbFss64=; b=w3Hp4vXIufRtIBPDOWvnPre51cbg83HYC+J3jXtLYaKoX4FV56GwQn9UKckjXDCZ8x IfiACLAij7TDiq1oeNWf+BOXwM+AUxLALgL77iy/oYfDtncXR0rcozNhwoIMyBhZA8hz gjUdhpRVSFPgVi7h5st+8G7SHhyGdVZC4qfNbQG/nCiVt2j6BrMnLDiZCbPEVXD9LSQn cm++RGg/Bg/gVMQ75J/BrUyC2jSjixnir9qa5gtQgdUoUTJKq08+sXH6bHkEmPNgC2LE zrJkHs10Pd+0HVYBPJNvZTTfYwbGXoCnX591humKE55xVqcwSHNeu57X3uV33gj2sSMX ZkBA== MIME-Version: 1.0 Received: by 10.50.219.194 with SMTP id pq2mr4509617igc.18.1333965232288; Mon, 09 Apr 2012 02:53:52 -0700 (PDT) Received: by 10.50.100.134 with HTTP; Mon, 9 Apr 2012 02:53:52 -0700 (PDT) In-Reply-To: <4F82AD27.7020506@cernet.edu.cn> References: <4F82AD27.7020506@cernet.edu.cn> Date: Mon, 9 Apr 2012 17:53:52 +0800 Message-ID: From: "Alex.Sukai" To: adurand@juniper.net Content-Type: multipart/alternative; boundary=14dae93411cdd0355c04bd3bfb99 Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:03:22 -0000 --14dae93411cdd0355c04bd3bfb99 Content-Type: text/plain; charset=ISO-8859-1 Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track,the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Su He, Extreme Networks: YES ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Su He, Extreme Networks: MAP ------------------------------------------------------------------------------ ===================================================================== -- Su He System Engineer Extreme Networks Tel: +86 10 6539 3900 Cell: +86 135 2009 0907 --14dae93411cdd0355c04bd3bfb99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Question 1: Do you agre= e that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard t= rack,the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see= both advance on the standard track.

-------------= ---------------------------------------------------------------

Su He, Extreme Networks:=A0 YES

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questions 2: Whi= ch one do you want to see placed on the Standards Track:
4rd-U or MAP?

-------------------------------= -----------------------------------------------
Su He, Extreme Ne= tworks: MAP
-----------------------------------------------------= -------------------------

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=A0

--
Su He =A0<suhe = at extremenetworks= .com>
System Engineer
Extreme Networks
Tel: +86 10 6539 3900
Cell: +86 1= 35 2009 0907

--14dae93411cdd0355c04bd3bfb99-- From jiangsheng@huawei.com Mon Apr 9 03:03:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5C21F855D for ; Mon, 9 Apr 2012 03:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86PT6mvvSNFg for ; Mon, 9 Apr 2012 03:03:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A56121F852A for ; Mon, 9 Apr 2012 03:03:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET47659; Mon, 09 Apr 2012 06:03:55 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:01:39 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:01:40 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 18:01:32 +0800 From: Sheng Jiang To: "softwires@ietf.org" Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg//+RWQCAAIj4IP//nIAAgACMaeA= Date: Mon, 9 Apr 2012 10:01:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E4837B6@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B921E4837B6SZXEML506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:03:56 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837B6SZXEML506MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aG91dCBhbnkgb2JqZWN0aW9uIHRvIE1BUCwgd2UganVzdCBzdGFydCB0byBjb2RpbmcgNHJk LXUgYW5kIGhlbHAgdG8gaW1wcm92ZSBpdC4NCg0KTXVsdGlwbGUgdHJhbnNpdGlvbiBtZWNoYW5p c21zIHdvdWxkIGNvLWV4aXN0IGluIHRoZSB3b3JsZC4gTmVpdGhlciBNQVAgbm9yIDRyZC1VIGNh biByZXBsYWNlIDZyZCBhbmQgRFMtTGl0ZS4gVGhlcmUgaXMgbm8gb25lLXN1aXQtYWxsIHNvbHV0 aW9uLg0KDQoNCkZyb206IE1hb2tlIFttYWlsdG86ZmlicmliQGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgQXByaWwgMDksIDIwMTIgNTozOSBQTQ0KVG86IFNoZW5nIEppYW5nDQpDYzogTGVlLCBZ aXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0 cmQtVSBhcyB0cmFuc3BhcmVudCBhcyBNQVAtRQ0KDQoNCjIwMTIvNC85IFNoZW5nIEppYW5nIDxq aWFuZ3NoZW5nQGh1YXdlaS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbT4+DQpQbGVh c2UgYWxsb3cgbWUgdG8gY2xhcmlmeSBteXNlbGY6IEkgc3VwcG9ydCBib3RoIE1BUCBhbmQgNHJk LXUuDQoNCk1BUCBoYXMgYmVlbiBhIGdvb2QgZWZmb3J0IHdpdGggbWFueSBleHBlcnRzIHRvZ2V0 aGVyIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIGFyZWEgYW5kIGhhcyBiZWVuIHByb3ZlZCBieSBy dW5uaW5nIGNvZGUuIEl0IGFsc28gbmVlZCB0byBpbXByb3ZlIGl0c2VsZiBiZWZvcmUgYmVpbmcg cHVibGlzaGVkIGFzIGEgUkZDIGxhdGVyLiBUaGlzIHByb2Nlc3Mgd2lsbCB0YWtlIHNldmVyYWwg bW9udGhzLg0KDQpQZXJzb25hbGx5LCBJIHRoaW5rIDRyZC11IGlzIGEgbGl0dGxlIGJpdCBiZWhp bmQgTUFQIGluIG1hdHVyaXR5IGFzcGVjdCBmb3Igbm93LiBCdXQsIGl0IGlzIG9ubHkgbWF0dGVy IG9mIHRpbWUuIFRoZSBhdXRob3JzIGhhdmUgYWdyZWVkIHRvIHJlbW92ZSB0aGUgYXJjaGl0ZWN0 dXJhbCBjb25mbGljdCwgaWYgdGhlcmUgd2FzIGFueS4gV2UgaGF2ZSBvZmZlcmVkIHRvIGhlbHAg b24gdGhlIGltcHJvdmVtZW50IGJ5IGltcGxlbWVudGF0aW9uLg0KDQpHaXZpbmcgdGltZSwgYm90 aCBzb2x1dGlvbiBjYW4gYmUgbWF0dXJlIGVub3VnaCBmb3Igb3BlcmF0aW9ucy4gSUVURiBkb2Vz IG5vdCBoYXZlIHRvIGNob29zZSBvbmUgYnkgbm93LiBBbmQsIHRoZXNlIHR3byBzb2x1dGlvbnMg YXJlIG5vdCBuZWNlc3NhcnkgdG8gYmUgYSBzYW1lIHBhY2UuDQoNCndoYXQgaWYsIGdpdmluZyB0 aW1lLCBwZW9wbGUgY2FuIGJlIG1hdHVyZSBlbm91Z2ggdG8gaWRlbnRpZnkgNHJkLVUgaXMgcmVh bGx5IGEgZmxhd2VkIGRvbmtvcnNlPyA7LSkgaWYgdGhlIDRyZC11IGRlc2lnbmVycyBhcmUgc28g Y29uZmlkZW50LCB3aHkgbm90IGRvIHRoZSByZWFsIGNvZGluZyB3b3JrIGZpcnN0IGFuZCB0aGVu IHByb3Bvc2UgaXQgYXMgYSByZXBsYWNlbWVudCBvZiBNQVAgc3VpdGU/IGkgZG9uJ3Qgc2VlIGFu eSB1bmZhaXJuZXNzIGhlcmUuIC0gbWFva2UNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837B6SZXEML506MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X aXRob3V0IGFueSBvYmplY3Rpb24gdG8gTUFQLCB3ZSBqdXN0IHN0YXJ0IHRvIGNvZGluZyA0cmQt dSBhbmQgaGVscCB0byBpbXByb3ZlIGl0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NdWx0aXBsZSB0cmFuc2l0aW9u IG1lY2hhbmlzbXMgd291bGQgY28tZXhpc3QgaW4gdGhlIHdvcmxkLiBOZWl0aGVyIE1BUCBub3Ig NHJkLVUgY2FuIHJlcGxhY2UgNnJkIGFuZCBEUy1MaXRlLiBUaGVyZSBpcyBubyBvbmUtc3VpdC1h bGwgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW9rZSBbbWFpbHRvOmZpYnJp YkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA1 OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4gTGVlLCBZ aXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3 aXRoIDRyZMWgIDRyZC1VIGFzIHRyYW5zcGFyZW50IGFzIE1BUC1FPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEy LzQvOSBTaGVuZyBKaWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNv bSI+amlhbmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGFsbG93IG1lIHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBv cnQgYm90aCBNQVAgYW5kIDRyZC11Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUCBoYXMgYmVlbiBhIGdvb2Qg ZWZmb3J0IHdpdGggbWFueSBleHBlcnRzIHRvZ2V0aGVyIGluIElQdjQvSVB2NiB0cmFuc2l0aW9u IGFyZWEgYW5kIGhhcyBiZWVuIHByb3ZlZA0KIGJ5IHJ1bm5pbmcgY29kZS4gSXQgYWxzbyBuZWVk IHRvIGltcHJvdmUgaXRzZWxmIGJlZm9yZSBiZWluZyBwdWJsaXNoZWQgYXMgYSBSRkMgbGF0ZXIu IFRoaXMgcHJvY2VzcyB3aWxsIHRha2Ugc2V2ZXJhbCBtb250aHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVy c29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQgYmVoaW5kIE1BUCBpbiBtYXR1 cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LCBpdCBpcyBvbmx5DQogbWF0dGVyIG9mIHRpbWUuIFRo ZSBhdXRob3JzIGhhdmUgYWdyZWVkIHRvIHJlbW92ZSB0aGUgYXJjaGl0ZWN0dXJhbCBjb25mbGlj dCwgaWYgdGhlcmUgd2FzIGFueS4gV2UgaGF2ZSBvZmZlcmVkIHRvIGhlbHAgb24gdGhlIGltcHJv dmVtZW50IGJ5IGltcGxlbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdpdmluZyB0aW1lLCBib3Ro IHNvbHV0aW9uIGNhbiBiZSBtYXR1cmUgZW5vdWdoIGZvciBvcGVyYXRpb25zLiBJRVRGIGRvZXMg bm90IGhhdmUgdG8gY2hvb3NlIG9uZQ0KIGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25z IGFyZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGEgc2FtZSBwYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGF0IGlm LCBnaXZpbmcgdGltZSwgcGVvcGxlIGNhbiBiZSBtYXR1cmUgZW5vdWdoIHRvIGlkZW50aWZ5IDRy ZC1VIGlzIHJlYWxseSBhIGZsYXdlZCBkb25rb3JzZT8gOy0pIGlmIHRoZSA0cmQtdSBkZXNpZ25l cnMgYXJlIHNvIGNvbmZpZGVudCwgd2h5IG5vdCBkbyB0aGUgcmVhbCBjb2Rpbmcgd29yayBmaXJz dCBhbmQgdGhlbiBwcm9wb3NlIGl0IGFzIGEgcmVwbGFjZW1lbnQgb2YgTUFQIHN1aXRlPyBpIGRv bid0DQogc2VlIGFueSB1bmZhaXJuZXNzIGhlcmUuIC0gbWFva2U8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837B6SZXEML506MBSchi_-- From fibrib@gmail.com Mon Apr 9 03:16:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0421F852A for ; Mon, 9 Apr 2012 03:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxO5dnseFMSm for ; Mon, 9 Apr 2012 03:16:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5910F21F8497 for ; Mon, 9 Apr 2012 03:16:33 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2794330qcs.31 for ; Mon, 09 Apr 2012 03:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3CEBH/3EgUAShe5Idp8ByH77wpOa9Ya2ls/zaLP5TWA=; b=QVjFM0AEQWvvSQl5qrlGIpD/siy2MD7Q26DD06UnTQShq2G7OAgpugyMQzIgTyT/KL upYFmo+k1G2zF9uFwgNj8MzaM6zGHIIztccRJjHMA/L25vwhxoXqYBI6CJOt6FckrxLd x2a6o2hf0pbNUmQAqgDAiG2C2F+ZiLqGiRqNPIDvm3yJ+7V2EPUmQSR7DGGhqMgq2ytY On4Wgekm1FIVdjV/kdiZIwI40Jj7UTHTjftF+tJJ0epbeOwU7Rj2LM0zmbHFWPGVsSgm q4fJgUGyy8FgBXum9CmM9fn1TcP1w2oN9CKAmM80rw1NLqKZgM1pUV4Ym2qED4IUvP63 Nj+w== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr8357875qao.23.1333966592891; Mon, 09 Apr 2012 03:16:32 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Mon, 9 Apr 2012 03:16:32 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8@szxeml509-mbs> Date: Mon, 9 Apr 2012 10:16:32 +0000 Message-ID: From: Maoke To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=20cf3074b41ae95b8a04bd3c4cba Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:16:35 -0000 --20cf3074b41ae95b8a04bd3c4cba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/4/9 Liubing (Leo) > >fine. we'd love to see it out with good amount of data and good amount > of feedback from testing operators. > > >if you invite me to test, i'd love to provide challenging scenarios. ;-) > > >but it doesn't mean we should postpone current process of standardizatio= n > of MAP, because the result of 4rd-u is still unsure. - maoke > > > > I=E2=80=99d love to see operators find proper mechanisms respectively acc= ording to > their own situations, rather than some mechanisms **out**. > joke. operators haven't know what the 4rd-u is. operators never make selection on things not belonging to its knowledge. come on, believe me, as an engineer in an operator company, the real operators are more conservative than me. ;-) > > > The transition mechanisms are developed for the operators, but in my > observation, the MAP hasn=E2=80=99t proved sufficiently for operators=E2= =80=99 long-term > selection. So why we have to rush to a **stand track**? > it is only your observation and it is a different question. you may argue that the MAP is not mature enough for the wg acceptance but the wg is doing a consensus decision. on the other hand, as i pointed out, even there is no MAP at all, i don't think 4rd-u now is at the time of talking about wg acceptance. may i suggest, as you have promised that you will code the stuff, to start the coding work as soon as possible. i don't like to make out a testing list but finally see nothing to test. thanks! - maoke > > > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 5:52 PM > > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > > > 2012/4/9 Sheng Jiang > > Without any objection to MAP, we just start to coding 4rd-u and help to > improve it. > > > > fine. we'd love to see it out with good amount of data and good amount of > feedback from testing operators. if you invite me to test, i'd love to > provide challenging scenarios. ;-) but it doesn't mean we should postpone > current process of standardization of MAP, because the result of 4rd-u is > still unsure. - maoke > > > > > > Multiple transition mechanisms would co-exist in the world. Neither MAP > nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution. > > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 5:39 PM > > > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > > > 2012/4/9 Sheng Jiang > > Please allow me to clarify myself: I support both MAP and 4rd-u. > > > > MAP has been a good effort with many experts together in IPv4/IPv6 > transition area and has been proved by running code. It also need to > improve itself before being published as a RFC later. This process will > take several months. > > > > Personally, I think 4rd-u is a little bit behind MAP in maturity aspect > for now. But, it is only matter of time. The authors have agreed to remov= e > the architectural conflict, if there was any. We have offered to help on > the improvement by implementation. > > > > Giving time, both solution can be mature enough for operations. IETF does > not have to choose one by now. And, these two solutions are not necessary > to be a same pace. > > > > what if, giving time, people can be mature enough to identify 4rd-U is > really a flawed donkorse? ;-) if the 4rd-u designers are so confident, wh= y > not do the real coding work first and then propose it as a replacement of > MAP suite? i don't see any unfairness here. - maoke > > > > > > Best regards, > > > > Sheng > > > > *From:* Maoke [mailto:fibrib@gmail.com] > *Sent:* Monday, April 09, 2012 3:24 PM > *To:* Sheng Jiang > *Cc:* Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > > > *Subject:* Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as > transparent as MAP-E > > > > hi Yiu and others, > > > > 1. "both published" does surely conflict with the design goal of 4rd-U > itself: > > unification of multiple standards. politically speaking, the 4rd-u > authors' > > positition is now quite confusing. > > > > 2. operators surely need to choose IPv6 transition mechanisms but such a > choice > > is based on their demand and understanding to the existing and > well-tested, > > well-practiced building blocks. i don't think any operators are waitin= g > for > > an option of choice they never see and never understand. and the > "enough > > technical supports" is now still "a check without signature". i do > suggest > > the 4rd-u authors and supporters say that after making something real. > > > > on the other hand, 4rd-u makes a tight coupling between the address > format > > and its own header mapping mechanism. this makes an operator unable to > have > > different choices of transition mechanism as long as it chooses 4rd-u. > if > > you concern the choice of IPv6 transition mechanism, i do recommend > MAP, as > > either encapsulation or translation is operatable with MAP address/por= t > > mapping without difficulty. > > > > 3. surely MAP still has room of improvement but i don't think there are > > architectural uncertainty as 4rd-U has. request on more testing data i= s > > surely appreciated but please think it over again if it is a correct > way > > to require further data of a counterpart in order to defense a solutio= n > > without any data. > > > > 4. even there were no MAP at all, current level of 4rd-U is far premature > to be > > talked about any working group acception. > > > > the authors and supporters will be appreciated if they talk about the > acception > > after their coding and testing and refinement on the document according t= o > their > > practical experiences, and understanding the problem again and again. > > > > thanks, > > maoke > > > > 2012/4/9 Sheng Jiang > > > I also followed the discussion. I appreciate both teams bought up the > > technical details for both designs. To be honest, I fail to see which > > one is better than other (yet). I like the fact that 4rd-u can do what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I like > > it not introducing any new requirement to the IPv6 header, but I need > > more published data to determine whether the double-translation would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. > > We would like to see both solution published. So that, operators can > choose according to their own networks and preference. There are enormous > number of operators, who do not come to IETF meeting or do not participat= e > in ML either. They also need to choose IPv6 transition mechanisms. They > should be provided enough technical supports. That's the response of IETF= , > in our understanding. > > > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and that > > >was exactly how they handle the similar situation in their WG. I think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > > > > > --20cf3074b41ae95b8a04bd3c4cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2012/4/9 Liubing (Leo) <leo.liubing@huawei.com&g= t;

>fine. we'd love to see = it out with good amount of data and good amount of feedback from testing op= erators.

>if you invite me to test, i= 'd love to provide challenging scenarios. ;-)

>but it doesn't mean we = should postpone current process of standardization of MAP, because the resu= lt of 4rd-u is still unsure. - maoke=C2=A0

=C2=A0

I=E2= =80=99d love to see operators find proper mechanisms respectively according= to their own situations, rather than some mechanisms *out*.<= /p>


joke. operators haven't kn= ow what the 4rd-u is. operators never make selection on things not belongin= g to its knowledge. come on, believe me, as an engineer in an operator comp= any, the real operators are more conservative than me. ;-)=C2=A0
=C2=A0

=C2=A0

The transi= tion mechanisms are developed for the operators, but in my observation, the= MAP hasn=E2=80=99t =C2=A0proved sufficiently for operators=E2=80=99 long-t= erm selection. So why we have to rush to a *stand track*?


it is only your observation and i= t is a different question. you may argue that the MAP is not mature enough = for the wg acceptance but the wg is doing a consensus decision.

on the other hand, as i pointed out, even there is no M= AP at all, i don't think 4rd-u now is at the time of talking about wg a= cceptance.=C2=A0

may i suggest, as you have promis= ed that you will code the stuff, to start the coding work as soon as possib= le. i don't like to make out a testing list but finally see nothing to = test. thanks!=C2=A0

- maoke=C2=A0
=C2=A0

=C2=A0

=C2=A0

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 5:52 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

= =C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com<= /a>>

Without an= y objection to MAP, we just start to coding 4rd-u and help to improve it.

=C2=A0

fine. we'd love to see it o= ut with good amount of data and good amount of feedback from testing operat= ors. if you invite me to test, i'd love to provide challenging scenario= s. ;-) but it doesn't mean we should postpone current process of standardization of MAP, because the result of 4rd-u is = still unsure. - maoke=C2=A0

=C2=A0

=C2=A0

Multiple t= ransition mechanisms would co-exist in the world. Neither MAP nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution.=C2=A0

=C2=A0

From: Maoke [mailto:fibrib@gmail= .com]
Sent: Monday, April 09, 2012 5:39 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

= =C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com<= /a>>

Please all= ow me to clarify myself: I support both MAP and 4rd-u.

=C2=A0

MAP has be= en a good effort with many experts together in IPv4/IPv6 transition area an= d has been proved by running code. It also need to improve itself before bei= ng published as a RFC later. This process will take several months.<= /p>

=C2=A0

Personally= , I think 4rd-u is a little bit behind MAP in maturity aspect for now. But, it is only matter of time. The authors have agreed to remove the architect= ural conflict, if there was any. We have offered to help on the improvement= by implementation.

=C2=A0

Giving tim= e, both solution can be mature enough for operations. IETF does not have to choose one by now. And, these two solutions are not necessary to be a same= pace.

=C2=A0

what if, giving time, people ca= n be mature enough to identify 4rd-U is really a flawed donkorse? ;-) if th= e 4rd-u designers are so confident, why not do the real coding work first and then propose it as a replacement of MAP suite? i don= 't see any unfairness here. - maoke

=C2=A0

=C2=A0

Best regar= ds,

=C2=A0

Sheng

=C2=A0

From: Maoke [mailto:fibrib@gmail= .com]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org


Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

=C2=A0

hi Yiu and others,=C2=A0=

=C2=A0

1. "both published" d= oes surely conflict with the design goal of 4rd-U itself:=C2=A0

=C2=A0 =C2=A0unification of mul= tiple standards.=C2=A0politically speaking, the 4rd-u authors'

=C2=A0 =C2=A0positition is now = quite confusing.=C2=A0

=C2=A0

2. operators surely need to cho= ose IPv6 transition mechanisms but such a choice=C2=A0

=C2=A0 =C2=A0is based on their = demand and understanding to the existing and well-tested,=C2=A0

=C2=A0 =C2=A0well-practiced bui= lding blocks. i don't think any operators are waiting for=C2=A0<= /p>

=C2=A0 =C2=A0an option of choic= e they never see and never understand. and the "enough=C2=A0

=C2=A0 =C2=A0technical supports= " is now still "a check without signature". i do suggest=C2= =A0

=C2=A0 =C2=A0the 4rd-u authors = and supporters say that after making something real.=C2=A0

=C2=A0

=C2=A0 =C2=A0on the other hand,= 4rd-u makes a tight coupling between the address format=C2=A0

=C2=A0 =C2=A0and its own header= mapping mechanism. this makes an operator unable to have=C2=A0

=C2=A0 =C2=A0different choices = of transition mechanism as long as it chooses 4rd-u. if=C2=A0

=C2=A0 =C2=A0you concern the ch= oice of IPv6 transition mechanism, i do recommend MAP, as=C2=A0

=C2=A0 =C2=A0either encapsulati= on or translation is operatable with MAP address/port=C2=A0

=C2=A0 =C2=A0mapping without di= fficulty.=C2=A0

=C2=A0

3. surely MAP still has room of= improvement but i don't think there are=C2=A0

=C2=A0 =C2=A0architectural unce= rtainty as 4rd-U has. request on more testing data is=C2=A0

=C2=A0 =C2=A0surely appreciated= but please think it over again if it is a correct way=C2=A0

=C2=A0 =C2=A0to require further= data of a counterpart in order to defense a solution=C2=A0

=C2=A0 =C2=A0without any data.= =C2=A0

=C2=A0

4. even there were no MAP at al= l, current level of 4rd-U is far premature to be=C2=A0

=C2=A0 =C2=A0talked about any w= orking group acception.

=C2=A0

the authors and supporters will= be appreciated if they talk about the acception=C2=A0

after their coding and testing = and refinement on the document according to their=C2=A0

practical experiences, and unde= rstanding the problem again and again.=C2=A0

=C2=A0

thanks,=C2=A0

maoke

=C2=A0

2012/4/9 Sheng Jiang <jiangsheng@huawei.com<= /a>>

= > I also followed the discussion. I appreciate both teams bought up the<= br> > technical details for both designs. To be honest, I fail to see which<= br> > one is better than other (yet). I like the fact that 4rd-u can do what=
> MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e
> it not introducing any new requirement to the IPv6 header, but I need<= br> > more published data to determine whether the double-translation would<= br> > cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future.

We would like to see both solut= ion published. So that, operators can choose according to their own network= s and preference. There are enormous number of operators, who do not come to IETF meeting or do not participate in ML either. They a= lso need to choose IPv6 transition mechanisms. They should be provided enou= gh technical supports. That's the response of IETF, in our understandin= g.


> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote= :
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"= ;? Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp an= d
> >lisp WG, suggested we publish both of them as experimental, and th= at
> >was exactly how they handle the similar situation in their WG. I t= hink
> >his suggestion is reasonable to be considered. (To Joel: Pardon me= if
> I
> >improperly quoted your comment, or I just misunderstood your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On =C2=A0Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: s= oftwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 = 4rd-U as
> >>transparent =C2=A0as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 addressi= ng. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> > =C2=A0 =C2=A0 mapping rule per subscriber. in this mode = e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> > =C2=A0 =C2=A0 possible in a translation solution like 4r= d-U.
> >>
> >> This mode of operation was suggested last week during the SD-= NAT
> >> presentation. There seemed to be consensus among operators th= at it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated packe= ts
> >> > different
> >>from
> >> encapsulated ones.
> >> > =C2=A0 =C2=A0 e.g. for the purposes of counting or for a= pplying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> > =C2=A0 =C2=A0 IPv4 datagram and the IPv6 header is avail= able, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are rarely<= br> > >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. Publish b= oth as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
> >> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softw= ires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@= ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

=C2=A0

=C2=A0

=C2=A0


--20cf3074b41ae95b8a04bd3c4cba-- From jan@go6.si Mon Apr 9 03:36:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A40C21F84B3 for ; Mon, 9 Apr 2012 03:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVRpCE+ozCST for ; Mon, 9 Apr 2012 03:36:33 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1373921F84AA for ; Mon, 9 Apr 2012 03:36:33 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 2E14522B4069; Mon, 9 Apr 2012 12:36:30 +0200 (CEST) Message-ID: <4F82BBBA.6020200@go6.si> Date: Mon, 09 Apr 2012 12:36:42 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <4F8294B4.5030905@go6.si> <5D36713D8A4E7348A7E10DF7437A4B921E48368C@SZXEML506-MBS.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45292A0383@szxeml509-mbs> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45292A0383@szxeml509-mbs> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:36:33 -0000 On 4/9/12 11:37 AM, Liubing (Leo) wrote: >>> On 4/9/12 8:17 AM, Sheng Jiang wrote: > ... >> Operators have their own brains. They may listen to vendors, but >> they do think by themselves and make decisions by themselves. >> Vendors would implement whatever the operators order. > ... > > +1 I believe most of the time operators understand their own networks > much better than other engineers. Operators come to IETF with some > requirements, if there're multiple solutions offered, finally they > should make the choice by themselves. > > "rough consensus and running code" maybe is not sufficient for > operators to have a decision of long-term deployment model, > especially the "consensus" seems not so strong so far. This probably means the vendors fight for customers, each deploying different not compatible solutions and CPE vendors will have to deploy all of them in order to be able to sell to different operators. Vendors did it in the past and it looks like we did not learn. I understand that VendorX would like to lock his customers to his solution, but that's a trap. A walled garden. I buy solutionX from VendorX and can't change it in the future, because my CPE base is locked to solutionX. Can we please do it properly this time? Cheers, Jan From jan@go6.si Mon Apr 9 03:38:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCF921F8663 for ; Mon, 9 Apr 2012 03:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7aprx-XrKpg for ; Mon, 9 Apr 2012 03:38:54 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE62321F84F7 for ; Mon, 9 Apr 2012 03:38:53 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 1360E22B4069 for ; Mon, 9 Apr 2012 12:38:52 +0200 (CEST) Message-ID: <4F82BC48.1070003@go6.si> Date: Mon, 09 Apr 2012 12:39:04 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E4837B6@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E4837B6@SZXEML506-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:38:54 -0000 On 4/9/12 12:01 PM, Sheng Jiang wrote: > Without any objection to MAP, we just start to coding 4rd-u and help to > improve it. > > Multiple transition mechanisms would co-exist in the world. Neither MAP > nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution. MAP or 4RD cannot replace 6RD, because the goal is different. But they were specifically done to replace DS-Lite and all CGN derivatives (and I hope we are not too late for that). Cheers, Jan From moreiras@nic.br Mon Apr 9 04:00:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6061721F86A2 for ; Mon, 9 Apr 2012 04:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia8f1qH0-yrs for ; Mon, 9 Apr 2012 04:00:05 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F321F869E for ; Mon, 9 Apr 2012 04:00:04 -0700 (PDT) Received: from minerva-2.local (unknown [189.78.115.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 59364208013F for ; Mon, 9 Apr 2012 08:00:02 -0300 (BRT) Message-ID: <4F82C131.4000309@nic.br> Date: Mon, 09 Apr 2012 08:00:01 -0300 From: "Antonio M. Moreiras" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 11:00:05 -0000 Em 09/04/12 04:56, Sheng Jiang escreveu: > Giving time, both solution can be mature enough for operations. IETF > does not have to choose one by now. And, these two solutions are not > necessary to be a same pace. IMHO the problem is that we don't have time. We have to consider that some ISPs are already committing themselves with NAT444, or other CGNs, for the transition. A transition based on A+P could be a better choice, but we have to have a real option to do that in a very short time. I think that it is the time to focus on one solution. If the decision is further delayed, it could be useless, because operators will have followed other paths, without even considering A+P. It seems to me that there is no more time to decide upon the ideal solution. We have to go with a choice already tested, with running code, proven to be good enough and workable, and it happens to be MAP. The perfect is the enemy of the good. Moreiras. From youda.ke@gmail.com Mon Apr 9 04:14:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948FF21F86B5 for ; Mon, 9 Apr 2012 04:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDHWUxqES0Fj for ; Mon, 9 Apr 2012 04:14:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 087CA21F869F for ; Mon, 9 Apr 2012 04:14:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2577896vbb.31 for ; Mon, 09 Apr 2012 04:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ClzOq5fK+1x//GT2QtuxBU+DPeDgg8F1eH1dDlxeUa4=; b=HonuWbwRgTgyVoP2cWeHWU0l0ZsQcxaACRXM3RoELo1YVk34/4NNAgy2ucl3QwRJEg EtJP6vTy3TCzbkuwugqAqimxEYSGH4Ot2HxxO9mArFgbPajvu3PfLAIB2gNrgxjGflBJ 7djDiLLQCF58ph5XKj6N+iKZLTg0VgN+xaE4ELr7c7fBICzRs2Lbm1QtjAfO0S822XV9 QLBwlBjGME1D+zChnnBYNhXOmBlfE06xfBSkDgFH6eNAviefGVWwpZ4w9p7M6CPSNQhX ppRnTnRA1DzVt1y7ZDXA2tsPnFPX2WcN2txB4HvxuSd/GUJBoIMCaGhyPg5H7qEj6NCA 4KmA== MIME-Version: 1.0 Received: by 10.220.108.10 with SMTP id d10mr3419118vcp.16.1333970070466; Mon, 09 Apr 2012 04:14:30 -0700 (PDT) Received: by 10.220.159.139 with HTTP; Mon, 9 Apr 2012 04:14:30 -0700 (PDT) In-Reply-To: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Mon, 9 Apr 2012 19:14:30 +0800 Message-ID: From: Xuejiao LI To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 11:14:31 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Xuejiao LI, Shenyang Unicom, YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Xuejiao LI, Shenyang Unicom, MAP -- Xujiao LI Shenyang Unicom From leo.liubing@huawei.com Mon Apr 9 05:02:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4921F86CE for ; Mon, 9 Apr 2012 05:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExDfQQJMlDql for ; Mon, 9 Apr 2012 05:02:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAD8C21F86CB for ; Mon, 9 Apr 2012 05:02:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET53454; Mon, 09 Apr 2012 08:02:55 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:00:46 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:00:48 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 20:00:36 +0800 From: "Liubing (Leo)" To: Maoke Thread-Index: Ac0WSFn0CdFflvAASfKNuJ8CHsM41A== Date: Mon, 9 Apr 2012 12:00:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A043A@szxeml509-mbs> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Acyo CeHN KUxh NKX/ PCCv U+K9 bfZS gBK8 gj4F kR08 l/xA tZP+ uRo1 vxLT 01nb 1Wi4; 4; ZgBpAGIAcgBpAGIAQABnAG0AYQBpAGwALgBjAG8AbQA7AHMAaQBtAG8AbgAuAHAAZQByAHIAZQBhAHUAbAB0AEAAdgBpAGEAZwBlAG4AaQBlAC4AYwBhADsAcwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcAOwB5AGkAdQBfAGwAZQBlAEAAYwBhAGIAbABlAC4AYwBvAG0AYwBhAHMAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {D9A20DA2-1BA5-4EE7-AFE8-712809AFCB00}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 09 Apr 2012 12:00:26 GMT;; x-cr-puzzleid: {D9A20DA2-1BA5-4EE7-AFE8-712809AFCB00} x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: [Softwires] (no subject) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:02:56 -0000 2012/4/9 Liubing (Leo) >>>fine. we'd love to see it out with good amount of data and good amount o= f feedback from testing operators.=20 >>>if you invite me to test, i'd love to provide challenging scenarios. ;-)= =20 >>>but it doesn't mean we should postpone current process of standardizatio= n of MAP, because the result of 4rd-u is still unsure. - maoke=20 =20 >>I'd love to see operators find proper mechanisms respectively according t= o their own situations, rather than some mechanisms *out*. >joke. operators haven't know what the 4rd-u is. operators never make selec= tion on things not belonging to its knowledge. come on, believe me, as an e= ngineer in an operator company, the real operators are more conservative th= an me. ;-)=20 =20 [Bing] Are you assuming the voters voted for MAP without knowing what the 4= rd-u is? I do believe 4rd-u is not as popular as MAP, but please don't make= the arbitrary assumption, especially from you who knows 4rd-u clearly. Just because the real operators are more conservative, so that maybe they d= on't want to rush to a standard track. =20 >>The transition mechanisms are developed for the operators, but in my obse= rvation, the MAP hasn't proved sufficiently for operators' >> long-term selection. So why we have to rush to a *stand track*? >it is only your observation and it is a different question. you may argue = that the MAP is not mature enough for the wg acceptance but the > wg is doing a consensus decision.=20 [Bing]Maybe MAP is ready for a RFC, but it doesn't mean it is ready for lon= g-term operators' selection. What I argued is that , let's do not hurry to = have only one standard track right now as we want to make the choice instea= d of the operators. >on the other hand, as i pointed out, even there is no MAP at all, i don't = think 4rd-u now is at the time of talking about wg acceptance.=20 >may i suggest, as you have promised that you will code the stuff, to start= the coding work as soon as possible. > i don't like to make out a testing list but finally see nothing to test. = thanks!=20 [Bing] You may mixed me with Sheng. Sorry for interrupting into your thread= without informing that. But regardless of 4rd-u coding&testing, MAP itself= also needs more sufficient test and improvement. - maoke=20 =20 From leo.liubing@huawei.com Mon Apr 9 05:38:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5198121F85AF for ; Mon, 9 Apr 2012 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKO8ru1knl4 for ; Mon, 9 Apr 2012 05:38:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E58D21F84F7 for ; Mon, 9 Apr 2012 05:38:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB54495; Mon, 09 Apr 2012 08:38:19 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:36:50 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:36:49 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 20:36:31 +0800 From: "Liubing (Leo)" To: "Jan Zorz @ go6.si" Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: AQHNFARgdrlwXvWelEujVWMXb2t8PZaRgssAgAAZ2QCAAAPyAIAAkV+g//+ZNACAAJ+MsA== Date: Mon, 9 Apr 2012 12:36:30 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A0468@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <4F8294B4.5030905@go6.si> <5D36713D8A4E7348A7E10DF7437A4B921E48368C@SZXEML506-MBS.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45292A0383@szxeml509-mbs> <4F82BBBA.6020200@go6.si> In-Reply-To: <4F82BBBA.6020200@go6.si> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:38:20 -0000 > -----Original Message----- > From: Jan Zorz @ go6.si [mailto:jan@go6.si] > Sent: Monday, April 09, 2012 6:37 PM > To: Liubing (Leo) > Cc: Sheng Jiang; softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-U as transp= arent > as MAP-E >=20 > On 4/9/12 11:37 AM, Liubing (Leo) wrote: > >>> On 4/9/12 8:17 AM, Sheng Jiang wrote: > > ... > >> Operators have their own brains. They may listen to vendors, but > >> they do think by themselves and make decisions by themselves. > >> Vendors would implement whatever the operators order. > > ... > > > > +1 I believe most of the time operators understand their own networks > > much better than other engineers. Operators come to IETF with some > > requirements, if there're multiple solutions offered, finally they > > should make the choice by themselves. > > > > "rough consensus and running code" maybe is not sufficient for > > operators to have a decision of long-term deployment model, > > especially the "consensus" seems not so strong so far. >=20 > This probably means the vendors fight for customers, each deploying > different not compatible solutions and CPE vendors will have to deploy > all of them in order to be able to sell to different operators. >=20 > Vendors did it in the past and it looks like we did not learn. [Bing] If operators' networks have different requirements, I guess we'll ha= ve to implement different CPEs. I think the networks' requirements should b= e the higher priority. I'm not a CPE expert, but as I learned, customized CPE is normal in current= networks, is it a big problem? > I understand that VendorX would like to lock his customers to his > solution, but that's a trap. A walled garden. I buy solutionX from > VendorX and can't change it in the future, because my CPE base is locked > to solutionX. >=20 [Bing] That's true, but it's not the situation of what we are discussing. I= n fact, if we hurry to make a choice right now, it is just like to be locke= d in one solution. We should open the choices to the operators, let them de= cide. > Can we please do it properly this time? >=20 > Cheers, Jan >=20 From leo.liubing@huawei.com Mon Apr 9 05:41:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE4E21F86F2 for ; Mon, 9 Apr 2012 05:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNM11C53wa9s for ; Mon, 9 Apr 2012 05:41:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0228B21F86F1 for ; Mon, 9 Apr 2012 05:41:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB54695; Mon, 09 Apr 2012 08:41:02 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:38:53 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 05:38:54 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 20:38:49 +0800 From: "Liubing (Leo)" To: "softwires@ietf.org" Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: Ac0WSFn0drlwXvWelEujVWMXb2t8PQABRtCg Date: Mon, 9 Apr 2012 12:38:49 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A0477@szxeml509-mbs> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:41:06 -0000 Sorry, I forgot to fill the title in the last mail, just forward it again. -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Liubing (Leo) Sent: Monday, April 09, 2012 8:01 PM To: Maoke Cc: softwires@ietf.org Subject: [Softwires] (no subject) 2012/4/9 Liubing (Leo) >>>fine. we'd love to see it out with good amount of data and good amount o= f feedback from testing operators.=20 >>>if you invite me to test, i'd love to provide challenging scenarios. ;-)= =20 >>>but it doesn't mean we should postpone current process of standardizatio= n of MAP, because the result of 4rd-u is still unsure. - maoke=20 =20 >>I'd love to see operators find proper mechanisms respectively according t= o their own situations, rather than some mechanisms *out*. >joke. operators haven't know what the 4rd-u is. operators never make selec= tion on things not belonging to its knowledge. come on, believe me, as an e= ngineer in an operator company, the real operators are more conservative th= an me. ;-)=20 =20 [Bing] Are you assuming the voters voted for MAP without knowing what the 4= rd-u is? I do believe 4rd-u is not as popular as MAP, but please don't make= the arbitrary assumption, especially from you who knows 4rd-u clearly. Just because the real operators are more conservative, so that maybe they d= on't want to rush to a standard track. =20 >>The transition mechanisms are developed for the operators, but in my obse= rvation, the MAP hasn't proved sufficiently for operators' >> long-term selection. So why we have to rush to a *stand track*? >it is only your observation and it is a different question. you may argue = that the MAP is not mature enough for the wg acceptance but the > wg is doing a consensus decision.=20 [Bing]Maybe MAP is ready for a RFC, but it doesn't mean it is ready for lon= g-term operators' selection. What I argued is that , let's do not hurry to = have only one standard track right now as we want to make the choice instea= d of the operators. >on the other hand, as i pointed out, even there is no MAP at all, i don't = think 4rd-u now is at the time of talking about wg acceptance.=20 >may i suggest, as you have promised that you will code the stuff, to start= the coding work as soon as possible. > i don't like to make out a testing list but finally see nothing to test. = thanks!=20 [Bing] You may mixed me with Sheng. Sorry for interrupting into your thread= without informing that. But regardless of 4rd-u coding&testing, MAP itself= also needs more sufficient test and improvement. - maoke=20 =20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From adurand@juniper.net Mon Apr 9 07:45:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA221F8749 for ; Mon, 9 Apr 2012 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deD1wTRmaX4s for ; Mon, 9 Apr 2012 07:45:41 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id A209521F873D for ; Mon, 9 Apr 2012 07:45:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT4L2E+3brOmwdSJ5iNvSLNP5TiZrUqgA@postini.com; Mon, 09 Apr 2012 07:45:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 9 Apr 2012 07:45:33 -0700 From: Alain Durand To: Maoke Date: Mon, 9 Apr 2012 07:45:31 -0700 Thread-Topic: =?Windows-1252?Q?[Softwires]=09Path_to_move_forward_with_4rd=8A_4rd-U_as_?= =?Windows-1252?Q?transparent_as_MAP-E?= Thread-Index: Ac0WX2qVTJLrkaSwSa6GlECGSd2Q/g== Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Haberman Brian , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:45:42 -0000 Makoe, The usage of disparaging language does not benefit the clarity of the discu= ssion. I understand that english may or may not be your primary language, nor is i= t for the majority of the wg members. I encourage everybody to remain civil in this discourse. As about implementation, they are a required element in the IETF standard p= rocess when we move from Proposed Standard to Draft Standard. I know that the routing area has experimented with requiring implementation= for Proposed Standard, but I'm not aware of any such requirement in the Internet Area. Alain. On Apr 9, 2012, at 5:38 AM, Maoke wrote: what if, giving time, people can be mature enough to identify 4rd-U is real= ly a flawed donkorse? ;-) if the 4rd-u designers are so confident, why not = do the real coding work first and then propose it as a replacement of MAP s= uite? i don't see any unfairness here. - maoke From fibrib@gmail.com Mon Apr 9 09:07:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40021F870F for ; Mon, 9 Apr 2012 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5fNg-rQrnt0 for ; Mon, 9 Apr 2012 09:07:22 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F20721F86B1 for ; Mon, 9 Apr 2012 09:07:18 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3001356qcs.31 for ; Mon, 09 Apr 2012 09:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TliOZcGcy6+5zRGizkp+OcOyXYMoWS4Mfyrchdhci10=; b=Ecq1171qad93MP0ei7CQHbvSZ8RjcmwynEVadQjYp+t60bm7FtURfXxVYEdEmAPynb BcAIiqheHJOtaRpJ0BFt3BXVRkb33/qfXbbN2ulx96um+Spm7gF8kn/4NayI4Q3IDKt7 CAp9X7ENKBYwgVueTn1Q6/9P0dlVI7dYPcHeJO2ygs9vvIOIzsQSRYB/waz7d06HoZu2 lrIhPPYGUIcOciKmxdIuAwKGDzAi/pseAlMC4ByLmEQkOIeauxwSEK8utyijonR987YS UekmkPKX9Q7fpgoNMCTpbAcdcgvgiU/w5zCKzYvrhSs436L8IHgGmEolHoQsDDkQ9fyK R/Ww== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr9964520qab.49.1333987637558; Mon, 09 Apr 2012 09:07:17 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Mon, 9 Apr 2012 09:07:17 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> Date: Tue, 10 Apr 2012 01:07:17 +0900 Message-ID: From: Maoke To: Alain Durand Content-Type: multipart/alternative; boundary=485b397dcfc9457d8b04bd413309 Cc: Softwires WG , Haberman Brian , Ralph Droms Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:07:24 -0000 --485b397dcfc9457d8b04bd413309 Content-Type: text/plain; charset=ISO-8859-1 dear Alain, thanks a lot for the message. i apologize for the language disparaging that i used in the above discussion. please Sheng and Bing accept my apology. what i am meaning is unchanged: i'm willing to contribute testing scenarios if people think they are useful for problem understanding and/or protocol improvement. sincerely, maoke 2012/4/9 Alain Durand > Makoe, > > The usage of disparaging language does not benefit the clarity of the > discussion. > I understand that english may or may not be your primary language, nor is > it for the majority of the wg members. > > I encourage everybody to remain civil in this discourse. > > As about implementation, they are a required element in the IETF standard > process when we move from Proposed Standard to Draft Standard. > I know that the routing area has experimented with requiring > implementation for Proposed Standard, but I'm not aware of any such > requirement > in the Internet Area. > > Alain. > > > On Apr 9, 2012, at 5:38 AM, Maoke wrote: > > what if, giving time, people can be mature enough to identify 4rd-U is > really a flawed donkorse? ;-) if the 4rd-u designers are so confident, why > not do the real coding work first and then propose it as a replacement of > MAP suite? i don't see any unfairness here. - maoke > > --485b397dcfc9457d8b04bd413309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Alain,
=A0
thanks a lot for the message. i a= pologize for the language disparaging that i used in the above discussion. = please Sheng and Bing accept my apology.
=A0
what i am= meaning is unchanged: i'm willing to contribute testing scenarios if p= eople think they are useful for problem understanding and/or protocol impro= vement.
=A0
sincerely,
maoke
=A0
2012/4/9 Alain Durand <adurand@juniper.net>
Makoe,

The usage of disparaging language does not benefit the clarity of the discu= ssion.
I understand that english may or may not be your primary language, nor is i= t for the majority of the wg members.

I encourage everybody to remain civil in this discourse.

As about implementation, they are a required element in the IETF standard p= rocess when we move from Proposed Standard to Draft Standard.
I know that the routing area has experimented with requiring implementation= for Proposed Standard, but I'm not aware of any such requirement
in the Internet Area.

Alain.


On Apr 9, 2012, at 5:38 AM, Maoke wrote:

what if, giving time, people can be mature enough to identify 4rd-U is real= ly a flawed donkorse? ;-) if the 4rd-u designers are so confident, why not = do the real coding work first and then propose it as a replacement of MAP s= uite? i don't see any unfairness here. - maoke


--485b397dcfc9457d8b04bd413309-- From despres.remi@laposte.net Mon Apr 9 10:39:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B89D21F87A3 for ; Mon, 9 Apr 2012 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyEJP6XfuWF8 for ; Mon, 9 Apr 2012 10:39:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0973021F878A for ; Mon, 9 Apr 2012 10:39:25 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id vtfH1i00D37Y3f403tfHYq; Mon, 09 Apr 2012 19:39:18 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-38--796328226 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 9 Apr 2012 19:39:17 +0200 Message-Id: <280E9652-580E-4FA9-82BC-E3336B682651@laposte.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8@szxeml509-mbs> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:39:29 -0000 --Apple-Mail-38--796328226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-04-09 =E0 12:16, Maoke a =E9crit : >=20 >=20 > 2012/4/9 Liubing (Leo) > >fine. we'd love to see it out with good amount of data and good = amount of feedback from testing operators. >=20 > >if you invite me to test, i'd love to provide challenging scenarios. = ;-) >=20 > >but it doesn't mean we should postpone current process of = standardization of MAP, because the result of 4rd-u is still unsure. - = maoke=20 >=20 > =20 > I=92d love to see operators find proper mechanisms respectively = according to their own situations, rather than some mechanisms *out*. >=20 >=20 > joke. operators haven't know what the 4rd-u is. This is disparaging for operator engineers who took the time to read the = specification (not to speak about those who co-autrhored the = specification!). > operators never make selection on things not belonging to its = knowledge. come on, believe me, as an engineer in an operator company, = the real operators are more conservative than me. ;-)=20 > =20 > =20 > The transition mechanisms are developed for the operators, but in my = observation, the MAP hasn=92t proved sufficiently for operators=92 = long-term selection. So why we have to rush to a *stand track*? >=20 >=20 > it is only your observation and it is a different question. > you may argue that the MAP is not mature enough for the wg acceptance = but the wg is doing a consensus decision. Precisely, and people who attended MAP and 4rd presentations couldn't = reach consensus. > on the other hand, as i pointed out, > even there is no MAP at all, i don't think 4rd-u now is at the time of = talking about wg acceptance.=20 WKG acceptance of 4rd as experimental isn't a long term commitment. > may i suggest, as you have promised that you will code the stuff, to = start the coding work as soon as possible. i don't like to make out a = testing list but finally see nothing to test. thanks!=20 Could you please at least describe, without waiting for anything else, = the worst challenging scenario you have in mind? This is a way to make progress. Thanks, RD >=20 > - maoke=20 > =20 > =20 > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 5:52 PM >=20 >=20 > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E > =20 > =20 > 2012/4/9 Sheng Jiang >=20 > Without any objection to MAP, we just start to coding 4rd-u and help = to improve it. >=20 > =20 > fine. we'd love to see it out with good amount of data and good amount = of feedback from testing operators. if you invite me to test, i'd love = to provide challenging scenarios. ;-) but it doesn't mean we should = postpone current process of standardization of MAP, because the result = of 4rd-u is still unsure. - maoke=20 >=20 > =20 > =20 > Multiple transition mechanisms would co-exist in the world. Neither = MAP nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all = solution.=20 >=20 > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 5:39 PM >=20 >=20 > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E >=20 > =20 > =20 > 2012/4/9 Sheng Jiang >=20 > Please allow me to clarify myself: I support both MAP and 4rd-u. >=20 > =20 > MAP has been a good effort with many experts together in IPv4/IPv6 = transition area and has been proved by running code. It also need to = improve itself before being published as a RFC later. This process will = take several months. >=20 > =20 > Personally, I think 4rd-u is a little bit behind MAP in maturity = aspect for now. But, it is only matter of time. The authors have agreed = to remove the architectural conflict, if there was any. We have offered = to help on the improvement by implementation. >=20 > =20 > Giving time, both solution can be mature enough for operations. IETF = does not have to choose one by now. And, these two solutions are not = necessary to be a same pace. >=20 > =20 > what if, giving time, people can be mature enough to identify 4rd-U is = really a flawed donkorse? ;-) if the 4rd-u designers are so confident, = why not do the real coding work first and then propose it as a = replacement of MAP suite? i don't see any unfairness here. - maoke >=20 > =20 > =20 > Best regards, >=20 > =20 > Sheng >=20 > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 3:24 PM > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org >=20 >=20 > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E >=20 > =20 > hi Yiu and others,=20 >=20 > =20 > 1. "both published" does surely conflict with the design goal of 4rd-U = itself:=20 >=20 > unification of multiple standards. politically speaking, the 4rd-u = authors' >=20 > positition is now quite confusing.=20 >=20 > =20 > 2. operators surely need to choose IPv6 transition mechanisms but such = a choice=20 >=20 > is based on their demand and understanding to the existing and = well-tested,=20 >=20 > well-practiced building blocks. i don't think any operators are = waiting for=20 >=20 > an option of choice they never see and never understand. and the = "enough=20 >=20 > technical supports" is now still "a check without signature". i do = suggest=20 >=20 > the 4rd-u authors and supporters say that after making something = real.=20 >=20 > =20 > on the other hand, 4rd-u makes a tight coupling between the address = format=20 >=20 > and its own header mapping mechanism. this makes an operator unable = to have=20 >=20 > different choices of transition mechanism as long as it chooses = 4rd-u. if=20 >=20 > you concern the choice of IPv6 transition mechanism, i do recommend = MAP, as=20 >=20 > either encapsulation or translation is operatable with MAP = address/port=20 >=20 > mapping without difficulty.=20 >=20 > =20 > 3. surely MAP still has room of improvement but i don't think there = are=20 >=20 > architectural uncertainty as 4rd-U has. request on more testing = data is=20 >=20 > surely appreciated but please think it over again if it is a = correct way=20 >=20 > to require further data of a counterpart in order to defense a = solution=20 >=20 > without any data.=20 >=20 > =20 > 4. even there were no MAP at all, current level of 4rd-U is far = premature to be=20 >=20 > talked about any working group acception. >=20 > =20 > the authors and supporters will be appreciated if they talk about the = acception=20 >=20 > after their coding and testing and refinement on the document = according to their=20 >=20 > practical experiences, and understanding the problem again and again.=20= >=20 > =20 > thanks,=20 >=20 > maoke >=20 > =20 > 2012/4/9 Sheng Jiang >=20 > > I also followed the discussion. I appreciate both teams bought up = the > > technical details for both designs. To be honest, I fail to see = which > > one is better than other (yet). I like the fact that 4rd-u can do = what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I = like > > it not introducing any new requirement to the IPv6 header, but I = need > > more published data to determine whether the double-translation = would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. >=20 > We would like to see both solution published. So that, operators can = choose according to their own networks and preference. There are = enormous number of operators, who do not come to IETF meeting or do not = participate in ML either. They also need to choose IPv6 transition = mechanisms. They should be provided enough technical supports. That's = the response of IETF, in our understanding. >=20 >=20 > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP = also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both = as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and = that > > >was exactly how they handle the similar situation in their WG. I = think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me = if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=F8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports = could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that = it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and = different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both = as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> = http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > =20 > =20 > =20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-38--796328226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


2012/4/9 Liubing (Leo) <leo.liubing@huawei.com>

>fine. we'd love to see it out with good amount of = data and good amount of feedback from testing operators.

>if you invite = me to test, i'd love to provide challenging scenarios. ;-)

>but it = doesn't mean we should postpone current process of standardization of = MAP, because the result of 4rd-u is still unsure. - = maoke 

 

I=92d love to see operators find proper mechanisms = respectively according to their own situations, rather than some = mechanisms *out*.


joke. operators haven't = know what the 4rd-u is.

This = is disparaging for operator engineers who took the time to read the = specification (not to speak about those who co-autrhored the = specification!).


operators never make selection on things not = belonging to its knowledge. come on, believe me, as an engineer in an = operator company, the real operators are more conservative than me. = ;-) 
 
 

The transition mechanisms are developed for the = operators, but in my observation, the MAP hasn=92t  proved = sufficiently for operators=92 long-term selection. So why we have to rush to a *stand = track*?


it is = only your observation and it is a different question. =

you may argue that the MAP is not mature = enough for the wg acceptance but the wg is doing a consensus decision. =

Precisely, and people who = attended MAP and 4rd presentations couldn't reach = consensus.

on the other hand, as i pointed out, =

even there is no MAP at all, i don't think = 4rd-u now is at the time of talking about wg = acceptance. 

WKG acceptance = of 4rd as experimental isn't a long term = commitment.

may i suggest, as you have promised that you = will code the stuff, to start the coding work as soon as possible. i = don't like to make out a testing list but finally see nothing to test. = thanks! 

Could you = please at least describe, without waiting for anything else, the = worst challenging scenario you have in mind?
This is a way to = make = progress.

Thanks,
RD



- maoke 
 
 
 

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 5:52 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as transparent as MAP-E
 
 

2012/4/9 Sheng Jiang = <jiangsheng@huawei.com>

Without any objection to MAP, we just start to = coding 4rd-u and help to improve it.

 

fine. we'd love to see = it out with good amount of data and good amount of feedback from testing = operators. if you invite me to test, i'd love to provide challenging = scenarios. ;-) but it doesn't mean we should postpone current process of standardization of MAP, because the result of 4rd-u = is still unsure. - maoke 

 
 

Multiple transition mechanisms would co-exist in = the world. Neither MAP nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution. 

 

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 5:39 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as transparent as MAP-E

 
 

2012/4/9 Sheng Jiang = <jiangsheng@huawei.com>

Please allow me to clarify myself: I support both = MAP and 4rd-u.

 

MAP has been a good effort with many experts = together in IPv4/IPv6 transition area and has been proved by running code. It also need to improve itself before = being published as a RFC later. This process will take several = months.

 

Personally, I think 4rd-u is a little bit behind = MAP in maturity aspect for now. But, it is only matter of time. The authors have agreed to remove the = architectural conflict, if there was any. We have offered to help on the = improvement by implementation.

 

Giving time, both solution can be mature enough = for operations. IETF does not have to choose one by now. And, these two solutions are not necessary to be a = same pace.

 

what if, giving time, = people can be mature enough to identify 4rd-U is really a flawed = donkorse? ;-) if the 4rd-u designers are so confident, why not do the = real coding work first and then propose it as a replacement of MAP suite? i = don't see any unfairness here. - maoke

 
 

Best regards,

 

Sheng

 

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org


Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as transparent as MAP-E

 

hi Yiu and = others, 

 

1. "both published" = does surely conflict with the design goal of 4rd-U = itself: 

  =  unification of multiple standards. politically speaking, the = 4rd-u authors'

   positition = is now quite confusing. 

 

2. operators surely = need to choose IPv6 transition mechanisms but such a = choice 

   is based = on their demand and understanding to the existing and = well-tested, 

  =  well-practiced building blocks. i don't think any operators are = waiting for 

   an option = of choice they never see and never understand. and the = "enough 

   technical = supports" is now still "a check without signature". i do = suggest 

   the 4rd-u = authors and supporters say that after making something = real. 

 

   on the = other hand, 4rd-u makes a tight coupling between the address = format 

   and its = own header mapping mechanism. this makes an operator unable to = have 

   different = choices of transition mechanism as long as it chooses 4rd-u. = if 

   you = concern the choice of IPv6 transition mechanism, i do recommend MAP, = as 

   either = encapsulation or translation is operatable with MAP = address/port 

   mapping = without difficulty. 

 

3. surely MAP still has = room of improvement but i don't think there are 

  =  architectural uncertainty as 4rd-U has. request on more testing = data is 

   surely = appreciated but please think it over again if it is a correct = way 

   to require = further data of a counterpart in order to defense a = solution 

   without = any data. 

 

4. even there were no = MAP at all, current level of 4rd-U is far premature to = be 

   talked = about any working group acception.

 

the authors and = supporters will be appreciated if they talk about the = acception 

after their coding and = testing and refinement on the document according to = their 

practical experiences, = and understanding the problem again and again. 

 

thanks, 

maoke

 

2012/4/9 Sheng Jiang = <jiangsheng@huawei.com>

> I also followed the discussion. I appreciate both = teams bought up the
> technical details for both designs. To be honest, I fail to see = which
> one is better than other (yet). I like the fact that 4rd-u can do = what
> MAP-T does w/o introducing any encap overhead. But I understand = the
> concerns others brought up in the ML such as V-octet. For MAP-T, I = like
> it not introducing any new requirement to the IPv6 header, but I = need
> more published data to determine whether the double-translation = would
> cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as = what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, = this
> technology will stay for long time. I do not want to rush to make = a
> decision and come back to regret in future.

We would like to see = both solution published. So that, operators can choose according to = their own networks and preference. There are enormous number of = operators, who do not come to IETF meeting or do not participate in ML either. = They also need to choose IPv6 transition mechanisms. They should be = provided enough technical supports. That's the response of IETF, in our = understanding.


> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"? = Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let = the
> >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp = and
> >lisp WG, suggested we publish both of them as experimental, and = that
> >was exactly how they handle the similar situation in their WG. = I think
> >his suggestion is reasonable to be considered. (To Joel: Pardon = me if
> I
> >improperly quoted your comment, or I just misunderstood = your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On  Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: softwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=8A = 4rd-U as
> >>transparent  as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=F8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 = addressing. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> >     mapping rule per subscriber. in this = mode e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> >     possible in a translation solution like = 4rd-U.
> >>
> >> This mode of operation was suggested last week during the = SD-NAT
> >> presentation. There seemed to be consensus among operators = that it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated = packets
> >> > different
> >>from
> >> encapsulated ones.
> >> >     e.g. for the purposes of counting or = for applying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> >     IPv4 datagram and the IPv6 header is = available, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are = rarely
> >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. = Publish both as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source        --> = http://ecdysis.viagenie.ca
> >> STUN/TURN server             =   --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

 
 
 

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail-38--796328226-- From despres.remi@laposte.net Mon Apr 9 10:40:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A26B21F87BF for ; Mon, 9 Apr 2012 10:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2tPXUx92+cb for ; Mon, 9 Apr 2012 10:40:19 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38521F878A for ; Mon, 9 Apr 2012 10:40:18 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id vtfH1i00D37Y3f403tgHiz; Mon, 09 Apr 2012 19:40:18 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-39--796267735 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 9 Apr 2012 19:40:17 +0200 Message-Id: <0FEE0192-65C0-4B17-BD8E-B2CE33870ECC@laposte.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A_4rd?= =?windows-1252?q?-U_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:40:21 -0000 --Apple-Mail-39--796267735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 2012-04-09 11:52, Maoke: > 2012/4/9 Sheng Jiang > Without any objection to MAP, we just start to coding 4rd-u and help = to improve it. >=20 >=20 > fine. we'd love to see it out with good amount of data and good amount = of feedback from testing operators. > if you invite me to test, i'd love to provide challenging scenarios. Providing such challenging scenarios to the WG will be welcome. That's a way to make progress. Thanks, > ;-) but it doesn't mean we should postpone current process of = standardization of MAP, Publishing MAP and 4rd as experimental doesn't slow down publication of = specifications, on the contrary. It just expresses that work in Softwire has made very serious progress, = but isn't finished yet. =20 > because the result of 4rd-u is still unsure. ... MAP-T+E is unsure too, with its unfinished specification, and = without report on tested scenarios. Besides, each of T and E (which until recently were well understood as = TWO proposed standards) has sure limitations that are, as you know, = avoided by design with 4rd-U.=20 Regards, RD > - maoke=20 > =20 >=20 > =20 > Multiple transition mechanisms would co-exist in the world. Neither = MAP nor 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all = solution.=20 >=20 > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 5:39 PM >=20 >=20 > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E > =20 > =20 > 2012/4/9 Sheng Jiang >=20 > Please allow me to clarify myself: I support both MAP and 4rd-u. >=20 > =20 > MAP has been a good effort with many experts together in IPv4/IPv6 = transition area and has been proved by running code. It also need to = improve itself before being published as a RFC later. This process will = take several months. >=20 > =20 > Personally, I think 4rd-u is a little bit behind MAP in maturity = aspect for now. But, it is only matter of time. The authors have agreed = to remove the architectural conflict, if there was any. We have offered = to help on the improvement by implementation. >=20 > =20 > Giving time, both solution can be mature enough for operations. IETF = does not have to choose one by now. And, these two solutions are not = necessary to be a same pace. >=20 > =20 > what if, giving time, people can be mature enough to identify 4rd-U is = really a flawed donkorse? ;-) if the 4rd-u designers are so confident, = why not do the real coding work first and then propose it as a = replacement of MAP suite? i don't see any unfairness here. - maoke >=20 > =20 > =20 > Best regards, >=20 > =20 > Sheng >=20 > =20 > From: Maoke [mailto:fibrib@gmail.com]=20 > Sent: Monday, April 09, 2012 3:24 PM > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org >=20 >=20 > Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U as = transparent as MAP-E >=20 > =20 > hi Yiu and others,=20 >=20 > =20 > 1. "both published" does surely conflict with the design goal of 4rd-U = itself:=20 >=20 > unification of multiple standards. politically speaking, the 4rd-u = authors' >=20 > positition is now quite confusing.=20 >=20 > =20 > 2. operators surely need to choose IPv6 transition mechanisms but such = a choice=20 >=20 > is based on their demand and understanding to the existing and = well-tested,=20 >=20 > well-practiced building blocks. i don't think any operators are = waiting for=20 >=20 > an option of choice they never see and never understand. and the = "enough=20 >=20 > technical supports" is now still "a check without signature". i do = suggest=20 >=20 > the 4rd-u authors and supporters say that after making something = real.=20 >=20 > =20 > on the other hand, 4rd-u makes a tight coupling between the address = format=20 >=20 > and its own header mapping mechanism. this makes an operator unable = to have=20 >=20 > different choices of transition mechanism as long as it chooses = 4rd-u. if=20 >=20 > you concern the choice of IPv6 transition mechanism, i do recommend = MAP, as=20 >=20 > either encapsulation or translation is operatable with MAP = address/port=20 >=20 > mapping without difficulty.=20 >=20 > =20 > 3. surely MAP still has room of improvement but i don't think there = are=20 >=20 > architectural uncertainty as 4rd-U has. request on more testing = data is=20 >=20 > surely appreciated but please think it over again if it is a = correct way=20 >=20 > to require further data of a counterpart in order to defense a = solution=20 >=20 > without any data.=20 >=20 > =20 > 4. even there were no MAP at all, current level of 4rd-U is far = premature to be=20 >=20 > talked about any working group acception. >=20 > =20 > the authors and supporters will be appreciated if they talk about the = acception=20 >=20 > after their coding and testing and refinement on the document = according to their=20 >=20 > practical experiences, and understanding the problem again and again.=20= >=20 > =20 > thanks,=20 >=20 > maoke >=20 > =20 > 2012/4/9 Sheng Jiang >=20 > > I also followed the discussion. I appreciate both teams bought up = the > > technical details for both designs. To be honest, I fail to see = which > > one is better than other (yet). I like the fact that 4rd-u can do = what > > MAP-T does w/o introducing any encap overhead. But I understand the > > concerns others brought up in the ML such as V-octet. For MAP-T, I = like > > it not introducing any new requirement to the IPv6 header, but I = need > > more published data to determine whether the double-translation = would > > cause any transparent issue or not. For example: I would very > > appreciate if somebody who trial MAP can publish data such as what > > applications they have tested, what pass and what fail. > > > > This piece of work is very important because once we select it, this > > technology will stay for long time. I do not want to rush to make a > > decision and come back to regret in future. >=20 > We would like to see both solution published. So that, operators can = choose according to their own networks and preference. There are = enormous number of operators, who do not come to IETF meeting or do not = participate in ML either. They also need to choose IPv6 transition = mechanisms. They should be provided enough technical supports. That's = the response of IETF, in our understanding. >=20 >=20 > > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: > > > > >+1 > > > > > >I've read the endless discussion, and found that is seems the MAP = also > > >has not fully convinced the ISP operation guys. > > >Since there's explicit controversy, why not just publish them both = as > > >experimental. why we must chose one as a "standard track"? Being a > > >standard track can eliminate operators' misgiving? > > > > > >If the technology is really appropriate, I don't think the > > "experimental" > > >status would be a issue for the operators to adopt. Just let the > > >operator decide by themselves. > > > > > >I remembered in the meeting venue, Joel Halpern who chairs Karp and > > >lisp WG, suggested we publish both of them as experimental, and = that > > >was exactly how they handle the similar situation in their WG. I = think > > >his suggestion is reasonable to be considered. (To Joel: Pardon me = if > > I > > >improperly quoted your comment, or I just misunderstood your > > suggestion > > >). > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] > > >>On Behalf Of Simon Perreault > > >> Sent: Tuesday, April 03, 2012 8:16 PM > > >> To: softwires@ietf.org > > >> Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as > > >>transparent as MAP-E > > >> > > >> On 2012-04-03 05:40, Ole Tr=F8an wrote: > > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by > > >> > using > > >>hub > > >> and spoke mode with a separate > > >> > mapping rule per subscriber. in this mode e.g only ports = could > > >> > be > > >> embedded in the address. this is not > > >> > possible in a translation solution like 4rd-U. > > >> > > >> This mode of operation was suggested last week during the SD-NAT > > >> presentation. There seemed to be consensus among operators that = it > > >> was not practically feasible. > > >> > > >> > 2) a node inside the network will treat translated packets > > >> > different > > >>from > > >> encapsulated ones. > > >> > e.g. for the purposes of counting or for applying features. > > for > > >> > an > > >> encapsulated packet both the complete > > >> > IPv4 datagram and the IPv6 header is available, and = different > > >>features > > >> can be applied to both. > > >> > > >> In practice, the contents of encapsulated packets are rarely > > >> inspected by firewalls and other such devices. > > >> > > >> > > >> IMHO at this point we should let the market decide. Publish both = as > > >> experimental. Let's work on something else now. > > >> > > >> Simon > > >> -- > > >> DTN made easy, lean, and smart --> = http://postellation.viagenie.ca > > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > >> STUN/TURN server --> http://numb.viagenie.ca > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > =20 > =20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-39--796267735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
2012/4/9 Sheng Jiang <jiangsheng@huawei.com>=

Without any objection to MAP, we just start to = coding 4rd-u and help to improve it.


fine. we'd love to see it out = with good amount of data and good amount of feedback from testing = operators.


if you invite me to test, = i'd love to provide challenging = scenarios.

Providing such = challenging scenarios to the WG will be welcome.
That's a way = to make progress.
Thanks,


;-) but it doesn't mean = we should postpone current process of standardization of = MAP,

Publishing MAP and 4rd as = experimental doesn't slow down publication of specifications, on the = contrary.
It just expresses that work in Softwire has made = very serious progress, but isn't finished = yet.
  
because the result of 4rd-u is still unsure. =

... MAP-T+E is unsure too, = with its unfinished specification, and without report on tested = scenarios.

Besides, each of T and E =  (which until recently were well understood as TWO proposed = standards) has sure limitations that are, as you know, avoided = by design with = 4rd-U. 

Regards,
RD

=


- maoke 
 

 

Multiple transition mechanisms would co-exist in = the world. Neither MAP nor 4rd-U can replace 6rd and DS-Lite. There is = no one-suit-all solution. 

 

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 5:39 PM


To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as transparent as MAP-E
 
 

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

Please allow me to clarify myself: I support both = MAP and 4rd-u.

 

MAP has been a good effort with many experts = together in IPv4/IPv6 transition area and has been proved by running code. It also need to improve itself before being published = as a RFC later. This process will take several = months.

 

Personally, I think 4rd-u is a little bit behind = MAP in maturity aspect for now. But, it is only matter of time. The authors have agreed to remove the architectural = conflict, if there was any. We have offered to help on the improvement = by implementation.

 

Giving time, both solution can be mature enough = for operations. IETF does not have to choose one by now. And, these two solutions are not necessary to be a same = pace.

 

what if, giving time, people can be mature = enough to identify 4rd-U is really a flawed donkorse? ;-) if the 4rd-u = designers are so confident, why not do the real coding work first and = then propose it as a replacement of MAP suite? i don't see any unfairness here. - maoke

 
 

Best regards,

 

Sheng

 

From: Maoke [mailto:fibrib@gmail.com]
Sent: Monday, April 09, 2012 3:24 PM
To: Sheng Jiang
Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; softwires@ietf.org


Subject: Re: [Softwires] Path to move forward with 4rd=8A 4rd-U = as transparent as MAP-E

 

hi Yiu and others, 

 

1. "both published" does surely conflict = with the design goal of 4rd-U itself: 

   unification of multiple = standards. politically speaking, the 4rd-u authors'

   positition is now quite = confusing. 

 

2. operators surely need to choose IPv6 = transition mechanisms but such a choice 

   is based on their demand and = understanding to the existing and well-tested, 

   well-practiced building blocks. = i don't think any operators are waiting for 

   an option of choice they never = see and never understand. and the "enough 

   technical supports" is now = still "a check without signature". i do suggest 

   the 4rd-u authors and = supporters say that after making something real. 

 

   on the other hand, 4rd-u makes = a tight coupling between the address format 

   and its own header mapping = mechanism. this makes an operator unable to have 

   different choices of transition = mechanism as long as it chooses 4rd-u. if 

   you concern the choice of IPv6 = transition mechanism, i do recommend MAP, as 

   either encapsulation or = translation is operatable with MAP address/port 

   mapping without = difficulty. 

 

3. surely MAP still has room of improvement = but i don't think there are 

   architectural uncertainty as = 4rd-U has. request on more testing data is 

   surely appreciated but please = think it over again if it is a correct way 

   to require further data of a = counterpart in order to defense a solution 

   without any data. 

 

4. even there were no MAP at all, current = level of 4rd-U is far premature to be 

   talked about any working group = acception.

 

the authors and supporters will be = appreciated if they talk about the acception 

after their coding and testing and = refinement on the document according to their 

practical experiences, and understanding the = problem again and again. 

 

thanks, 

maoke

 

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

> I also = followed the discussion. I appreciate both teams bought up the
> technical details for both designs. To be honest, I fail to see = which
> one is better than other (yet). I like the fact that 4rd-u can do = what
> MAP-T does w/o introducing any encap overhead. But I understand = the
> concerns others brought up in the ML such as V-octet. For MAP-T, I = like
> it not introducing any new requirement to the IPv6 header, but I = need
> more published data to determine whether the double-translation = would
> cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as = what
> applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, = this
> technology will stay for long time. I do not want to rush to make = a
> decision and come back to regret in future.

We would like to see both solution = published. So that, operators can choose according to their own networks = and preference. There are enormous number of operators, who do not come to IETF meeting or do not participate in ML either. They also need to = choose IPv6 transition mechanisms. They should be provided enough = technical supports. That's the response of IETF, in our = understanding.


> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the = MAP also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them = both as
> >experimental. why we must chose one as a "standard track"? = Being a
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let = the
> >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp = and
> >lisp WG, suggested we publish both of them as experimental, and = that
> >was exactly how they handle the similar situation in their WG. = I think
> >his suggestion is reasonable to be considered. (To Joel: Pardon = me if
> I
> >improperly quoted your comment, or I just misunderstood = your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]
> >>On  Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: softwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=8A = 4rd-U as
> >>transparent  as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=F8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 = addressing. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> >     mapping rule per subscriber. in this = mode e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> >     possible in a translation solution like = 4rd-U.
> >>
> >> This mode of operation was suggested last week during the = SD-NAT
> >> presentation. There seemed to be consensus among operators = that it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated = packets
> >> > different
> >>from
> >> encapsulated ones.
> >> >     e.g. for the purposes of counting or = for applying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> >     IPv4 datagram and the IPv6 header is = available, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are = rarely
> >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. = Publish both as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source        --> = http://ecdysis.viagenie.ca
> >> STUN/TURN server             =   --> http://numb.viagenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

 
 

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-39--796267735-- From ecordeiro@nic.br Mon Apr 9 12:11:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3B21F8716 for ; Mon, 9 Apr 2012 12:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpwTefIwwNG9 for ; Mon, 9 Apr 2012 12:11:35 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 75FEC21F8720 for ; Mon, 9 Apr 2012 12:11:35 -0700 (PDT) Received: from [IPv6:2001:12ff:0:5::107] (unknown [IPv6:2001:12ff:0:5::107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 796EC208013A; Mon, 9 Apr 2012 16:11:34 -0300 (BRT) Message-ID: <4F833466.8030104@nic.br> Date: Mon, 09 Apr 2012 16:11:34 -0300 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alain Durand References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:11:36 -0000 > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > > ---------------------------------------------------------------------------- > Edwin Santos Cordeiro, NIC.br: YES > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Edwin Santos Cordeiro, NIC.br: MAP > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From adurand@juniper.net Mon Apr 9 13:24:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DE21F87DA for ; Mon, 9 Apr 2012 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAhS3uAjE1Mw for ; Mon, 9 Apr 2012 13:24:35 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3129D21F87AD for ; Mon, 9 Apr 2012 13:24:30 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT4NFfcQPb8/aiSGcA8oN1NXOBTBUwqO9@postini.com; Mon, 09 Apr 2012 13:24:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 9 Apr 2012 13:24:18 -0700 From: Alain Durand To: "softwires@ietf.org WG" Date: Mon, 9 Apr 2012 13:24:17 -0700 Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Wjr0zi/crtN0YQS2V+JU6ZTyAGA== Message-ID: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:24:36 -0000 Dear Softwire wg, The consensus call is closing in a few days.=20 The two questions being asked are the same ones that were asked during the = meeting in Paris. Those questions may or may not be perfect, you may or may not like them, bu= t they are the tool we have to gauge consensus (or lack thereof) on the mailing list. So, If you have not yet expressed your opinion answeri= ng both questions, now is the time to do it. In IETF tradition, silence is consent. Alain, Softwires wg co-chair On Apr 4, 2012, at 5:14 PM, Alain Durand wrote: > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as= a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should m= ake this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as = standard track. > Answering NO to this question means you want to see both advance on the s= tandard track. >=20 > -------------------------------------------------------------------------= --- > Your full name, your affiliation, your choice: YES or NO > -------------------------------------------------------------------------= --- >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? >=20 > -------------------------------------------------------------------------= ----- > Your full name, your affiliation, your choice: 4rd-U or MAP > -------------------------------------------------------------------------= ----- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Mon Apr 9 15:22:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FFF21F87FE for ; Mon, 9 Apr 2012 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.99 X-Spam-Level: X-Spam-Status: No, score=-99.99 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydvsDoGtvMBS for ; Mon, 9 Apr 2012 15:22:08 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id EA54521F87F7 for ; Mon, 9 Apr 2012 15:22:07 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12719760; Mon, 09 Apr 2012 16:09:03 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 18:22:00 -0400 From: "Lee, Yiu" To: Congxiao Bao Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFp8umegIVyosXkqwNU9whO/hDg== Date: Mon, 9 Apr 2012 22:21:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416840516_9205624" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:22:09 -0000 --B_3416840516_9205624 Content-type: multipart/alternative; boundary="B_3416840513_9257707" --B_3416840513_9257707 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Congxiao, Thanks for sharing with us some of the tests MAP has been tested. Could you please share some test cases and data to the team? This is the way to clear our doubts.=20 Thanks, Yiu From: Congxiao Bao Date: Mon, 9 Apr 2012 13:41:06 +0800 To: "Yiu L. LEE" Cc: "Liubing (Leo)" , Simon Perreault , "softwires@ietf.org" Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as transparent as MAP-E Hi, =20 MAP-T has been tested in CERNET2 and we have tested applications such as http, telnet, ssh=EF=BC=8Cftp, icmp echo request/reply, qq, skype, msn, video (f= or example: youku.com , xunlei.com , etc) without any problem. =20 Congxiao =20 --B_3416840513_9257707 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Congxiao,

<= /div>
Thanks for sharing with us some of the tests MAP has been tested. = Could you please share some test cases and data to the team? This is the way= to clear our doubts. 

Thanks,
Yiu

From: Congxiao Bao &l= t;cx.cernet@gmail.com>
Date: Mon, 9 Apr 2012 13:41:06 +0800
To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Cc: "Liubing (Leo)" <leo.liubing@huawei.com>, Simon Perreault <simon.perreault@viagenie.ca>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U a= s transparent as MAP-E

Hi,
 
MAP-T has been tested in CERNET2 and we have tested= applications such as http, telnet, ssh=EF=BC=8Cftp, icmp echo request/reply, qq, = skype, msn,  video (for example:&nb= sp;youku.com, xunlei.com, etc)&nbs= p; without any problem.
 
Congxiao
 
<= /span> --B_3416840513_9257707-- --B_3416840516_9205624 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSN6tmk vi4M+7JqqgUlv9yEN6TM2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDkyMjIxNTNaMA0GCSqGSIb3DQEBAQUABIIBACrwseaqRrerGuTZBXk47Tus CBnPHXvadBMdjC+x/x4+JqQgBpixh6EbQYNETxIrKDv8OGAHLoIYsQ3X1tnIQtDnNFAgsBox QH3BQt1Y3Ro7HnNv+Y0pNVQ+aZHCltGRxG8cvqNjbY1fx42Qio7JpgiVRkV/DRu9uTY31+so 9qq7RBzMxV6QX4NNpy7nW4muO6TiKCHNd95pzKOCzZQJKy4Wu9WSLE8GP9AtgMGc4dIIL483 K1vigZueZoXwRdqVW4zzIHdGcAnBGwHAPMFvTOXkygcVQPQa+ybYjTDGk+f/H0CU2Bd5+uJ+ EmghsYFKM6kJCB5lfadTvgW8myH0PFE= --B_3416840516_9205624-- From yiu_lee@cable.comcast.com Mon Apr 9 15:45:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699D421F8803 for ; Mon, 9 Apr 2012 15:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.686 X-Spam-Level: X-Spam-Status: No, score=-99.686 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVY8YIqJkyex for ; Mon, 9 Apr 2012 15:45:58 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1C21F8796 for ; Mon, 9 Apr 2012 15:45:57 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12722022; Mon, 09 Apr 2012 16:32:53 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 18:45:51 -0400 From: "Lee, Yiu" To: Maoke , Sheng Jiang Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFqKDEr9EipuvuEaVN0gHw13eUw== Date: Mon, 9 Apr 2012 22:45:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416841948_9318313" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:45:59 -0000 --B_3416841948_9318313 Content-type: multipart/alternative; boundary="B_3416841947_9350520" --B_3416841947_9350520 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear Maoke, Comments inline: From: Maoke Date: Mon, 9 Apr 2012 07:24:30 +0000 To: Sheng Jiang Cc: "Yiu L. LEE" , "Liubing (Leo)" , Simon Perreault , "softwires@ietf.org" Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as transparent as MAP-E hi Yiu and others,=20 1. "both published" does surely conflict with the design goal of 4rd-U itself:=20 unification of multiple standards. politically speaking, the 4rd-u authors'=20 positition is now quite confusing. [YL] I can live with both stay as draft format. When Remi proposed 4rd-u, what he saw was a way to use reverse-header to support encapsulation w/o encapsulation overhead. This is why he called it "Unified". However, this doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started the work, we had BGP and LDP for signaling. In the end, we have RFC4761 and RFC4762. It isn't end of the world, is it? 2. operators surely need to choose IPv6 transition mechanisms but such a choice=20 is based on their demand and understanding to the existing and well-tested,=20 well-practiced building blocks. i don't think any operators are waiting for=20 an option of choice they never see and never understand. and the "enough technical supports" is now still "a check without signature". i do suggest=20 the 4rd-u authors and supporters say that after making something real. [YL] I think we have at least one volunteer in the ML taking this job. Thanks Sheng Jiang. on the other hand, 4rd-u makes a tight coupling between the address format=20 and its own header mapping mechanism. this makes an operator unable to have=20 different choices of transition mechanism as long as it chooses 4rd-u. i= f you concern the choice of IPv6 transition mechanism, i do recommend MAP, as=20 either encapsulation or translation is operatable with MAP address/port mapping without difficulty. [YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupling address format and header mapping? 3. surely MAP still has room of improvement but i don't think there are architectural uncertainty as 4rd-U has. request on more testing data is surely appreciated but please think it over again if it is a correct way to require further data of a counterpart in order to defense a solution without any data. [YL] Again, MAP has started the work couple years earlier back to double-IVI. Thanks for the good work. 4rd-u only started in few months. Al= l I asked is to give time to understand both protocols better. That's it. [YL] Last remark. MAP and 4rd-u both work inside the operator network, they are connected by IPv4 network, they don't need to interwork with each other= , so incompatibility isn't a concern here. In theory, an operator can deploy 4rd-u in one test site and MAP in other test site to compare their good and bad. We do this all the time for other technologies, why when we come to MA= P vs 4rd-u, we can't do something similar? 4. even there were no MAP at all, current level of 4rd-U is far premature t= o be=20 talked about any working group acception. the authors and supporters will be appreciated if they talk about the acception=20 after their coding and testing and refinement on the document according to their=20 practical experiences, and understanding the problem again and again. thanks,=20 maoke 2012/4/9 Sheng Jiang >> > I also followed the discussion. I appreciate both teams bought up the >> > technical details for both designs. To be honest, I fail to see which >> > one is better than other (yet). I like the fact that 4rd-u can do what >> > MAP-T does w/o introducing any encap overhead. But I understand the >> > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e >> > it not introducing any new requirement to the IPv6 header, but I need >> > more published data to determine whether the double-translation would >> > cause any transparent issue or not. For example: I would very >> > appreciate if somebody who trial MAP can publish data such as what >> > applications they have tested, what pass and what fail. >> > >> > This piece of work is very important because once we select it, this >> > technology will stay for long time. I do not want to rush to make a >> > decision and come back to regret in future. >=20 > We would like to see both solution published. So that, operators can choo= se > according to their own networks and preference. There are enormous number= of > operators, who do not come to IETF meeting or do not participate in ML ei= ther. > They also need to choose IPv6 transition mechanisms. They should be provi= ded > enough technical supports. That's the response of IETF, in our understand= ing. >=20 >> > On 4/6/12 6:00 AM, "Liubing (Leo)" wrote: >> > >>> > >+1 >>> > > >>> > >I've read the endless discussion, and found that is seems the MAP al= so >>> > >has not fully convinced the ISP operation guys. >>> > >Since there's explicit controversy, why not just publish them both a= s >>> > >experimental. why we must chose one as a "standard track"? Being a >>> > >standard track can eliminate operators' misgiving? >>> > > >>> > >If the technology is really appropriate, I don't think the >> > "experimental" >>> > >status would be a issue for the operators to adopt. Just let the >>> > >operator decide by themselves. >>> > > >>> > >I remembered in the meeting venue, Joel Halpern who chairs Karp and >>> > >lisp WG, suggested we publish both of them as experimental, and that >>> > >was exactly how they handle the similar situation in their WG. I thi= nk >>> > >his suggestion is reasonable to be considered. (To Joel: Pardon me i= f >> > I >>> > >improperly quoted your comment, or I just misunderstood your >> > suggestion >>> > >). >>> > > >>>> > >> -----Original Message----- >>>> > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.o= rg] >>>> > >>On Behalf Of Simon Perreault >>>> > >> Sent: Tuesday, April 03, 2012 8:16 PM >>>> > >> To: softwires@ietf.org >>>> > >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-U as >>>> > >>transparent as MAP-E >>>> > >> >>>> > >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote: >>>>> > >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by >>>>> > >> > using >>>> > >>hub >>>> > >> and spoke mode with a separate >>>>> > >> > mapping rule per subscriber. in this mode e.g only ports c= ould >>>>> > >> > be >>>> > >> embedded in the address. this is not >>>>> > >> > possible in a translation solution like 4rd-U. >>>> > >> >>>> > >> This mode of operation was suggested last week during the SD-NAT >>>> > >> presentation. There seemed to be consensus among operators that i= t >>>> > >> was not practically feasible. >>>> > >> >>>>> > >> > 2) a node inside the network will treat translated packets >>>>> > >> > different >>>> > >>from >>>> > >> encapsulated ones. >>>>> > >> > e.g. for the purposes of counting or for applying features= . >> > for >>>>> > >> > an >>>> > >> encapsulated packet both the complete >>>>> > >> > IPv4 datagram and the IPv6 header is available, and differ= ent >>>> > >>features >>>> > >> can be applied to both. >>>> > >> >>>> > >> In practice, the contents of encapsulated packets are rarely >>>> > >> inspected by firewalls and other such devices. >>>> > >> >>>> > >> >>>> > >> IMHO at this point we should let the market decide. Publish both = as >>>> > >> experimental. Let's work on something else now. >>>> > >> >>>> > >> Simon >>>> > >> -- >>>> > >> DTN made easy, lean, and smart --> http://postellation.viagenie.c= a >>>> > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>>> > >> STUN/TURN server --> http://numb.viagenie.ca >>>> > >> _______________________________________________ >>>> > >> Softwires mailing list >>>> > >> Softwires@ietf.org >>>> > >> https://www.ietf.org/mailman/listinfo/softwires >>> > >_______________________________________________ >>> > >Softwires mailing list >>> > >Softwires@ietf.org >>> > >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3416841947_9350520 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Dear Maoke,

Comments inline:

Fr= om: Maoke <fibrib@gmail.com= >
Date: Mon, 9 Apr 2012 07:24:3= 0 +0000
To: Sheng Jiang <jiangsheng@huawei.com>
Cc: "Yiu L. LEE" <yiu_lee@cable.comcast.com>, "Liubing (Leo)" <leo.liubing@huawei.com>, Simon Pe= rreault <simon.perreault@via= genie.ca>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Path to move fo= rward with 4rd=C5=A0 4rd-U as transparent as MAP-E

hi Yiu an= d others, 

1. "both published" does surely con= flict with the design goal of 4rd-U itself: 
   = ;unification of multiple standards. politically speaking, the 4rd-u aut= hors'
   positition is now quite confusing. 
=

[YL] I can live with both stay as draft format. W= hen Remi proposed 4rd-u, what he saw was a way to use reverse-header to supp= ort encapsulation w/o encapsulation overhead. This is why he called it "Unif= ied". However, this doesn't mean it must replace MAP-E/T. This recalls me wh= en L2-MPLS started the work, we had BGP and LDP for signaling. In the end, w= e have RFC4761 and RFC4762. It isn't end of the world, is it?

2. operators surely need to choos= e IPv6 transition mechanisms but such a choice 
   = is based on their demand and understanding to the existing and well-tested,&= nbsp;
   well-practiced building blocks. i don't think a= ny operators are waiting for 
   an option of choic= e they never see and never understand. and the "enough 
 = ;  technical supports" is now still "a check without signature". i do s= uggest 
   the 4rd-u authors and supporters say tha= t after making something real. 

[YL] I = think we have at least one volunteer in the ML taking this job. Thanks Sheng= Jiang.

  &nbs= p;on the other hand, 4rd-u makes a tight coupling between the address format=  
   and its own header mapping mechanism. this mak= es an operator unable to have 
   different choices= of transition mechanism as long as it chooses 4rd-u. if 
&nb= sp;  you concern the choice of IPv6 transition mechanism, i do recommen= d MAP, as 
   either encapsulation or translation i= s operatable with MAP address/port 
   mapping with= out difficulty. 

[YL] Sorry for my lack= of knowledge. Please explain how MAP isn't coupling address format and head= er mapping?

3. sure= ly MAP still has room of improvement but i don't think there are 
=
   architectural uncertainty as 4rd-U has. request on more te= sting data is 
   surely appreciated but please thi= nk it over again if it is a correct way 
   to requ= ire further data of a counterpart in order to defense a solution 
=
   without any data. 

[Y= L] Again, MAP has started the work couple years earlier back to double-IVI. = Thanks for the good work. 4rd-u only started in few months.  All I aske= d is to give time to understand both protocols better. That's it. 

[YL] Last remark. MAP and 4rd-u both work inside the op= erator network, they are connected by IPv4 network, they don't need to inter= work with each other, so incompatibility isn't a concern here. In theory, an= operator can deploy 4rd-u in one test site and MAP in other test site to co= mpare their good and bad. We do this all the time for other technologies, wh= y when we come to MAP vs 4rd-u, we can't do something similar?

4. even there were no MAP at all, current level of 4rd-U is far premature t= o be 
   talked about any working group acception.<= /div>

the authors and supporters will be appreciated if t= hey talk about the acception 
after their coding and testing = and refinement on the document according to their 
practical = experiences, and understanding the problem again and again. 
=
thanks, 
maoke

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>
> I also followed the discussion. I appreciate bo= th teams bought up the
> technical details for both designs. To be honest, I fail to see which<= br> > one is better than other (yet). I like the fact that 4rd-u can do what=
> MAP-T does w/o introducing any encap overhead. But I understand the > concerns others brought up in the ML such as V-octet. For MAP-T, I lik= e
> it not introducing any new requirement to the IPv6 header, but I need<= br> > more published data to determine whether the double-translation would<= br> > cause any transparent issue or not. For example: I would very
> appreciate if somebody who trial MAP can publish data such as what
= > applications they have tested, what pass and what fail.
>
> This piece of work is very important because once we select it, this > technology will stay for long time. I do not want to rush to make a > decision and come back to regret in future.

We would like= to see both solution published. So that, operators can choose according to = their own networks and preference. There are enormous number of operators, w= ho do not come to IETF meeting or do not participate in ML either. They also= need to choose IPv6 transition mechanisms. They should be provided enough t= echnical supports. That's the response of IETF, in our understanding.

> On 4/6/12 6:00 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:
>
> >+1
> >
> >I've read the endless discussion, and found that is seems the MAP = also
> >has not fully convinced the ISP operation guys.
> >Since there's explicit controversy, why not just publish them both= as
> >experimental. why we must chose one as a "standard track"? Being a=
> >standard track can eliminate operators' misgiving?
> >
> >If the technology is really appropriate, I don't think the
> "experimental"
> >status would be a issue for the operators to adopt. Just let the > >operator decide by themselves.
> >
> >I remembered in the meeting venue, Joel Halpern who chairs Karp an= d
> >lisp WG, suggested we publish both of them as experimental, and th= at
> >was exactly how they handle the similar situation in their WG. I t= hink
> >his suggestion is reasonable to be considered. (To Joel: Pardon me= if
> I
> >improperly quoted your comment, or I just misunderstood your
> suggestion
> >).
> >
> >> -----Original Message-----
> >> From: softwires-b= ounces@ietf.org [mailto:soft= wires-bounces@ietf.org]
> >>On  Behalf Of Simon Perreault
> >> Sent: Tuesday, April 03, 2012 8:16 PM
> >> To: softwires@ietf.org
> >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 4rd-= U as
> >>transparent  as MAP-E
> >>
> >> On 2012-04-03 05:40, Ole Tr=C3=B8an wrote:
> >> > 1) MAP-E supports independence of IPv4 and IPv6 addressi= ng. by
> >> > using
> >>hub
> >> and spoke mode with a separate
> >> >     mapping rule per subscriber. in this mode = e.g only ports could
> >> > be
> >> embedded in the address. this is not
> >> >     possible in a translation solution like 4r= d-U.
> >>
> >> This mode of operation was suggested last week during the SD-= NAT
> >> presentation. There seemed to be consensus among operators th= at it
> >> was not practically feasible.
> >>
> >> > 2) a node inside the network will treat translated packe= ts
> >> > different
> >>from
> >> encapsulated ones.
> >> >     e.g. for the purposes of counting or for a= pplying features.
> for
> >> > an
> >> encapsulated packet both the complete
> >> >     IPv4 datagram and the IPv6 header is avail= able, and different
> >>features
> >> can be applied to both.
> >>
> >> In practice, the contents of encapsulated packets are rarely<= br> > >> inspected by firewalls and other such devices.
> >>
> >>
> >> IMHO at this point we should let the market decide. Publish b= oth as
> >> experimental. Let's work on something else now.
> >>
> >> Simon
> >> --
> >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca=
> >> STUN/TURN server             &n= bsp; --> http://numb.vi= agenie.ca
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires
> >_______________________________________________
> >Softwires mailing list
> >Softwires@ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@iet= f.org
https://www.ietf.org/mailman/listinfo/softwires

--B_3416841947_9350520-- --B_3416841948_9318313 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRAB8jV /BzgZEad5NtNRofUNed8szAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDkyMjQ1NDdaMA0GCSqGSIb3DQEBAQUABIIBAH+IpL1yuuL0lLMdZBNzOp6d wD7hw3CBsPujM44DcFH8GDGgz7bfiFUuPb+jbS/hnKAr+3OBu/C7LKUjzteCKrXNQhHmEh0M 8y6xVemJ9M1hqwjcsF7u+1lJOzj24RrIpy8I3p1XP4SZz9oE/Vb7Az78WiQi9FuYY9wAXTuQ 4SidM/hptE0WuCoUfLwh4f09IkoSzAonWdUhefmTYk32jsYxzbgO+w92qmVBiEuCBMTVVVl3 U6h+iMTPQ+OsBAsMPDdN5gXmLweuguhaEoXiAu2QzZQYW0hP94hwKgE79KownCsSG9LKx46+ DPKGgW18Al9LE2yBQ8a1h2StmFvwoRA= --B_3416841948_9318313-- From yiu_lee@cable.comcast.com Mon Apr 9 15:52:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38AD21F87AE for ; Mon, 9 Apr 2012 15:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.66 X-Spam-Level: X-Spam-Status: No, score=-99.66 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsiEAFCZU6Tt for ; Mon, 9 Apr 2012 15:52:11 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E223D21F8496 for ; Mon, 9 Apr 2012 15:52:10 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12722483; Mon, 09 Apr 2012 16:39:06 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 18:52:02 -0400 From: "Lee, Yiu" To: Maoke , Sheng Jiang Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: AQHNFqNgkPsG9sWwpkiEy+W9I1RPLQ== Date: Mon, 9 Apr 2012 22:52:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416842319_9357685" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:52:12 -0000 --B_3416842319_9357685 Content-type: multipart/alternative; boundary="B_3416842318_9373382" --B_3416842318_9373382 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable I am sorry, the two drafts should be RFC4447 and RFC4761. My mistake. From: "Yiu L. LEE" Date: Mon, 9 Apr 2012 22:45:50 +0000 To: Maoke , Sheng Jiang Cc: "softwires@ietf.org" Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-U as transparent as MAP-E [YL] I can live with both stay as draft format. When Remi proposed 4rd-u, what he saw was a way to use reverse-header to support encapsulation w/o encapsulation overhead. This is why he called it "Unified". However, this doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started the work, we had BGP and LDP for signaling. In the end, we have RFC4761 and RFC4762. It isn't end of the world, is it? --B_3416842318_9373382 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable
I am sorry, the two drafts s= hould be RFC4447 and RFC4761. My mistake. 

From: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Date: Mon, 9 Apr 2012 22:45:50 +0000
To: Maoke <fibrib@= gmail.com>, Sheng Jiang <ji= angsheng@huawei.com>
Cc: "<= a href=3D"mailto:softwires@ietf.org">softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-= U as transparent as MAP-E

[YL] I can live with both stay as draft format. When Remi proposed 4r= d-u, what he saw was a way to use reverse-header to support encapsulation w/= o encapsulation overhead. This is why he called it "Unified". However, this = doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started t= he work, we had BGP and LDP for signaling. In the end, we have RFC4761 and R= FC4762. It isn't end of the world, is it? --B_3416842318_9373382-- --B_3416842319_9357685 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRDuT6x OEmbqNAlyv5allHvVE4GaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDkyMjUxNThaMA0GCSqGSIb3DQEBAQUABIIBAJxV5OjE3gJYsJTKeC0y15xc fH0CkurOEcYoWs2Ch8aVH9JWnKPXXiznCwZmY9KaY38/A/H6Bw1zequ3ZfWHknZY8wchyeEX tzsM7SvaANs0+PB3FWTmYdfUvvaKVBgl/IqSF+2+uDPz8QQC00knEnXoPZctc05guJn0hDXR 0OhHWlSypxxQM5TtWsL/C1sR0pExq2hXv1ek/z6kda/rOObqVSqGo0Z9mMUXHpMDD9xXY/wI 2kVR9o4c6ppq98H1yHgVNFRoOWTuglZmqKkbMR63XHjaBNzd0E9mEyoWP/euTZl7yXs//o+8 PocPNtnZBw2nir5jUS6j3lGqkXfWVYw= --B_3416842319_9357685-- From yiu_lee@cable.comcast.com Mon Apr 9 16:00:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE02421F87CD for ; Mon, 9 Apr 2012 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.462 X-Spam-Level: X-Spam-Status: No, score=-99.462 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83hmvge42Wr5 for ; Mon, 9 Apr 2012 16:00:01 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id E090A21F879A for ; Mon, 9 Apr 2012 16:00:00 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.8693887; Mon, 09 Apr 2012 18:53:15 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 18:59:51 -0400 From: "Lee, Yiu" To: Maoke , Sheng Jiang Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9_4rd-U_as_tran?= =?iso-8859-2?Q?sparent_as_MAP-E?= Thread-Index: AQHNFqR4kPsG9sWwpkiEy+W9I1RPLQ== Date: Mon, 9 Apr 2012 22:59:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416842786_9394786" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9_4rd-U?= =?iso-8859-2?q?_as_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 23:00:02 -0000 --B_3416842786_9394786 Content-type: multipart/alternative; boundary="B_3416842783_9368274" --B_3416842783_9368274 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable I am sorry flooding the mailing list. Rajiv is kind to remind me I am wrong= . RFC4761/4762 are meant for VPLS. According to this link http://www.networkers-online.com/blog/2009/01/draft-martini-draft-kompella-= a nd-l2vpn-services/, draft-martini was published as RFC4906 (Categorized as Historic). Both LDP and BGP was combined to be RFC6074. draft-kompella was never standardized. From: "Yiu L. LEE" Date: Mon, 9 Apr 2012 22:52:01 +0000 To: Maoke , Sheng Jiang Cc: "softwires@ietf.org" Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-U as transparent as MAP-E I am sorry, the two drafts should be RFC4447 and RFC4761. My mistake. From: "Yiu L. LEE" Date: Mon, 9 Apr 2012 22:45:50 +0000 To: Maoke , Sheng Jiang Cc: "softwires@ietf.org" Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-U as transparent as MAP-E [YL] I can live with both stay as draft format. When Remi proposed 4rd-u, what he saw was a way to use reverse-header to support encapsulation w/o encapsulation overhead. This is why he called it "Unified". However, this doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started the work, we had BGP and LDP for signaling. In the end, we have RFC4761 and RFC4762. It isn't end of the world, is it? _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --B_3416842783_9368274 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable
I am sorry flooding the mail= ing list. Rajiv is kind to remind me I am wrong. RFC4761/4762 are meant for = VPLS. According to this link http://www.net= workers-online.com/blog/2009/01/draft-martini-draft-kompella-and-l2vpn-servi= ces/, draft-martini was published as RFC4906 (Categorized as Historic). = Both LDP and BGP was combined to be RFC6074. draft-kompella was never standa= rdized. 

From: = "Yiu L. LEE" <yiu_lee@cable.co= mcast.com>
Date: Mon, 9 Apr= 2012 22:52:01 +0000
To: Maoke <= ;fibrib@gmail.com>, Sheng Jiang <= ;jiangsheng@huawei.com>
Cc: "softwires@ietf.org" <softwires@i= etf.org>
Subject: Re: [Soft= wires] Path to move forward with 4rd=A9 4rd-U as transparent as MAP-E

I am sorry, the two drafts s= hould be RFC4447 and RFC4761. My mistake. 

From: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Date: Mon, 9 Apr 2012 22:45:50 +0000
To: Maoke <fibrib@= gmail.com>, Sheng Jiang <ji= angsheng@huawei.com>
Cc: "<= a href=3D"mailto:softwires@ietf.org">softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-= U as transparent as MAP-E

[YL] I can live with both stay as draft format. When Remi proposed 4r= d-u, what he saw was a way to use reverse-header to support encapsulation w/= o encapsulation overhead. This is why he called it "Unified". However, this = doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started t= he work, we had BGP and LDP for signaling. In the end, we have RFC4761 and R= FC4762. It isn't end of the world, is it?
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.= org/mailman/listinfo/softwires --B_3416842783_9368274-- --B_3416842786_9394786 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRAUBNC vj0h9cnmCXid3kPVKPqBUjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDkyMjU5NDNaMA0GCSqGSIb3DQEBAQUABIIBAChGB0p3WLSqUBfC7FRcwMYZ YM7nlusp4fZKW00f539oPxCbLA0s7IDZxET2MFoeU1O/fIdRJf+KmlrtZTTWen4I/P/hCEN3 +gfvQASD8PReaD7ngTzb33d4xtJsnlRBmpfFW66kryq1IVnXfupRv9vYVrsCf8yv09r2HK+O bm9C6ceQdt9v1kPHynMbmhsfgu0p7SGjQGLIK1vH2CSqePnqxLza/t9t0HCKrrRpxxxRO9iI MhhxVJ9xxtL+VbMjQWYv/WKM9s8vyMBYzLyaqlB7xT6pKWZCJnYzF0eZDOXKlNYAMkKzYif6 7bj7bzFYIi53zGiXJduWJXnyxl8gHyc= --B_3416842786_9394786-- From murai@fnsc.co.jp Mon Apr 9 18:34:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4421F85B4 for ; Mon, 9 Apr 2012 18:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1JSprEQJr0D for ; Mon, 9 Apr 2012 18:34:49 -0700 (PDT) Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBF21F8562 for ; Mon, 9 Apr 2012 18:34:48 -0700 (PDT) Received: from ([158.202.234.12]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.829185; Tue, 10 Apr 2012 10:34:44 +0900 Date: Tue, 10 Apr 2012 10:34:44 +0900 (JST) Message-Id: <20120410.103444.67911517.murai@fnsc.co.jp> To: adurand@juniper.net In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> From: Tomoki Murai X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:34:49 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Tomoki Murai, Furukawa Network Solution Corp.: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Tomoki Murai, Furukawa Network Solution Corp.: MAP ------------------------------------------------------------------------------ ===================================================================== From despres.remi@laposte.net Mon Apr 9 22:21:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D483D21F880B for ; Mon, 9 Apr 2012 22:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh5m6cVGVHrk for ; Mon, 9 Apr 2012 22:21:11 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0E21F8782 for ; Mon, 9 Apr 2012 22:21:08 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 987029400BE; Tue, 10 Apr 2012 07:20:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 07:20:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B09C072-84C8-434C-BDAC-0BAA393CA136@laposte.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Softwire Chairs X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" , int-ads@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:21:11 -0000 Alain, Yong, 2012-04-09 22:24, Alain Durand : > Dear Softwire wg, >=20 > The consensus call is closing in a few days.=20 >=20 > The two questions being asked are the same ones that were asked during = the meeting in Paris. > Those questions may or may not be perfect, you may or may not like = them, but they are the tool we have to gauge consensus (or lack thereof) > on the mailing list. So, If you have not yet expressed your opinion = answering both questions, now is the time to do it. > In IETF tradition, silence is consent. Please be sure that, in this instance where the current procedure is = disapproved, not answering the two questions below isn't consent to a = supposed consensus. Thanks, RD =20 >=20 > Alain, Softwires wg co-chair >=20 >=20 >=20 >=20 > On Apr 4, 2012, at 5:14 PM, Alain Durand wrote: >=20 >> Dear Softwire wg members: >>=20 >> At the Paris IETF Softwire meeting, we had presentations on MAP = (taken as a whole) and >> 4rd-U. We got very strong feedback that we needed to select one >> solution to cover that full stateless case, not two, and that we = should make this >> decision relatively quickly. >>=20 >> During Paris meeting, we asked the following additional question: >> Do you prefer MAP or 4rd-U? >> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>=20 >> The real gauge of consensus is the mailing list, so we would like >> to ask the same questions to the list. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, >> the other being published as experimental or informational. >> Answering YES to this question means you agree we cannot publish both = as standard track. >> Answering NO to this question means you want to see both advance on = the standard track. >>=20 >> = --------------------------------------------------------------------------= -- >> Your full name, your affiliation, your choice: YES or NO >> = --------------------------------------------------------------------------= -- >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Questions 2: Which one do you want to see placed on the Standards = Track: >> 4rd-U or MAP? >>=20 >> = --------------------------------------------------------------------------= ---- >> Your full name, your affiliation, your choice: 4rd-U or MAP >> = --------------------------------------------------------------------------= ---- >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >> Please fill out the following form and reply to the list >> by Wednesday 4/10 5pm EDT. >>=20 >> Note: Use this thread ONLY for expressing your support to >> one OR the other, and redirect any discussions to other threads. >> That would help up gauge consensus. >>=20 >> Alain & Yong. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From phdgang@gmail.com Mon Apr 9 22:35:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FB911E8074 for ; Mon, 9 Apr 2012 22:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl9Sm+D2xMby for ; Mon, 9 Apr 2012 22:35:28 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65B21F8758 for ; Mon, 9 Apr 2012 22:35:28 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2740014wib.1 for ; Mon, 09 Apr 2012 22:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8PqP8V6sKMJvMK7/RuiFjZDs0k0m/YV8wPFmgHRIx+s=; b=BWdvagvb9yXpTUpowmJJlxb5DBCCWqcbiUnAyPMcbZxwDV/3i5r5EXhKZa6piaqMSv EBaiGTS0X7P5I97o5NKxjMXjnma1WbQ+BkiqZt8djrmIxTW/F6IpLcWIzHKEMlNnbWHr LVfVf7cCFJdWXSDbK/Xy5IJobe1QPyNjZXtTUPCM4xgdNs7WTyyakE7PYv8eNr/jeJU/ Ev4Aw1hhyu/vghqQ2SCzgJ8UwhqyiBzFU+kLEii3m4j6vlmlWnqfmnj8FSjwxnT5gr52 xwmV+48R2udYRGAJ+6GhCzkU+10OQv5rmGQhlLOuMBL/KV6bX/Yd7gSoBekI1bLZbPM1 AXuA== MIME-Version: 1.0 Received: by 10.216.132.216 with SMTP id o66mr5569979wei.14.1334036127640; Mon, 09 Apr 2012 22:35:27 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Mon, 9 Apr 2012 22:35:27 -0700 (PDT) Date: Tue, 10 Apr 2012 13:35:27 +0800 Message-ID: From: GangChen To: softwires Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:35:29 -0000 Hello all, I have tried to work hard and technically contribute to all documents: MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned with all of them. Please allow me to share some points here. Basic idea of MAP algorithm were originally built on 4rd and DIVI (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, draft-xli-behave-divi, ..). It was improved by design team members and evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and MAP-E. Identical address format is used for -T and -E. Backing to the earlier version of MAP document, it included all features (e.g. Checksum-neutrality, Vbit etc.). Some people were in favor of it; some thought it not key points. For example, CNP is desirable for translation solution. But it's in some extent against current tunnel implementation, because encapsulation requires fixed IPv6 address representing an endpoint depending on tunnel code today. People have to sacrifice this feature in order to keep the benefits of unified address format. However, that obviously is of value to transparency. (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network Prefix Translation). 4rd-U was trying to keep all merits together considering trade-off points. It was targeted to be reversible process and full transparency which I guess is important for a stateless design. Meanwhile, some additional extensions have to be considered. It's maybe a point to bring up "endless discussion" on the list. I agree with what Yiu said it's hard to simply answer YES or NO at this time. Both solutions deserve spending more time, because these solutions were born only for half a year. Implementation may need more time and operation normally will also need to wait. OTOH, I'm still not fully convinced MAP-E and -T should be treated as one solution. I like MAP-E or -T to be deployed as a separate solution. However, coexistence means operators should have double packages inspection toolkits, double operational rules delivery and double provisioning costs. In some cases, translation solution is exclusive to encapsulation (Please see more in draft-dec-stateless-4v6). Even you can implement in the same box, that's very inconvenient for operation and subscriber. According RFC6180, it is fundamental two different solution. BRs Gang From phdgang@gmail.com Mon Apr 9 23:51:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155F521F86FF for ; Mon, 9 Apr 2012 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81DnFll6j690 for ; Mon, 9 Apr 2012 23:51:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1721F86FE for ; Mon, 9 Apr 2012 23:51:12 -0700 (PDT) Received: by werb10 with SMTP id b10so3634191wer.31 for ; Mon, 09 Apr 2012 23:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0eZkLHwtcc9UGEZzRrh4eZIBba0dbnkjQTc/lnMimTI=; b=IH7aZM11vKE+voO3JZMAM9yYuRif/b3Z6L62XP7ScYQYYrFodhyyMaF9btOsuGrPb/ 2F44FvfvLC1Jgc91ZJ2DyFAj6MuLpYG0RQ+6TvJxb00f+HVbq7yPdIIr0GEv2rv7qktI cV2zZsh+fYeyFcAPMwu/iOzyI0jBAKumIknyZ4teUUw3DXufoym2cl4NIuPDEo5umhcR 6lDc6sy+2CaO8GkYEH933tEaaT/4CK+T+d0A9xmLngUsvItUAICfHU18MVZIg6MDIe7l xgQ6haL1c+YMu4OqupoKG6Iymwm+aEmx05QrGGmDbKUxUu8u+lwEquL1+c2q3+EIpPx1 axsw== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr4187201wib.2.1334040672282; Mon, 09 Apr 2012 23:51:12 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Mon, 9 Apr 2012 23:51:12 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Tue, 10 Apr 2012 14:51:12 +0800 Message-ID: From: GangChen To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 06:51:14 -0000 2012/4/5, Alain Durand : > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a > whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make > this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. Please be note Wednesday should be 4/11 Gang > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Tue Apr 10 00:31:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7721F868A for ; Tue, 10 Apr 2012 00:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTCyiLNtGJF7 for ; Tue, 10 Apr 2012 00:31:43 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5121F8671 for ; Tue, 10 Apr 2012 00:31:42 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id w7Xf1i00C37Y3f4037Xftd; Tue, 10 Apr 2012 09:31:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 09:31:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Softwire Chairs X-Mailer: Apple Mail (2.1084) Cc: softwires Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:31:44 -0000 Le 2012-04-10 =E0 07:35, GangChen a =E9crit : > Hello all, >=20 > I have tried to work hard and technically contribute to all documents: > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned > with all of them. Please allow me to share some points here. >=20 > Basic idea of MAP algorithm were originally built on 4rd and DIVI > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, > draft-xli-behave-divi, ..). It was improved by design team members and > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and > MAP-E. Identical address format is used for -T and -E. Backing to the > earlier version of MAP document, it included all features (e.g. > Checksum-neutrality, Vbit etc.). Some people were in favor of it; some > thought it not key points. For example, CNP is desirable for > translation solution. But it's in some extent against current tunnel > implementation, because encapsulation requires fixed IPv6 address > representing an endpoint depending on tunnel code today. People have > to sacrifice this feature in order to keep the benefits of unified > address format. However, that obviously is of value to transparency. > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network > Prefix Translation). >=20 > 4rd-U was trying to keep all merits together considering trade-off > points. It was targeted to be reversible process and full transparency > which I guess is important for a stateless design. Meanwhile, some > additional extensions have to be considered. It's maybe a point to > bring up "endless discussion" on the list. >=20 > I agree with what Yiu said it's hard to simply answer YES or NO at > this time. Both solutions deserve spending more time, because these > solutions were born only for half a year. +1 > Implementation may need more > time and operation normally will also need to wait. >=20 > OTOH, I'm still not fully convinced MAP-E and -T should be treated as > one solution. +1 (They were previously considered to be two distinct candidates for = standard track.) =20 > I like MAP-E or -T to be deployed as a separate > solution. However, coexistence means operators should have double > packages inspection toolkits, double operational rules delivery and > double provisioning costs. In some cases, translation solution is > exclusive to encapsulation (Please see more in > draft-dec-stateless-4v6). > Even you can implement in the same box, > that's very inconvenient for operation and subscriber. +1=20 With MAP-T+E, subscribers wouldn't have the same service depending on = which specification their local operator has chosen, with subtle = differences they shouldn't be concerned with. RD > According > RFC6180, it is fundamental two different solution. >=20 > BRs >=20 > Gang > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jan@go6.si Tue Apr 10 00:38:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E247921F8702 for ; Tue, 10 Apr 2012 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJhoJ+zzCFyX for ; Tue, 10 Apr 2012 00:38:00 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A21B21F86C7 for ; Tue, 10 Apr 2012 00:38:00 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 3AF7622B4069 for ; Tue, 10 Apr 2012 09:37:57 +0200 (CEST) Message-ID: <4F83E358.1090409@go6.si> Date: Tue, 10 Apr 2012 09:38:00 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:38:01 -0000 On 4/10/12 7:35 AM, GangChen wrote: > OTOH, I'm still not fully convinced MAP-E and -T should be treated as > one solution. I like MAP-E or -T to be deployed as a separate > solution. However, coexistence means operators should have double > packages inspection toolkits, double operational rules delivery and > double provisioning costs. In some cases, translation solution is > exclusive to encapsulation (Please see more in > draft-dec-stateless-4v6). Even you can implement in the same box, > that's very inconvenient for operation and subscriber. According > RFC6180, it is fundamental two different solution. Hi, I see MAP-E/T combo as one solution, where you "turn the knob" when implementing it - you choose encap *or* translation mode. Whichever mode you choose, there is no sign of the other anymore. Cheers, Jan From ichiroumakino@gmail.com Tue Apr 10 00:43:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30A21F863B for ; Tue, 10 Apr 2012 00:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ15v20R4qez for ; Tue, 10 Apr 2012 00:43:19 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D48BC21F8638 for ; Tue, 10 Apr 2012 00:43:18 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3275170wgb.13 for ; Tue, 10 Apr 2012 00:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Xkaoe1eC/57bl3pp7V6rmKRxVNQVsvq15X0z0IDutfQ=; b=rUC+oTc1RWvwzIVlbnE2kf1fEvorfcygS1y8zySahJQ8FiGsge1deYJUqEmFhBb8ra 96KoDJAR7zqhNNIOhtK1dg/RVSTWTZmcVQCf3t4MjvBafuJMuDv5M3j2tPRqmlU4b9jg OSsLCrAEOSADvo9NOeKzyhwY/4qGznyIhpHlroOcqzOHWiZDk4vhgDbNFdMgn96Xhml2 l60lEVqrfgFMrGckZL6n8WCalQy4gkR3POrp7SPMndg4XgyQmpreWUQLKvxT7Vnr83Vl s6M/qzn2/scR615Jvkkgj7zyD9HCBs79+84epryiAdURkybgq0NtzFrpU7b9+AEZAJlS sDNw== Received: by 10.216.225.12 with SMTP id y12mr5536792wep.39.1334043798020; Tue, 10 Apr 2012 00:43:18 -0700 (PDT) Received: from [173.38.129.95] ([173.38.129.95]) by mx.google.com with ESMTPS id ea6sm35947303wib.5.2012.04.10.00.43.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 00:43:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Tue, 10 Apr 2012 09:43:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:43:19 -0000 Ole Troan, cisco, YES, MAP. cheers, Ole > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we = should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. >=20 > = --------------------------------------------------------------------------= -- > Your full name, your affiliation, your choice: YES or NO > = --------------------------------------------------------------------------= -- >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 > = --------------------------------------------------------------------------= ---- > Your full name, your affiliation, your choice: 4rd-U or MAP > = --------------------------------------------------------------------------= ---- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ggottard@cisco.com Tue Apr 10 00:56:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BEF21F878E for ; Tue, 10 Apr 2012 00:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFkRo9Jrmhkz for ; Tue, 10 Apr 2012 00:56:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6188121F8768 for ; Tue, 10 Apr 2012 00:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ggottard@cisco.com; l=1716; q=dns/txt; s=iport; t=1334044590; x=1335254190; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jOS1f/LhvB3wu5X7n9zZ7whVsCCYcm1Jjnej4XpoRsM=; b=Do9zu87bBo+8cUMG0EBPATS4XLI1k9IVveBh0EiJuvgyAyYZGXkp51pD b28PXSjfNqhgRg/LQzZ4QWd9Q3ezd12938wysBBf0fFIVk8lxdAS2aakC D2OBp/B2arIagCAt9rr7V0PDJ8Lup4df7wIl7iK400VJEwgL3pWd1uYwA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABXng0+Q/khM/2dsb2JhbABEuU6BB4IKAQEEEgEnNAsQCwkFOFcGNYdsmjuRDYZuiECGEIluYwSOBodmjk2BaYJp X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="134664550" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 07:56:29 +0000 Received: from dhcp-144-254-59-68.cisco.com (dhcp-144-254-59-68.cisco.com [144.254.59.68]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3A7uSr5018630; Tue, 10 Apr 2012 07:56:29 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: ggottard In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Tue, 10 Apr 2012 09:56:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org WG" , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:56:31 -0000 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. >=20 > = --------------------------------------------------------------------------= -- > Your full name, your affiliation, your choice: YES or NO > = --------------------------------------------------------------------------= -- Guillaume Gottardi, Cisco, YES >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 > = --------------------------------------------------------------------------= ---- > Your full name, your affiliation, your choice: 4rd-U or MAP > = --------------------------------------------------------------------------= ---- Guillaume Gottardi, Cisco, MAP >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 - Guillaume= From wdec.ietf@gmail.com Tue Apr 10 00:59:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3113E21F877E for ; Tue, 10 Apr 2012 00:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZdeMCqKFswX for ; Tue, 10 Apr 2012 00:59:04 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58B21F87BE for ; Tue, 10 Apr 2012 00:59:04 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3451903qcs.31 for ; Tue, 10 Apr 2012 00:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=41shK99Ejgk067q3fmU1ocvywwuWepyNjM2fYAvaSpg=; b=a+ZR0dle2qdTJdFYgnBlJw4zIfYzu5qxhq2EORP5OKYURqxKTCxV7f7IKNacXl5ZSx nk2K2YUKh06r+1WIz3hS4c40qRwh5RuAY29o1jzUuvl63hm9hBVsS3QInx+7HeW2jZ+W NLV1AhEU0jrNrB7Ut7dCThn4FqCUfDTwpca4xGdC7r8n82eWkazEJ96UaRn/BiHBNpzO kVzugzvq+bJ4PMJixDUlcvh2MgsO0HuvhD5nF2ZEScnrGIp/ZtGT4y7+85dlQbEwJ9Ag Haqh9ud+B/DVf8uaFYNicfik7s9goBOPWP+RLET/5cVlWmI2d5AeOwa1rN2Bh/1TqyFS cVsg== MIME-Version: 1.0 Received: by 10.229.136.4 with SMTP id p4mr4000918qct.131.1334044743621; Tue, 10 Apr 2012 00:59:03 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 00:59:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 09:59:03 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c70fc8d0edc7c04bd4e7f8d Cc: softwires , Softwire Chairs Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:59:05 -0000 --00248c70fc8d0edc7c04bd4e7f8d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10 April 2012 09:31, R=E9mi Despr=E9s wrote: > Le 2012-04-10 =E0 07:35, GangChen a =E9crit : > > > Hello all, > > > > I have tried to work hard and technically contribute to all documents: > > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned > > with all of them. Please allow me to share some points here. > > > > Basic idea of MAP algorithm were originally built on 4rd and DIVI > > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, > > draft-xli-behave-divi, ..). It was improved by design team members and > > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and > > MAP-E. Identical address format is used for -T and -E. Backing to the > > earlier version of MAP document, it included all features (e.g. > > Checksum-neutrality, Vbit etc.). Some people were in favor of it; some > > thought it not key points. For example, CNP is desirable for > > translation solution. But it's in some extent against current tunnel > > implementation, because encapsulation requires fixed IPv6 address > > representing an endpoint depending on tunnel code today. People have > > to sacrifice this feature in order to keep the benefits of unified > > address format. However, that obviously is of value to transparency. > > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network > > Prefix Translation). > > > > 4rd-U was trying to keep all merits together considering trade-off > > points. It was targeted to be reversible process and full transparency > > which I guess is important for a stateless design. Meanwhile, some > > additional extensions have to be considered. It's maybe a point to > > bring up "endless discussion" on the list. > > > > I agree with what Yiu said it's hard to simply answer YES or NO at > > this time. Both solutions deserve spending more time, because these > > solutions were born only for half a year. > > +1 > > > Implementation may need more > > time and operation normally will also need to wait. > > > > OTOH, I'm still not fully convinced MAP-E and -T should be treated as > > one solution. > > +1 > (They were previously considered to be two distinct candidates for > standard track.) > > > I like MAP-E or -T to be deployed as a separate > > solution. However, coexistence means operators should have double > > packages inspection toolkits, double operational rules delivery and > > double provisioning costs. In some cases, translation solution is > > exclusive to encapsulation (Please see more in > > draft-dec-stateless-4v6). > > Even you can implement in the same box, > > that's very inconvenient for operation and subscriber. > > +1 > With MAP-T+E, subscribers wouldn't have the same service depending on > which specification their local operator has chosen, with subtle > differences they shouldn't be concerned with. > The service would be the same. Note: NAT64 based services are a reality today, and although you may think differently, no operator calls "checksum neutrality" a service (with this apparently being the main feature of 4rd-u). What more, given that 4rd-U needs to be combined with BIH, the claim of it offering some "unified" solution, different operationally from MAP is bogus. If anything this combination and the fact that there is a IPv6.1 being created actually makes 4rd-u operations a major challenge in comparison to what we know of as IPinIP tunnelling or NAT64 with MAP. Remi, at one point you stated publicly that you would withdraw 4rd-u should it not gain WG consensus. You also chose to quit the MAP design team, where your proposals failed to get consensus. At this stage it appears that not only you are not intending to honour you public statement, but also in general disputing the process of establishing consensus in the WG. One is tempted to see it that no consensus other than "consensus on your terms" is what you really want, and those terms change with each new draft revision. Perhaps its time for draft 4rd-X in a new WG... -Woj. > > RD > > > > > According > > RFC6180, it is fundamental two different solution. > > > > BRs > > > > Gang > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00248c70fc8d0edc7c04bd4e7f8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 10 April 2012 09:31, R=E9mi Despr=E9s= <despres.= remi@laposte.net> wrote:
Le 2012-04-10 =E0 07:35, GangChen a =E9crit :

> Hello all,
>
> I have tried to work hard and technically contribute to all documents:=
> MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned<= br> > with all of them. Please allow me to share some points here.
>
> Basic idea of MAP algorithm were originally built on 4rd and DIVI
> (draft-despres-softwire-4rd,draft-murakami-softwire-4rd,
> draft-xli-behave-divi, ..). It was improved by design team members and=
> evolved into "polarized solutions"(as Jan mentioned), i.e. M= AP-T and
> MAP-E. Identical address format is used for -T and -E. Backing to the<= br> > earlier version of MAP document, it included all features (e.g.
> Checksum-neutrality, Vbit etc.). Some people were in favor of it; some=
> thought it not key points. For example, CNP is desirable for
> translation solution. But it's in some extent against current tunn= el
> implementation, because encapsulation requires fixed IPv6 address
> representing an endpoint depending on tunnel code today. People have > to sacrifice this feature in order to keep the benefits of unified
> address format. However, that obviously is of value to transparency. > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network<= br> > Prefix Translation).
>
> 4rd-U was trying to keep all merits together considering trade-off
> points. It was targeted to be reversible process and full transparency=
> which I guess is important for a stateless design. Meanwhile, some
> additional extensions have to be considered. It's maybe a point to=
> bring up "endless discussion" on the list.
>
> I agree with what Yiu said it's hard to simply answer YES or NO at=
> this time. Both solutions deserve spending more time, because these > solutions were born only for half a year.

+1

> Implementation may need more
> time and operation normally will also need to wait.
>
> OTOH, I'm still not fully convinced MAP-E and -T should be treated= as
> one solution.

+1
(They were previously considered to be two distinct candidates for standard= track.)

> I like MAP-E or -T to be deployed as a separate
> solution. However, coexistence means operators should have double
> packages inspection toolkits, double operational rules delivery and > double provisioning costs. In some cases, translation solution is
> exclusive to encapsulation (Please see more in
> draft-dec-stateless-4v6).
> Even you can implement in the same box,
> that's very inconvenient for operation and subscriber.

+1
With MAP-T+E, subscribers wouldn't have the same service depending on w= hich specification their local operator has chosen, with subtle differences= they shouldn't be concerned with.

The service= would be the same. Note: NAT64 based services are a reality today, and alt= hough you may think differently, no operator calls "checksum neutralit= y" a service (with this apparently being the main feature of 4rd-u). <= br> What more, given that 4rd-U needs to be combined with BIH, the claim of it = offering some "unified" solution, different operationally from MA= P is bogus. If anything this combination and the fact that there is a IPv6.= 1 being created actually makes 4rd-u operations a major challenge in compar= ison to what we know of as IPinIP tunnelling or NAT64 with MAP.

Remi, at one point you stated publicly that you would withdraw 4rd-u sh= ould it not gain WG consensus. You also chose to quit the MAP design team, = where your proposals failed to get consensus. At this stage it appears that= not only you are not intending to honour you public statement, but also in= general disputing the process of establishing consensus in the WG. One is = tempted to see it that no consensus other than "consensus on your term= s" is what you really want, and those terms change with each new draft= revision. Perhaps its time for draft 4rd-X in a new WG...

-Woj.
=A0

RD



> According
> RFC6180, it is fundamental two different solution.
>
> BRs
>
> Gang
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00248c70fc8d0edc7c04bd4e7f8d-- From eleven.fuyu@huawei.com Tue Apr 10 01:05:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C521F87CC for ; Tue, 10 Apr 2012 01:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SshKbAB36Z4 for ; Tue, 10 Apr 2012 01:05:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1621F84DE for ; Tue, 10 Apr 2012 01:05:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC19500; Tue, 10 Apr 2012 04:05:15 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 01:01:41 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 01:01:43 -0700 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.169]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 16:01:40 +0800 From: "Fuyu (Eleven)" To: "Jan Zorz @ go6.si" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E&T vs 4rd-U Thread-Index: AQHNFuznhMPPjNYNXkux3itmp2C/PJaTr65A Date: Tue, 10 Apr 2012 08:01:39 +0000 Message-ID: References: <4F83E358.1090409@go6.si> In-Reply-To: <4F83E358.1090409@go6.si> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:05:16 -0000 Hi Jan, =20 ISPs can't deploy MAP-E/T and use the two mechanism to transmit IPv4 traf= fic in their network at the same time.=20 So I aggree with Gang that MAP-E and MAP-T should be treated as separate = solutions. BR=20 Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Jan Zorz @ go6.si Sent: Tuesday, April 10, 2012 3:38 PM To: softwires@ietf.org Subject: Re: [Softwires] MAP-E&T vs 4rd-U On 4/10/12 7:35 AM, GangChen wrote: > OTOH, I'm still not fully convinced MAP-E and -T should be treated as > one solution. I like MAP-E or -T to be deployed as a separate > solution. However, coexistence means operators should have double > packages inspection toolkits, double operational rules delivery and > double provisioning costs. In some cases, translation solution is > exclusive to encapsulation (Please see more in > draft-dec-stateless-4v6). Even you can implement in the same box, > that's very inconvenient for operation and subscriber. According > RFC6180, it is fundamental two different solution. Hi, I see MAP-E/T combo as one solution, where you "turn the knob" when=20 implementing it - you choose encap *or* translation mode. Whichever mode=20 you choose, there is no sign of the other anymore. Cheers, Jan _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From th@imu.edu.cn Tue Apr 10 01:12:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A1821F84FB for ; Tue, 10 Apr 2012 01:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9pEByKY1GWT for ; Tue, 10 Apr 2012 01:12:56 -0700 (PDT) Received: from imu.edu.cn (xzwlzx.imu.edu.cn [202.207.0.50]) by ietfa.amsl.com (Postfix) with SMTP id 63E9021F8782 for ; Tue, 10 Apr 2012 01:12:51 -0700 (PDT) Received: from localhost ([127.0.0.1]) by imu.edu.cn with sendmail id 2e4b7c1512a915345da5c07ccbe90017; Tue, 10 Apr 2012 16:12:39 +0800 Date: Tue, 10 Apr 2012 16:12:39 +0800 From: "th" To: "Alain Durand" References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Message-Id: <1204101612394872004d4f5df72c3b8f3c7080f2638b@imu.edu.cn> MIME-Version: 1.0 X-Mailer: eYou WebMail 5.0.4rc4.fix2 X-Eyou-Client: 202.207.146.7 Content-Type: text/plain; charset="GBK" Content-Transfer-Encoding: base64 X-Eyou-Sender: Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:12:58 -0000 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpRdWVzdGlvbiAxOiBEbyB5b3UgYWdyZWUgdGhhdCB0 aGUgd2cgc2hvdWxkIHB1dCBFSVRIRVIgNHJkLVUgT1IgTUFQIChhcyBhIHdob2xlKSBv biB0aGUgc3RhbmRhcmQgdHJhY2ssCnRoZSBvdGhlciBiZWluZyBwdWJsaXNoZWQgYXMg ZXhwZXJpbWVudGFsIG9yIGluZm9ybWF0aW9uYWwuCkFuc3dlcmluZyBZRVMgdG8gdGhp cyBxdWVzdGlvbiBtZWFucyB5b3UgYWdyZWUgd2UgY2Fubm90IHB1Ymxpc2ggYm90aCBh cyBzdGFuZGFyZCB0cmFjay4KQW5zd2VyaW5nIE5PIHRvIHRoaXMgcXVlc3Rpb24gbWVh bnMgeW91IHdhbnQgdG8gc2VlIGJvdGggYWR2YW5jZSBvbiB0aGUgc3RhbmRhcmQgdHJh Y2suCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkFvIFRlbmdoZSwgTmV0d29yayBD ZW50ZXIgb2YgSW5uZXIgTW9uZ29saWEgVW5pdmVyc2l0eSAsIFlFUwotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCgoKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpRdWVzdGlvbnMgMjog V2hpY2ggb25lIGRvIHlvdSB3YW50IHRvIHNlZSBwbGFjZWQgb24gdGhlIFN0YW5kYXJk cyBUcmFjazoKNHJkLVUgb3IgTUFQPwoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CkFvIFRlbmdoZSwgTmV0d29yayBDZW50ZXIgb2YgSW5uZXIgTW9uZ29saWEgVW5pdmVy c2l0eSAsIE1BUAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQoKCi0tLS0tLS0tLS0KICAgQW8gVGVuZ2hlCiAgIE5ldHdvcmsgQ2VudGVy IG9mIElNVQ== From phdgang@gmail.com Tue Apr 10 01:21:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9B21F8731 for ; Tue, 10 Apr 2012 01:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMBy6NrYeuVO for ; Tue, 10 Apr 2012 01:21:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2570121F872A for ; Tue, 10 Apr 2012 01:21:48 -0700 (PDT) Received: by werb10 with SMTP id b10so3690010wer.31 for ; Tue, 10 Apr 2012 01:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x+OIIPBVDnUM2pM2BkABBLqeOu8sJzAQS5+aJy+KxIw=; b=HaQvvNBphBB8LBHBCGGhezH1pM0NH4H05+76sTDM0J2hw8+/2TP8OdF4Gnd4dV2FI4 kYPZYH0t+RpX9VPid+iMe9op1FzkhxslNCzKKQiWnYocsbXN4DvbG0DXL3i2e94f0SkD r0utUWg6hdeyv5iCsQ8N2lQaqkVN6kjLiS1eyxcmB3kZJ+bcdBW01gPVicFU+oOitQAy g/dRpNq/foMxRL+pklDXTl0WaMkcBlTohYc+DfU10RgI7o9k5zbpJ2vvRPa8LkDg5zZc 2vobuQXY9YhU/oU7FllkV7EOhl8kRUyqOlYSud6aUScZcEekS3lpB7CaxPKS/XxfRo+s 5JRA== MIME-Version: 1.0 Received: by 10.216.132.216 with SMTP id o66mr5838042wei.14.1334046108054; Tue, 10 Apr 2012 01:21:48 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 10 Apr 2012 01:21:48 -0700 (PDT) In-Reply-To: <4F83E358.1090409@go6.si> References: <4F83E358.1090409@go6.si> Date: Tue, 10 Apr 2012 16:21:48 +0800 Message-ID: From: GangChen To: "Jan Zorz @ go6.si" Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:21:53 -0000 Hello Jan, 2012/4/10, Jan Zorz @ go6.si : > On 4/10/12 7:35 AM, GangChen wrote: >> OTOH, I'm still not fully convinced MAP-E and -T should be treated as >> one solution. I like MAP-E or -T to be deployed as a separate >> solution. However, coexistence means operators should have double >> packages inspection toolkits, double operational rules delivery and >> double provisioning costs. In some cases, translation solution is >> exclusive to encapsulation (Please see more in >> draft-dec-stateless-4v6). Even you can implement in the same box, >> that's very inconvenient for operation and subscriber. According >> RFC6180, it is fundamental two different solution. > > Hi, > > I see MAP-E/T combo as one solution, where you "turn the knob" when > implementing it - you choose encap *or* translation mode. Whichever mode > you choose, there is no sign of the other anymore. You could combo 100 solultions as you want. However, that is still seems to me separated solutions. This recalls me 6204bits recommended 6rd and DS-Lite for IPv6 CPE. I prefer to understand that are two solutions, even you can combo them together? BTW, this combo thing is not only CE business, but also corresponding complexity on network sides. As I mentioned above it requires double efforts to operators. BRs Gang > Cheers, Jan > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Tue Apr 10 01:23:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F1121F8733 for ; Tue, 10 Apr 2012 01:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V20KiJaL06W for ; Tue, 10 Apr 2012 01:23:41 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id AE93E21F872E for ; Tue, 10 Apr 2012 01:23:39 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id w8Pc1i00D37Y3f4038Pcrq; Tue, 10 Apr 2012 10:23:37 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-47--743268956 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 10:23:36 +0200 Message-Id: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires , Softwire Chairs Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:23:42 -0000 --Apple-Mail-47--743268956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-10 =E0 09:59, Wojciech Dec a =E9crit : >=20 >=20 > On 10 April 2012 09:31, R=E9mi Despr=E9s = wrote: > Le 2012-04-10 =E0 07:35, GangChen a =E9crit : >=20 > > Hello all, > > > > I have tried to work hard and technically contribute to all = documents: > > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also = cosigned > > with all of them. Please allow me to share some points here. > > > > Basic idea of MAP algorithm were originally built on 4rd and DIVI > > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, > > draft-xli-behave-divi, ..). It was improved by design team members = and > > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and > > MAP-E. Identical address format is used for -T and -E. Backing to = the > > earlier version of MAP document, it included all features (e.g. > > Checksum-neutrality, Vbit etc.). Some people were in favor of it; = some > > thought it not key points. For example, CNP is desirable for > > translation solution. But it's in some extent against current tunnel > > implementation, because encapsulation requires fixed IPv6 address > > representing an endpoint depending on tunnel code today. People have > > to sacrifice this feature in order to keep the benefits of unified > > address format. However, that obviously is of value to transparency. > > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 = Network > > Prefix Translation). > > > > 4rd-U was trying to keep all merits together considering trade-off > > points. It was targeted to be reversible process and full = transparency > > which I guess is important for a stateless design. Meanwhile, some > > additional extensions have to be considered. It's maybe a point to > > bring up "endless discussion" on the list. > > > > I agree with what Yiu said it's hard to simply answer YES or NO at > > this time. Both solutions deserve spending more time, because these > > solutions were born only for half a year. >=20 > +1 >=20 > > Implementation may need more > > time and operation normally will also need to wait. > > > > OTOH, I'm still not fully convinced MAP-E and -T should be treated = as > > one solution. >=20 > +1 > (They were previously considered to be two distinct candidates for = standard track.) >=20 > > I like MAP-E or -T to be deployed as a separate > > solution. However, coexistence means operators should have double > > packages inspection toolkits, double operational rules delivery and > > double provisioning costs. In some cases, translation solution is > > exclusive to encapsulation (Please see more in > > draft-dec-stateless-4v6). > > Even you can implement in the same box, > > that's very inconvenient for operation and subscriber. >=20 > +1 > With MAP-T+E, subscribers wouldn't have the same service depending on = which specification their local operator has chosen, with subtle = differences they shouldn't be concerned with. >=20 > The service would be the same. Note: NAT64 based services are a = reality today, and although you may think differently, no operator calls = "checksum neutrality" a service (with this apparently being the main = feature of 4rd-u).=20 Please avoid inventing my thoughts to then criticize them. The key service offered by 4rd-U is complete IPv4 transparency (a MAP-E = property) combined with compatibility with IPv6-only O&M-tools (a MAP-T = property). Checksum neutrality is just a tool. > What more, given that 4rd-U needs to be combined with BIH, the claim = of it offering some "unified" solution, different operationally from MAP = is bogus. If anything this combination and the fact that there is a = IPv6.1 being created actually makes 4rd-u operations a major challenge = in comparison to what we know of as IPinIP tunnelling or NAT64 with MAP. The need for an IPv6 6.1 is AFAIK an invention of yours, not something = needed by 4rd-U. > Remi, at one point you stated publicly that you would withdraw 4rd-u = should it not gain WG consensus. (*) I said, and confirm, that my personal work is to achieve a single = standard, not to have 3. =20 My appreciation is that 4rd-U is more than ever the best candidate for = this since the idea of having only MAP-T OR MAP-E on standard track has = ben abandoned.=20 =20 > You also chose to quit the MAP design team, where your proposals = failed to get consensus. Conditions in which the 4rd-U approach has been rejected, in an = improvised meeting in Taipei, has already been commented. There has been after that no alternative to a separate work, approved by = the chair.=20 result is the self contained and complete 4rd-U specification, which, = despite aggressive comments made on the list and in meetings, has = already arisen substantial interest in the WG. =20 > At this stage it appears that not only you are not intending to honour = you public statement, See (*) above. > but also in general disputing the process of establishing consensus in = the WG. One is tempted to see it that no consensus other than "consensus = on your terms" is what you really want, and those terms change with each = new draft revision. ??? > Perhaps its time for draft 4rd-X in a new WG... ??? RD >=20 > -Woj. > =20 >=20 > RD >=20 >=20 >=20 > > According > > RFC6180, it is fundamental two different solution. > > > > BRs > > > > Gang > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-47--743268956 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 10 April 2012 09:31, = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
Le 2012-04-10 =E0 07:35, GangChen a =E9crit :

> Hello all,
>
> I have tried to work hard and technically contribute to all = documents:
> MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also = cosigned
> with all of them. Please allow me to share some points here.
>
> Basic idea of MAP algorithm were originally built on 4rd and = DIVI
> (draft-despres-softwire-4rd,draft-murakami-softwire-4rd,
> draft-xli-behave-divi, ..). It was improved by design team members = and
> evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T = and
> MAP-E. Identical address format is used for -T and -E. Backing to = the
> earlier version of MAP document, it included all features (e.g.
> Checksum-neutrality, Vbit etc.). Some people were in favor of it; = some
> thought it not key points. For example, CNP is desirable for
> translation solution. But it's in some extent against current = tunnel
> implementation, because encapsulation requires fixed IPv6 = address
> representing an endpoint depending on tunnel code today. People = have
> to sacrifice this feature in order to keep the benefits of = unified
> address format. However, that obviously is of value to = transparency.
> (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 = Network
> Prefix Translation).
>
> 4rd-U was trying to keep all merits together considering = trade-off
> points. It was targeted to be reversible process and full = transparency
> which I guess is important for a stateless design. Meanwhile, = some
> additional extensions have to be considered. It's maybe a point = to
> bring up "endless discussion" on the list.
>
> I agree with what Yiu said it's hard to simply answer YES or NO = at
> this time. Both solutions deserve spending more time, because = these
> solutions were born only for half a year.

+1

> Implementation may need more
> time and operation normally will also need to wait.
>
> OTOH, I'm still not fully convinced MAP-E and -T should be treated = as
> one solution.

+1
(They were previously considered to be two distinct candidates for = standard track.)

> I like MAP-E or -T to be deployed as a separate
> solution. However, coexistence means operators should have = double
> packages inspection toolkits, double operational rules delivery = and
> double provisioning costs. In some cases, translation solution = is
> exclusive to encapsulation (Please see more in
> draft-dec-stateless-4v6).
> Even you can implement in the same box,
> that's very inconvenient for operation and subscriber.

+1
With MAP-T+E, subscribers wouldn't have the same service depending on = which specification their local operator has chosen, with subtle = differences they shouldn't be concerned = with.

The service would be the same. Note: = NAT64 based services are a reality today, and although you may think = differently, no operator calls "checksum neutrality" a service (with = this apparently being the main feature of 4rd-u). =

Please avoid inventing = my thoughts to then criticize them.
The key service offered by = 4rd-U is complete IPv4 transparency (a MAP-E property) combined with = compatibility with IPv6-only O&M-tools (a MAP-T property). Checksum = neutrality is just a tool.

What more, given that 4rd-U needs to be combined with BIH, the claim of = it offering some "unified" solution, different operationally from MAP is = bogus. If anything this combination and the fact that there is a IPv6.1 = being created actually makes 4rd-u operations a major challenge in = comparison to what we know of as IPinIP tunnelling or NAT64 with = MAP.

The need for an = IPv6 6.1 is AFAIK an invention of yours, not something needed by = 4rd-U.


Remi, at one point you stated publicly that you would withdraw 4rd-u = should it not gain WG consensus. =

(*) I said, and confirm, that my = personal work is to achieve a single standard, not to have 3. =  
My appreciation is that 4rd-U is more than ever the = best candidate for this since the idea of having only MAP-T OR MAP-E on = standard track has ben abandoned. 
 
You also chose to quit the = MAP design team, where your proposals failed to get consensus. =

Conditions in which the 4rd-U = approach has been rejected, in an improvised meeting in Taipei, has = already been commented.

There has been after = that no alternative to a separate work, approved by the = chair. 
result is the self contained and complete 4rd-U = specification, which, despite aggressive comments made on the list and = in meetings, has already arisen substantial interest in the = WG.
 
At this stage it appears that not only you = are not intending to honour you public = statement,

See (*) = above.

but also in general disputing the process of = establishing consensus in the WG. One is tempted to see it that no = consensus other than "consensus on your terms" is what you really want, = and those terms change with each new draft revision. =

???

Perhaps its time for draft = 4rd-X in a new = WG...

???

<= div>RD



-Woj.
 

RD



> According
> RFC6180, it is fundamental two different solution.
>
> BRs
>
> Gang
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-47--743268956-- From wdec.ietf@gmail.com Tue Apr 10 02:21:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40D821F8721 for ; Tue, 10 Apr 2012 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m55+7G+1bZ6C for ; Tue, 10 Apr 2012 02:21:45 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id BF6DB21F8716 for ; Tue, 10 Apr 2012 02:21:44 -0700 (PDT) Received: by qafi31 with SMTP id i31so2448070qaf.15 for ; Tue, 10 Apr 2012 02:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eDggsUO5Bymb5y9DjNM5vhK2+4nLskpHDFR0j+3svtw=; b=KYe6QEenvTVx61stTlFTrVLtVnjb3Kb5jPCfBhmEM2mk8Hzf+DhBKb1cJa43bh9p1P nbeY+bygzvTFUbHxuPeaBaPLavziWeaPQEMF8NJYarxONIZ40zmzZr67SPeVHNDp8EOz 6gGCAMGeEjHSB/gdyPUZrLo1NJbD5yLI5od8l21Tc1+XOME6sFt0+HBvJKf9tpb6lm8v NNgbNzUQlbfXcSgbM8uphxzO6spRKwPGypJFcPru/ZoFyV9PT4BNxPBeITzHw4yPZSGC 4mstnRd+gK/s4wC310kI1MxCWMhCJHISpnWDIJYtw2t7ZlwOYyf9uoWzpfVyO2ravdHW IBCA== MIME-Version: 1.0 Received: by 10.224.179.201 with SMTP id br9mr13451096qab.34.1334049704115; Tue, 10 Apr 2012 02:21:44 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 02:21:44 -0700 (PDT) In-Reply-To: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> Date: Tue, 10 Apr 2012 11:21:44 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30334fd9b9fdb004bd4fa606 Cc: softwires , Softwire Chairs Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:21:48 -0000 --20cf30334fd9b9fdb004bd4fa606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10 April 2012 10:23, R=E9mi Despr=E9s wrote: > > Le 2012-04-10 =E0 09:59, Wojciech Dec a =E9crit : > > > > On 10 April 2012 09:31, R=E9mi Despr=E9s wrote= : > >> Le 2012-04-10 =E0 07:35, GangChen a =E9crit : >> >> > Hello all, >> > >> > I have tried to work hard and technically contribute to all documents: >> > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned >> > with all of them. Please allow me to share some points here. >> > >> > Basic idea of MAP algorithm were originally built on 4rd and DIVI >> > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, >> > draft-xli-behave-divi, ..). It was improved by design team members and >> > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and >> > MAP-E. Identical address format is used for -T and -E. Backing to the >> > earlier version of MAP document, it included all features (e.g. >> > Checksum-neutrality, Vbit etc.). Some people were in favor of it; some >> > thought it not key points. For example, CNP is desirable for >> > translation solution. But it's in some extent against current tunnel >> > implementation, because encapsulation requires fixed IPv6 address >> > representing an endpoint depending on tunnel code today. People have >> > to sacrifice this feature in order to keep the benefits of unified >> > address format. However, that obviously is of value to transparency. >> > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network >> > Prefix Translation). >> > >> > 4rd-U was trying to keep all merits together considering trade-off >> > points. It was targeted to be reversible process and full transparency >> > which I guess is important for a stateless design. Meanwhile, some >> > additional extensions have to be considered. It's maybe a point to >> > bring up "endless discussion" on the list. >> > >> > I agree with what Yiu said it's hard to simply answer YES or NO at >> > this time. Both solutions deserve spending more time, because these >> > solutions were born only for half a year. >> >> +1 >> >> > Implementation may need more >> > time and operation normally will also need to wait. >> > >> > OTOH, I'm still not fully convinced MAP-E and -T should be treated as >> > one solution. >> >> +1 >> (They were previously considered to be two distinct candidates for >> standard track.) >> >> > I like MAP-E or -T to be deployed as a separate >> > solution. However, coexistence means operators should have double >> > packages inspection toolkits, double operational rules delivery and >> > double provisioning costs. In some cases, translation solution is >> > exclusive to encapsulation (Please see more in >> > draft-dec-stateless-4v6). >> > Even you can implement in the same box, >> > that's very inconvenient for operation and subscriber. >> >> +1 >> With MAP-T+E, subscribers wouldn't have the same service depending on >> which specification their local operator has chosen, with subtle >> differences they shouldn't be concerned with. >> > > The service would be the same. Note: NAT64 based services are a reality > today, and although you may think differently, no operator calls "checksu= m > neutrality" a service (with this apparently being the main feature of > 4rd-u). > > > Please avoid inventing my thoughts to then criticize them. > The key service offered by 4rd-U is complete IPv4 transparency (a MAP-E > property) combined with compatibility with IPv6-only O&M-tools (a MAP-T > property). Checksum neutrality is just a tool. > That is not a service as an operator would typically see it. In any case, there is nothing preventing MAP from supporting the purported IPv4 transparency, but so far there has been no consensus that this is actually desirable, or worthwhile. > > What more, given that 4rd-U needs to be combined with BIH, the claim of i= t > offering some "unified" solution, different operationally from MAP is > bogus. If anything this combination and the fact that there is a IPv6.1 > being created actually makes 4rd-u operations a major challenge in > comparison to what we know of as IPinIP tunnelling or NAT64 with MAP. > > > The need for an IPv6 6.1 is AFAIK an invention of yours, not something > needed by 4rd-U. > 4rd-u does change the basic semantics of fields in IPv6, and that is not my invention. > > > Remi, at one point you stated publicly that you would withdraw 4rd-u > should it not gain WG consensus. > > > (*) I said, and confirm, that my personal work is to achieve a single > standard, not to have 3. > My appreciation is that 4rd-U is more than ever the best candidate for > this since the idea of having only MAP-T OR MAP-E on standard track has b= en > abandoned. > 4rd-u requires coupling with BIH, so it's not a single standard by any means (not to mention the changes to IPv6). > > > You also chose to quit the MAP design team, where your proposals failed t= o > get consensus. > > > Conditions in which the 4rd-U approach has been rejected, in an improvise= d > meeting in Taipei, has already been commented. > The design team worked on the principles of common consensus and seeking compromise in an effort to create a solution that addressed the core problems and the agreement of the Beijing meeting in a timely manner. Concepts that are apparently foreign to those who choose first to work on the design team and then abandoned the team to seek the personal advancement of their own solution. As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a worthy idea that should be considered, allowing the rest of the world to proceed with getting things done. -Woj. > > There has been after that no alternative to a separate work, approved by > the chair. > result is the self contained and complete 4rd-U specification, which, > despite aggressive comments made on the list and in meetings, has already > arisen substantial interest in the WG. > > > > At this stage it appears that not only you are not intending to honour yo= u > public statement, > > > See (*) above. > > but also in general disputing the process of establishing consensus in th= e > WG. One is tempted to see it that no consensus other than "consensus on > your terms" is what you really want, and those terms change with each new > draft revision. > > > ??? > > Perhaps its time for draft 4rd-X in a new WG... > > > ??? > > RD > > > > -Woj. > > >> >> RD >> >> >> >> > According >> > RFC6180, it is fundamental two different solution. >> > >> > BRs >> > >> > Gang >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --20cf30334fd9b9fdb004bd4fa606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 10 April 2012 10:23, R=E9mi Despr=E9s= <despres.= remi@laposte.net> wrote:

Le 2012-04-10 =E0 09:59, = Wojciech Dec a =E9crit :



On 10 April 2012 09:31, R=E9mi= Despr=E9s <despres.remi@laposte.net> wrote:
Le 2012-04-10 =E0 07:35, GangChen a =E9crit :

> Hello all,
>
> I have tried to work hard and technically contribute to all documents:=
> MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned<= br> > with all of them. Please allow me to share some points here.
>
> Basic idea of MAP algorithm were originally built on 4rd and DIVI
> (draft-despres-softwire-4rd,draft-murakami-softwire-4rd,
> draft-xli-behave-divi, ..). It was improved by design team members and=
> evolved into "polarized solutions"(as Jan mentioned), i.e. M= AP-T and
> MAP-E. Identical address format is used for -T and -E. Backing to the<= br> > earlier version of MAP document, it included all features (e.g.
> Checksum-neutrality, Vbit etc.). Some people were in favor of it; some=
> thought it not key points. For example, CNP is desirable for
> translation solution. But it's in some extent against current tunn= el
> implementation, because encapsulation requires fixed IPv6 address
> representing an endpoint depending on tunnel code today. People have > to sacrifice this feature in order to keep the benefits of unified
> address format. However, that obviously is of value to transparency. > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network<= br> > Prefix Translation).
>
> 4rd-U was trying to keep all merits together considering trade-off
> points. It was targeted to be reversible process and full transparency=
> which I guess is important for a stateless design. Meanwhile, some
> additional extensions have to be considered. It's maybe a point to=
> bring up "endless discussion" on the list.
>
> I agree with what Yiu said it's hard to simply answer YES or NO at=
> this time. Both solutions deserve spending more time, because these > solutions were born only for half a year.

+1

> Implementation may need more
> time and operation normally will also need to wait.
>
> OTOH, I'm still not fully convinced MAP-E and -T should be treated= as
> one solution.

+1
(They were previously considered to be two distinct candidates for standard= track.)

> I like MAP-E or -T to be deployed as a separate
> solution. However, coexistence means operators should have double
> packages inspection toolkits, double operational rules delivery and > double provisioning costs. In some cases, translation solution is
> exclusive to encapsulation (Please see more in
> draft-dec-stateless-4v6).
> Even you can implement in the same box,
> that's very inconvenient for operation and subscriber.

+1
With MAP-T+E, subscribers wouldn't have the same service depending on w= hich specification their local operator has chosen, with subtle differences= they shouldn't be concerned with.

The service= would be the same. Note: NAT64 based services are a reality today, and alt= hough you may think differently, no operator calls "checksum neutralit= y" a service (with this apparently being the main feature of 4rd-u). <= br>

Please avoid inven= ting my thoughts to then criticize them.
The key service offered = by 4rd-U is complete IPv4 transparency (a MAP-E property) combined with com= patibility with IPv6-only O&M-tools (a MAP-T property). Checksum neutra= lity is just a tool.

That is not a service as an operator woul= d typically see it. In any case, there is nothing preventing MAP from suppo= rting the purported IPv4 transparency, but so far there has been no consens= us that this is actually desirable, or worthwhile.
=A0

What more, given that 4rd-U needs to be combined with BIH, the claim of it = offering some "unified" solution, different operationally from MA= P is bogus. If anything this combination and the fact that there is a IPv6.= 1 being created actually makes 4rd-u operations a major challenge in compar= ison to what we know of as IPinIP tunnelling or NAT64 with MAP.

The need for an IPv6 6.1= is AFAIK an invention of yours, not something needed by 4rd-U.
=

=A04rd-u does change the basic semantics of fie= lds in IPv6, and that is not my invention.


Remi, at one point you stated publicly that you would withdraw 4rd-u should= it not gain WG consensus.

(*= ) I said, and confirm, that my personal work is to achieve a single standar= d, not to have 3. =A0
My appreciation is that 4rd-U is more than ever the best candidate for= this since the idea of having only MAP-T OR MAP-E on standard track has be= n abandoned.=A0

4rd-u requires coupling wi= th BIH, so it's not a single standard by any means (not to mention the = changes to IPv6).
=A0
=A0
You also chose to quit the MAP design team, where your proposals faile= d to get consensus.

Condition= s in which the 4rd-U approach has been rejected, in an improvised meeting i= n Taipei, has already been commented.

The design team worked on the principles of com= mon consensus and seeking compromise in an effort to create a solution that= addressed the core problems and the agreement of the Beijing meeting in a = timely manner. Concepts that are apparently foreign to those who choose fir= st to work on the design team and then abandoned the team to seek the perso= nal advancement of their own solution.
As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a wo= rthy idea that should be considered, allowing the rest of the world to proc= eed with getting things done.

-Woj.
=A0

There has been afte= r that no alternative to a separate work, approved by the chair.=A0
result is the self contained and complete 4rd-U specification, which, de= spite aggressive comments made on the list and in meetings, has already ari= sen substantial interest in the WG.
=A0
=A0
At this stage it appears that not only you = are not intending to honour you public statement,
<= div>
See (*) above.

but also in general disputing the process = of establishing consensus in the WG. One is tempted to see it that no conse= nsus other than "consensus on your terms" is what you really want= , and those terms change with each new draft revision.

???
Perhaps its time= for draft 4rd-X in a new WG...

=
???

RD



-Woj.
=A0

RD



> According
> RFC6180, it is fundamental two different solution.
>
> BRs
>
> Gang
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--20cf30334fd9b9fdb004bd4fa606-- From xing@cernet.edu.cn Tue Apr 10 02:28:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275B021F87BF for ; Tue, 10 Apr 2012 02:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPA9wsScAB3v for ; Tue, 10 Apr 2012 02:28:43 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0601821F87BE for ; Tue, 10 Apr 2012 02:28:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [202.38.102.1]) by centos (Coremail) with SMTP id AQAAf3CbDwN8_INPzAAAAA--.24S2; Tue, 10 Apr 2012 17:25:16 +0800 (CST) Message-ID: <4F83FD4B.1080009@cernet.edu.cn> Date: Tue, 10 Apr 2012 17:28:43 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alain Durand References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf3CbDwN8_INPzAAAAA--.24S2 X-Coremail-Antispam: 1UD129KBjvdXoW7JrWUWFy8XrWUJFW3uw1fXrb_yoWkXrc_Ja 4UXF4UJr1UXr1UJr1UJr1UJr1UJr1UJr1UJr4UJr4UJr17Jr1UJr1UJr4UXr18Xr17Jr1U Jr1UJr1UJr17JjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb58YjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l84ACjcxK6xIIjxv20x vE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280 aVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r1j6r4UM2AIxVAIcxkEcVAq07 x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18 McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7 I2V7IY0VAS07AlzVAYIcxG8wCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41lx2IqxVAq x4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r 1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x 07jcmiiUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:28:44 -0000 ==================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Xing Li, CERNET, your choice: YES ---------------------------------------------------------------------------- ===================================================================== Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------------ Xing Li, CERNET, your choice: MAP ------------------------------------------------------------------------------ ===================================================================== From despres.remi@laposte.net Tue Apr 10 02:35:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F4021F87CC for ; Tue, 10 Apr 2012 02:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKJTVN6YMbon for ; Tue, 10 Apr 2012 02:35:09 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id E39A621F873B for ; Tue, 10 Apr 2012 02:35:08 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id w9b41i00B37Y3f4039b4Gw; Tue, 10 Apr 2012 11:35:07 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-48--738981087 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 11:35:04 +0200 Message-Id: <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires , Softwire Chairs Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:35:10 -0000 --Apple-Mail-48--738981087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-10 =E0 11:21, Wojciech Dec a =E9crit : >=20 >=20 > On 10 April 2012 10:23, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-04-10 =E0 09:59, Wojciech Dec a =E9crit : >=20 >>=20 >>=20 >> On 10 April 2012 09:31, R=E9mi Despr=E9s = wrote: >> Le 2012-04-10 =E0 07:35, GangChen a =E9crit : >>=20 >> > Hello all, >> > >> > I have tried to work hard and technically contribute to all = documents: >> > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also = cosigned >> > with all of them. Please allow me to share some points here. >> > >> > Basic idea of MAP algorithm were originally built on 4rd and DIVI >> > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, >> > draft-xli-behave-divi, ..). It was improved by design team members = and >> > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T = and >> > MAP-E. Identical address format is used for -T and -E. Backing to = the >> > earlier version of MAP document, it included all features (e.g. >> > Checksum-neutrality, Vbit etc.). Some people were in favor of it; = some >> > thought it not key points. For example, CNP is desirable for >> > translation solution. But it's in some extent against current = tunnel >> > implementation, because encapsulation requires fixed IPv6 address >> > representing an endpoint depending on tunnel code today. People = have >> > to sacrifice this feature in order to keep the benefits of unified >> > address format. However, that obviously is of value to = transparency. >> > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 = Network >> > Prefix Translation). >> > >> > 4rd-U was trying to keep all merits together considering trade-off >> > points. It was targeted to be reversible process and full = transparency >> > which I guess is important for a stateless design. Meanwhile, some >> > additional extensions have to be considered. It's maybe a point to >> > bring up "endless discussion" on the list. >> > >> > I agree with what Yiu said it's hard to simply answer YES or NO at >> > this time. Both solutions deserve spending more time, because these >> > solutions were born only for half a year. >>=20 >> +1 >>=20 >> > Implementation may need more >> > time and operation normally will also need to wait. >> > >> > OTOH, I'm still not fully convinced MAP-E and -T should be treated = as >> > one solution. >>=20 >> +1 >> (They were previously considered to be two distinct candidates for = standard track.) >>=20 >> > I like MAP-E or -T to be deployed as a separate >> > solution. However, coexistence means operators should have double >> > packages inspection toolkits, double operational rules delivery and >> > double provisioning costs. In some cases, translation solution is >> > exclusive to encapsulation (Please see more in >> > draft-dec-stateless-4v6). >> > Even you can implement in the same box, >> > that's very inconvenient for operation and subscriber. >>=20 >> +1 >> With MAP-T+E, subscribers wouldn't have the same service depending on = which specification their local operator has chosen, with subtle = differences they shouldn't be concerned with. >>=20 >> The service would be the same. Note: NAT64 based services are a = reality today, and although you may think differently, no operator calls = "checksum neutrality" a service (with this apparently being the main = feature of 4rd-u).=20 >=20 > Please avoid inventing my thoughts to then criticize them. > The key service offered by 4rd-U is complete IPv4 transparency (a = MAP-E property) combined with compatibility with IPv6-only O&M-tools (a = MAP-T property). Checksum neutrality is just a tool. >=20 > That is not a service as an operator would typically see it. In any = case, there is nothing preventing MAP from supporting the purported IPv4 = transparency, but so far there has been no consensus that this is = actually desirable, or worthwhile. > =20 >=20 >> What more, given that 4rd-U needs to be combined with BIH, the claim = of it offering some "unified" solution, different operationally from MAP = is bogus. If anything this combination and the fact that there is a = IPv6.1 being created actually makes 4rd-u operations a major challenge = in comparison to what we know of as IPinIP tunnelling or NAT64 with MAP. >=20 > The need for an IPv6 6.1 is AFAIK an invention of yours, not something = needed by 4rd-U. >=20 > 4rd-u does change the basic semantics of fields in IPv6, ??? (If you would have evidence that everything isn't backward compatible, = please share this information.) > and that is not my invention. >=20 >=20 >> Remi, at one point you stated publicly that you would withdraw 4rd-u = should it not gain WG consensus. >=20 > (*) I said, and confirm, that my personal work is to achieve a single = standard, not to have 3. =20 > My appreciation is that 4rd-U is more than ever the best candidate for = this since the idea of having only MAP-T OR MAP-E on standard track has = ben abandoned.=20 >=20 > 4rd-u requires coupling with BIH, so it's not a single standard by any = means (not to mention the changes to IPv6). 4rd-U is is a Softwire solution (IPv4 via IPv6). IPv4-only to IPv6-only communication is a different subject, already = covered by a standard-track RFC. If there are criticisms of this existing RFC, they belong to a different = forum. RD >> You also chose to quit the MAP design team, where your proposals = failed to get consensus. >=20 > Conditions in which the 4rd-U approach has been rejected, in an = improvised meeting in Taipei, has already been commented. >=20 > The design team worked on the principles of common consensus and = seeking compromise in an effort to create a solution that addressed the = core problems and the agreement of the Beijing meeting in a timely = manner. Concepts that are apparently foreign to those who choose first = to work on the design team and then abandoned the team to seek the = personal advancement of their own solution. > As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is = a worthy idea that should be considered, allowing the rest of the world = to proceed with getting things done. >=20 > -Woj. > =20 >=20 > There has been after that no alternative to a separate work, approved = by the chair.=20 > result is the self contained and complete 4rd-U specification, which, = despite aggressive comments made on the list and in meetings, has = already arisen substantial interest in the WG. > =20 > =20 >> At this stage it appears that not only you are not intending to = honour you public statement, >=20 > See (*) above. >=20 >> but also in general disputing the process of establishing consensus = in the WG. One is tempted to see it that no consensus other than = "consensus on your terms" is what you really want, and those terms = change with each new draft revision. >=20 > ??? >=20 >> Perhaps its time for draft 4rd-X in a new WG... >=20 > ??? >=20 > RD >=20 >=20 >>=20 >> -Woj. >> =20 >>=20 >> RD >>=20 >>=20 >>=20 >> > According >> > RFC6180, it is fundamental two different solution. >> > >> > BRs >> > >> > Gang >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-48--738981087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 10 April 2012 10:23, = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:

Le 2012-04-10 =E0 = 09:59, Wojciech Dec a =E9crit :



On 10 April 2012 09:31, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Le 2012-04-10 =E0 07:35, GangChen a =E9crit :

> Hello all,
>
> I have tried to work hard and technically contribute to all = documents:
> MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also = cosigned
> with all of them. Please allow me to share some points here.
>
> Basic idea of MAP algorithm were originally built on 4rd and = DIVI
> (draft-despres-softwire-4rd,draft-murakami-softwire-4rd,
> draft-xli-behave-divi, ..). It was improved by design team members = and
> evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T = and
> MAP-E. Identical address format is used for -T and -E. Backing to = the
> earlier version of MAP document, it included all features (e.g.
> Checksum-neutrality, Vbit etc.). Some people were in favor of it; = some
> thought it not key points. For example, CNP is desirable for
> translation solution. But it's in some extent against current = tunnel
> implementation, because encapsulation requires fixed IPv6 = address
> representing an endpoint depending on tunnel code today. People = have
> to sacrifice this feature in order to keep the benefits of = unified
> address format. However, that obviously is of value to = transparency.
> (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 = Network
> Prefix Translation).
>
> 4rd-U was trying to keep all merits together considering = trade-off
> points. It was targeted to be reversible process and full = transparency
> which I guess is important for a stateless design. Meanwhile, = some
> additional extensions have to be considered. It's maybe a point = to
> bring up "endless discussion" on the list.
>
> I agree with what Yiu said it's hard to simply answer YES or NO = at
> this time. Both solutions deserve spending more time, because = these
> solutions were born only for half a year.

+1

> Implementation may need more
> time and operation normally will also need to wait.
>
> OTOH, I'm still not fully convinced MAP-E and -T should be treated = as
> one solution.

+1
(They were previously considered to be two distinct candidates for = standard track.)

> I like MAP-E or -T to be deployed as a separate
> solution. However, coexistence means operators should have = double
> packages inspection toolkits, double operational rules delivery = and
> double provisioning costs. In some cases, translation solution = is
> exclusive to encapsulation (Please see more in
> draft-dec-stateless-4v6).
> Even you can implement in the same box,
> that's very inconvenient for operation and subscriber.

+1
With MAP-T+E, subscribers wouldn't have the same service depending on = which specification their local operator has chosen, with subtle = differences they shouldn't be concerned = with.

The service would be the same. Note: = NAT64 based services are a reality today, and although you may think = differently, no operator calls "checksum neutrality" a service (with = this apparently being the main feature of 4rd-u).

Please avoid = inventing my thoughts to then criticize them.
The key service = offered by 4rd-U is complete IPv4 transparency (a MAP-E property) = combined with compatibility with IPv6-only O&M-tools (a MAP-T = property). Checksum neutrality is just a tool.

That is not a service as an operator = would typically see it. In any case, there is nothing preventing MAP = from supporting the purported IPv4 transparency, but so far there has = been no consensus that this is actually desirable, or worthwhile.
 

What more, given that 4rd-U needs to be combined with BIH, the claim of = it offering some "unified" solution, different operationally from MAP is = bogus. If anything this combination and the fact that there is a IPv6.1 = being created actually makes 4rd-u operations a major challenge in = comparison to what we know of as IPinIP tunnelling or NAT64 with = MAP.

The need for an IPv6 = 6.1 is AFAIK an invention of yours, not something needed by = 4rd-U.

 4rd-u does change = the basic semantics of fields in IPv6, =

???
(If you would have = evidence that everything isn't backward compatible, please share this = information.)

and that is not my invention.


Remi, at one point you stated publicly that you would withdraw 4rd-u = should it not gain WG consensus. =

(*) I said, and confirm, = that my personal work is to achieve a single standard, not to have 3. =  
My appreciation is that 4rd-U is more than ever the best candidate = for this since the idea of having only MAP-T OR MAP-E on standard track = has ben abandoned. 

4rd-u requires = coupling with BIH, so it's not a single standard by any means (not to = mention the changes to = IPv6).

4rd-U is is a Softwire = solution (IPv4 via IPv6).
IPv4-only to IPv6-only communication = is a different subject, already covered by a standard-track = RFC.
If there are criticisms of this existing RFC, they belong = to a different = forum.

RD



You also chose to quit the MAP design team, where your proposals = failed to get consensus. =

Conditions in which the = 4rd-U approach has been rejected, in an improvised meeting in Taipei, = has already been commented.

The design team worked on the principles of = common consensus and seeking compromise in an effort to create a = solution that addressed the core problems and the agreement of the = Beijing meeting in a timely manner. Concepts that are apparently foreign = to those who choose first to work on the design team and then abandoned = the team to seek the personal advancement of their own solution.
As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a = worthy idea that should be considered, allowing the rest of the world to = proceed with getting things = done.

-Woj.
 

There has been = after that no alternative to a separate work, approved by the = chair. 
result is the self contained and complete 4rd-U = specification, which, despite aggressive comments made on the list and = in meetings, has already arisen substantial interest in the WG.
 
 
At this stage it appears that not only = you are not intending to honour you public = statement,

See (*) = above.

but also in general disputing the = process of establishing consensus in the WG. One is tempted to see it = that no consensus other than "consensus on your terms" is what you = really want, and those terms change with each new draft revision.

???

Perhaps its time for draft 4rd-X in a new = WG...

???

RD



-Woj.
 

RD



> According
> RFC6180, it is fundamental two different solution.
>
> BRs
>
> Gang
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-48--738981087-- From despres.remi@laposte.net Tue Apr 10 02:37:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1621F8702 for ; Tue, 10 Apr 2012 02:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXUTHO5iNEqy for ; Tue, 10 Apr 2012 02:37:31 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6446F21F855F for ; Tue, 10 Apr 2012 02:37:31 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id w9dW1i00737Y3f4039dWZt; Tue, 10 Apr 2012 11:37:30 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 10 Apr 2012 11:37:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> References: To: Softwires WG X-Mailer: Apple Mail (2.1084) Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:37:32 -0000 Hello, all, We have heard many times that MAP is completely specified, and has been = extensively tested. Yet: - mapping rules of tested configurations have not been provided - several missing points of the MAP-T+E specification have been = identified (ref (*) = www.ietf.org/mail-archive/web/softwires/current/msg04049.html). This mail is just about ONE of these, the hub-and-spoke issue. It has been discussed several times but AFAIK still without a complete = answer. The difficulty is that: - The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke. - According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules". - As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)". Questions I have are then: - Is the choice provisioned explicitly, implicitly, or possibly both? - How? - Which tests have confirmed that it worked? Answer by any one who asserts he or she understands how MAP works will = be welcome. Thanks, RD > De : Ole Tr=F8an > Date : 2012-03-14 14:29 > =C0 : R=E9mi Despr=E9s > Cc : Tomasz Mrugalski , Softwires WG = > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in = MAP >=20 > Remi, >=20 >> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication: >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how = do they know whether their ISP expects direct paths between them (mesh) = or BR hairpinning (hub-and-spoke)? >>=20 >=20 > that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules). >=20 > cheers, > Ole From wdec.ietf@gmail.com Tue Apr 10 02:51:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2F21F85D8 for ; Tue, 10 Apr 2012 02:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hABlqUjs4zZk for ; Tue, 10 Apr 2012 02:51:47 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEE721F85A8 for ; Tue, 10 Apr 2012 02:51:47 -0700 (PDT) Received: by qaea16 with SMTP id a16so2035568qae.10 for ; Tue, 10 Apr 2012 02:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=04zJHk2xfi2u/Eq6rk5mfbkhy46KB4FGgntQUipPupU=; b=TvTX5XvuPJ1VpKFUpaQpMYvSKXA8XvCIVhm3I3Clu+G5X+YEDM05E3i/duaAUqIwmI ScAS8b/kJEkxyjFVehdYYhBjQ0yi1/lJ1G0L8h6zbkEApzNVA5/guPTl4HVJF4s7NiEO uvO86jGlloRTv6W+PuIUvq944fcfHeZ0XD/QxS1j6ZoN3YlP46gguxyvyGz55hu9mAOA wf97z2evY3C6XPxEN4kC8Y50Raa3YYc4WQOM5bmgBZIfEs54TIJGGkTm1uFIyLgjQaGk zJgku74qFj/n7JVMfj9xRrg5CcydXxdcQBv/cSdSKV3miKz4tL3un16X0XONjpH4OXH7 yLdQ== MIME-Version: 1.0 Received: by 10.229.136.4 with SMTP id p4mr4111350qct.131.1334051506633; Tue, 10 Apr 2012 02:51:46 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 02:51:46 -0700 (PDT) In-Reply-To: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> Date: Tue, 10 Apr 2012 11:51:46 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c70fc8d2a3b7f04bd5012c2 Cc: Softwires WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:51:48 -0000 --00248c70fc8d2a3b7f04bd5012c2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, you're apparently confusing matters. There is no need to have a DHCPv6 option, or a million node deployment to test MAP implementations. DS-lite is a good example, with implementations and standards track before the DHCPv6 option. Needless to say, if you're implying that tests of MAP without testing the standards based DHCPv6 option are insufficient, then any test of 4rd-u or anything for that matter without using the fully standards DHCP option would be equally flawed. At the very least however, MAP does not need to prove on thing: Compatibility with IPv6, which 4rd-u would need to. -Woj. On 10 April 2012 11:37, R=E9mi Despr=E9s wrote: > Hello, all, > > We have heard many times that MAP is completely specified, and has been > extensively tested. > Yet: > - mapping rules of tested configurations have not been provided > - several missing points of the MAP-T+E specification have been identifie= d > (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html). > > This mail is just about ONE of these, the hub-and-spoke issue. > It has been discussed several times but AFAIK still without a complete > answer. > > The difficulty is that: > - The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chose= n > topology is mesh or hub-and-spoke. > - According to the MAP-address-and-port draft, "each MAP node in the > domain has the same set of rules". > - As answered in the mail below, the choice "needs to be provisioned. > either explicitly or implicitly (via the rules)". > > Questions I have are then: > - Is the choice provisioned explicitly, implicitly, or possibly both? > - How? > - Which tests have confirmed that it worked? > > Answer by any one who asserts he or she understands how MAP works will be > welcome. > > Thanks, > RD > > > > > > > > > De : Ole Tr=F8an > > Date : 2012-03-14 14:29 > > =C0 : R=E9mi Despr=E9s > > Cc : Tomasz Mrugalski , Softwires WG < > softwires@ietf.org> > > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in M= AP > > > > Remi, > > > >> I couldn't figure out by how CEs can be required to work hub-and-spoke > without some DHCPv6 indication: > >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how > do they know whether their ISP expects direct paths between them (mesh) o= r > BR hairpinning (hub-and-spoke)? > >> > > > > that's correct it needs to be provisioned. either explicitly or > implicitly (via the rules). > > > > cheers, > > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00248c70fc8d2a3b7f04bd5012c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi,

you're apparently confusing matters. There is no need to h= ave a DHCPv6 option, or a million node deployment to test MAP implementatio= ns. DS-lite is a good example, with implementations and standards track bef= ore the DHCPv6 option.

Needless to say, if you're implying that tests of MAP without testi= ng the standards based DHCPv6 option are insufficient, then any test of 4rd= -u or anything for that matter without using the fully standards DHCP optio= n would be equally flawed.
At the very least however, MAP does not need to prove on thing: Compatibili= ty with IPv6, which 4rd-u would need to.

-Woj.

On 10 April 2012 11:37, R=E9mi Despr=E9s <= ;despres.remi@laposte.net&g= t; wrote:
Hello, all,

We have heard many times that MAP is completely specified, and has been ext= ensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been identified = (ref (*) www.ietf.org/mail-archive/web/softwires/cu= rrent/msg04049.html).

This mail is just about ONE of these, the hub-and-spoke issue.
It has been discussed several times but AFAIK still without a complete answ= er.

The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chosen = topology is mesh or hub-and-spoke.
- According to the MAP-address-and-port draft, "each MAP node in the d= omain has the same set of rules".
- As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)".

Questions I have are then:
- Is the choice provisioned explicitly, implicitly, or possibly both?
- How?
- Which tests have confirmed that it worked?

Answer by any one who asserts he or she understands how MAP works will be w= elcome.

Thanks,
RD







> De : Ole Tr=F8an <ot@cisco.com&= gt;
> Date : 2012-03-14 14:29
> =C0 : R=E9mi Despr=E9s <despres.remi@laposte.net>
> Cc : Tomasz Mrugalski <tomasz.mrugalski@gmail.com>, Softwires WG <softwires@ietf.org>
> Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in = MAP
>
> Remi,
>
>> I couldn't figure out by how CEs can be required to work hub-a= nd-spoke without some DHCPv6 indication:
>> - If two CEs apply the same BMR to their delegated IPv6 prefixes, = how do they know whether their ISP expects direct paths between them (mesh)= or BR hairpinning (hub-and-spoke)?
>>
>
> that's correct it needs to be provisioned. either explicitly or im= plicitly (via the rules).
>
> cheers,
> Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00248c70fc8d2a3b7f04bd5012c2-- From fibrib@gmail.com Tue Apr 10 02:53:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F022E21F880B for ; Tue, 10 Apr 2012 02:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO1zoW-5heOL for ; Tue, 10 Apr 2012 02:53:55 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5457721F8807 for ; Tue, 10 Apr 2012 02:53:55 -0700 (PDT) Received: by qaea16 with SMTP id a16so2036441qae.10 for ; Tue, 10 Apr 2012 02:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kRdZybl8s6XWn9MY6J+MdUF536+DIPkUPbH9gIKA4Ok=; b=Rg860xRwHVf0CFmc9I+3VzLrKy+CViGTPApWXymzMTXlVRD5OCiFIu4PA+K/GrGV1E 0H2NNmQvoHQTVtQ0soNO1dgMH9enAtMVutM7PcQgcVHJrFh3UFnH5Dl4tiTmZXEt7Dap N8ZuJ0wgvGggCLMPlSvtQX1klMToBrxt1sP/Yp8GL227pNjfM398PfwqlPXORNzU5L35 9uSeoa9pH+O7+wT9FJ8DOTO31zxWUen/1fDMo8V8wlCMsc4W96IUWJDqzrzU74zaosgG UxxTN60OCOWb2k7h+ZN/lFYli55wJoI6H/qTTPSH9nqKqZX1jcVRgr3zem8yG/2ObsdB 9BqA== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr13696553qab.36.1334051634885; Tue, 10 Apr 2012 02:53:54 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 10 Apr 2012 02:53:54 -0700 (PDT) In-Reply-To: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 09:53:54 +0000 Message-ID: From: Maoke To: Softwires-wg Content-Type: multipart/alternative; boundary=20cf300faff5cf35a204bd501925 Subject: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:53:56 -0000 --20cf300faff5cf35a204bd501925 Content-Type: text/plain; charset=ISO-8859-1 hi all, i made an internet-draft discussing the semantics issue of 4rd-U. comments, recommendations, technical discussions are welcome. http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 thanks and regards, maoke ---------- Forwarded message ---------- From: Date: 2012/4/10 Subject: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt To: fibrib@gmail.com A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been successfully submitted by Maoke Chen and posted to the IETF repository. Filename: draft-chen-softwire-4rd-u-comment Revision: 00 Title: A Commentary on 4rd-U Architecture and Semantics Creation date: 2012-04-10 WG ID: Individual Submission Number of pages: 19 Abstract: 4rd-U is proposed as an effort of unifying encapsulation and double translation solutions for the softwire of IPv4 over IPv6 domain. This attempt introduces new behaviors in the Internet transition architecture as well as semantics other than that of well-known Internet protocols. This documents provides a commentary on the semantic changes and their impacts. The IETF Secretariat --20cf300faff5cf35a204bd501925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi all,=A0

i made an internet-draft discussin= g the semantics issue of 4rd-U. comments, recommendations, technical discus= sions are welcome.=A0


thanks and regards,
maoke

---------- Forwarded message ----------
From: <internet-drafts@i= etf.org>
Date: 2012/4/10
Subject: New Version Notification for draft-chen-softwir= e-4rd-u-comment-00.txt
To: fibrib@gm= ail.com


A new version of I-D, draft-chen-softwire-4rd-u-comm= ent-00.txt has been successfully submitted by Maoke Chen and posted to the = IETF repository.

Filename: =A0 =A0 =A0 =A0draft-chen-softwire-4rd-u-comment
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A Commentary on 4rd-U Architecture and Semantics=
Creation date: =A0 2012-04-10
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 19

Abstract:
=A0 4rd-U is proposed as an effort of unifying encapsulation and double =A0 translation solutions for the softwire of IPv4 over IPv6 domain.
=A0 This attempt introduces new behaviors in the Internet transition
=A0 architecture as well as semantics other than that of well-known
=A0 Internet protocols. =A0This documents provides a commentary on the
=A0 semantic changes and their impacts.




The IETF Secretariat

--20cf300faff5cf35a204bd501925-- From despres.remi@laposte.net Tue Apr 10 03:01:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6E21F883E for ; Tue, 10 Apr 2012 03:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvje4JHVRRSu for ; Tue, 10 Apr 2012 03:01:30 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id B76B721F881A for ; Tue, 10 Apr 2012 03:01:29 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id wA1P1i00F37Y3f403A1Qj5; Tue, 10 Apr 2012 12:01:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-49--737401646 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 12:01:23 +0200 Message-Id: <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:01:31 -0000 --Apple-Mail-49--737401646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Wojciech, This isn't answers to questions I asked. They remain open. RD Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9crit : > Remi, >=20 > you're apparently confusing matters. There is no need to have a DHCPv6 = option, or a million node deployment to test MAP implementations. = DS-lite is a good example, with implementations and standards track = before the DHCPv6 option. >=20 > Needless to say, if you're implying that tests of MAP without testing = the standards based DHCPv6 option are insufficient, then any test of = 4rd-u or anything for that matter without using the fully standards DHCP = option would be equally flawed.=20 > At the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need to. >=20 > -Woj. >=20 > On 10 April 2012 11:37, R=E9mi Despr=E9s = wrote: > Hello, all, >=20 > We have heard many times that MAP is completely specified, and has = been extensively tested. > Yet: > - mapping rules of tested configurations have not been provided > - several missing points of the MAP-T+E specification have been = identified (ref (*) = www.ietf.org/mail-archive/web/softwires/current/msg04049.html). >=20 > This mail is just about ONE of these, the hub-and-spoke issue. > It has been discussed several times but AFAIK still without a complete = answer. >=20 > The difficulty is that: > - The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke. > - According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules". > - As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)". >=20 > Questions I have are then: > - Is the choice provisioned explicitly, implicitly, or possibly both? > - How? > - Which tests have confirmed that it worked? >=20 > Answer by any one who asserts he or she understands how MAP works will = be welcome. >=20 > Thanks, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > De : Ole Tr=F8an > > Date : 2012-03-14 14:29 > > =C0 : R=E9mi Despr=E9s > > Cc : Tomasz Mrugalski , Softwires WG = > > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation = in MAP > > > > Remi, > > > >> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication: > >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, = how do they know whether their ISP expects direct paths between them = (mesh) or BR hairpinning (hub-and-spoke)? > >> > > > > that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules). > > > > cheers, > > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-49--737401646 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Remi,

you're apparently confusing matters. There is = no need to have a DHCPv6 option, or a million node deployment to test = MAP implementations. DS-lite is a good example, with implementations and = standards track before the DHCPv6 option.

Needless to say, if you're implying that tests of MAP without = testing the standards based DHCPv6 option are insufficient, then any = test of 4rd-u or anything for that matter without using the fully = standards DHCP option would be equally flawed.
At the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need = to.

-Woj.

On 10 April 2012 = 11:37, R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
Hello, all,

We have heard many times that MAP is completely specified, and has been = extensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been = identified (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049= .html).

This mail is just about ONE of these, the hub-and-spoke issue.
It has been discussed several times but AFAIK still without a complete = answer.

The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke.
- According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules".
- As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)".

Questions I have are then:
- Is the choice provisioned explicitly, implicitly, or possibly = both?
- How?
- Which tests have confirmed that it worked?

Answer by any one who asserts he or she understands how MAP works will = be welcome.

Thanks,
RD







> De : Ole Tr=F8an <ot@cisco.com>
> Date : 2012-03-14 14:29
> =C0 : R=E9mi Despr=E9s <despres.remi@laposte.net><= br> > Cc : Tomasz Mrugalski <tomasz.mrugalski@gmail.com&= gt;, Softwires WG <softwires@ietf.org>
> Objet : R=E9p : [Softwires] Question about hub-and-spoke operation = in MAP
>
> Remi,
>
>> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication:
>> - If two CEs apply the same BMR to their delegated IPv6 = prefixes, how do they know whether their ISP expects direct paths = between them (mesh) or BR hairpinning (hub-and-spoke)?
>>
>
> that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules).
>
> cheers,
> Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-49--737401646-- From despres.remi@laposte.net Tue Apr 10 03:04:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD54E21F8830 for ; Tue, 10 Apr 2012 03:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AbxB-KraYI5 for ; Tue, 10 Apr 2012 03:04:12 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id CA7E621F8819 for ; Tue, 10 Apr 2012 03:04:11 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id wA4A1i00H37Y3f403A4A0M; Tue, 10 Apr 2012 12:04:10 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-50--737235328 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 12:04:10 +0200 Message-Id: <3A6D428D-7E19-4D69-9DD8-4D827E5EB578@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:04:12 -0000 --Apple-Mail-50--737235328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Maoke? Thanks for this draft. Serious technical work is the best way to progress. I will work on it and comment after that. Regards, RD =20 Le 2012-04-10 =E0 11:53, Maoke a =E9crit : > hi all,=20 >=20 > i made an internet-draft discussing the semantics issue of 4rd-U. = comments, recommendations, technical discussions are welcome.=20 >=20 > http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 >=20 > thanks and regards, > maoke >=20 > ---------- Forwarded message ---------- > From: > Date: 2012/4/10 > Subject: New Version Notification for = draft-chen-softwire-4rd-u-comment-00.txt > To: fibrib@gmail.com >=20 >=20 > A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has = been successfully submitted by Maoke Chen and posted to the IETF = repository. >=20 > Filename: draft-chen-softwire-4rd-u-comment > Revision: 00 > Title: A Commentary on 4rd-U Architecture and Semantics > Creation date: 2012-04-10 > WG ID: Individual Submission > Number of pages: 19 >=20 > Abstract: > 4rd-U is proposed as an effort of unifying encapsulation and double > translation solutions for the softwire of IPv4 over IPv6 domain. > This attempt introduces new behaviors in the Internet transition > architecture as well as semantics other than that of well-known > Internet protocols. This documents provides a commentary on the > semantic changes and their impacts. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-50--737235328 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Maoke?

Thanks for this draft.
Serious = technical work is the best way to progress.
I will work on it = and comment after = that.

Regards,
RD

<= div>  
Le 2012-04-10 =E0 11:53, Maoke a =E9crit = :

hi all, 

i made an = internet-draft discussing the semantics issue of 4rd-U. comments, = recommendations, technical discussions are = welcome. 


thanks and regards,
maoke

---------- Forwarded message ----------
From: = <internet-drafts@ietf.org><= /span>
Date: 2012/4/10
Subject: New Version Notification for = draft-chen-softwire-4rd-u-comment-00.txt
To: fibrib@gmail.com


A new = version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been = successfully submitted by Maoke Chen and posted to the IETF = repository.

Filename:       =  draft-chen-softwire-4rd-u-comment
Revision:        00
Title:           A Commentary on 4rd-U = Architecture and Semantics
Creation date:   2012-04-10
WG ID:           Individual Submission
Number of pages: 19

Abstract:
  4rd-U is proposed as an effort of unifying encapsulation and = double
  translation solutions for the softwire of IPv4 over IPv6 = domain.
  This attempt introduces new behaviors in the Internet = transition
  architecture as well as semantics other than that of = well-known
  Internet protocols.  This documents provides a commentary = on the
  semantic changes and their impacts.




The IETF Secretariat

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-50--737235328-- From fibrib@gmail.com Tue Apr 10 03:04:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03221F883E for ; Tue, 10 Apr 2012 03:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlbmw-YjmfW6 for ; Tue, 10 Apr 2012 03:04:18 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AC21F8836 for ; Tue, 10 Apr 2012 03:04:18 -0700 (PDT) Received: by qafi31 with SMTP id i31so2471264qaf.15 for ; Tue, 10 Apr 2012 03:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9SjiakvrQOB/OUiBCR7bz0+yInwQQbHFPoKWA+ws0eI=; b=FZc6OvPS+4YKtTMNPC3VOnTS3DEov80siVrRUH+f5oF+rBaZbi0qM+pAGPYitlAusx FqwH0v5G5jICoLY16+Puh5v598kde9MV6aLDmuDz3JhDc/usX7buxM48MSr4dPc5XJVT wm3N21xUUvBd8/2zcRNlu0O9YRz+jlqoyRo5l1LCqFlFnuXrk99D5wmB39RREWZlIsIk tLoj/ObNQAq/pFsxjkCGCu/EBMuQUWRkckTLuR4nbdXvMtj+X19mMLhloijuiX0F9zo6 oQ5EMidxRCwMX1EyPTnyq2WnsYcojd3XQDntcIAIylrf8y/Gm4DpJFBf73+7pCs5YIjS Ho4A== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr13561923qab.49.1334052258036; Tue, 10 Apr 2012 03:04:18 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 10 Apr 2012 03:04:17 -0700 (PDT) In-Reply-To: <0FEE0192-65C0-4B17-BD8E-B2CE33870ECC@laposte.net> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> <0FEE0192-65C0-4B17-BD8E-B2CE33870ECC@laposte.net> Date: Tue, 10 Apr 2012 10:04:17 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dcfc9f3b9e404bd503ec7 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:04:19 -0000 --485b397dcfc9f3b9e404bd503ec7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/9 R=E9mi Despr=E9s > > 2012-04-09 11:52, Maoke: > > 2012/4/9 Sheng Jiang > >> Without any objection to MAP, we just start to coding 4rd-u and help to >> improve it. >> > > fine. we'd love to see it out with good amount of data and good amount of > feedback from testing operators. > > > > if you invite me to test, i'd love to provide challenging scenarios. > > > Providing such challenging scenarios to the WG will be welcome. > That's a way to make progress. > thanks, Remi, for the encouragement. i think the first step is to clarify "what is needed to be ensured through the test". for this purpose, i made out an I-D (as i already posted to the wg), discussing the semantics issue of 4rd-U according to my understanding up to now. i think i wrote that as neutral as possible, and took my best effort in avoiding to write what i have not understood. if you (also others) find anything misunderstood, please don't hesitate to point out. thanks, maoke > Thanks, > > --485b397dcfc9f3b9e404bd503ec7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/9 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>

2012-04-09 =A011:= 52, Maoke:

2012/4/9 Sheng Jiang <jiangsheng@huawei.com>

Without any objectio= n to MAP, we just start to coding 4rd-u and help to improve it.


fine. we'd love to see it out wi= th good amount of data and good amount of feedback from testing operators. =


if you invite me to test, i'd love to provide challenging scenario= s.

Providing such challen= ging scenarios to the WG will be welcome.
That's a way to mak= e progress.

thanks, Remi, for the encourag= ement. i think the first step is to clarify "what is needed to be ensu= red through the test". for this purpose, i made out an I-D (as i alrea= dy posted to the wg), discussing the semantics issue of 4rd-U according to = my understanding up to now. i think i wrote that as neutral as possible, an= d took my best effort in avoiding to write what i have not understood. if y= ou (also others) find anything misunderstood, please don't hesitate to = point out.=A0

thanks,=A0
maoke
=A0
Thanks,=


--485b397dcfc9f3b9e404bd503ec7-- From wdec.ietf@gmail.com Tue Apr 10 03:07:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD821F87EF for ; Tue, 10 Apr 2012 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUOhuOpeeoxT for ; Tue, 10 Apr 2012 03:07:53 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id DC16721F87E9 for ; Tue, 10 Apr 2012 03:07:50 -0700 (PDT) Received: by qafi31 with SMTP id i31so2473376qaf.15 for ; Tue, 10 Apr 2012 03:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s5fOk6xrPMbYF5SKD6AauwGnTD/VUFW635ELFqZCA5g=; b=IVyPPTedp0tYCkl/lzXYbwKjQcRBgHCtqD6KL+2oww3hrEq8DYTAQBN/AM3oEg+i5w bqIjelmFlOwoOS8r3En0E2v20pjbQeVlxPDwSVxNm1xRiw5XsWfrjgBPOCUnYb5M7ndU mBu6u1/UX/FbCrUpcdIPjgwM3hrB45bUhuvQR/18X4eWL6Y5QQGMYpUXvCdeynyxJeDy HuPJ7YnxpK1jhv/VWm9yZOjBwLSpWjv+LuNO0VgK5IIsgwtW+xJWp8bvUlCdga0esqI+ 5jsigGNTCh1eIS/HK2G+kUxinRrcPk0iBjkD8FQsh+SRBHEnADJG340iyjkDlXqm4SlG 2Hbw== MIME-Version: 1.0 Received: by 10.224.179.201 with SMTP id br9mr13605100qab.34.1334052470255; Tue, 10 Apr 2012 03:07:50 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 03:07:50 -0700 (PDT) In-Reply-To: <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> Date: Tue, 10 Apr 2012 12:07:50 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30334fd999f08304bd504bc6 Cc: Softwires WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:07:54 -0000 --20cf30334fd999f08304bd504bc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI based configuration including scripting was applied. Question closed. -Woj. On 10 April 2012 12:01, R=E9mi Despr=E9s wrote: > Wojciech, > > This isn't answers to questions I asked. > They remain open. > > RD > > Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9crit : > > Remi, > > you're apparently confusing matters. There is no need to have a DHCPv6 > option, or a million node deployment to test MAP implementations. DS-lite > is a good example, with implementations and standards track before the > DHCPv6 option. > > Needless to say, if you're implying that tests of MAP without testing the > standards based DHCPv6 option are insufficient, then any test of 4rd-u or > anything for that matter without using the fully standards DHCP option > would be equally flawed. > At the very least however, MAP does not need to prove on thing: > Compatibility with IPv6, which 4rd-u would need to. > > -Woj. > > On 10 April 2012 11:37, R=E9mi Despr=E9s wrote= : > >> Hello, all, >> >> We have heard many times that MAP is completely specified, and has been >> extensively tested. >> Yet: >> - mapping rules of tested configurations have not been provided >> - several missing points of the MAP-T+E specification have been >> identified (ref (*) >> www.ietf.org/mail-archive/web/softwires/current/msg04049.html). >> >> This mail is just about ONE of these, the hub-and-spoke issue. >> It has been discussed several times but AFAIK still without a complete >> answer. >> >> The difficulty is that: >> - The MAP-DHCPv6 draft has no parameter to indicate whether the >> ISP-chosen topology is mesh or hub-and-spoke. >> - According to the MAP-address-and-port draft, "each MAP node in the >> domain has the same set of rules". >> - As answered in the mail below, the choice "needs to be provisioned. >> either explicitly or implicitly (via the rules)". >> >> Questions I have are then: >> - Is the choice provisioned explicitly, implicitly, or possibly both? >> - How? >> - Which tests have confirmed that it worked? >> >> Answer by any one who asserts he or she understands how MAP works will b= e >> welcome. >> >> Thanks, >> RD >> >> >> >> >> >> >> >> > De : Ole Tr=F8an >> > Date : 2012-03-14 14:29 >> > =C0 : R=E9mi Despr=E9s >> > Cc : Tomasz Mrugalski , Softwires WG < >> softwires@ietf.org> >> > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in = MAP >> > >> > Remi, >> > >> >> I couldn't figure out by how CEs can be required to work hub-and-spok= e >> without some DHCPv6 indication: >> >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how >> do they know whether their ISP expects direct paths between them (mesh) = or >> BR hairpinning (hub-and-spoke)? >> >> >> > >> > that's correct it needs to be provisioned. either explicitly or >> implicitly (via the rules). >> > >> > cheers, >> > Ole >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --20cf30334fd999f08304bd504bc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI = based configuration including scripting was applied.

Question closed= .

-Woj.

On 10 April 2012 12:01, R= =E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Wojciech= ,

This isn't answers to questions I asked.
They remain open.

RD

Le 2012-04-10 =E0 11:51, Woj= ciech Dec a =E9crit :

Remi,

you're apparently confusing matters. There is no need= to have a DHCPv6 option, or a million node deployment to test MAP implemen= tations. DS-lite is a good example, with implementations and standards trac= k before the DHCPv6 option.

Needless to say, if you're implying that tests of MAP without testi= ng the standards based DHCPv6 option are insufficient, then any test of 4rd= -u or anything for that matter without using the fully standards DHCP optio= n would be equally flawed.
At the very least however, MAP does not need to prove on thing: Compatibili= ty with IPv6, which 4rd-u would need to.

-Woj.

On 10 April 2012 11:37, R=E9mi Despr=E9s <= ;despres.remi= @laposte.net> wrote:
Hello, all,

We have heard many times that MAP is completely specified, and has been ext= ensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been identified = (ref (*) www.ietf.org/mail-archive/web/softwires/cu= rrent/msg04049.html).

This mail is just about ONE of these, the hub-and-spoke issue.
It has been discussed several times but AFAIK still without a complete answ= er.

The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chosen = topology is mesh or hub-and-spoke.
- According to the MAP-address-and-port draft, "each MAP node in the d= omain has the same set of rules".
- As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)".

Questions I have are then:
- Is the choice provisioned explicitly, implicitly, or possibly both?
- How?
- Which tests have confirmed that it worked?

Answer by any one who asserts he or she understands how MAP works will be w= elcome.

Thanks,
RD







> De : Ole Tr=F8an <ot@cisco.com>
> Date : 2012-03-14 14:29
> =C0 : R=E9mi Despr=E9s <despres.remi@laposte.net>
> Cc : Tomasz Mrugalski <tomasz.mrugalski@gmail.com>, Softwires WG <softwires@ietf.org>
> Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in = MAP
>
> Remi,
>
>> I couldn't figure out by how CEs can be required to work hub-a= nd-spoke without some DHCPv6 indication:
>> - If two CEs apply the same BMR to their delegated IPv6 prefixes, = how do they know whether their ISP expects direct paths between them (mesh)= or BR hairpinning (hub-and-spoke)?
>>
>
> that's correct it needs to be provisioned. either explicitly or im= plicitly (via the rules).
>
> cheers,
> Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--20cf30334fd999f08304bd504bc6-- From wdec.ietf@gmail.com Tue Apr 10 03:26:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D621F85A8 for ; Tue, 10 Apr 2012 03:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1dQ1Q9uy2oA for ; Tue, 10 Apr 2012 03:26:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3521F84DD for ; Tue, 10 Apr 2012 03:26:52 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3523905qcs.31 for ; Tue, 10 Apr 2012 03:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IF55treoFJZwili0uw+na5LefJwgSd8nTZVGF872rHM=; b=gTHuRIpuPTIOj5s3u075vdTXSuwoeig04Fw1YH9OVq6hqcqfuqueTuzWXUdNw7SBPD 7CjjoM/633MrH6fkchiNu03GY9t/OvQYbvpT7IPs2SEOA3LJeEGA3L0QnnQV/VgL9nhW 90W0si77tchp9XrOJZIm0uRrazydHp2GOSQ15YXQw1DrTa8Ur5DqLxgKdsmUGj+DT7fP fVUUTt4nwC8/u93DzWoKE/1AxfsGK4JtDxJcIM0y6Bj0+PZYpSaXLBRrMKYrKPG414iW NpE0FVkuOPeNSyd1EOoLA/bPPpv1GLiklFhN8TTH27wIa9JQKt+mD9ud4NfYnNw9jCHL icpQ== MIME-Version: 1.0 Received: by 10.224.101.197 with SMTP id d5mr10353314qao.8.1334053611924; Tue, 10 Apr 2012 03:26:51 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 03:26:51 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Tue, 10 Apr 2012 12:26:51 +0200 Message-ID: From: Wojciech Dec To: Alain Durand Content-Type: multipart/alternative; boundary=20cf30668195a66b1004bd508fba Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:26:53 -0000 --20cf30668195a66b1004bd508fba Content-Type: text/plain; charset=ISO-8859-1 On 4 April 2012 23:14, Alain Durand wrote: > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > ---------------------------------------------------------------------------- > Wojciech Dec, Cisco: YES > > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > ------------------------------------------------------------------------------ > Wojciech Dec, Cisco: MAP > > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf30668195a66b1004bd508fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 4 April 2012 23:14, Alain Durand <adurand@juniper.ne= t> wrote:
Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) =A0and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should mak= e this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

---------------------------------------------------------------------------= -
Wojciech Dec, Cisco: YES
---------------------------------------------------------------------------= -


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP?

---------------------------------------------------------------------------= ---
Wojciech Dec, Cisco: MAP
---------------------------------------------------------------------------= ---

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf30668195a66b1004bd508fba-- From leaf.y.yeh@huawei.com Tue Apr 10 04:20:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBB21F8601 for ; Tue, 10 Apr 2012 04:20:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mof1cI1-VaZf for ; Tue, 10 Apr 2012 04:20:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAF3021F85F6 for ; Tue, 10 Apr 2012 04:20:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC30544; Tue, 10 Apr 2012 07:20:22 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:18:38 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:18:40 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 19:18:33 +0800 From: Leaf yeh To: Alain Durand , "softwires@ietf.org WG" Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgDo83CAAC/ZtfA= Date: Tue, 10 Apr 2012 11:18:33 +0000 Message-ID: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:20:23 -0000 TGVhZiBZZWgsIG15c2VsZiwgWWVzLCBNQVANCg0KLSBqdXN0IGJlY2F1c2UgSSByZWFkIGEgbGl0 dGxlIG1vcmUgTUFQIHRoYW4gNHJkLVUuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGFpbiBEdXJhbmQNClNlbnQ6IFR1ZXNkYXksIEFw cmlsIDEwLCAyMDEyIDQ6MjQgQU0NClRvOiBzb2Z0d2lyZXNAaWV0Zi5vcmcgV0cNCkNjOiBpbnQt YWRzQHRvb2xzLmlldGYub3JnOyBTb2Z0d2lyZSBDaGFpcnMNClN1YmplY3Q6IFJlOiBbU29mdHdp cmVzXSBNYWlsaW5nIGxpc3QgcXVlc3Rpb24gdG8gZ2F1Z2UgY29uc2Vuc3VzIG9uIDRyZC1VIHZz IE1BUA0KDQpEZWFyIFNvZnR3aXJlIHdnLA0KDQpUaGUgY29uc2Vuc3VzIGNhbGwgaXMgY2xvc2lu ZyBpbiBhIGZldyBkYXlzLiANCg0KVGhlIHR3byBxdWVzdGlvbnMgYmVpbmcgYXNrZWQgYXJlIHRo ZSBzYW1lIG9uZXMgdGhhdCB3ZXJlIGFza2VkIGR1cmluZyB0aGUgbWVldGluZyBpbiBQYXJpcy4N ClRob3NlIHF1ZXN0aW9ucyBtYXkgb3IgbWF5IG5vdCBiZSBwZXJmZWN0LCB5b3UgbWF5IG9yIG1h eSBub3QgbGlrZSB0aGVtLCBidXQgdGhleSBhcmUgdGhlIHRvb2wgd2UgaGF2ZSB0byBnYXVnZSBj b25zZW5zdXMgKG9yIGxhY2sgdGhlcmVvZikNCm9uIHRoZSBtYWlsaW5nIGxpc3QuIFNvLCBJZiB5 b3UgaGF2ZSBub3QgeWV0IGV4cHJlc3NlZCB5b3VyIG9waW5pb24gYW5zd2VyaW5nIGJvdGggcXVl c3Rpb25zLCBub3cgaXMgdGhlIHRpbWUgdG8gZG8gaXQuDQpJbiBJRVRGIHRyYWRpdGlvbiwgc2ls ZW5jZSBpcyBjb25zZW50Lg0KDQogICAgQWxhaW4sIFNvZnR3aXJlcyB3ZyBjby1jaGFpcg0KDQoN Cg0KDQpPbiBBcHIgNCwgMjAxMiwgYXQgNToxNCBQTSwgQWxhaW4gRHVyYW5kIHdyb3RlOg0KDQo+ IERlYXIgU29mdHdpcmUgd2cgbWVtYmVyczoNCj4gDQo+IEF0IHRoZSBQYXJpcyBJRVRGIFNvZnR3 aXJlIG1lZXRpbmcsIHdlIGhhZCBwcmVzZW50YXRpb25zIG9uIE1BUCAodGFrZW4gYXMgYSB3aG9s ZSkgIGFuZA0KPiA0cmQtVS4gV2UgZ290IHZlcnkgc3Ryb25nIGZlZWRiYWNrIHRoYXQgd2UgbmVl ZGVkIHRvIHNlbGVjdCBvbmUNCj4gc29sdXRpb24gdG8gY292ZXIgdGhhdCBmdWxsIHN0YXRlbGVz cyBjYXNlLCBub3QgdHdvLCBhbmQgdGhhdCB3ZSBzaG91bGQgbWFrZSB0aGlzDQo+IGRlY2lzaW9u IHJlbGF0aXZlbHkgcXVpY2tseS4NCj4gDQo+IER1cmluZyBQYXJpcyBtZWV0aW5nLCB3ZSBhc2tl ZCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgcXVlc3Rpb246DQo+IERvIHlvdSBwcmVmZXIgTUFQ IG9yIDRyZC1VPw0KPiBXZSBnb3QgYWJvdXQgMS8zIHN1cHBvcnQgZm9yIDRyZC1VIGFuZCAyLzMg Zm9yIE1BUC4NCj4gDQo+IFRoZSByZWFsIGdhdWdlIG9mIGNvbnNlbnN1cyBpcyB0aGUgbWFpbGlu ZyBsaXN0LCBzbyB3ZSB3b3VsZCBsaWtlDQo+IHRvIGFzayB0aGUgc2FtZSBxdWVzdGlvbnMgdG8g dGhlIGxpc3QuDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gUXVlc3Rpb24gMTogRG8geW91IGFncmVl IHRoYXQgdGhlIHdnIHNob3VsZCBwdXQgRUlUSEVSIDRyZC1VIE9SIE1BUCAoYXMgYSB3aG9sZSkg b24gdGhlIHN0YW5kYXJkIHRyYWNrLA0KPiB0aGUgb3RoZXIgYmVpbmcgcHVibGlzaGVkIGFzIGV4 cGVyaW1lbnRhbCBvciBpbmZvcm1hdGlvbmFsLg0KPiBBbnN3ZXJpbmcgWUVTIHRvIHRoaXMgcXVl c3Rpb24gbWVhbnMgeW91IGFncmVlIHdlIGNhbm5vdCBwdWJsaXNoIGJvdGggYXMgc3RhbmRhcmQg dHJhY2suDQo+IEFuc3dlcmluZyBOTyB0byB0aGlzIHF1ZXN0aW9uIG1lYW5zIHlvdSB3YW50IHRv IHNlZSBib3RoIGFkdmFuY2Ugb24gdGhlIHN0YW5kYXJkIHRyYWNrLg0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBZb3VyIGZ1bGwgbmFtZSwgeW91ciBhZmZpbGlhdGlvbiwgeW91ciBjaG9p Y2U6IFlFUyBvciBOTw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo+IA0KPiBRdWVzdGlvbnMgMjogV2hpY2ggb25lIGRvIHlvdSB3YW50IHRvIHNlZSBwbGFj ZWQgb24gdGhlIFN0YW5kYXJkcyBUcmFjazoNCj4gNHJkLVUgb3IgTUFQPw0KPiANCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IFlvdXIgZnVsbCBuYW1lLCB5b3VyIGFmZmlsaWF0aW9uLCB5b3Vy IGNob2ljZTogNHJkLVUgb3IgTUFQDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2UgZmlsbCBvdXQgdGhlIGZvbGxvd2lu ZyBmb3JtIGFuZCByZXBseSB0byB0aGUgbGlzdA0KPiBieSBXZWRuZXNkYXkgNC8xMCA1cG0gRURU Lg0KPiANCj4gTm90ZTogVXNlIHRoaXMgdGhyZWFkIE9OTFkgZm9yIGV4cHJlc3NpbmcgeW91ciBz dXBwb3J0IHRvDQo+IG9uZSBPUiB0aGUgb3RoZXIsIGFuZCByZWRpcmVjdCBhbnkgZGlzY3Vzc2lv bnMgdG8gb3RoZXIgdGhyZWFkcy4NCj4gVGhhdCB3b3VsZCBoZWxwIHVwIGdhdWdlIGNvbnNlbnN1 cy4NCj4gDQo+IEFsYWluICYgWW9uZy4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiBTb2Z0d2lyZXNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly ZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNv ZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg== From tomasz.mrugalski@gmail.com Tue Apr 10 04:52:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7D21F85AA for ; Tue, 10 Apr 2012 04:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AGr5Jlv-CHD for ; Tue, 10 Apr 2012 04:52:40 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79A6921F85A8 for ; Tue, 10 Apr 2012 04:52:40 -0700 (PDT) Received: by bkuw5 with SMTP id w5so4507571bku.31 for ; Tue, 10 Apr 2012 04:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=91/qBEpbEO+suShhBR7umW6ZZLGsyrca5YjCchFJB1M=; b=t/x8hOMB4vBcDMk1ApkGLO59r/SAhSVzGzZtak1JQGSM4f2omMq+uSu50aM3+yAbg/ 798is3/2p/as1U3jLSPyWzQLCU1G+r0IT+Ezf0NS8DXHyAFopYAh6nrt43ZQ67uM0hzm ALMpNJwkvnpGpJLZ0/0xiqqKJLIOErAq5zDNRHWSG+IIktPrA/dH+dQARN4v+HQHk2zQ VQthtLSCk6TxKcFV4bah8QF2PVGOt1RI+SeL0usQqrTAFZ+iyaI89/B4/FfwF7/cBWGj XzIXc77Nfjz0cTaj/mt2YVkcO5cJspmW7tEk2JH3WH4Z+uvEpVjJGBdtGiO+qrEGsvfz 2mag== Received: by 10.205.139.20 with SMTP id iu20mr4302250bkc.93.1334058759605; Tue, 10 Apr 2012 04:52:39 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id zx16sm35645998bkb.13.2012.04.10.04.52.38 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 04:52:38 -0700 (PDT) Message-ID: <4F841F00.1050506@gmail.com> Date: Tue, 10 Apr 2012 13:52:32 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: softwires@ietf.org References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> In-Reply-To: X-TagToolbar-Keys: D20120410135232448 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:52:41 -0000 On 10.04.2012 11:51, Wojciech Dec wrote: > you're apparently confusing matters. There is no need to have a DHCPv6 > option, or a million node deployment to test MAP implementations. > DS-lite is a good example, with implementations and standards track > before the DHCPv6 option. > On 10 April 2012 11:37, Rémi Després > wrote: > The difficulty is that: > - The MAP-DHCPv6 draft has no parameter to indicate whether the > ISP-chosen topology is mesh or hub-and-spoke. Guys, Please be reasonable. DHCP provisioning is trivial compared to other MAP/4rd-U aspects. It is not relevant for core aspects of the technology comparisons. My advice to people who spend their time on "my solution is better than yours" discussions: Forget about DHCP for now and focus on more important aspects. My personal opinion is that DHCP does not matter at this stage. Sure, it will be needed eventually, but you can *now* test implementations that are statically configured. Now, to the actual question about hub&spoke. We assumed that CE can detect on its own if it is running in hub&spoke or mesh topology by analyzing received rules. See last paragraph of section 4.2 of mdt-softwire-map-dhcp-option that explain this simple algorithm (if it can be called an algorithm at all - it is a simple "if" statement). Honestly speaking as a co-author of MAP DHCP option draft, I didn't want to spend too much time on this *yet*. That is also one of the reasons why I didn't look at 4rd-U DHCP option yet. It changes too greatly between revisions. Cheers, Tomek From adurand@juniper.net Tue Apr 10 05:19:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5321F85D9 for ; Tue, 10 Apr 2012 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.393 X-Spam-Level: X-Spam-Status: No, score=-106.393 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBCxuOaNMphu for ; Tue, 10 Apr 2012 05:19:13 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id E875B21F85D6 for ; Tue, 10 Apr 2012 05:19:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT4QlOYXuK/TYfyCSz19RUjYncQtnQUSO@postini.com; Tue, 10 Apr 2012 05:19:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Apr 2012 05:18:33 -0700 From: Alain Durand To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "wdec.ietf@gmail.com" Date: Tue, 10 Apr 2012 05:18:30 -0700 Thread-Topic: Call for restrain and reason on the mailing list Thread-Index: Ac0XFAxDZXN9hykkQguEbjITitYtKA== Message-ID: <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> In-Reply-To: <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires , "softwire-ads@tools.ietf.org" , Softwire Chairs Subject: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:19:14 -0000 Remi, Woj: We have heard a number of times that you both think the "other" solution is= broken. Technical points have been made, no need for personal attacks. I'm getting concerned that the working group is losing sight of the very re= ason why we participate to the IETF; to promote good standards, not to figh= t endlessly about which of the two or three solutions we have on the table = (and that are 99% identical) is more "pure". Standardizing is about finding= common ground, not about ego, fighting for whose name is on the draft, cha= racter assassination, using disparaging language, threatening appeals, boyc= otting, or ballot stuffing. Alain, wg-co-chair. From despres.remi@laposte.net Tue Apr 10 05:52:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3255F21F85D0 for ; Tue, 10 Apr 2012 05:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jrmpp78TPMo for ; Tue, 10 Apr 2012 05:52:03 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4550221F8472 for ; Tue, 10 Apr 2012 05:52:01 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id wCrx1i00A37Y3f403CryYG; Tue, 10 Apr 2012 14:51:59 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-51--727167053 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Apr 2012 14:51:58 +0200 Message-Id: <11FD4DBC-D314-476B-89A1-EBB93C791912@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:52:04 -0000 --Apple-Mail-51--727167053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-10 =E0 12:07, Wojciech Dec a =E9crit : > The pre-standard-still-being-defined DHCPv6 option was not tested, and = CLI based configuration including scripting was applied. >=20 > Question closed. For you, that's your choice, fair enough. But not closed for the WG: members deserve to know how CEs are proposed = to know whether they must work in mesh or hub-an-spoke topology (even if = MAP remains experimental). RD > -Woj. >=20 > On 10 April 2012 12:01, R=E9mi Despr=E9s = wrote: > Wojciech, >=20 > This isn't answers to questions I asked. > They remain open. >=20 > RD >=20 > Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9crit : >=20 >> Remi, >>=20 >> you're apparently confusing matters. There is no need to have a = DHCPv6 option, or a million node deployment to test MAP implementations. = DS-lite is a good example, with implementations and standards track = before the DHCPv6 option. >>=20 >> Needless to say, if you're implying that tests of MAP without testing = the standards based DHCPv6 option are insufficient, then any test of = 4rd-u or anything for that matter without using the fully standards DHCP = option would be equally flawed.=20 >> At the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need to. >>=20 >> -Woj. >>=20 >> On 10 April 2012 11:37, R=E9mi Despr=E9s = wrote: >> Hello, all, >>=20 >> We have heard many times that MAP is completely specified, and has = been extensively tested. >> Yet: >> - mapping rules of tested configurations have not been provided >> - several missing points of the MAP-T+E specification have been = identified (ref (*) = www.ietf.org/mail-archive/web/softwires/current/msg04049.html). >>=20 >> This mail is just about ONE of these, the hub-and-spoke issue. >> It has been discussed several times but AFAIK still without a = complete answer. >>=20 >> The difficulty is that: >> - The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke. >> - According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules". >> - As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)". >>=20 >> Questions I have are then: >> - Is the choice provisioned explicitly, implicitly, or possibly both? >> - How? >> - Which tests have confirmed that it worked? >>=20 >> Answer by any one who asserts he or she understands how MAP works = will be welcome. >>=20 >> Thanks, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> > De : Ole Tr=F8an >> > Date : 2012-03-14 14:29 >> > =C0 : R=E9mi Despr=E9s >> > Cc : Tomasz Mrugalski , Softwires WG = >> > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation = in MAP >> > >> > Remi, >> > >> >> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication: >> >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, = how do they know whether their ISP expects direct paths between them = (mesh) or BR hairpinning (hub-and-spoke)? >> >> >> > >> > that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules). >> > >> > cheers, >> > Ole >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-51--727167053 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
The pre-standard-still-being-defined DHCPv6 option was not = tested, and CLI based configuration including scripting was = applied.


Question = closed.

For you, that's your choice, fair = enough.

But not closed for the WG: members = deserve to know how CEs are proposed to know whether they must work in = mesh or hub-an-spoke topology (even if MAP remains = experimental).

RD


-Woj.

On 10 = April 2012 12:01, R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
Wojciech,

This isn't = answers to questions I asked.
They remain open.

RD

Le 2012-04-10 =E0 11:51, = Wojciech Dec a =E9crit :

Remi,

you're apparently confusing matters. There is = no need to have a DHCPv6 option, or a million node deployment to test = MAP implementations. DS-lite is a good example, with implementations and = standards track before the DHCPv6 option.

Needless to say, if you're implying that tests of MAP without = testing the standards based DHCPv6 option are insufficient, then any = test of 4rd-u or anything for that matter without using the fully = standards DHCP option would be equally flawed.
At the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need = to.

-Woj.

On 10 April 2012 = 11:37, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Hello, all,

We have heard many times that MAP is completely specified, and has been = extensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been = identified (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049= .html).

This mail is just about ONE of these, the hub-and-spoke issue.
It has been discussed several times but AFAIK still without a complete = answer.

The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke.
- According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules".
- As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)".

Questions I have are then:
- Is the choice provisioned explicitly, implicitly, or possibly = both?
- How?
- Which tests have confirmed that it worked?

Answer by any one who asserts he or she understands how MAP works will = be welcome.

Thanks,
RD







> De : Ole Tr=F8an <ot@cisco.com>
> Date : 2012-03-14 14:29
> =C0 : R=E9mi Despr=E9s <despres.remi@laposte.net>
> Cc : Tomasz Mrugalski <tomasz.mrugalski@gmail.com>, Softwires WG = <softwires@ietf.org>
> Objet : R=E9p : [Softwires] Question about hub-and-spoke operation = in MAP
>
> Remi,
>
>> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication:
>> - If two CEs apply the same BMR to their delegated IPv6 = prefixes, how do they know whether their ISP expects direct paths = between them (mesh) or BR hairpinning (hub-and-spoke)?
>>
>
> that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules).
>
> cheers,
> Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-51--727167053-- From simon.perreault@viagenie.ca Tue Apr 10 06:07:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1821F85D4 for ; Tue, 10 Apr 2012 06:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa+bZ9wiYiry for ; Tue, 10 Apr 2012 06:07:51 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2082321F85D0 for ; Tue, 10 Apr 2012 06:07:51 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:29cd:113f:9d32:b807]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 50003400A1 for ; Tue, 10 Apr 2012 09:07:50 -0400 (EDT) Message-ID: <4F8430A5.2010108@viagenie.ca> Date: Tue, 10 Apr 2012 09:07:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <4F83E358.1090409@go6.si> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:07:52 -0000 On 2012-04-10 04:21, GangChen wrote: >> I see MAP-E/T combo as one solution, where you "turn the knob" when >> implementing it - you choose encap *or* translation mode. > > You could combo 100 solultions as you want. However, that is still > seems to me separated solutions. +1 From a deployment point of view, it makes no sense to treat them as one. You would need to evaluate T and E separately for *everything*: routers, provisioning, customer equipment, accounting, etc. So it makes no sense to treat T and E as a single protocol. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Tue Apr 10 06:12:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A02721F85F6 for ; Tue, 10 Apr 2012 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GQSYo3mAKIC for ; Tue, 10 Apr 2012 06:12:35 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 498F721F8566 for ; Tue, 10 Apr 2012 06:12:34 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id wDCZ1i00C37Y3f403DCZsi; Tue, 10 Apr 2012 15:12:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> Date: Tue, 10 Apr 2012 15:12:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: softwires , softwire-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:12:36 -0000 Hi, Alain, 2012-04-10 14:18, Alain Durand: > Remi, Woj: >=20 > We have heard a number of times that you both think the "other" = solution is broken. > Technical points have been made, Exchanging real technical points with Maoke isn't finished (he just = posted a new draft about 4rd-U). Since this has been productive so far (despite some heat from time to = time), clarifying the last points which we understand differently is = useful (IMHO). > no need for personal attacks. I don't recognize myself in this one (at least as the initiator). > I'm getting concerned that the working group is losing sight of the = very reason why we participate to the IETF; to promote good standards, = not to fight endlessly about which of the two or three solutions we have = on the table (and that are 99% identical) is more "pure". Standardizing = is about finding common ground, not about ego, > fighting for whose name is on the draft, character assassination, = using disparaging language, Neither in this one. > threatening appeals, Feeling concerned with this one. However, exercising an appeal if found appropriate is each one's = prerogative, and can sometimes be a duty. Sincerely hope to have no need for that. =20 > boycotting, Feeling concerned with this one too. However, the fact is that, personally, I cannot answer YES and cannot = answer NO either: - Now convinced that either MAP-T+E or 4rd-U on standard track is = premature, I can't answer YES. - Also convinced that both on standard track would be a mistake, I can't = vote NO. =20 > or ballot stuffing. The proportion of this is well beyond what I thought was predictable. Please be sure that all these efforts of mine are for the best of = standardization. Regards, RD >=20 > Alain, wg-co-chair. From jdrake@juniper.net Tue Apr 10 06:19:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8860421F8606 for ; Tue, 10 Apr 2012 06:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIt+mVpxPDVU for ; Tue, 10 Apr 2012 06:19:13 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id E93D221F8604 for ; Tue, 10 Apr 2012 06:19:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT4QzQ4TaoXgA8bYBhI5O7wHacmwDGg1B@postini.com; Tue, 10 Apr 2012 06:19:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Apr 2012 06:15:12 -0700 From: John E Drake To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Wojciech Dec Date: Tue, 10 Apr 2012 06:15:11 -0700 Thread-Topic: [Softwires] Provisioning Hub-and-spoke in MAP - How? Thread-Index: Ac0XGL1RQdhedZs0QF+BbS2h34e9EgAAvvlQ Message-ID: <5E893DB832F57341992548CDBB333163A56DF93536@EMBX01-HQ.jnpr.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> <11FD4DBC-D314-476B-89A1-EBB93C791912@laposte.net> In-Reply-To: <11FD4DBC-D314-476B-89A1-EBB93C791912@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A56DF93536EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Softwires WG , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:19:14 -0000 --_000_5E893DB832F57341992548CDBB333163A56DF93536EMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Remi, As an observer, it seems as though you think you are running the WG rather = than being a participant in it. Thanks, John Sent from my iPhone From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of R=E9mi Despr=E9s Sent: Tuesday, April 10, 2012 5:52 AM To: Wojciech Dec Cc: Softwires WG; int-ads@tools.ietf.org; Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? Le 2012-04-10 =E0 12:07, Wojciech Dec a =E9crit : The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI = based configuration including scripting was applied. Question closed. For you, that's your choice, fair enough. But not closed for the WG: members deserve to know how CEs are proposed to = know whether they must work in mesh or hub-an-spoke topology (even if MAP r= emains experimental). RD -Woj. On 10 April 2012 12:01, R=E9mi Despr=E9s > wrote: Wojciech, This isn't answers to questions I asked. They remain open. RD Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9crit : Remi, you're apparently confusing matters. There is no need to have a DHCPv6 opti= on, or a million node deployment to test MAP implementations. DS-lite is a = good example, with implementations and standards track before the DHCPv6 op= tion. Needless to say, if you're implying that tests of MAP without testing the s= tandards based DHCPv6 option are insufficient, then any test of 4rd-u or an= ything for that matter without using the fully standards DHCP option would = be equally flawed. At the very least however, MAP does not need to prove on thing: Compatibili= ty with IPv6, which 4rd-u would need to. -Woj. On 10 April 2012 11:37, R=E9mi Despr=E9s > wrote: Hello, all, We have heard many times that MAP is completely specified, and has been ext= ensively tested. Yet: - mapping rules of tested configurations have not been provided - several missing points of the MAP-T+E specification have been identified = (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html). This mail is just about ONE of these, the hub-and-spoke issue. It has been discussed several times but AFAIK still without a complete answ= er. The difficulty is that: - The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chosen = topology is mesh or hub-and-spoke. - According to the MAP-address-and-port draft, "each MAP node in the domain= has the same set of rules". - As answered in the mail below, the choice "needs to be provisioned. eithe= r explicitly or implicitly (via the rules)". Questions I have are then: - Is the choice provisioned explicitly, implicitly, or possibly both? - How? - Which tests have confirmed that it worked? Answer by any one who asserts he or she understands how MAP works will be w= elcome. Thanks, RD > De : Ole Tr=F8an > > Date : 2012-03-14 14:29 > =C0 : R=E9mi Despr=E9s > > Cc : Tomasz Mrugalski >, Softwires WG > > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in MAP > > Remi, > >> I couldn't figure out by how CEs can be required to work hub-and-spoke w= ithout some DHCPv6 indication: >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do= they know whether their ISP expects direct paths between them (mesh) or BR= hairpinning (hub-and-spoke)? >> > > that's correct it needs to be provisioned. either explicitly or implicitl= y (via the rules). > > cheers, > Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_5E893DB832F57341992548CDBB333163A56DF93536EMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Remi,

 

<= p class=3DMsoNormal>As an observer, it seems as though you think you= are running the WG rather than being a participant in it.

 

Thanks,

 

John<= /p>

 

Sent from my iPhone

 

From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.= org] On Behalf Of R=E9mi Despr=E9s
Sent: Tuesday, April 10= , 2012 5:52 AM
To: Wojciech Dec
Cc: Softwires WG; int-a= ds@tools.ietf.org; Softwire Chairs
Subject: Re: [Softwires] Provi= sioning Hub-and-spoke in MAP - How?

 

 <= /p>

Le 2012-04-10 =E0 12:07, Wojciech Dec a = =E9crit :



<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>The pre-standard-still-b= eing-defined DHCPv6 option was not tested, and CLI based configuration incl= uding scripting was applied.



Question closed.


For you, that's your choice, fair enough.

 

But not closed for the WG: members deserve to know how CEs are pr= oposed to know whether they must work in mesh or hub-an-spoke topology (eve= n if MAP remains experimental).

 

RD

 



-Woj.

On 10 April 2012 12:0= 1, R=E9mi Despr=E9s <despres= .remi@laposte.net> wrote:

Wo= jciech,

 

=

This isn't answers to questions I asked.

They remain open.

 

RD

 

=

Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9c= rit :



Remi,

you'r= e apparently confusing matters. There is no need to have a DHCPv6 option, o= r a million node deployment to test MAP implementations. DS-lite is a good = example, with implementations and standards track before the DHCPv6 option.=

Needless to say, if you're implying that tests of MAP without testi= ng the standards based DHCPv6 option are insufficient, then any test of 4rd= -u or anything for that matter without using the fully standards DHCP optio= n would be equally flawed.
At the very least however, MAP does not need= to prove on thing: Compatibility with IPv6, which 4rd-u would need to.
=
-Woj.

On 10 April 2012 11:37, R= =E9mi Despr=E9s <despres.remi@laposte.net> wrote:

Hello, all,

We have heard many times that MAP is completely s= pecified, and has been extensively tested.
Yet:
- mapping rules of te= sted configurations have not been provided
- several missing points of t= he MAP-T+E specification have been identified (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html).
=
This mail is just about ONE of these, the hub-and-spoke issue.
It ha= s been discussed several times but AFAIK still without a complete answer.
The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to= indicate whether the ISP-chosen topology is mesh or hub-and-spoke.
- Ac= cording to the MAP-address-and-port draft, "each MAP node in the domai= n has the same set of rules".
- As answered in the mail below, the = choice "needs to be provisioned. either explicitly or implicitly (via = the rules)".

Questions I have are then:
- Is the choice prov= isioned explicitly, implicitly, or possibly both?
- How?
- Which test= s have confirmed that it worked?

Answer by any one who asserts he or= she understands how MAP works will be welcome.

Thanks,
RD






> De : Ole Tr=F8an <ot@cisco.com>
> Date : 2012-03-14 14= :29
> =C0 : R=E9mi Despr=E9s <despres.remi@laposte.net>
> Cc : Tom= asz Mrugalski <tomasz.mrugalski@gmail.com>, Softwires WG <softwires@ietf.org>
>= Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in MAP<= br>>
> Remi,
>
>> I couldn't figure out by how CEs = can be required to work hub-and-spoke without some DHCPv6 indication:
&g= t;> - If two CEs apply the same BMR to their delegated IPv6 prefixes, ho= w do they know whether their ISP expects direct paths between them (mesh) o= r BR hairpinning (hub-and-spoke)?
>>
>
> that's correc= t it needs to be provisioned. either explicitly or implicitly (via the rule= s).
>
> cheers,
> Ole

____________________________= ___________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf= .org/mailman/listinfo/softwires

 

 

 

<= p class=3DMsoNormal> 

= --_000_5E893DB832F57341992548CDBB333163A56DF93536EMBX01HQjnprn_-- From despres.remi@laposte.net Tue Apr 10 06:33:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D7021F84F6 for ; Tue, 10 Apr 2012 06:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtHHLuppEOgy for ; Tue, 10 Apr 2012 06:33:47 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id D5B4421F84A6 for ; Tue, 10 Apr 2012 06:33:46 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id wDZh1i00C37Y3f403DZhQc; Tue, 10 Apr 2012 15:33:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-52--724663413 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5E893DB832F57341992548CDBB333163A56DF93536@EMBX01-HQ.jnpr.net> Date: Tue, 10 Apr 2012 15:33:41 +0200 Message-Id: <8A191309-29CF-44D2-93EC-986FC45D0C17@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> <54550967-246A-45E3-9E78-D6633A8A2CE1@laposte.net> <11FD4DBC-D314-476B-89A1-EBB93C791912@laposte.net> <5E893DB832F57341992548CDBB333163A56DF93536@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:33:48 -0000 --Apple-Mail-52--724663413 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 John, 2012-04-10 15:15, John E Drake: > Remi, > =20 > As an observer, it seems as though you think you are running the WG = rather than being a participant in it. Be sure I am far too realistic to believe that! But I did invest lot of time and energy to build what a number of people = find a good proposal.=20 Current effort is to avoid this to be lost just because of a premature = decision, one that would not reflect the clear lack of consensus for MAP = that we saw in Paris. Regards, RD > =20 > Thanks, > =20 > John > =20 > Sent from my iPhone > =20 > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of R=E9mi Despr=E9s > Sent: Tuesday, April 10, 2012 5:52 AM > To: Wojciech Dec > Cc: Softwires WG; int-ads@tools.ietf.org; Softwire Chairs > Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? > =20 > =20 > Le 2012-04-10 =E0 12:07, Wojciech Dec a =E9crit : >=20 >=20 > The pre-standard-still-being-defined DHCPv6 option was not tested, and = CLI based configuration including scripting was applied. >=20 >=20 >=20 > Question closed. >=20 > For you, that's your choice, fair enough. > =20 > But not closed for the WG: members deserve to know how CEs are = proposed to know whether they must work in mesh or hub-an-spoke topology = (even if MAP remains experimental). > =20 > RD > =20 >=20 >=20 > -Woj. >=20 > On 10 April 2012 12:01, R=E9mi Despr=E9s = wrote: > Wojciech, > =20 > This isn't answers to questions I asked. > They remain open. > =20 > RD > =20 > Le 2012-04-10 =E0 11:51, Wojciech Dec a =E9crit : >=20 >=20 > Remi, >=20 > you're apparently confusing matters. There is no need to have a DHCPv6 = option, or a million node deployment to test MAP implementations. = DS-lite is a good example, with implementations and standards track = before the DHCPv6 option. >=20 > Needless to say, if you're implying that tests of MAP without testing = the standards based DHCPv6 option are insufficient, then any test of = 4rd-u or anything for that matter without using the fully standards DHCP = option would be equally flawed.=20 > At the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need to. >=20 > -Woj. >=20 > On 10 April 2012 11:37, R=E9mi Despr=E9s = wrote: > Hello, all, >=20 > We have heard many times that MAP is completely specified, and has = been extensively tested. > Yet: > - mapping rules of tested configurations have not been provided > - several missing points of the MAP-T+E specification have been = identified (ref (*) = www.ietf.org/mail-archive/web/softwires/current/msg04049.html). >=20 > This mail is just about ONE of these, the hub-and-spoke issue. > It has been discussed several times but AFAIK still without a complete = answer. >=20 > The difficulty is that: > - The MAP-DHCPv6 draft has no parameter to indicate whether the = ISP-chosen topology is mesh or hub-and-spoke. > - According to the MAP-address-and-port draft, "each MAP node in the = domain has the same set of rules". > - As answered in the mail below, the choice "needs to be provisioned. = either explicitly or implicitly (via the rules)". >=20 > Questions I have are then: > - Is the choice provisioned explicitly, implicitly, or possibly both? > - How? > - Which tests have confirmed that it worked? >=20 > Answer by any one who asserts he or she understands how MAP works will = be welcome. >=20 > Thanks, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > De : Ole Tr=F8an > > Date : 2012-03-14 14:29 > > =C0 : R=E9mi Despr=E9s > > Cc : Tomasz Mrugalski , Softwires WG = > > Objet : R=E9p : [Softwires] Question about hub-and-spoke operation = in MAP > > > > Remi, > > > >> I couldn't figure out by how CEs can be required to work = hub-and-spoke without some DHCPv6 indication: > >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, = how do they know whether their ISP expects direct paths between them = (mesh) or BR hairpinning (hub-and-spoke)? > >> > > > > that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules). > > > > cheers, > > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > =20 > =20 > =20 > =20 --Apple-Mail-52--724663413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
As an = observer, it seems as though you think you are running the WG rather = than being a participant in = it.

Be sure I = am far too realistic to believe that!

But I did = invest lot of time and energy to build what a number of people find a = good proposal. 
Current effort is to avoid this to be = lost just because of a premature decision, one that would not reflect = the clear lack of consensus for MAP that we saw in = Paris.

Regards,
RD

=



Sent = from my iPhone
 
From: softwires-bounces@ietf.org [mailto:softwires-bounces@iet= f.org] On Behalf = Of R=E9mi = Despr=E9s
Sent: Tuesday, April 10, 2012 = 5:52 AM
To: Wojciech = Dec
Cc: Softwires WG; int-ads@tools.ietf.org; Softwire = Chairs
Subject: Re: [Softwires] = Provisioning Hub-and-spoke in MAP - = How?
Le 2012-04-10 =E0 12:07, = Wojciech Dec a =E9crit :
The = pre-standard-still-being-defined DHCPv6 option was not tested, and CLI = based configuration including scripting was applied.



Question = closed.

For you, that's your = choice, fair enough.
But not closed for the = WG: members deserve to know how CEs are proposed to know whether = they must work in mesh or hub-an-spoke topology (even if MAP remains = experimental).
On 10 April 2012 12:01, R=E9mi = Despr=E9s <despres.remi@laposte.net> = wrote:
This isn't answers to = questions I asked.
They remain = open.
Le 2012-04-10 =E0 11:51, = Wojciech Dec a =E9crit :


Remi,

you're apparently confusing matters. There is no = need to have a DHCPv6 option, or a million node deployment to test MAP = implementations. DS-lite is a good example, with implementations and = standards track before the DHCPv6 option.

Needless to say, if = you're implying that tests of MAP without testing the standards based = DHCPv6 option are insufficient, then any test of 4rd-u or anything for = that matter without using the fully standards DHCP option would be = equally flawed. 
At = the very least however, MAP does not need to prove on thing: = Compatibility with IPv6, which 4rd-u would need = to.

-Woj.

On 10 April 2012 11:37, = R=E9mi Despr=E9s <Hello, all,

We have heard many times that MAP is = completely specified, and has been extensively tested.
Yet:
- = mapping rules of tested configurations have not been provided
- = several missing points of the MAP-T+E specification have been identified = (ref (*) - As answered in = the mail below, the choice "needs to be provisioned. either explicitly = or implicitly (via the rules)".

Questions I have are then:
- = Is the choice provisioned explicitly, implicitly, or possibly both?
- = How?
- Which tests have confirmed that it worked?

Answer by = any one who asserts he or she understands how MAP works will be = welcome.

Thanks,
RD







> De : = Ole Tr=F8an <softwires@ietf.org>
> = Objet : R=E9p : [Softwires] Question about hub-and-spoke operation in = MAP
>
> Remi,
>
>> I couldn't figure out by = how CEs can be required to work hub-and-spoke without some DHCPv6 = indication:
>> - If two CEs apply the same BMR to their = delegated IPv6 prefixes, how do they know whether their ISP expects = direct paths between them (mesh) or BR hairpinning = (hub-and-spoke)?
>>
>
> that's correct it needs to = be provisioned. either explicitly or implicitly (via the = rules).
>
> cheers,
> = Ole

_______________________________________________
Softwires = mailing list
 
, Softwire Chairs Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:49:22 -0000 --002354470c5c58d5c104bd543a52 Content-Type: text/plain; charset=ISO-8859-1 For some reason, it's also forgotten that WG adoption does not equate to a WG last call... It has been said several times that several of the 4rd-u features can be accommodated by the MAP spec should these ever be consented to by the WG as necessary. Candidly, however these technical matters appear to be secondary, as they were on the MAP design team, and the circus on the matter is more about the ego of an individual and his style of collaboration, including also the name of the draft. There likely is no better way to end this than to get the WG to adopt a solution that not only has considerable support but also several trial implementations, and let it progress as a standards track WG document capturing consented WG feedback as it does so. This is indeed a basis of standardization. My 2c. 2012/4/10 Alain Durand > Remi, Woj: > > We have heard a number of times that you both think the "other" solution > is broken. Technical points have been made, no need for personal attacks. > > I'm getting concerned that the working group is losing sight of the very > reason why we participate to the IETF; to promote good standards, not to > fight endlessly about which of the two or three solutions we have on the > table (and that are 99% identical) is more "pure". Standardizing is about > finding common ground, not about ego, fighting for whose name is on the > draft, character assassination, using disparaging language, threatening > appeals, boycotting, or ballot stuffing. > > Alain, wg-co-chair. > --002354470c5c58d5c104bd543a52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For some reason, it's also forgotten that WG adoption does not equate t= o a WG last call...
It has been said several times that several of the 4= rd-u features can be accommodated by the MAP spec should these ever be cons= ented to by the WG as necessary.
Candidly, however these technical matters appear to be secondary, as they w= ere on the MAP design team, and the circus on the matter is more about the = ego of an individual and his style of collaboration, including also the nam= e of the draft.

There likely is no better way to end this than to get the WG to adopt a= solution that not only has considerable support but also several trial imp= lementations, and let it progress as a standards track WG document capturin= g consented WG feedback as it does so. This is indeed a basis of standardiz= ation.

My 2c.


2012/4/10 Alain Durand <= ;adurand@juniper.n= et>
Remi, Woj:

We have heard a number of times that you both think the "other" s= olution is broken. Technical points have been made, no need for personal at= tacks.

I'm getting concerned that the working group is losing sight of the ver= y reason why we participate to the IETF; to promote good standards, not to = fight endlessly about which of the two or three solutions we have on the ta= ble (and that are 99% identical) is more "pure". Standardizing is= about finding common ground, not about ego, fighting for whose name is on = the draft, character assassination, using disparaging language, threatening= appeals, boycotting, or ballot stuffing.

Alain, wg-co-chair.

--002354470c5c58d5c104bd543a52-- From adurand@juniper.net Tue Apr 10 08:03:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7511E80F1 for ; Tue, 10 Apr 2012 08:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6PsBxIUh4ru for ; Tue, 10 Apr 2012 08:03:28 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 75CEB21F86F3 for ; Tue, 10 Apr 2012 08:03:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT4RLt6WtpGIoaWPBmZFCxtceC2AGZI1I@postini.com; Tue, 10 Apr 2012 08:03:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Apr 2012 08:01:38 -0700 From: Alain Durand To: Wojciech Dec Date: Tue, 10 Apr 2012 08:01:37 -0700 Thread-Topic: Call for restrain and reason on the mailing list Thread-Index: Ac0XKtSxyiYEJeU6TrCQFM7tuydSMg== Message-ID: References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires , "softwire-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:03:29 -0000 On Apr 10, 2012, at 10:49 AM, Wojciech Dec wrote: > For some reason, it's also forgotten that WG adoption does not equate to = a WG last call... Very good point, and thank you for raising it. If this wg succeed in deciding which document (or document set) to put on s= tandard track, that is not the end of the road. It just means that these document(s) will be adopted as working group item(= s) and will have to evolve to take into consideration working group input (as opposed to design team input). These documents wi= ll then have to mature to the point where we, as a wg, feel comfortable we can have a working group last call. Alain. From jdrake@juniper.net Tue Apr 10 08:16:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284D211E80EF for ; Tue, 10 Apr 2012 08:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFhfslNtgT-d for ; Tue, 10 Apr 2012 08:16:17 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2B21F8537 for ; Tue, 10 Apr 2012 08:16:08 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT4ROtGOCuc4GbqIREqyB9L66cwUelTAf@postini.com; Tue, 10 Apr 2012 08:16:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 10 Apr 2012 08:14:31 -0700 From: John E Drake To: Alain Durand , "softwires@ietf.org WG" Date: Tue, 10 Apr 2012 08:14:30 -0700 Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Wjr0zi/crtN0YQS2V+JU6ZTyAGAAnC4pw Message-ID: <5E893DB832F57341992548CDBB333163A56DF935DD@EMBX01-HQ.jnpr.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:16:18 -0000 Alain, I'm sorry but I missed the following in your original email from last week: "We got about 1/3 support for 4rd-U and 2/3 for MAP." As an observer, this sounds like a rough consensus that you should be verif= ying on the mailing list, so you are exactly following the process of RFC 2= 418, despite Remi's assertions to the contrary. Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Alain Durand > Sent: Monday, April 09, 2012 1:24 PM > To: softwires@ietf.org WG > Cc: int-ads@tools.ietf.org; Softwire Chairs > Subject: Re: [Softwires] Mailing list question to gauge consensus on > 4rd-U vs MAP >=20 > Dear Softwire wg, >=20 > The consensus call is closing in a few days. >=20 > The two questions being asked are the same ones that were asked during > the meeting in Paris. > Those questions may or may not be perfect, you may or may not like > them, but they are the tool we have to gauge consensus (or lack > thereof) on the mailing list. So, If you have not yet expressed your > opinion answering both questions, now is the time to do it. > In IETF tradition, silence is consent. >=20 > Alain, Softwires wg co-chair >=20 >=20 >=20 >=20 > On Apr 4, 2012, at 5:14 PM, Alain Durand wrote: >=20 > > Dear Softwire wg members: > > > > At the Paris IETF Softwire meeting, we had presentations on MAP > (taken > > as a whole) and 4rd-U. We got very strong feedback that we needed to > > select one solution to cover that full stateless case, not two, and > > that we should make this decision relatively quickly. > > > > During Paris meeting, we asked the following additional question: > > Do you prefer MAP or 4rd-U? > > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > > > The real gauge of consensus is the mailing list, so we would like to > > ask the same questions to the list. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP > > (as a whole) on the standard track, the other being published as > experimental or informational. > > Answering YES to this question means you agree we cannot publish both > as standard track. > > Answering NO to this question means you want to see both advance on > the standard track. > > > > --------------------------------------------------------------------- > - > > ------ Your full name, your affiliation, your choice: YES or NO > > --------------------------------------------------------------------- > - > > ------ > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Questions 2: Which one do you want to see placed on the Standards > Track: > > 4rd-U or MAP? > > > > --------------------------------------------------------------------- > - > > -------- Your full name, your affiliation, your choice: 4rd-U or MAP > > --------------------------------------------------------------------- > - > > -------- > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > Please fill out the following form and reply to the list by Wednesday > > 4/10 5pm EDT. > > > > Note: Use this thread ONLY for expressing your support to one OR the > > other, and redirect any discussions to other threads. > > That would help up gauge consensus. > > > > Alain & Yong. > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jiangsheng@huawei.com Mon Apr 9 02:48:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D705321F8664 for ; Mon, 9 Apr 2012 02:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds3gLPHH9e+r for ; Mon, 9 Apr 2012 02:48:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0A21F8657 for ; Mon, 9 Apr 2012 02:48:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET46796; Mon, 09 Apr 2012 05:48:16 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 02:45:00 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 02:44:59 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 17:44:47 +0800 From: Sheng Jiang To: Maoke Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg//+RWQCAAIj4IP//nIAAgACGnOA= Date: Mon, 9 Apr 2012 09:44:47 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Doyb Ec4C IWr1 IYbF JQFe Lsll OkBV P8Y9 T0bq XpQm YcAg dZJM fIoi jHwn qX3A u9Ua; 4; ZgBpAGIAcgBpAGIAQABnAG0AYQBpAGwALgBjAG8AbQA7AHMAaQBtAG8AbgAuAHAAZQByAHIAZQBhAHUAbAB0AEAAdgBpAGEAZwBlAG4AaQBlAC4AYwBhADsAcwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcAOwB5AGkAdQBfAGwAZQBlAEAAYwBhAGIAbABlAC4AYwBvAG0AYwBhAHMAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {9E652485-B865-47B6-86E1-5CB017EE6502}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 09 Apr 2012 09:44:40 GMT; UgBFADoAIABbAFMAbwBmAHQAdwBpAHIAZQBzAF0AIABQAGEAdABoACAAdABvACAAbQBvAHYAZQAgAGYAbwByAHcAYQByAGQAIAB3AGkAdABoACAANAByAGQAYAEgADQAcgBkAC0AVQAgAGEAcwAgAHQAcgBhAG4AcwBwAGEAcgBlAG4AdAAgAGEAcwAgAE0AQQBQAC0ARQA= x-cr-puzzleid: {9E652485-B865-47B6-86E1-5CB017EE6502} x-originating-ip: [10.108.4.115] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B921E48376DSZXEML506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 10 Apr 2012 08:49:03 -0700 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:48:18 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B921E48376DSZXEML506MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aG91dCBhbnkgb2JqZWN0aW9uIHRvIE1BUCwgd2UganVzdCBzdGFydCB0byBjb2RpbmcgNHJk LXUgYW5kIGhlbHAgdG8gaW1wcm92ZSBpdC4NCg0KTXVsdGlwbGUgdHJhbnNpdGlvbiBtZWNoYW5p c21zIHdvdWxkIGNvLWV4aXN0IGluIHRoZSB3b3JsZC4gTmVpdGhlciBNQVAgbm9yIDRyZC1VIGNh biByZXBsYWNlIDZyZCBhbmQgRFMtTGl0ZS4gVGhlcmUgaXMgbm8gb25lLXN1aXQtYWxsIHNvbHV0 aW9uLg0KDQpGcm9tOiBNYW9rZSBbbWFpbHRvOmZpYnJpYkBnbWFpbC5jb21dDQpTZW50OiBNb25k YXksIEFwcmlsIDA5LCAyMDEyIDU6MzkgUE0NClRvOiBTaGVuZyBKaWFuZw0KQ2M6IExlZSwgWWl1 OyBMaXViaW5nIChMZW8pOyBTaW1vbiBQZXJyZWF1bHQ7IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtTb2Z0d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJk LVUgYXMgdHJhbnNwYXJlbnQgYXMgTUFQLUUNCg0KDQoyMDEyLzQvOSBTaGVuZyBKaWFuZyA8amlh bmdzaGVuZ0BodWF3ZWkuY29tPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20+Pg0KUGxlYXNl IGFsbG93IG1lIHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBvcnQgYm90aCBNQVAgYW5kIDRyZC11 Lg0KDQpNQVAgaGFzIGJlZW4gYSBnb29kIGVmZm9ydCB3aXRoIG1hbnkgZXhwZXJ0cyB0b2dldGhl ciBpbiBJUHY0L0lQdjYgdHJhbnNpdGlvbiBhcmVhIGFuZCBoYXMgYmVlbiBwcm92ZWQgYnkgcnVu bmluZyBjb2RlLiBJdCBhbHNvIG5lZWQgdG8gaW1wcm92ZSBpdHNlbGYgYmVmb3JlIGJlaW5nIHB1 Ymxpc2hlZCBhcyBhIFJGQyBsYXRlci4gVGhpcyBwcm9jZXNzIHdpbGwgdGFrZSBzZXZlcmFsIG1v bnRocy4NCg0KUGVyc29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQgYmVoaW5k IE1BUCBpbiBtYXR1cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LCBpdCBpcyBvbmx5IG1hdHRlciBv ZiB0aW1lLiBUaGUgYXV0aG9ycyBoYXZlIGFncmVlZCB0byByZW1vdmUgdGhlIGFyY2hpdGVjdHVy YWwgY29uZmxpY3QsIGlmIHRoZXJlIHdhcyBhbnkuIFdlIGhhdmUgb2ZmZXJlZCB0byBoZWxwIG9u IHRoZSBpbXByb3ZlbWVudCBieSBpbXBsZW1lbnRhdGlvbi4NCg0KR2l2aW5nIHRpbWUsIGJvdGgg c29sdXRpb24gY2FuIGJlIG1hdHVyZSBlbm91Z2ggZm9yIG9wZXJhdGlvbnMuIElFVEYgZG9lcyBu b3QgaGF2ZSB0byBjaG9vc2Ugb25lIGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25zIGFy ZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGEgc2FtZSBwYWNlLg0KDQp3aGF0IGlmLCBnaXZpbmcgdGlt ZSwgcGVvcGxlIGNhbiBiZSBtYXR1cmUgZW5vdWdoIHRvIGlkZW50aWZ5IDRyZC1VIGlzIHJlYWxs eSBhIGZsYXdlZCBkb25rb3JzZT8gOy0pIGlmIHRoZSA0cmQtdSBkZXNpZ25lcnMgYXJlIHNvIGNv bmZpZGVudCwgd2h5IG5vdCBkbyB0aGUgcmVhbCBjb2Rpbmcgd29yayBmaXJzdCBhbmQgdGhlbiBw cm9wb3NlIGl0IGFzIGEgcmVwbGFjZW1lbnQgb2YgTUFQIHN1aXRlPyBpIGRvbid0IHNlZSBhbnkg dW5mYWlybmVzcyBoZXJlLiAtIG1hb2tlDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQpG cm9tOiBNYW9rZSBbbWFpbHRvOmZpYnJpYkBnbWFpbC5jb208bWFpbHRvOmZpYnJpYkBnbWFpbC5j b20+XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiAzOjI0IFBNDQpUbzogU2hlbmcgSmlh bmcNCkNjOiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVycmVhdWx0OyBzb2Z0d2ly ZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtT b2Z0d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJkLVUgYXMgdHJhbnNw YXJlbnQgYXMgTUFQLUUNCg0KaGkgWWl1IGFuZCBvdGhlcnMsDQoNCjEuICJib3RoIHB1Ymxpc2hl ZCIgZG9lcyBzdXJlbHkgY29uZmxpY3Qgd2l0aCB0aGUgZGVzaWduIGdvYWwgb2YgNHJkLVUgaXRz ZWxmOg0KICAgdW5pZmljYXRpb24gb2YgbXVsdGlwbGUgc3RhbmRhcmRzLiBwb2xpdGljYWxseSBz cGVha2luZywgdGhlIDRyZC11IGF1dGhvcnMnDQogICBwb3NpdGl0aW9uIGlzIG5vdyBxdWl0ZSBj b25mdXNpbmcuDQoNCjIuIG9wZXJhdG9ycyBzdXJlbHkgbmVlZCB0byBjaG9vc2UgSVB2NiB0cmFu c2l0aW9uIG1lY2hhbmlzbXMgYnV0IHN1Y2ggYSBjaG9pY2UNCiAgIGlzIGJhc2VkIG9uIHRoZWly IGRlbWFuZCBhbmQgdW5kZXJzdGFuZGluZyB0byB0aGUgZXhpc3RpbmcgYW5kIHdlbGwtdGVzdGVk LA0KICAgd2VsbC1wcmFjdGljZWQgYnVpbGRpbmcgYmxvY2tzLiBpIGRvbid0IHRoaW5rIGFueSBv cGVyYXRvcnMgYXJlIHdhaXRpbmcgZm9yDQogICBhbiBvcHRpb24gb2YgY2hvaWNlIHRoZXkgbmV2 ZXIgc2VlIGFuZCBuZXZlciB1bmRlcnN0YW5kLiBhbmQgdGhlICJlbm91Z2gNCiAgIHRlY2huaWNh bCBzdXBwb3J0cyIgaXMgbm93IHN0aWxsICJhIGNoZWNrIHdpdGhvdXQgc2lnbmF0dXJlIi4gaSBk byBzdWdnZXN0DQogICB0aGUgNHJkLXUgYXV0aG9ycyBhbmQgc3VwcG9ydGVycyBzYXkgdGhhdCBh ZnRlciBtYWtpbmcgc29tZXRoaW5nIHJlYWwuDQoNCiAgIG9uIHRoZSBvdGhlciBoYW5kLCA0cmQt dSBtYWtlcyBhIHRpZ2h0IGNvdXBsaW5nIGJldHdlZW4gdGhlIGFkZHJlc3MgZm9ybWF0DQogICBh bmQgaXRzIG93biBoZWFkZXIgbWFwcGluZyBtZWNoYW5pc20uIHRoaXMgbWFrZXMgYW4gb3BlcmF0 b3IgdW5hYmxlIHRvIGhhdmUNCiAgIGRpZmZlcmVudCBjaG9pY2VzIG9mIHRyYW5zaXRpb24gbWVj aGFuaXNtIGFzIGxvbmcgYXMgaXQgY2hvb3NlcyA0cmQtdS4gaWYNCiAgIHlvdSBjb25jZXJuIHRo ZSBjaG9pY2Ugb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbSwgaSBkbyByZWNvbW1lbmQgTUFQ LCBhcw0KICAgZWl0aGVyIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRpb24gaXMgb3BlcmF0YWJs ZSB3aXRoIE1BUCBhZGRyZXNzL3BvcnQNCiAgIG1hcHBpbmcgd2l0aG91dCBkaWZmaWN1bHR5Lg0K DQozLiBzdXJlbHkgTUFQIHN0aWxsIGhhcyByb29tIG9mIGltcHJvdmVtZW50IGJ1dCBpIGRvbid0 IHRoaW5rIHRoZXJlIGFyZQ0KICAgYXJjaGl0ZWN0dXJhbCB1bmNlcnRhaW50eSBhcyA0cmQtVSBo YXMuIHJlcXVlc3Qgb24gbW9yZSB0ZXN0aW5nIGRhdGEgaXMNCiAgIHN1cmVseSBhcHByZWNpYXRl ZCBidXQgcGxlYXNlIHRoaW5rIGl0IG92ZXIgYWdhaW4gaWYgaXQgaXMgYSBjb3JyZWN0IHdheQ0K ICAgdG8gcmVxdWlyZSBmdXJ0aGVyIGRhdGEgb2YgYSBjb3VudGVycGFydCBpbiBvcmRlciB0byBk ZWZlbnNlIGEgc29sdXRpb24NCiAgIHdpdGhvdXQgYW55IGRhdGEuDQoNCjQuIGV2ZW4gdGhlcmUg d2VyZSBubyBNQVAgYXQgYWxsLCBjdXJyZW50IGxldmVsIG9mIDRyZC1VIGlzIGZhciBwcmVtYXR1 cmUgdG8gYmUNCiAgIHRhbGtlZCBhYm91dCBhbnkgd29ya2luZyBncm91cCBhY2NlcHRpb24uDQoN CnRoZSBhdXRob3JzIGFuZCBzdXBwb3J0ZXJzIHdpbGwgYmUgYXBwcmVjaWF0ZWQgaWYgdGhleSB0 YWxrIGFib3V0IHRoZSBhY2NlcHRpb24NCmFmdGVyIHRoZWlyIGNvZGluZyBhbmQgdGVzdGluZyBh bmQgcmVmaW5lbWVudCBvbiB0aGUgZG9jdW1lbnQgYWNjb3JkaW5nIHRvIHRoZWlyDQpwcmFjdGlj YWwgZXhwZXJpZW5jZXMsIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBwcm9ibGVtIGFnYWluIGFuZCBh Z2Fpbi4NCg0KdGhhbmtzLA0KbWFva2UNCg0KMjAxMi80LzkgU2hlbmcgSmlhbmcgPGppYW5nc2hl bmdAaHVhd2VpLmNvbTxtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tPj4NCj4gSSBhbHNvIGZv bGxvd2VkIHRoZSBkaXNjdXNzaW9uLiBJIGFwcHJlY2lhdGUgYm90aCB0ZWFtcyBib3VnaHQgdXAg dGhlDQo+IHRlY2huaWNhbCBkZXRhaWxzIGZvciBib3RoIGRlc2lnbnMuIFRvIGJlIGhvbmVzdCwg SSBmYWlsIHRvIHNlZSB3aGljaA0KPiBvbmUgaXMgYmV0dGVyIHRoYW4gb3RoZXIgKHlldCkuIEkg bGlrZSB0aGUgZmFjdCB0aGF0IDRyZC11IGNhbiBkbyB3aGF0DQo+IE1BUC1UIGRvZXMgdy9vIGlu dHJvZHVjaW5nIGFueSBlbmNhcCBvdmVyaGVhZC4gQnV0IEkgdW5kZXJzdGFuZCB0aGUNCj4gY29u Y2VybnMgb3RoZXJzIGJyb3VnaHQgdXAgaW4gdGhlIE1MIHN1Y2ggYXMgVi1vY3RldC4gRm9yIE1B UC1ULCBJIGxpa2UNCj4gaXQgbm90IGludHJvZHVjaW5nIGFueSBuZXcgcmVxdWlyZW1lbnQgdG8g dGhlIElQdjYgaGVhZGVyLCBidXQgSSBuZWVkDQo+IG1vcmUgcHVibGlzaGVkIGRhdGEgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdGhlIGRvdWJsZS10cmFuc2xhdGlvbiB3b3VsZA0KPiBjYXVzZSBhbnkg dHJhbnNwYXJlbnQgaXNzdWUgb3Igbm90LiBGb3IgZXhhbXBsZTogSSB3b3VsZCB2ZXJ5DQo+IGFw cHJlY2lhdGUgaWYgc29tZWJvZHkgd2hvIHRyaWFsIE1BUCBjYW4gcHVibGlzaCBkYXRhIHN1Y2gg YXMgd2hhdA0KPiBhcHBsaWNhdGlvbnMgdGhleSBoYXZlIHRlc3RlZCwgd2hhdCBwYXNzIGFuZCB3 aGF0IGZhaWwuDQo+DQo+IFRoaXMgcGllY2Ugb2Ygd29yayBpcyB2ZXJ5IGltcG9ydGFudCBiZWNh dXNlIG9uY2Ugd2Ugc2VsZWN0IGl0LCB0aGlzDQo+IHRlY2hub2xvZ3kgd2lsbCBzdGF5IGZvciBs b25nIHRpbWUuIEkgZG8gbm90IHdhbnQgdG8gcnVzaCB0byBtYWtlIGENCj4gZGVjaXNpb24gYW5k IGNvbWUgYmFjayB0byByZWdyZXQgaW4gZnV0dXJlLg0KV2Ugd291bGQgbGlrZSB0byBzZWUgYm90 aCBzb2x1dGlvbiBwdWJsaXNoZWQuIFNvIHRoYXQsIG9wZXJhdG9ycyBjYW4gY2hvb3NlIGFjY29y ZGluZyB0byB0aGVpciBvd24gbmV0d29ya3MgYW5kIHByZWZlcmVuY2UuIFRoZXJlIGFyZSBlbm9y bW91cyBudW1iZXIgb2Ygb3BlcmF0b3JzLCB3aG8gZG8gbm90IGNvbWUgdG8gSUVURiBtZWV0aW5n IG9yIGRvIG5vdCBwYXJ0aWNpcGF0ZSBpbiBNTCBlaXRoZXIuIFRoZXkgYWxzbyBuZWVkIHRvIGNo b29zZSBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gVGhleSBzaG91bGQgYmUgcHJvdmlkZWQg ZW5vdWdoIHRlY2huaWNhbCBzdXBwb3J0cy4gVGhhdCdzIHRoZSByZXNwb25zZSBvZiBJRVRGLCBp biBvdXIgdW5kZXJzdGFuZGluZy4NCg0KPiBPbiA0LzYvMTIgNjowMCBBTSwgIkxpdWJpbmcgKExl bykiIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPG1haWx0bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29t Pj4gd3JvdGU6DQo+DQo+ID4rMQ0KPiA+DQo+ID5JJ3ZlIHJlYWQgdGhlIGVuZGxlc3MgZGlzY3Vz c2lvbiwgYW5kIGZvdW5kIHRoYXQgaXMgc2VlbXMgdGhlIE1BUCBhbHNvDQo+ID5oYXMgbm90IGZ1 bGx5IGNvbnZpbmNlZCB0aGUgSVNQIG9wZXJhdGlvbiBndXlzLg0KPiA+U2luY2UgdGhlcmUncyBl eHBsaWNpdCBjb250cm92ZXJzeSwgd2h5IG5vdCBqdXN0IHB1Ymxpc2ggdGhlbSBib3RoIGFzDQo+ ID5leHBlcmltZW50YWwuIHdoeSB3ZSBtdXN0IGNob3NlIG9uZSBhcyBhICJzdGFuZGFyZCB0cmFj ayI/IEJlaW5nIGENCj4gPnN0YW5kYXJkIHRyYWNrIGNhbiBlbGltaW5hdGUgb3BlcmF0b3JzJyBt aXNnaXZpbmc/DQo+ID4NCj4gPklmIHRoZSB0ZWNobm9sb2d5IGlzIHJlYWxseSBhcHByb3ByaWF0 ZSwgSSBkb24ndCB0aGluayB0aGUNCj4gImV4cGVyaW1lbnRhbCINCj4gPnN0YXR1cyB3b3VsZCBi ZSBhIGlzc3VlIGZvciB0aGUgb3BlcmF0b3JzIHRvIGFkb3B0LiBKdXN0IGxldCB0aGUNCj4gPm9w ZXJhdG9yIGRlY2lkZSBieSB0aGVtc2VsdmVzLg0KPiA+DQo+ID5JIHJlbWVtYmVyZWQgaW4gdGhl IG1lZXRpbmcgdmVudWUsIEpvZWwgSGFscGVybiB3aG8gY2hhaXJzIEthcnAgYW5kDQo+ID5saXNw IFdHLCBzdWdnZXN0ZWQgd2UgcHVibGlzaCBib3RoIG9mIHRoZW0gYXMgZXhwZXJpbWVudGFsLCBh bmQgdGhhdA0KPiA+d2FzIGV4YWN0bHkgaG93IHRoZXkgaGFuZGxlIHRoZSBzaW1pbGFyIHNpdHVh dGlvbiBpbiB0aGVpciBXRy4gSSB0aGluaw0KPiA+aGlzIHN1Z2dlc3Rpb24gaXMgcmVhc29uYWJs ZSB0byBiZSBjb25zaWRlcmVkLiAoVG8gSm9lbDogUGFyZG9uIG1lIGlmDQo+IEkNCj4gPmltcHJv cGVybHkgcXVvdGVkIHlvdXIgY29tbWVudCwgb3IgSSBqdXN0IG1pc3VuZGVyc3Rvb2QgeW91cg0K PiBzdWdnZXN0aW9uDQo+ID4pLg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPiA+Pk9uICBCZWhhbGYgT2YgU2ltb24g UGVycmVhdWx0DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDEyIDg6MTYgUE0NCj4g Pj4gVG86IHNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPg0KPiA+ PiBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTF oCA0cmQtVSBhcw0KPiA+PnRyYW5zcGFyZW50ICBhcyBNQVAtRQ0KPiA+Pg0KPiA+PiBPbiAyMDEy LTA0LTAzIDA1OjQwLCBPbGUgVHLDuGFuIHdyb3RlOg0KPiA+PiA+IDEpIE1BUC1FIHN1cHBvcnRz IGluZGVwZW5kZW5jZSBvZiBJUHY0IGFuZCBJUHY2IGFkZHJlc3NpbmcuIGJ5DQo+ID4+ID4gdXNp bmcNCj4gPj5odWINCj4gPj4gYW5kIHNwb2tlIG1vZGUgd2l0aCBhIHNlcGFyYXRlDQo+ID4+ID4g ICAgIG1hcHBpbmcgcnVsZSBwZXIgc3Vic2NyaWJlci4gaW4gdGhpcyBtb2RlIGUuZyBvbmx5IHBv cnRzIGNvdWxkDQo+ID4+ID4gYmUNCj4gPj4gZW1iZWRkZWQgaW4gdGhlIGFkZHJlc3MuIHRoaXMg aXMgbm90DQo+ID4+ID4gICAgIHBvc3NpYmxlIGluIGEgdHJhbnNsYXRpb24gc29sdXRpb24gbGlr ZSA0cmQtVS4NCj4gPj4NCj4gPj4gVGhpcyBtb2RlIG9mIG9wZXJhdGlvbiB3YXMgc3VnZ2VzdGVk IGxhc3Qgd2VlayBkdXJpbmcgdGhlIFNELU5BVA0KPiA+PiBwcmVzZW50YXRpb24uIFRoZXJlIHNl ZW1lZCB0byBiZSBjb25zZW5zdXMgYW1vbmcgb3BlcmF0b3JzIHRoYXQgaXQNCj4gPj4gd2FzIG5v dCBwcmFjdGljYWxseSBmZWFzaWJsZS4NCj4gPj4NCj4gPj4gPiAyKSBhIG5vZGUgaW5zaWRlIHRo ZSBuZXR3b3JrIHdpbGwgdHJlYXQgdHJhbnNsYXRlZCBwYWNrZXRzDQo+ID4+ID4gZGlmZmVyZW50 DQo+ID4+ZnJvbQ0KPiA+PiBlbmNhcHN1bGF0ZWQgb25lcy4NCj4gPj4gPiAgICAgZS5nLiBmb3Ig dGhlIHB1cnBvc2VzIG9mIGNvdW50aW5nIG9yIGZvciBhcHBseWluZyBmZWF0dXJlcy4NCj4gZm9y DQo+ID4+ID4gYW4NCj4gPj4gZW5jYXBzdWxhdGVkIHBhY2tldCBib3RoIHRoZSBjb21wbGV0ZQ0K PiA+PiA+ICAgICBJUHY0IGRhdGFncmFtIGFuZCB0aGUgSVB2NiBoZWFkZXIgaXMgYXZhaWxhYmxl LCBhbmQgZGlmZmVyZW50DQo+ID4+ZmVhdHVyZXMNCj4gPj4gY2FuIGJlIGFwcGxpZWQgdG8gYm90 aC4NCj4gPj4NCj4gPj4gSW4gcHJhY3RpY2UsIHRoZSBjb250ZW50cyBvZiBlbmNhcHN1bGF0ZWQg cGFja2V0cyBhcmUgcmFyZWx5DQo+ID4+IGluc3BlY3RlZCBieSBmaXJld2FsbHMgYW5kIG90aGVy IHN1Y2ggZGV2aWNlcy4NCj4gPj4NCj4gPj4NCj4gPj4gSU1ITyBhdCB0aGlzIHBvaW50IHdlIHNo b3VsZCBsZXQgdGhlIG1hcmtldCBkZWNpZGUuIFB1Ymxpc2ggYm90aCBhcw0KPiA+PiBleHBlcmlt ZW50YWwuIExldCdzIHdvcmsgb24gc29tZXRoaW5nIGVsc2Ugbm93Lg0KPiA+Pg0KPiA+PiBTaW1v bg0KPiA+PiAtLQ0KPiA+PiBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6 Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2ENCj4gPj4gTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2Ug ICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPiA+PiBTVFVOL1RVUk4gc2Vy dmVyICAgICAgICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFNvZnR3aXJl cyBtYWlsaW5nIGxpc3QNCj4gPj4gU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNA aWV0Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzDQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+U29mdHdpcmVzQGlldGYub3JnPG1haWx0 bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NvZnR3aXJlcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZzxtYWls dG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMNCg0KDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B921E48376DSZXEML506MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X aXRob3V0IGFueSBvYmplY3Rpb24gdG8gTUFQLCB3ZSBqdXN0IHN0YXJ0IHRvIGNvZGluZyA0cmQt dSBhbmQgaGVscCB0byBpbXByb3ZlIGl0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NdWx0aXBsZSB0cmFuc2l0aW9u IG1lY2hhbmlzbXMgd291bGQgY28tZXhpc3QgaW4gdGhlIHdvcmxkLiBOZWl0aGVyIE1BUCBub3Ig NHJkLVUgY2FuIHJlcGxhY2UgNnJkIGFuZCBEUy1MaXRlLiBUaGVyZSBpcyBubyBvbmUtc3VpdC1h bGwgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IE1hb2tlIFttYWlsdG86ZmlicmliQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEFwcmlsIDA5LCAyMDEyIDU6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IFNoZW5nIEppYW5nPGJy Pg0KPGI+Q2M6PC9iPiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVycmVhdWx0OyBz b2Z0d2lyZXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTb2Z0d2lyZXNdIFBh dGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJkLVUgYXMgdHJhbnNwYXJlbnQgYXMgTUFQ LUU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIwMTIvNC85IFNoZW5nIEppYW5nICZsdDs8YSBocmVmPSJtYWlsdG86 amlhbmdzaGVuZ0BodWF3ZWkuY29tIj5qaWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgYWxsb3cgbWUgdG8gY2xh cmlmeSBteXNlbGY6IEkgc3VwcG9ydCBib3RoIE1BUCBhbmQgNHJkLXUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TUFQIGhhcyBiZWVuIGEgZ29vZCBlZmZvcnQgd2l0aCBtYW55IGV4cGVydHMgdG9nZXRoZXIgaW4g SVB2NC9JUHY2IHRyYW5zaXRpb24gYXJlYSBhbmQgaGFzIGJlZW4gcHJvdmVkDQogYnkgcnVubmlu ZyBjb2RlLiBJdCBhbHNvIG5lZWQgdG8gaW1wcm92ZSBpdHNlbGYgYmVmb3JlIGJlaW5nIHB1Ymxp c2hlZCBhcyBhIFJGQyBsYXRlci4gVGhpcyBwcm9jZXNzIHdpbGwgdGFrZSBzZXZlcmFsIG1vbnRo cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5QZXJzb25hbGx5LCBJIHRoaW5rIDRyZC11IGlzIGEgbGl0dGxlIGJp dCBiZWhpbmQgTUFQIGluIG1hdHVyaXR5IGFzcGVjdCBmb3Igbm93LiBCdXQsIGl0IGlzIG9ubHkN CiBtYXR0ZXIgb2YgdGltZS4gVGhlIGF1dGhvcnMgaGF2ZSBhZ3JlZWQgdG8gcmVtb3ZlIHRoZSBh cmNoaXRlY3R1cmFsIGNvbmZsaWN0LCBpZiB0aGVyZSB3YXMgYW55LiBXZSBoYXZlIG9mZmVyZWQg dG8gaGVscCBvbiB0aGUgaW1wcm92ZW1lbnQgYnkgaW1wbGVtZW50YXRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+R2l2aW5nIHRpbWUsIGJvdGggc29sdXRpb24gY2FuIGJlIG1hdHVyZSBlbm91Z2ggZm9yIG9w ZXJhdGlvbnMuIElFVEYgZG9lcyBub3QgaGF2ZSB0byBjaG9vc2Ugb25lDQogYnkgbm93LiBBbmQs IHRoZXNlIHR3byBzb2x1dGlvbnMgYXJlIG5vdCBuZWNlc3NhcnkgdG8gYmUgYSBzYW1lIHBhY2Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndoYXQgaWYsIGdpdmluZyB0aW1lLCBwZW9wbGUgY2FuIGJlIG1hdHVyZSBl bm91Z2ggdG8gaWRlbnRpZnkgNHJkLVUgaXMgcmVhbGx5IGEgZmxhd2VkIGRvbmtvcnNlPyA7LSkg aWYgdGhlIDRyZC11IGRlc2lnbmVycyBhcmUgc28gY29uZmlkZW50LCB3aHkgbm90IGRvIHRoZSBy ZWFsIGNvZGluZyB3b3JrIGZpcnN0IGFuZCB0aGVuIHByb3Bvc2UgaXQgYXMgYSByZXBsYWNlbWVu dCBvZiBNQVAgc3VpdGU/IGkgZG9uJ3QNCiBzZWUgYW55IHVuZmFpcm5lc3MgaGVyZS4gLSBtYW9r ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TaGVuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTWFva2UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmlicmliQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZpYnJpYkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXByaWwgMDksIDIwMTIgMzoyNCBQTTxicj4NCjxiPlRvOjwvYj4gU2hl bmcgSmlhbmc8YnI+DQo8Yj5DYzo8L2I+IExlZSwgWWl1OyBMaXViaW5nIChMZW8pOyBTaW1vbiBQ ZXJyZWF1bHQ7IDxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj4NCnNvZnR3aXJlc0BpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0cmQtVSBhcyB0cmFu c3BhcmVudCBhcyBNQVAtRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5oaSBZaXUgYW5kIG90aGVy cywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjEuICZxdW90O2JvdGggcHVibGlzaGVkJnF1b3Q7IGRvZXMgc3VyZWx5IGNvbmZs aWN0IHdpdGggdGhlIGRlc2lnbiBnb2FsIG9mIDRyZC1VIGl0c2VsZjombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNw O3VuaWZpY2F0aW9uIG9mIG11bHRpcGxlIHN0YW5kYXJkcy4mbmJzcDtwb2xpdGljYWxseSBzcGVh a2luZywgdGhlIDRyZC11IGF1dGhvcnMnDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3Bvc2l0aXRpb24gaXMgbm93IHF1 aXRlIGNvbmZ1c2luZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIG9wZXJhdG9ycyBzdXJlbHkgbmVlZCB0byBjaG9vc2Ug SVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgYnV0IHN1Y2ggYSBjaG9pY2UmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZu YnNwO2lzIGJhc2VkIG9uIHRoZWlyIGRlbWFuZCBhbmQgdW5kZXJzdGFuZGluZyB0byB0aGUgZXhp c3RpbmcgYW5kIHdlbGwtdGVzdGVkLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7d2VsbC1wcmFjdGljZWQgYnVp bGRpbmcgYmxvY2tzLiBpIGRvbid0IHRoaW5rIGFueSBvcGVyYXRvcnMgYXJlIHdhaXRpbmcgZm9y Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyAmbmJzcDthbiBvcHRpb24gb2YgY2hvaWNlIHRoZXkgbmV2ZXIgc2VlIGFuZCBu ZXZlciB1bmRlcnN0YW5kLiBhbmQgdGhlICZxdW90O2Vub3VnaCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7dGVj aG5pY2FsIHN1cHBvcnRzJnF1b3Q7IGlzIG5vdyBzdGlsbCAmcXVvdDthIGNoZWNrIHdpdGhvdXQg c2lnbmF0dXJlJnF1b3Q7LiBpIGRvIHN1Z2dlc3QmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3RoZSA0cmQtdSBh dXRob3JzIGFuZCBzdXBwb3J0ZXJzIHNheSB0aGF0IGFmdGVyIG1ha2luZyBzb21ldGhpbmcgcmVh bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtvbiB0aGUgb3RoZXIgaGFuZCwgNHJkLXUgbWFrZXMgYSB0 aWdodCBjb3VwbGluZyBiZXR3ZWVuIHRoZSBhZGRyZXNzIGZvcm1hdCZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 YW5kIGl0cyBvd24gaGVhZGVyIG1hcHBpbmcgbWVjaGFuaXNtLiB0aGlzIG1ha2VzIGFuIG9wZXJh dG9yIHVuYWJsZSB0byBoYXZlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtkaWZmZXJlbnQgY2hvaWNlcyBvZiB0 cmFuc2l0aW9uIG1lY2hhbmlzbSBhcyBsb25nIGFzIGl0IGNob29zZXMgNHJkLXUuIGlmJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDt5b3UgY29uY2VybiB0aGUgY2hvaWNlIG9mIElQdjYgdHJhbnNpdGlvbiBtZWNo YW5pc20sIGkgZG8gcmVjb21tZW5kIE1BUCwgYXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2VpdGhlciBlbmNh cHN1bGF0aW9uIG9yIHRyYW5zbGF0aW9uIGlzIG9wZXJhdGFibGUgd2l0aCBNQVAgYWRkcmVzcy9w b3J0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDttYXBwaW5nIHdpdGhvdXQgZGlmZmljdWx0eS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMu IHN1cmVseSBNQVAgc3RpbGwgaGFzIHJvb20gb2YgaW1wcm92ZW1lbnQgYnV0IGkgZG9uJ3QgdGhp bmsgdGhlcmUgYXJlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDthcmNoaXRlY3R1cmFsIHVuY2VydGFpbnR5IGFz IDRyZC1VIGhhcy4gcmVxdWVzdCBvbiBtb3JlIHRlc3RpbmcgZGF0YSBpcyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7c3VyZWx5IGFwcHJlY2lhdGVkIGJ1dCBwbGVhc2UgdGhpbmsgaXQgb3ZlciBhZ2FpbiBpZiBp dCBpcyBhIGNvcnJlY3Qgd2F5Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0byByZXF1aXJlIGZ1cnRoZXIgZGF0 YSBvZiBhIGNvdW50ZXJwYXJ0IGluIG9yZGVyIHRvIGRlZmVuc2UgYSBzb2x1dGlvbiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7d2l0aG91dCBhbnkgZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuIGV2ZW4gdGhlcmUgd2VyZSBubyBN QVAgYXQgYWxsLCBjdXJyZW50IGxldmVsIG9mIDRyZC1VIGlzIGZhciBwcmVtYXR1cmUgdG8gYmUm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwO3RhbGtlZCBhYm91dCBhbnkgd29ya2luZyBncm91cCBhY2NlcHRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij50aGUgYXV0aG9ycyBhbmQgc3VwcG9ydGVycyB3aWxsIGJlIGFwcHJlY2lhdGVkIGlmIHRoZXkg dGFsayBhYm91dCB0aGUgYWNjZXB0aW9uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFmdGVyIHRoZWlyIGNvZGluZyBhbmQgdGVzdGlu ZyBhbmQgcmVmaW5lbWVudCBvbiB0aGUgZG9jdW1lbnQgYWNjb3JkaW5nIHRvIHRoZWlyJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnBy YWN0aWNhbCBleHBlcmllbmNlcywgYW5kIHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0gYWdhaW4g YW5kIGFnYWluLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+dGhhbmtzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5tYW9rZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxMi80LzkgU2hlbmcgSmlhbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5r Ij5qaWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+Jmd0OyBJIGFsc28gZm9sbG93ZWQgdGhlIGRpc2N1c3Npb24uIEkgYXBw cmVjaWF0ZSBib3RoIHRlYW1zIGJvdWdodCB1cCB0aGU8YnI+DQomZ3Q7IHRlY2huaWNhbCBkZXRh aWxzIGZvciBib3RoIGRlc2lnbnMuIFRvIGJlIGhvbmVzdCwgSSBmYWlsIHRvIHNlZSB3aGljaDxi cj4NCiZndDsgb25lIGlzIGJldHRlciB0aGFuIG90aGVyICh5ZXQpLiBJIGxpa2UgdGhlIGZhY3Qg dGhhdCA0cmQtdSBjYW4gZG8gd2hhdDxicj4NCiZndDsgTUFQLVQgZG9lcyB3L28gaW50cm9kdWNp bmcgYW55IGVuY2FwIG92ZXJoZWFkLiBCdXQgSSB1bmRlcnN0YW5kIHRoZTxicj4NCiZndDsgY29u Y2VybnMgb3RoZXJzIGJyb3VnaHQgdXAgaW4gdGhlIE1MIHN1Y2ggYXMgVi1vY3RldC4gRm9yIE1B UC1ULCBJIGxpa2U8YnI+DQomZ3Q7IGl0IG5vdCBpbnRyb2R1Y2luZyBhbnkgbmV3IHJlcXVpcmVt ZW50IHRvIHRoZSBJUHY2IGhlYWRlciwgYnV0IEkgbmVlZDxicj4NCiZndDsgbW9yZSBwdWJsaXNo ZWQgZGF0YSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG91YmxlLXRyYW5zbGF0aW9uIHdvdWxk PGJyPg0KJmd0OyBjYXVzZSBhbnkgdHJhbnNwYXJlbnQgaXNzdWUgb3Igbm90LiBGb3IgZXhhbXBs ZTogSSB3b3VsZCB2ZXJ5PGJyPg0KJmd0OyBhcHByZWNpYXRlIGlmIHNvbWVib2R5IHdobyB0cmlh bCBNQVAgY2FuIHB1Ymxpc2ggZGF0YSBzdWNoIGFzIHdoYXQ8YnI+DQomZ3Q7IGFwcGxpY2F0aW9u cyB0aGV5IGhhdmUgdGVzdGVkLCB3aGF0IHBhc3MgYW5kIHdoYXQgZmFpbC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaGlzIHBpZWNlIG9mIHdvcmsgaXMgdmVyeSBpbXBvcnRhbnQgYmVjYXVzZSBvbmNl IHdlIHNlbGVjdCBpdCwgdGhpczxicj4NCiZndDsgdGVjaG5vbG9neSB3aWxsIHN0YXkgZm9yIGxv bmcgdGltZS4gSSBkbyBub3Qgd2FudCB0byBydXNoIHRvIG1ha2UgYTxicj4NCiZndDsgZGVjaXNp b24gYW5kIGNvbWUgYmFjayB0byByZWdyZXQgaW4gZnV0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIHdvdWxkIGxpa2UgdG8gc2VlIGJvdGggc29s dXRpb24gcHVibGlzaGVkLiBTbyB0aGF0LCBvcGVyYXRvcnMgY2FuIGNob29zZSBhY2NvcmRpbmcg dG8gdGhlaXIgb3duIG5ldHdvcmtzIGFuZCBwcmVmZXJlbmNlLiBUaGVyZSBhcmUgZW5vcm1vdXMg bnVtYmVyIG9mIG9wZXJhdG9ycywgd2hvIGRvIG5vdCBjb21lDQogdG8gSUVURiBtZWV0aW5nIG9y IGRvIG5vdCBwYXJ0aWNpcGF0ZSBpbiBNTCBlaXRoZXIuIFRoZXkgYWxzbyBuZWVkIHRvIGNob29z ZSBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gVGhleSBzaG91bGQgYmUgcHJvdmlkZWQgZW5v dWdoIHRlY2huaWNhbCBzdXBwb3J0cy4gVGhhdCdzIHRoZSByZXNwb25zZSBvZiBJRVRGLCBpbiBv dXIgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQomZ3Q7IE9uIDQvNi8xMiA2OjAwIEFNLCAmcXVvdDtMaXViaW5n IChMZW8pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmxlby5saXViaW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7JiM0MzsxPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 SSd2ZSByZWFkIHRoZSBlbmRsZXNzIGRpc2N1c3Npb24sIGFuZCBmb3VuZCB0aGF0IGlzIHNlZW1z IHRoZSBNQVAgYWxzbzxicj4NCiZndDsgJmd0O2hhcyBub3QgZnVsbHkgY29udmluY2VkIHRoZSBJ U1Agb3BlcmF0aW9uIGd1eXMuPGJyPg0KJmd0OyAmZ3Q7U2luY2UgdGhlcmUncyBleHBsaWNpdCBj b250cm92ZXJzeSwgd2h5IG5vdCBqdXN0IHB1Ymxpc2ggdGhlbSBib3RoIGFzPGJyPg0KJmd0OyAm Z3Q7ZXhwZXJpbWVudGFsLiB3aHkgd2UgbXVzdCBjaG9zZSBvbmUgYXMgYSAmcXVvdDtzdGFuZGFy ZCB0cmFjayZxdW90Oz8gQmVpbmcgYTxicj4NCiZndDsgJmd0O3N0YW5kYXJkIHRyYWNrIGNhbiBl bGltaW5hdGUgb3BlcmF0b3JzJyBtaXNnaXZpbmc/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7SWYgdGhlIHRlY2hub2xvZ3kgaXMgcmVhbGx5IGFwcHJvcHJpYXRlLCBJIGRvbid0IHRoaW5r IHRoZTxicj4NCiZndDsgJnF1b3Q7ZXhwZXJpbWVudGFsJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7c3Rh dHVzIHdvdWxkIGJlIGEgaXNzdWUgZm9yIHRoZSBvcGVyYXRvcnMgdG8gYWRvcHQuIEp1c3QgbGV0 IHRoZTxicj4NCiZndDsgJmd0O29wZXJhdG9yIGRlY2lkZSBieSB0aGVtc2VsdmVzLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0O0kgcmVtZW1iZXJlZCBpbiB0aGUgbWVldGluZyB2ZW51ZSwg Sm9lbCBIYWxwZXJuIHdobyBjaGFpcnMgS2FycCBhbmQ8YnI+DQomZ3Q7ICZndDtsaXNwIFdHLCBz dWdnZXN0ZWQgd2UgcHVibGlzaCBib3RoIG9mIHRoZW0gYXMgZXhwZXJpbWVudGFsLCBhbmQgdGhh dDxicj4NCiZndDsgJmd0O3dhcyBleGFjdGx5IGhvdyB0aGV5IGhhbmRsZSB0aGUgc2ltaWxhciBz aXR1YXRpb24gaW4gdGhlaXIgV0cuIEkgdGhpbms8YnI+DQomZ3Q7ICZndDtoaXMgc3VnZ2VzdGlv biBpcyByZWFzb25hYmxlIHRvIGJlIGNvbnNpZGVyZWQuIChUbyBKb2VsOiBQYXJkb24gbWUgaWY8 YnI+DQomZ3Q7IEk8YnI+DQomZ3Q7ICZndDtpbXByb3Blcmx5IHF1b3RlZCB5b3VyIGNvbW1lbnQs IG9yIEkganVzdCBtaXN1bmRlcnN0b29kIHlvdXI8YnI+DQomZ3Q7IHN1Z2dlc3Rpb248YnI+DQom Z3Q7ICZndDspLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpz b2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXMtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPC9h Pl08YnI+DQomZ3Q7ICZndDsmZ3Q7T24gJm5ic3A7QmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVsdDxi cj4NCiZndDsgJmd0OyZndDsgU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIwMTIgODoxNiBQTTxi cj4NCiZndDsgJmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTF oCA0cmQtVSBhczxicj4NCiZndDsgJmd0OyZndDt0cmFuc3BhcmVudCAmbmJzcDthcyBNQVAtRTxi cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9uIDIwMTItMDQtMDMgMDU6NDAs IE9sZSBUcsO4YW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDEpIE1BUC1FIHN1cHBv cnRzIGluZGVwZW5kZW5jZSBvZiBJUHY0IGFuZCBJUHY2IGFkZHJlc3NpbmcuIGJ5PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7IHVzaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0O2h1Yjxicj4NCiZndDsgJmd0 OyZndDsgYW5kIHNwb2tlIG1vZGUgd2l0aCBhIHNlcGFyYXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgbWFwcGluZyBydWxlIHBlciBzdWJzY3JpYmVyLiBpbiB0aGlzIG1v ZGUgZS5nIG9ubHkgcG9ydHMgY291bGQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgYmU8YnI+DQom Z3Q7ICZndDsmZ3Q7IGVtYmVkZGVkIGluIHRoZSBhZGRyZXNzLiB0aGlzIGlzIG5vdDxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHBvc3NpYmxlIGluIGEgdHJhbnNsYXRpb24g c29sdXRpb24gbGlrZSA0cmQtVS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBUaGlzIG1vZGUgb2Ygb3BlcmF0aW9uIHdhcyBzdWdnZXN0ZWQgbGFzdCB3ZWVrIGR1cmluZyB0 aGUgU0QtTkFUPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBwcmVzZW50YXRpb24uIFRoZXJlIHNlZW1lZCB0 byBiZSBjb25zZW5zdXMgYW1vbmcgb3BlcmF0b3JzIHRoYXQgaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHdhcyBub3QgcHJhY3RpY2FsbHkgZmVhc2libGUuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyAyKSBhIG5vZGUgaW5zaWRlIHRoZSBuZXR3b3JrIHdpbGwgdHJlYXQg dHJhbnNsYXRlZCBwYWNrZXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGRpZmZlcmVudDxicj4N CiZndDsgJmd0OyZndDtmcm9tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbmNhcHN1bGF0ZWQgb25lcy48 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBlLmcuIGZvciB0aGUgcHVycG9z ZXMgb2YgY291bnRpbmcgb3IgZm9yIGFwcGx5aW5nIGZlYXR1cmVzLjxicj4NCiZndDsgZm9yPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbmNhcHN1bGF0ZWQg cGFja2V0IGJvdGggdGhlIGNvbXBsZXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgSVB2NCBkYXRhZ3JhbSBhbmQgdGhlIElQdjYgaGVhZGVyIGlzIGF2YWlsYWJsZSwgYW5k IGRpZmZlcmVudDxicj4NCiZndDsgJmd0OyZndDtmZWF0dXJlczxicj4NCiZndDsgJmd0OyZndDsg Y2FuIGJlIGFwcGxpZWQgdG8gYm90aC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBJbiBwcmFjdGljZSwgdGhlIGNvbnRlbnRzIG9mIGVuY2Fwc3VsYXRlZCBwYWNrZXRzIGFy ZSByYXJlbHk8YnI+DQomZ3Q7ICZndDsmZ3Q7IGluc3BlY3RlZCBieSBmaXJld2FsbHMgYW5kIG90 aGVyIHN1Y2ggZGV2aWNlcy48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgSU1ITyBhdCB0aGlzIHBvaW50IHdlIHNob3VsZCBsZXQgdGhlIG1h cmtldCBkZWNpZGUuIFB1Ymxpc2ggYm90aCBhczxicj4NCiZndDsgJmd0OyZndDsgZXhwZXJpbWVu dGFsLiBMZXQncyB3b3JrIG9uIHNvbWV0aGluZyBlbHNlIG5vdy48YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTaW1vbjxicj4NCiZndDsgJmd0OyZndDsgLS08YnI+DQomZ3Q7 ICZndDsmZ3Q7IERUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLSZndDsgPGEgaHJlZj0i aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov L3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IE5BVDY0L0RO UzY0IG9wZW4tc291cmNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tJmd0OyA8YSBocmVm PSJodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2Vj ZHlzaXMudmlhZ2VuaWUuY2E8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTVFVOL1RVUk4gc2VydmVy ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSZndDsg PGEgaHJlZj0iaHR0cDovL251bWIudmlhZ2VuaWUuY2EiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly9udW1iLnZpYWdlbmllLmNhPC9hPjxicj4NCiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7IFNvZnR3 aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpTb2Z0 d2lyZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NvZnR3aXJlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjxicj4NCiZndDsgJmd0O19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7U29mdHdpcmVz IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpTb2Z0d2lyZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm Z3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly ZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NvZnR3aXJlczwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86U29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U29mdHdpcmVzQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zb2Z0d2lyZXM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B921E48376DSZXEML506MBSchi_-- From jiangsheng@huawei.com Mon Apr 9 03:03:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A021F855D for ; Mon, 9 Apr 2012 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mecXzC-8NeX for ; Mon, 9 Apr 2012 03:03:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2BC21F852A for ; Mon, 9 Apr 2012 03:03:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB46659; Mon, 09 Apr 2012 06:03:01 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:00:44 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:00:43 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 18:00:35 +0800 From: Sheng Jiang To: "softwires@ietf.org" Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFARiZtrTrKb1lUiyg6DfbC+e/JaSBBzg//+RWQCAAIj4IP//nIAAgACMLsA= Date: Mon, 9 Apr 2012 10:00:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E4837A5@SZXEML506-MBS.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BQrM CHVI CfdV DSqz ENRE ETG1 FYX2 Fnyi FsRa F571 HUge HnSl HrAO Jpgj Jq2Z KNDe; 1; cwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8FAFA482-9146-4DBB-90FA-5611D5DFF3FE}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 09 Apr 2012 10:00:32 GMT; UgBFADoAIABbAFMAbwBmAHQAdwBpAHIAZQBzAF0AIABQAGEAdABoACAAdABvACAAbQBvAHYAZQAgAGYAbwByAHcAYQByAGQAIAB3AGkAdABoACAANAByAGQAYAEgADQAcgBkAC0AVQAgAGEAcwAgAHQAcgBhAG4AcwBwAGEAcgBlAG4AdAAgAGEAcwAgAE0AQQBQAC0ARQA= x-cr-puzzleid: {8FAFA482-9146-4DBB-90FA-5611D5DFF3FE} x-originating-ip: [10.108.4.115] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B921E4837A5SZXEML506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 10 Apr 2012 08:49:04 -0700 Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:03:03 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837A5SZXEML506MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aG91dCBhbnkgb2JqZWN0aW9uIHRvIE1BUCwgd2UganVzdCBzdGFydCB0byBjb2RpbmcgNHJk LXUgYW5kIGhlbHAgdG8gaW1wcm92ZSBpdC4NCg0KTXVsdGlwbGUgdHJhbnNpdGlvbiBtZWNoYW5p c21zIHdvdWxkIGNvLWV4aXN0IGluIHRoZSB3b3JsZC4gTmVpdGhlciBNQVAgbm9yIDRyZC1VIGNh biByZXBsYWNlIDZyZCBhbmQgRFMtTGl0ZS4gVGhlcmUgaXMgbm8gb25lLXN1aXQtYWxsIHNvbHV0 aW9uLg0KDQoNCkZyb206IE1hb2tlIFttYWlsdG86ZmlicmliQGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgQXByaWwgMDksIDIwMTIgNTozOSBQTQ0KVG86IFNoZW5nIEppYW5nDQpDYzogTGVlLCBZ aXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0 cmQtVSBhcyB0cmFuc3BhcmVudCBhcyBNQVAtRQ0KDQoNCjIwMTIvNC85IFNoZW5nIEppYW5nIDxq aWFuZ3NoZW5nQGh1YXdlaS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbT4+DQpQbGVh c2UgYWxsb3cgbWUgdG8gY2xhcmlmeSBteXNlbGY6IEkgc3VwcG9ydCBib3RoIE1BUCBhbmQgNHJk LXUuDQoNCk1BUCBoYXMgYmVlbiBhIGdvb2QgZWZmb3J0IHdpdGggbWFueSBleHBlcnRzIHRvZ2V0 aGVyIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIGFyZWEgYW5kIGhhcyBiZWVuIHByb3ZlZCBieSBy dW5uaW5nIGNvZGUuIEl0IGFsc28gbmVlZCB0byBpbXByb3ZlIGl0c2VsZiBiZWZvcmUgYmVpbmcg cHVibGlzaGVkIGFzIGEgUkZDIGxhdGVyLiBUaGlzIHByb2Nlc3Mgd2lsbCB0YWtlIHNldmVyYWwg bW9udGhzLg0KDQpQZXJzb25hbGx5LCBJIHRoaW5rIDRyZC11IGlzIGEgbGl0dGxlIGJpdCBiZWhp bmQgTUFQIGluIG1hdHVyaXR5IGFzcGVjdCBmb3Igbm93LiBCdXQsIGl0IGlzIG9ubHkgbWF0dGVy IG9mIHRpbWUuIFRoZSBhdXRob3JzIGhhdmUgYWdyZWVkIHRvIHJlbW92ZSB0aGUgYXJjaGl0ZWN0 dXJhbCBjb25mbGljdCwgaWYgdGhlcmUgd2FzIGFueS4gV2UgaGF2ZSBvZmZlcmVkIHRvIGhlbHAg b24gdGhlIGltcHJvdmVtZW50IGJ5IGltcGxlbWVudGF0aW9uLg0KDQpHaXZpbmcgdGltZSwgYm90 aCBzb2x1dGlvbiBjYW4gYmUgbWF0dXJlIGVub3VnaCBmb3Igb3BlcmF0aW9ucy4gSUVURiBkb2Vz IG5vdCBoYXZlIHRvIGNob29zZSBvbmUgYnkgbm93LiBBbmQsIHRoZXNlIHR3byBzb2x1dGlvbnMg YXJlIG5vdCBuZWNlc3NhcnkgdG8gYmUgYSBzYW1lIHBhY2UuDQoNCndoYXQgaWYsIGdpdmluZyB0 aW1lLCBwZW9wbGUgY2FuIGJlIG1hdHVyZSBlbm91Z2ggdG8gaWRlbnRpZnkgNHJkLVUgaXMgcmVh bGx5IGEgZmxhd2VkIGRvbmtvcnNlPyA7LSkgaWYgdGhlIDRyZC11IGRlc2lnbmVycyBhcmUgc28g Y29uZmlkZW50LCB3aHkgbm90IGRvIHRoZSByZWFsIGNvZGluZyB3b3JrIGZpcnN0IGFuZCB0aGVu IHByb3Bvc2UgaXQgYXMgYSByZXBsYWNlbWVudCBvZiBNQVAgc3VpdGU/IGkgZG9uJ3Qgc2VlIGFu eSB1bmZhaXJuZXNzIGhlcmUuIC0gbWFva2UNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoN CkZyb206IE1hb2tlIFttYWlsdG86ZmlicmliQGdtYWlsLmNvbTxtYWlsdG86ZmlicmliQGdtYWls LmNvbT5dDQpTZW50OiBNb25kYXksIEFwcmlsIDA5LCAyMDEyIDM6MjQgUE0NClRvOiBTaGVuZyBK aWFuZw0KQ2M6IExlZSwgWWl1OyBMaXViaW5nIChMZW8pOyBTaW1vbiBQZXJyZWF1bHQ7IHNvZnR3 aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0cmQtVSBhcyB0cmFu c3BhcmVudCBhcyBNQVAtRQ0KDQpoaSBZaXUgYW5kIG90aGVycywNCg0KMS4gImJvdGggcHVibGlz aGVkIiBkb2VzIHN1cmVseSBjb25mbGljdCB3aXRoIHRoZSBkZXNpZ24gZ29hbCBvZiA0cmQtVSBp dHNlbGY6DQogICB1bmlmaWNhdGlvbiBvZiBtdWx0aXBsZSBzdGFuZGFyZHMuIHBvbGl0aWNhbGx5 IHNwZWFraW5nLCB0aGUgNHJkLXUgYXV0aG9ycycNCiAgIHBvc2l0aXRpb24gaXMgbm93IHF1aXRl IGNvbmZ1c2luZy4NCg0KMi4gb3BlcmF0b3JzIHN1cmVseSBuZWVkIHRvIGNob29zZSBJUHY2IHRy YW5zaXRpb24gbWVjaGFuaXNtcyBidXQgc3VjaCBhIGNob2ljZQ0KICAgaXMgYmFzZWQgb24gdGhl aXIgZGVtYW5kIGFuZCB1bmRlcnN0YW5kaW5nIHRvIHRoZSBleGlzdGluZyBhbmQgd2VsbC10ZXN0 ZWQsDQogICB3ZWxsLXByYWN0aWNlZCBidWlsZGluZyBibG9ja3MuIGkgZG9uJ3QgdGhpbmsgYW55 IG9wZXJhdG9ycyBhcmUgd2FpdGluZyBmb3INCiAgIGFuIG9wdGlvbiBvZiBjaG9pY2UgdGhleSBu ZXZlciBzZWUgYW5kIG5ldmVyIHVuZGVyc3RhbmQuIGFuZCB0aGUgImVub3VnaA0KICAgdGVjaG5p Y2FsIHN1cHBvcnRzIiBpcyBub3cgc3RpbGwgImEgY2hlY2sgd2l0aG91dCBzaWduYXR1cmUiLiBp IGRvIHN1Z2dlc3QNCiAgIHRoZSA0cmQtdSBhdXRob3JzIGFuZCBzdXBwb3J0ZXJzIHNheSB0aGF0 IGFmdGVyIG1ha2luZyBzb21ldGhpbmcgcmVhbC4NCg0KICAgb24gdGhlIG90aGVyIGhhbmQsIDRy ZC11IG1ha2VzIGEgdGlnaHQgY291cGxpbmcgYmV0d2VlbiB0aGUgYWRkcmVzcyBmb3JtYXQNCiAg IGFuZCBpdHMgb3duIGhlYWRlciBtYXBwaW5nIG1lY2hhbmlzbS4gdGhpcyBtYWtlcyBhbiBvcGVy YXRvciB1bmFibGUgdG8gaGF2ZQ0KICAgZGlmZmVyZW50IGNob2ljZXMgb2YgdHJhbnNpdGlvbiBt ZWNoYW5pc20gYXMgbG9uZyBhcyBpdCBjaG9vc2VzIDRyZC11LiBpZg0KICAgeW91IGNvbmNlcm4g dGhlIGNob2ljZSBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtLCBpIGRvIHJlY29tbWVuZCBN QVAsIGFzDQogICBlaXRoZXIgZW5jYXBzdWxhdGlvbiBvciB0cmFuc2xhdGlvbiBpcyBvcGVyYXRh YmxlIHdpdGggTUFQIGFkZHJlc3MvcG9ydA0KICAgbWFwcGluZyB3aXRob3V0IGRpZmZpY3VsdHku DQoNCjMuIHN1cmVseSBNQVAgc3RpbGwgaGFzIHJvb20gb2YgaW1wcm92ZW1lbnQgYnV0IGkgZG9u J3QgdGhpbmsgdGhlcmUgYXJlDQogICBhcmNoaXRlY3R1cmFsIHVuY2VydGFpbnR5IGFzIDRyZC1V IGhhcy4gcmVxdWVzdCBvbiBtb3JlIHRlc3RpbmcgZGF0YSBpcw0KICAgc3VyZWx5IGFwcHJlY2lh dGVkIGJ1dCBwbGVhc2UgdGhpbmsgaXQgb3ZlciBhZ2FpbiBpZiBpdCBpcyBhIGNvcnJlY3Qgd2F5 DQogICB0byByZXF1aXJlIGZ1cnRoZXIgZGF0YSBvZiBhIGNvdW50ZXJwYXJ0IGluIG9yZGVyIHRv IGRlZmVuc2UgYSBzb2x1dGlvbg0KICAgd2l0aG91dCBhbnkgZGF0YS4NCg0KNC4gZXZlbiB0aGVy ZSB3ZXJlIG5vIE1BUCBhdCBhbGwsIGN1cnJlbnQgbGV2ZWwgb2YgNHJkLVUgaXMgZmFyIHByZW1h dHVyZSB0byBiZQ0KICAgdGFsa2VkIGFib3V0IGFueSB3b3JraW5nIGdyb3VwIGFjY2VwdGlvbi4N Cg0KdGhlIGF1dGhvcnMgYW5kIHN1cHBvcnRlcnMgd2lsbCBiZSBhcHByZWNpYXRlZCBpZiB0aGV5 IHRhbGsgYWJvdXQgdGhlIGFjY2VwdGlvbg0KYWZ0ZXIgdGhlaXIgY29kaW5nIGFuZCB0ZXN0aW5n IGFuZCByZWZpbmVtZW50IG9uIHRoZSBkb2N1bWVudCBhY2NvcmRpbmcgdG8gdGhlaXINCnByYWN0 aWNhbCBleHBlcmllbmNlcywgYW5kIHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0gYWdhaW4gYW5k IGFnYWluLg0KDQp0aGFua3MsDQptYW9rZQ0KDQoyMDEyLzQvOSBTaGVuZyBKaWFuZyA8amlhbmdz aGVuZ0BodWF3ZWkuY29tPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20+Pg0KPiBJIGFsc28g Zm9sbG93ZWQgdGhlIGRpc2N1c3Npb24uIEkgYXBwcmVjaWF0ZSBib3RoIHRlYW1zIGJvdWdodCB1 cCB0aGUNCj4gdGVjaG5pY2FsIGRldGFpbHMgZm9yIGJvdGggZGVzaWducy4gVG8gYmUgaG9uZXN0 LCBJIGZhaWwgdG8gc2VlIHdoaWNoDQo+IG9uZSBpcyBiZXR0ZXIgdGhhbiBvdGhlciAoeWV0KS4g SSBsaWtlIHRoZSBmYWN0IHRoYXQgNHJkLXUgY2FuIGRvIHdoYXQNCj4gTUFQLVQgZG9lcyB3L28g aW50cm9kdWNpbmcgYW55IGVuY2FwIG92ZXJoZWFkLiBCdXQgSSB1bmRlcnN0YW5kIHRoZQ0KPiBj b25jZXJucyBvdGhlcnMgYnJvdWdodCB1cCBpbiB0aGUgTUwgc3VjaCBhcyBWLW9jdGV0LiBGb3Ig TUFQLVQsIEkgbGlrZQ0KPiBpdCBub3QgaW50cm9kdWNpbmcgYW55IG5ldyByZXF1aXJlbWVudCB0 byB0aGUgSVB2NiBoZWFkZXIsIGJ1dCBJIG5lZWQNCj4gbW9yZSBwdWJsaXNoZWQgZGF0YSB0byBk ZXRlcm1pbmUgd2hldGhlciB0aGUgZG91YmxlLXRyYW5zbGF0aW9uIHdvdWxkDQo+IGNhdXNlIGFu eSB0cmFuc3BhcmVudCBpc3N1ZSBvciBub3QuIEZvciBleGFtcGxlOiBJIHdvdWxkIHZlcnkNCj4g YXBwcmVjaWF0ZSBpZiBzb21lYm9keSB3aG8gdHJpYWwgTUFQIGNhbiBwdWJsaXNoIGRhdGEgc3Vj aCBhcyB3aGF0DQo+IGFwcGxpY2F0aW9ucyB0aGV5IGhhdmUgdGVzdGVkLCB3aGF0IHBhc3MgYW5k IHdoYXQgZmFpbC4NCj4NCj4gVGhpcyBwaWVjZSBvZiB3b3JrIGlzIHZlcnkgaW1wb3J0YW50IGJl Y2F1c2Ugb25jZSB3ZSBzZWxlY3QgaXQsIHRoaXMNCj4gdGVjaG5vbG9neSB3aWxsIHN0YXkgZm9y IGxvbmcgdGltZS4gSSBkbyBub3Qgd2FudCB0byBydXNoIHRvIG1ha2UgYQ0KPiBkZWNpc2lvbiBh bmQgY29tZSBiYWNrIHRvIHJlZ3JldCBpbiBmdXR1cmUuDQpXZSB3b3VsZCBsaWtlIHRvIHNlZSBi b3RoIHNvbHV0aW9uIHB1Ymxpc2hlZC4gU28gdGhhdCwgb3BlcmF0b3JzIGNhbiBjaG9vc2UgYWNj b3JkaW5nIHRvIHRoZWlyIG93biBuZXR3b3JrcyBhbmQgcHJlZmVyZW5jZS4gVGhlcmUgYXJlIGVu b3Jtb3VzIG51bWJlciBvZiBvcGVyYXRvcnMsIHdobyBkbyBub3QgY29tZSB0byBJRVRGIG1lZXRp bmcgb3IgZG8gbm90IHBhcnRpY2lwYXRlIGluIE1MIGVpdGhlci4gVGhleSBhbHNvIG5lZWQgdG8g Y2hvb3NlIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc21zLiBUaGV5IHNob3VsZCBiZSBwcm92aWRl ZCBlbm91Z2ggdGVjaG5pY2FsIHN1cHBvcnRzLiBUaGF0J3MgdGhlIHJlc3BvbnNlIG9mIElFVEYs IGluIG91ciB1bmRlcnN0YW5kaW5nLg0KDQo+IE9uIDQvNi8xMiA2OjAwIEFNLCAiTGl1YmluZyAo TGVvKSIgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5j b20+PiB3cm90ZToNCj4NCj4gPisxDQo+ID4NCj4gPkkndmUgcmVhZCB0aGUgZW5kbGVzcyBkaXNj dXNzaW9uLCBhbmQgZm91bmQgdGhhdCBpcyBzZWVtcyB0aGUgTUFQIGFsc28NCj4gPmhhcyBub3Qg ZnVsbHkgY29udmluY2VkIHRoZSBJU1Agb3BlcmF0aW9uIGd1eXMuDQo+ID5TaW5jZSB0aGVyZSdz IGV4cGxpY2l0IGNvbnRyb3ZlcnN5LCB3aHkgbm90IGp1c3QgcHVibGlzaCB0aGVtIGJvdGggYXMN Cj4gPmV4cGVyaW1lbnRhbC4gd2h5IHdlIG11c3QgY2hvc2Ugb25lIGFzIGEgInN0YW5kYXJkIHRy YWNrIj8gQmVpbmcgYQ0KPiA+c3RhbmRhcmQgdHJhY2sgY2FuIGVsaW1pbmF0ZSBvcGVyYXRvcnMn IG1pc2dpdmluZz8NCj4gPg0KPiA+SWYgdGhlIHRlY2hub2xvZ3kgaXMgcmVhbGx5IGFwcHJvcHJp YXRlLCBJIGRvbid0IHRoaW5rIHRoZQ0KPiAiZXhwZXJpbWVudGFsIg0KPiA+c3RhdHVzIHdvdWxk IGJlIGEgaXNzdWUgZm9yIHRoZSBvcGVyYXRvcnMgdG8gYWRvcHQuIEp1c3QgbGV0IHRoZQ0KPiA+ b3BlcmF0b3IgZGVjaWRlIGJ5IHRoZW1zZWx2ZXMuDQo+ID4NCj4gPkkgcmVtZW1iZXJlZCBpbiB0 aGUgbWVldGluZyB2ZW51ZSwgSm9lbCBIYWxwZXJuIHdobyBjaGFpcnMgS2FycCBhbmQNCj4gPmxp c3AgV0csIHN1Z2dlc3RlZCB3ZSBwdWJsaXNoIGJvdGggb2YgdGhlbSBhcyBleHBlcmltZW50YWws IGFuZCB0aGF0DQo+ID53YXMgZXhhY3RseSBob3cgdGhleSBoYW5kbGUgdGhlIHNpbWlsYXIgc2l0 dWF0aW9uIGluIHRoZWlyIFdHLiBJIHRoaW5rDQo+ID5oaXMgc3VnZ2VzdGlvbiBpcyByZWFzb25h YmxlIHRvIGJlIGNvbnNpZGVyZWQuIChUbyBKb2VsOiBQYXJkb24gbWUgaWYNCj4gSQ0KPiA+aW1w cm9wZXJseSBxdW90ZWQgeW91ciBjb21tZW50LCBvciBJIGp1c3QgbWlzdW5kZXJzdG9vZCB5b3Vy DQo+IHN1Z2dlc3Rpb24NCj4gPikuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJl cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZz5dDQo+ID4+T24gIEJlaGFsZiBPZiBTaW1v biBQZXJyZWF1bHQNCj4gPj4gU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIwMTIgODoxNiBQTQ0K PiA+PiBUbzogc29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+DQo+ ID4+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3aXRoIDRy ZMWgIDRyZC1VIGFzDQo+ID4+dHJhbnNwYXJlbnQgIGFzIE1BUC1FDQo+ID4+DQo+ID4+IE9uIDIw MTItMDQtMDMgMDU6NDAsIE9sZSBUcsO4YW4gd3JvdGU6DQo+ID4+ID4gMSkgTUFQLUUgc3VwcG9y dHMgaW5kZXBlbmRlbmNlIG9mIElQdjQgYW5kIElQdjYgYWRkcmVzc2luZy4gYnkNCj4gPj4gPiB1 c2luZw0KPiA+Pmh1Yg0KPiA+PiBhbmQgc3Bva2UgbW9kZSB3aXRoIGEgc2VwYXJhdGUNCj4gPj4g PiAgICAgbWFwcGluZyBydWxlIHBlciBzdWJzY3JpYmVyLiBpbiB0aGlzIG1vZGUgZS5nIG9ubHkg cG9ydHMgY291bGQNCj4gPj4gPiBiZQ0KPiA+PiBlbWJlZGRlZCBpbiB0aGUgYWRkcmVzcy4gdGhp cyBpcyBub3QNCj4gPj4gPiAgICAgcG9zc2libGUgaW4gYSB0cmFuc2xhdGlvbiBzb2x1dGlvbiBs aWtlIDRyZC1VLg0KPiA+Pg0KPiA+PiBUaGlzIG1vZGUgb2Ygb3BlcmF0aW9uIHdhcyBzdWdnZXN0 ZWQgbGFzdCB3ZWVrIGR1cmluZyB0aGUgU0QtTkFUDQo+ID4+IHByZXNlbnRhdGlvbi4gVGhlcmUg c2VlbWVkIHRvIGJlIGNvbnNlbnN1cyBhbW9uZyBvcGVyYXRvcnMgdGhhdCBpdA0KPiA+PiB3YXMg bm90IHByYWN0aWNhbGx5IGZlYXNpYmxlLg0KPiA+Pg0KPiA+PiA+IDIpIGEgbm9kZSBpbnNpZGUg dGhlIG5ldHdvcmsgd2lsbCB0cmVhdCB0cmFuc2xhdGVkIHBhY2tldHMNCj4gPj4gPiBkaWZmZXJl bnQNCj4gPj5mcm9tDQo+ID4+IGVuY2Fwc3VsYXRlZCBvbmVzLg0KPiA+PiA+ICAgICBlLmcuIGZv ciB0aGUgcHVycG9zZXMgb2YgY291bnRpbmcgb3IgZm9yIGFwcGx5aW5nIGZlYXR1cmVzLg0KPiBm b3INCj4gPj4gPiBhbg0KPiA+PiBlbmNhcHN1bGF0ZWQgcGFja2V0IGJvdGggdGhlIGNvbXBsZXRl DQo+ID4+ID4gICAgIElQdjQgZGF0YWdyYW0gYW5kIHRoZSBJUHY2IGhlYWRlciBpcyBhdmFpbGFi bGUsIGFuZCBkaWZmZXJlbnQNCj4gPj5mZWF0dXJlcw0KPiA+PiBjYW4gYmUgYXBwbGllZCB0byBi b3RoLg0KPiA+Pg0KPiA+PiBJbiBwcmFjdGljZSwgdGhlIGNvbnRlbnRzIG9mIGVuY2Fwc3VsYXRl ZCBwYWNrZXRzIGFyZSByYXJlbHkNCj4gPj4gaW5zcGVjdGVkIGJ5IGZpcmV3YWxscyBhbmQgb3Ro ZXIgc3VjaCBkZXZpY2VzLg0KPiA+Pg0KPiA+Pg0KPiA+PiBJTUhPIGF0IHRoaXMgcG9pbnQgd2Ug c2hvdWxkIGxldCB0aGUgbWFya2V0IGRlY2lkZS4gUHVibGlzaCBib3RoIGFzDQo+ID4+IGV4cGVy aW1lbnRhbC4gTGV0J3Mgd29yayBvbiBzb21ldGhpbmcgZWxzZSBub3cuDQo+ID4+DQo+ID4+IFNp bW9uDQo+ID4+IC0tDQo+ID4+IERUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLT4gaHR0 cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYQ0KPiA+PiBOQVQ2NC9ETlM2NCBvcGVuLXNvdXJj ZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhDQo+ID4+IFNUVU4vVFVSTiBz ZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlhZ2VuaWUuY2ENCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gU29mdHdp cmVzIG1haWxpbmcgbGlzdA0KPiA+PiBTb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJl c0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z b2Z0d2lyZXMNCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ID5Tb2Z0d2lyZXNAaWV0Zi5vcmc8bWFp bHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc29mdHdpcmVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1h aWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NvZnR3aXJlcw0KDQoNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837A5SZXEML506MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X aXRob3V0IGFueSBvYmplY3Rpb24gdG8gTUFQLCB3ZSBqdXN0IHN0YXJ0IHRvIGNvZGluZyA0cmQt dSBhbmQgaGVscCB0byBpbXByb3ZlIGl0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NdWx0aXBsZSB0cmFuc2l0aW9u IG1lY2hhbmlzbXMgd291bGQgY28tZXhpc3QgaW4gdGhlIHdvcmxkLiBOZWl0aGVyIE1BUCBub3Ig NHJkLVUgY2FuIHJlcGxhY2UgNnJkIGFuZCBEUy1MaXRlLiBUaGVyZSBpcyBubyBvbmUtc3VpdC1h bGwgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW9rZSBbbWFpbHRvOmZpYnJp YkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA1 OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4gTGVlLCBZ aXU7IExpdWJpbmcgKExlbyk7IFNpbW9uIFBlcnJlYXVsdDsgc29mdHdpcmVzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3 aXRoIDRyZMWgIDRyZC1VIGFzIHRyYW5zcGFyZW50IGFzIE1BUC1FPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEy LzQvOSBTaGVuZyBKaWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNv bSI+amlhbmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGFsbG93IG1lIHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBv cnQgYm90aCBNQVAgYW5kIDRyZC11Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUCBoYXMgYmVlbiBhIGdvb2Qg ZWZmb3J0IHdpdGggbWFueSBleHBlcnRzIHRvZ2V0aGVyIGluIElQdjQvSVB2NiB0cmFuc2l0aW9u IGFyZWEgYW5kIGhhcyBiZWVuIHByb3ZlZA0KIGJ5IHJ1bm5pbmcgY29kZS4gSXQgYWxzbyBuZWVk IHRvIGltcHJvdmUgaXRzZWxmIGJlZm9yZSBiZWluZyBwdWJsaXNoZWQgYXMgYSBSRkMgbGF0ZXIu IFRoaXMgcHJvY2VzcyB3aWxsIHRha2Ugc2V2ZXJhbCBtb250aHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVy c29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQgYmVoaW5kIE1BUCBpbiBtYXR1 cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LCBpdCBpcyBvbmx5DQogbWF0dGVyIG9mIHRpbWUuIFRo ZSBhdXRob3JzIGhhdmUgYWdyZWVkIHRvIHJlbW92ZSB0aGUgYXJjaGl0ZWN0dXJhbCBjb25mbGlj dCwgaWYgdGhlcmUgd2FzIGFueS4gV2UgaGF2ZSBvZmZlcmVkIHRvIGhlbHAgb24gdGhlIGltcHJv dmVtZW50IGJ5IGltcGxlbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdpdmluZyB0aW1lLCBib3Ro IHNvbHV0aW9uIGNhbiBiZSBtYXR1cmUgZW5vdWdoIGZvciBvcGVyYXRpb25zLiBJRVRGIGRvZXMg bm90IGhhdmUgdG8gY2hvb3NlIG9uZQ0KIGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25z IGFyZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGEgc2FtZSBwYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGF0IGlm LCBnaXZpbmcgdGltZSwgcGVvcGxlIGNhbiBiZSBtYXR1cmUgZW5vdWdoIHRvIGlkZW50aWZ5IDRy ZC1VIGlzIHJlYWxseSBhIGZsYXdlZCBkb25rb3JzZT8gOy0pIGlmIHRoZSA0cmQtdSBkZXNpZ25l cnMgYXJlIHNvIGNvbmZpZGVudCwgd2h5IG5vdCBkbyB0aGUgcmVhbCBjb2Rpbmcgd29yayBmaXJz dCBhbmQgdGhlbiBwcm9wb3NlIGl0IGFzIGEgcmVwbGFjZW1lbnQgb2YgTUFQIHN1aXRlPyBpIGRv bid0DQogc2VlIGFueSB1bmZhaXJuZXNzIGhlcmUuIC0gbWFva2U8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hl bmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hb2tl IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmZpYnJpYkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5maWJyaWJAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmls IDA5LCAyMDEyIDM6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNoZW5nIEppYW5nPGJyPg0KPGI+Q2M6 PC9iPiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVycmVhdWx0OyA8YSBocmVmPSJt YWlsdG86c29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzb2Z0d2lyZXNAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTb2Z0d2lyZXNdIFBhdGggdG8g bW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJkLVUgYXMgdHJhbnNwYXJlbnQgYXMgTUFQLUU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+aGkgWWl1IGFuZCBvdGhlcnMsJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLiAmcXVvdDti b3RoIHB1Ymxpc2hlZCZxdW90OyBkb2VzIHN1cmVseSBjb25mbGljdCB3aXRoIHRoZSBkZXNpZ24g Z29hbCBvZiA0cmQtVSBpdHNlbGY6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt1bmlmaWNhdGlvbiBvZiBtdWx0 aXBsZSBzdGFuZGFyZHMuJm5ic3A7cG9saXRpY2FsbHkgc3BlYWtpbmcsIHRoZSA0cmQtdSBhdXRo b3JzJw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyAmbmJzcDtwb3NpdGl0aW9uIGlzIG5vdyBxdWl0ZSBjb25mdXNpbmcuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4yLiBvcGVyYXRvcnMgc3VyZWx5IG5lZWQgdG8gY2hvb3NlIElQdjYgdHJhbnNpdGlvbiBtZWNo YW5pc21zIGJ1dCBzdWNoIGEgY2hvaWNlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtpcyBiYXNlZCBvbiB0aGVp ciBkZW1hbmQgYW5kIHVuZGVyc3RhbmRpbmcgdG8gdGhlIGV4aXN0aW5nIGFuZCB3ZWxsLXRlc3Rl ZCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwO3dlbGwtcHJhY3RpY2VkIGJ1aWxkaW5nIGJsb2Nrcy4gaSBkb24n dCB0aGluayBhbnkgb3BlcmF0b3JzIGFyZSB3YWl0aW5nIGZvciZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YW4g b3B0aW9uIG9mIGNob2ljZSB0aGV5IG5ldmVyIHNlZSBhbmQgbmV2ZXIgdW5kZXJzdGFuZC4gYW5k IHRoZSAmcXVvdDtlbm91Z2gmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3RlY2huaWNhbCBzdXBwb3J0cyZxdW90 OyBpcyBub3cgc3RpbGwgJnF1b3Q7YSBjaGVjayB3aXRob3V0IHNpZ25hdHVyZSZxdW90Oy4gaSBk byBzdWdnZXN0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0aGUgNHJkLXUgYXV0aG9ycyBhbmQgc3VwcG9ydGVy cyBzYXkgdGhhdCBhZnRlciBtYWtpbmcgc29tZXRoaW5nIHJlYWwuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7b24gdGhlIG90aGVyIGhhbmQsIDRyZC11IG1ha2VzIGEgdGlnaHQgY291cGxpbmcgYmV0d2Vl biB0aGUgYWRkcmVzcyBmb3JtYXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2FuZCBpdHMgb3duIGhlYWRlciBt YXBwaW5nIG1lY2hhbmlzbS4gdGhpcyBtYWtlcyBhbiBvcGVyYXRvciB1bmFibGUgdG8gaGF2ZSZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7ZGlmZmVyZW50IGNob2ljZXMgb2YgdHJhbnNpdGlvbiBtZWNoYW5pc20g YXMgbG9uZyBhcyBpdCBjaG9vc2VzIDRyZC11LiBpZiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7eW91IGNvbmNl cm4gdGhlIGNob2ljZSBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtLCBpIGRvIHJlY29tbWVu ZCBNQVAsIGFzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtlaXRoZXIgZW5jYXBzdWxhdGlvbiBvciB0cmFuc2xh dGlvbiBpcyBvcGVyYXRhYmxlIHdpdGggTUFQIGFkZHJlc3MvcG9ydCZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 bWFwcGluZyB3aXRob3V0IGRpZmZpY3VsdHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLiBzdXJlbHkgTUFQIHN0aWxsIGhh cyByb29tIG9mIGltcHJvdmVtZW50IGJ1dCBpIGRvbid0IHRoaW5rIHRoZXJlIGFyZSZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7YXJjaGl0ZWN0dXJhbCB1bmNlcnRhaW50eSBhcyA0cmQtVSBoYXMuIHJlcXVlc3Qg b24gbW9yZSB0ZXN0aW5nIGRhdGEgaXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3N1cmVseSBhcHByZWNpYXRl ZCBidXQgcGxlYXNlIHRoaW5rIGl0IG92ZXIgYWdhaW4gaWYgaXQgaXMgYSBjb3JyZWN0IHdheSZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7dG8gcmVxdWlyZSBmdXJ0aGVyIGRhdGEgb2YgYSBjb3VudGVycGFydCBp biBvcmRlciB0byBkZWZlbnNlIGEgc29sdXRpb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3dpdGhvdXQgYW55 IGRhdGEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj40LiBldmVuIHRoZXJlIHdlcmUgbm8gTUFQIGF0IGFsbCwgY3VycmVudCBs ZXZlbCBvZiA0cmQtVSBpcyBmYXIgcHJlbWF0dXJlIHRvIGJlJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0YWxr ZWQgYWJvdXQgYW55IHdvcmtpbmcgZ3JvdXAgYWNjZXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlIGF1dGhvcnMgYW5kIHN1 cHBvcnRlcnMgd2lsbCBiZSBhcHByZWNpYXRlZCBpZiB0aGV5IHRhbGsgYWJvdXQgdGhlIGFjY2Vw dGlvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5hZnRlciB0aGVpciBjb2RpbmcgYW5kIHRlc3RpbmcgYW5kIHJlZmluZW1lbnQgb24g dGhlIGRvY3VtZW50IGFjY29yZGluZyB0byB0aGVpciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5wcmFjdGljYWwgZXhwZXJpZW5jZXMs IGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBwcm9ibGVtIGFnYWluIGFuZCBhZ2Fpbi4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRo YW5rcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+bWFva2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjIwMTIvNC85IFNoZW5nIEppYW5nICZsdDs8YSBocmVmPSJtYWlsdG86 amlhbmdzaGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amlhbmdzaGVuZ0BodWF3ZWku Y29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsg SSBhbHNvIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uLiBJIGFwcHJlY2lhdGUgYm90aCB0ZWFtcyBi b3VnaHQgdXAgdGhlPGJyPg0KJmd0OyB0ZWNobmljYWwgZGV0YWlscyBmb3IgYm90aCBkZXNpZ25z LiBUbyBiZSBob25lc3QsIEkgZmFpbCB0byBzZWUgd2hpY2g8YnI+DQomZ3Q7IG9uZSBpcyBiZXR0 ZXIgdGhhbiBvdGhlciAoeWV0KS4gSSBsaWtlIHRoZSBmYWN0IHRoYXQgNHJkLXUgY2FuIGRvIHdo YXQ8YnI+DQomZ3Q7IE1BUC1UIGRvZXMgdy9vIGludHJvZHVjaW5nIGFueSBlbmNhcCBvdmVyaGVh ZC4gQnV0IEkgdW5kZXJzdGFuZCB0aGU8YnI+DQomZ3Q7IGNvbmNlcm5zIG90aGVycyBicm91Z2h0 IHVwIGluIHRoZSBNTCBzdWNoIGFzIFYtb2N0ZXQuIEZvciBNQVAtVCwgSSBsaWtlPGJyPg0KJmd0 OyBpdCBub3QgaW50cm9kdWNpbmcgYW55IG5ldyByZXF1aXJlbWVudCB0byB0aGUgSVB2NiBoZWFk ZXIsIGJ1dCBJIG5lZWQ8YnI+DQomZ3Q7IG1vcmUgcHVibGlzaGVkIGRhdGEgdG8gZGV0ZXJtaW5l IHdoZXRoZXIgdGhlIGRvdWJsZS10cmFuc2xhdGlvbiB3b3VsZDxicj4NCiZndDsgY2F1c2UgYW55 IHRyYW5zcGFyZW50IGlzc3VlIG9yIG5vdC4gRm9yIGV4YW1wbGU6IEkgd291bGQgdmVyeTxicj4N CiZndDsgYXBwcmVjaWF0ZSBpZiBzb21lYm9keSB3aG8gdHJpYWwgTUFQIGNhbiBwdWJsaXNoIGRh dGEgc3VjaCBhcyB3aGF0PGJyPg0KJmd0OyBhcHBsaWNhdGlvbnMgdGhleSBoYXZlIHRlc3RlZCwg d2hhdCBwYXNzIGFuZCB3aGF0IGZhaWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBwaWVjZSBv ZiB3b3JrIGlzIHZlcnkgaW1wb3J0YW50IGJlY2F1c2Ugb25jZSB3ZSBzZWxlY3QgaXQsIHRoaXM8 YnI+DQomZ3Q7IHRlY2hub2xvZ3kgd2lsbCBzdGF5IGZvciBsb25nIHRpbWUuIEkgZG8gbm90IHdh bnQgdG8gcnVzaCB0byBtYWtlIGE8YnI+DQomZ3Q7IGRlY2lzaW9uIGFuZCBjb21lIGJhY2sgdG8g cmVncmV0IGluIGZ1dHVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5XZSB3b3VsZCBsaWtlIHRvIHNlZSBib3RoIHNvbHV0aW9uIHB1Ymxpc2hlZC4gU28g dGhhdCwgb3BlcmF0b3JzIGNhbiBjaG9vc2UgYWNjb3JkaW5nIHRvIHRoZWlyIG93biBuZXR3b3Jr cyBhbmQgcHJlZmVyZW5jZS4gVGhlcmUgYXJlIGVub3Jtb3VzIG51bWJlciBvZiBvcGVyYXRvcnMs IHdobyBkbyBub3QgY29tZQ0KIHRvIElFVEYgbWVldGluZyBvciBkbyBub3QgcGFydGljaXBhdGUg aW4gTUwgZWl0aGVyLiBUaGV5IGFsc28gbmVlZCB0byBjaG9vc2UgSVB2NiB0cmFuc2l0aW9uIG1l Y2hhbmlzbXMuIFRoZXkgc2hvdWxkIGJlIHByb3ZpZGVkIGVub3VnaCB0ZWNobmljYWwgc3VwcG9y dHMuIFRoYXQncyB0aGUgcmVzcG9uc2Ugb2YgSUVURiwgaW4gb3VyIHVuZGVyc3RhbmRpbmcuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K Jmd0OyBPbiA0LzYvMTIgNjowMCBBTSwgJnF1b3Q7TGl1YmluZyAoTGVvKSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sZW8u bGl1YmluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0 OyYjNDM7MTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0kndmUgcmVhZCB0aGUgZW5kbGVz cyBkaXNjdXNzaW9uLCBhbmQgZm91bmQgdGhhdCBpcyBzZWVtcyB0aGUgTUFQIGFsc288YnI+DQom Z3Q7ICZndDtoYXMgbm90IGZ1bGx5IGNvbnZpbmNlZCB0aGUgSVNQIG9wZXJhdGlvbiBndXlzLjxi cj4NCiZndDsgJmd0O1NpbmNlIHRoZXJlJ3MgZXhwbGljaXQgY29udHJvdmVyc3ksIHdoeSBub3Qg anVzdCBwdWJsaXNoIHRoZW0gYm90aCBhczxicj4NCiZndDsgJmd0O2V4cGVyaW1lbnRhbC4gd2h5 IHdlIG11c3QgY2hvc2Ugb25lIGFzIGEgJnF1b3Q7c3RhbmRhcmQgdHJhY2smcXVvdDs/IEJlaW5n IGE8YnI+DQomZ3Q7ICZndDtzdGFuZGFyZCB0cmFjayBjYW4gZWxpbWluYXRlIG9wZXJhdG9ycycg bWlzZ2l2aW5nPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0lmIHRoZSB0ZWNobm9sb2d5 IGlzIHJlYWxseSBhcHByb3ByaWF0ZSwgSSBkb24ndCB0aGluayB0aGU8YnI+DQomZ3Q7ICZxdW90 O2V4cGVyaW1lbnRhbCZxdW90Ozxicj4NCiZndDsgJmd0O3N0YXR1cyB3b3VsZCBiZSBhIGlzc3Vl IGZvciB0aGUgb3BlcmF0b3JzIHRvIGFkb3B0LiBKdXN0IGxldCB0aGU8YnI+DQomZ3Q7ICZndDtv cGVyYXRvciBkZWNpZGUgYnkgdGhlbXNlbHZlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDtJIHJlbWVtYmVyZWQgaW4gdGhlIG1lZXRpbmcgdmVudWUsIEpvZWwgSGFscGVybiB3aG8gY2hh aXJzIEthcnAgYW5kPGJyPg0KJmd0OyAmZ3Q7bGlzcCBXRywgc3VnZ2VzdGVkIHdlIHB1Ymxpc2gg Ym90aCBvZiB0aGVtIGFzIGV4cGVyaW1lbnRhbCwgYW5kIHRoYXQ8YnI+DQomZ3Q7ICZndDt3YXMg ZXhhY3RseSBob3cgdGhleSBoYW5kbGUgdGhlIHNpbWlsYXIgc2l0dWF0aW9uIGluIHRoZWlyIFdH LiBJIHRoaW5rPGJyPg0KJmd0OyAmZ3Q7aGlzIHN1Z2dlc3Rpb24gaXMgcmVhc29uYWJsZSB0byBi ZSBjb25zaWRlcmVkLiAoVG8gSm9lbDogUGFyZG9uIG1lIGlmPGJyPg0KJmd0OyBJPGJyPg0KJmd0 OyAmZ3Q7aW1wcm9wZXJseSBxdW90ZWQgeW91ciBjb21tZW50LCBvciBJIGp1c3QgbWlzdW5kZXJz dG9vZCB5b3VyPGJyPg0KJmd0OyBzdWdnZXN0aW9uPGJyPg0KJmd0OyAmZ3Q7KS48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21h aWx0bzo8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0 O09uICZuYnNwO0JlaGFsZiBPZiBTaW1vbiBQZXJyZWF1bHQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNl bnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDEyIDg6MTYgUE08YnI+DQomZ3Q7ICZndDsmZ3Q7IFRv OiA8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c29m dHdpcmVzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IFtTb2Z0 d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJkLVUgYXM8YnI+DQomZ3Q7 ICZndDsmZ3Q7dHJhbnNwYXJlbnQgJm5ic3A7YXMgTUFQLUU8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBPbiAyMDEyLTA0LTAzIDA1OjQwLCBPbGUgVHLDuGFuIHdyb3RlOjxi cj4NCiZndDsgJmd0OyZndDsgJmd0OyAxKSBNQVAtRSBzdXBwb3J0cyBpbmRlcGVuZGVuY2Ugb2Yg SVB2NCBhbmQgSVB2NiBhZGRyZXNzaW5nLiBieTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyB1c2lu Zzxicj4NCiZndDsgJmd0OyZndDtodWI8YnI+DQomZ3Q7ICZndDsmZ3Q7IGFuZCBzcG9rZSBtb2Rl IHdpdGggYSBzZXBhcmF0ZTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IG1h cHBpbmcgcnVsZSBwZXIgc3Vic2NyaWJlci4gaW4gdGhpcyBtb2RlIGUuZyBvbmx5IHBvcnRzIGNv dWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbWJlZGRl ZCBpbiB0aGUgYWRkcmVzcy4gdGhpcyBpcyBub3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyBwb3NzaWJsZSBpbiBhIHRyYW5zbGF0aW9uIHNvbHV0aW9uIGxpa2UgNHJkLVUu PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhpcyBtb2RlIG9mIG9wZXJh dGlvbiB3YXMgc3VnZ2VzdGVkIGxhc3Qgd2VlayBkdXJpbmcgdGhlIFNELU5BVDxicj4NCiZndDsg Jmd0OyZndDsgcHJlc2VudGF0aW9uLiBUaGVyZSBzZWVtZWQgdG8gYmUgY29uc2Vuc3VzIGFtb25n IG9wZXJhdG9ycyB0aGF0IGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3YXMgbm90IHByYWN0aWNhbGx5 IGZlYXNpYmxlLjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgMikg YSBub2RlIGluc2lkZSB0aGUgbmV0d29yayB3aWxsIHRyZWF0IHRyYW5zbGF0ZWQgcGFja2V0czxi cj4NCiZndDsgJmd0OyZndDsgJmd0OyBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ZnJvbTxi cj4NCiZndDsgJmd0OyZndDsgZW5jYXBzdWxhdGVkIG9uZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgZS5nLiBmb3IgdGhlIHB1cnBvc2VzIG9mIGNvdW50aW5nIG9yIGZv ciBhcHBseWluZyBmZWF0dXJlcy48YnI+DQomZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyZndDsgJmd0 OyBhbjxicj4NCiZndDsgJmd0OyZndDsgZW5jYXBzdWxhdGVkIHBhY2tldCBib3RoIHRoZSBjb21w bGV0ZTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IElQdjQgZGF0YWdyYW0g YW5kIHRoZSBJUHY2IGhlYWRlciBpcyBhdmFpbGFibGUsIGFuZCBkaWZmZXJlbnQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7ZmVhdHVyZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNhbiBiZSBhcHBsaWVkIHRvIGJv dGguPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSW4gcHJhY3RpY2UsIHRo ZSBjb250ZW50cyBvZiBlbmNhcHN1bGF0ZWQgcGFja2V0cyBhcmUgcmFyZWx5PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBpbnNwZWN0ZWQgYnkgZmlyZXdhbGxzIGFuZCBvdGhlciBzdWNoIGRldmljZXMuPGJy Pg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IElN SE8gYXQgdGhpcyBwb2ludCB3ZSBzaG91bGQgbGV0IHRoZSBtYXJrZXQgZGVjaWRlLiBQdWJsaXNo IGJvdGggYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4cGVyaW1lbnRhbC4gTGV0J3Mgd29yayBvbiBz b21ldGhpbmcgZWxzZSBub3cuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg U2ltb248YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEVE4gbWFkZSBl YXN5LCBsZWFuLCBhbmQgc21hcnQgLS0mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9wb3N0ZWxsYXRpb24u dmlhZ2VuaWUuY2EiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2Vu aWUuY2E8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSZndDsgPGEgaHJlZj0iaHR0cDovL2VjZHlzaXMudmlh Z2VuaWUuY2EiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPC9h Pjxicj4NCiZndDsgJmd0OyZndDsgU1RVTi9UVVJOIHNlcnZlciAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9udW1i LnZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vbnVtYi52aWFnZW5pZS5jYTwv YT48YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3 aXJlczwvYT48YnI+DQomZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0O1NvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7ICZndDs8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OzxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTb2Z0 d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5D36713D8A4E7348A7E10DF7437A4B921E4837A5SZXEML506MBSchi_-- From leo.liubing@huawei.com Mon Apr 9 03:07:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192A421F85E4 for ; Mon, 9 Apr 2012 03:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Ll-Il+W5DG for ; Mon, 9 Apr 2012 03:07:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAD921F85DD for ; Mon, 9 Apr 2012 03:07:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET47824; Mon, 09 Apr 2012 06:07:03 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:04:22 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 03:04:20 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 18:04:12 +0800 From: "Liubing (Leo)" To: Maoke , Sheng Jiang Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0?= =?utf-8?Q?rd-U_as_transparent_as_MAP-E?= Thread-Index: AQHNFARgdrlwXvWelEujVWMXb2t8PZaRgssAgAASqgCAAAjNAIAAHKsAgAABuoCAAAITAIAAhsBA Date: Mon, 9 Apr 2012 10:04:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452929E75E@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B921E483543@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48364F@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B921E48376D@SZXEML506-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8szxeml509mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 10 Apr 2012 08:49:03 -0700 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:07:06 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8szxeml509mbs_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PmZpbmUuIHdlJ2QgbG92ZSB0byBzZWUgaXQgb3V0IHdpdGggZ29vZCBhbW91bnQgb2YgZGF0YSBh bmQgZ29vZCBhbW91bnQgb2YgZmVlZGJhY2sgZnJvbSB0ZXN0aW5nIG9wZXJhdG9ycy4NCj5pZiB5 b3UgaW52aXRlIG1lIHRvIHRlc3QsIGknZCBsb3ZlIHRvIHByb3ZpZGUgY2hhbGxlbmdpbmcgc2Nl bmFyaW9zLiA7LSkNCj5idXQgaXQgZG9lc24ndCBtZWFuIHdlIHNob3VsZCBwb3N0cG9uZSBjdXJy ZW50IHByb2Nlc3Mgb2Ygc3RhbmRhcmRpemF0aW9uIG9mIE1BUCwgYmVjYXVzZSB0aGUgcmVzdWx0 IG9mIDRyZC11IGlzIHN0aWxsIHVuc3VyZS4gLSBtYW9rZQ0KDQpJ4oCZZCBsb3ZlIHRvIHNlZSBv cGVyYXRvcnMgZmluZCBwcm9wZXIgbWVjaGFuaXNtcyByZXNwZWN0aXZlbHkgYWNjb3JkaW5nIHRv IHRoZWlyIG93biBzaXR1YXRpb25zLCByYXRoZXIgdGhhbiBzb21lIG1lY2hhbmlzbXMgKm91dCou DQoNClRoZSB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgYXJlIGRldmVsb3BlZCBmb3IgdGhlIG9wZXJh dG9ycywgYnV0IGluIG15IG9ic2VydmF0aW9uLCB0aGUgTUFQIGhhc27igJl0ICBwcm92ZWQgc3Vm ZmljaWVudGx5IGZvciBvcGVyYXRvcnPigJkgbG9uZy10ZXJtIHNlbGVjdGlvbi4gU28gd2h5IHdl IGhhdmUgdG8gcnVzaCB0byBhICpzdGFuZCB0cmFjayo/DQoNCg0KRnJvbTogTWFva2UgW21haWx0 bzpmaWJyaWJAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA1OjUyIFBN DQpUbzogU2hlbmcgSmlhbmcNCkNjOiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVy cmVhdWx0OyBzb2Z0d2lyZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBQYXRo IHRvIG1vdmUgZm9yd2FyZCB3aXRoIDRyZMWgIDRyZC1VIGFzIHRyYW5zcGFyZW50IGFzIE1BUC1F DQoNCg0KMjAxMi80LzkgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86 amlhbmdzaGVuZ0BodWF3ZWkuY29tPj4NCldpdGhvdXQgYW55IG9iamVjdGlvbiB0byBNQVAsIHdl IGp1c3Qgc3RhcnQgdG8gY29kaW5nIDRyZC11IGFuZCBoZWxwIHRvIGltcHJvdmUgaXQuDQoNCmZp bmUuIHdlJ2QgbG92ZSB0byBzZWUgaXQgb3V0IHdpdGggZ29vZCBhbW91bnQgb2YgZGF0YSBhbmQg Z29vZCBhbW91bnQgb2YgZmVlZGJhY2sgZnJvbSB0ZXN0aW5nIG9wZXJhdG9ycy4gaWYgeW91IGlu dml0ZSBtZSB0byB0ZXN0LCBpJ2QgbG92ZSB0byBwcm92aWRlIGNoYWxsZW5naW5nIHNjZW5hcmlv cy4gOy0pIGJ1dCBpdCBkb2Vzbid0IG1lYW4gd2Ugc2hvdWxkIHBvc3Rwb25lIGN1cnJlbnQgcHJv Y2VzcyBvZiBzdGFuZGFyZGl6YXRpb24gb2YgTUFQLCBiZWNhdXNlIHRoZSByZXN1bHQgb2YgNHJk LXUgaXMgc3RpbGwgdW5zdXJlLiAtIG1hb2tlDQoNCg0KTXVsdGlwbGUgdHJhbnNpdGlvbiBtZWNo YW5pc21zIHdvdWxkIGNvLWV4aXN0IGluIHRoZSB3b3JsZC4gTmVpdGhlciBNQVAgbm9yIDRyZC1V IGNhbiByZXBsYWNlIDZyZCBhbmQgRFMtTGl0ZS4gVGhlcmUgaXMgbm8gb25lLXN1aXQtYWxsIHNv bHV0aW9uLg0KDQpGcm9tOiBNYW9rZSBbbWFpbHRvOmZpYnJpYkBnbWFpbC5jb208bWFpbHRvOmZp YnJpYkBnbWFpbC5jb20+XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA1OjM5IFBNDQoN ClRvOiBTaGVuZyBKaWFuZw0KQ2M6IExlZSwgWWl1OyBMaXViaW5nIChMZW8pOyBTaW1vbiBQZXJy ZWF1bHQ7IHNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtTb2Z0d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJk LVUgYXMgdHJhbnNwYXJlbnQgYXMgTUFQLUUNCg0KDQoyMDEyLzQvOSBTaGVuZyBKaWFuZyA8amlh bmdzaGVuZ0BodWF3ZWkuY29tPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20+Pg0KUGxlYXNl IGFsbG93IG1lIHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBvcnQgYm90aCBNQVAgYW5kIDRyZC11 Lg0KDQpNQVAgaGFzIGJlZW4gYSBnb29kIGVmZm9ydCB3aXRoIG1hbnkgZXhwZXJ0cyB0b2dldGhl ciBpbiBJUHY0L0lQdjYgdHJhbnNpdGlvbiBhcmVhIGFuZCBoYXMgYmVlbiBwcm92ZWQgYnkgcnVu bmluZyBjb2RlLiBJdCBhbHNvIG5lZWQgdG8gaW1wcm92ZSBpdHNlbGYgYmVmb3JlIGJlaW5nIHB1 Ymxpc2hlZCBhcyBhIFJGQyBsYXRlci4gVGhpcyBwcm9jZXNzIHdpbGwgdGFrZSBzZXZlcmFsIG1v bnRocy4NCg0KUGVyc29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQgYmVoaW5k IE1BUCBpbiBtYXR1cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LCBpdCBpcyBvbmx5IG1hdHRlciBv ZiB0aW1lLiBUaGUgYXV0aG9ycyBoYXZlIGFncmVlZCB0byByZW1vdmUgdGhlIGFyY2hpdGVjdHVy YWwgY29uZmxpY3QsIGlmIHRoZXJlIHdhcyBhbnkuIFdlIGhhdmUgb2ZmZXJlZCB0byBoZWxwIG9u IHRoZSBpbXByb3ZlbWVudCBieSBpbXBsZW1lbnRhdGlvbi4NCg0KR2l2aW5nIHRpbWUsIGJvdGgg c29sdXRpb24gY2FuIGJlIG1hdHVyZSBlbm91Z2ggZm9yIG9wZXJhdGlvbnMuIElFVEYgZG9lcyBu b3QgaGF2ZSB0byBjaG9vc2Ugb25lIGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25zIGFy ZSBub3QgbmVjZXNzYXJ5IHRvIGJlIGEgc2FtZSBwYWNlLg0KDQp3aGF0IGlmLCBnaXZpbmcgdGlt ZSwgcGVvcGxlIGNhbiBiZSBtYXR1cmUgZW5vdWdoIHRvIGlkZW50aWZ5IDRyZC1VIGlzIHJlYWxs eSBhIGZsYXdlZCBkb25rb3JzZT8gOy0pIGlmIHRoZSA0cmQtdSBkZXNpZ25lcnMgYXJlIHNvIGNv bmZpZGVudCwgd2h5IG5vdCBkbyB0aGUgcmVhbCBjb2Rpbmcgd29yayBmaXJzdCBhbmQgdGhlbiBw cm9wb3NlIGl0IGFzIGEgcmVwbGFjZW1lbnQgb2YgTUFQIHN1aXRlPyBpIGRvbid0IHNlZSBhbnkg dW5mYWlybmVzcyBoZXJlLiAtIG1hb2tlDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQpG cm9tOiBNYW9rZSBbbWFpbHRvOmZpYnJpYkBnbWFpbC5jb208bWFpbHRvOmZpYnJpYkBnbWFpbC5j b20+XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiAzOjI0IFBNDQpUbzogU2hlbmcgSmlh bmcNCkNjOiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVycmVhdWx0OyBzb2Z0d2ly ZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtT b2Z0d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaAgNHJkLVUgYXMgdHJhbnNw YXJlbnQgYXMgTUFQLUUNCg0KaGkgWWl1IGFuZCBvdGhlcnMsDQoNCjEuICJib3RoIHB1Ymxpc2hl ZCIgZG9lcyBzdXJlbHkgY29uZmxpY3Qgd2l0aCB0aGUgZGVzaWduIGdvYWwgb2YgNHJkLVUgaXRz ZWxmOg0KICAgdW5pZmljYXRpb24gb2YgbXVsdGlwbGUgc3RhbmRhcmRzLiBwb2xpdGljYWxseSBz cGVha2luZywgdGhlIDRyZC11IGF1dGhvcnMnDQogICBwb3NpdGl0aW9uIGlzIG5vdyBxdWl0ZSBj b25mdXNpbmcuDQoNCjIuIG9wZXJhdG9ycyBzdXJlbHkgbmVlZCB0byBjaG9vc2UgSVB2NiB0cmFu c2l0aW9uIG1lY2hhbmlzbXMgYnV0IHN1Y2ggYSBjaG9pY2UNCiAgIGlzIGJhc2VkIG9uIHRoZWly IGRlbWFuZCBhbmQgdW5kZXJzdGFuZGluZyB0byB0aGUgZXhpc3RpbmcgYW5kIHdlbGwtdGVzdGVk LA0KICAgd2VsbC1wcmFjdGljZWQgYnVpbGRpbmcgYmxvY2tzLiBpIGRvbid0IHRoaW5rIGFueSBv cGVyYXRvcnMgYXJlIHdhaXRpbmcgZm9yDQogICBhbiBvcHRpb24gb2YgY2hvaWNlIHRoZXkgbmV2 ZXIgc2VlIGFuZCBuZXZlciB1bmRlcnN0YW5kLiBhbmQgdGhlICJlbm91Z2gNCiAgIHRlY2huaWNh bCBzdXBwb3J0cyIgaXMgbm93IHN0aWxsICJhIGNoZWNrIHdpdGhvdXQgc2lnbmF0dXJlIi4gaSBk byBzdWdnZXN0DQogICB0aGUgNHJkLXUgYXV0aG9ycyBhbmQgc3VwcG9ydGVycyBzYXkgdGhhdCBh ZnRlciBtYWtpbmcgc29tZXRoaW5nIHJlYWwuDQoNCiAgIG9uIHRoZSBvdGhlciBoYW5kLCA0cmQt dSBtYWtlcyBhIHRpZ2h0IGNvdXBsaW5nIGJldHdlZW4gdGhlIGFkZHJlc3MgZm9ybWF0DQogICBh bmQgaXRzIG93biBoZWFkZXIgbWFwcGluZyBtZWNoYW5pc20uIHRoaXMgbWFrZXMgYW4gb3BlcmF0 b3IgdW5hYmxlIHRvIGhhdmUNCiAgIGRpZmZlcmVudCBjaG9pY2VzIG9mIHRyYW5zaXRpb24gbWVj aGFuaXNtIGFzIGxvbmcgYXMgaXQgY2hvb3NlcyA0cmQtdS4gaWYNCiAgIHlvdSBjb25jZXJuIHRo ZSBjaG9pY2Ugb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbSwgaSBkbyByZWNvbW1lbmQgTUFQ LCBhcw0KICAgZWl0aGVyIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRpb24gaXMgb3BlcmF0YWJs ZSB3aXRoIE1BUCBhZGRyZXNzL3BvcnQNCiAgIG1hcHBpbmcgd2l0aG91dCBkaWZmaWN1bHR5Lg0K DQozLiBzdXJlbHkgTUFQIHN0aWxsIGhhcyByb29tIG9mIGltcHJvdmVtZW50IGJ1dCBpIGRvbid0 IHRoaW5rIHRoZXJlIGFyZQ0KICAgYXJjaGl0ZWN0dXJhbCB1bmNlcnRhaW50eSBhcyA0cmQtVSBo YXMuIHJlcXVlc3Qgb24gbW9yZSB0ZXN0aW5nIGRhdGEgaXMNCiAgIHN1cmVseSBhcHByZWNpYXRl ZCBidXQgcGxlYXNlIHRoaW5rIGl0IG92ZXIgYWdhaW4gaWYgaXQgaXMgYSBjb3JyZWN0IHdheQ0K ICAgdG8gcmVxdWlyZSBmdXJ0aGVyIGRhdGEgb2YgYSBjb3VudGVycGFydCBpbiBvcmRlciB0byBk ZWZlbnNlIGEgc29sdXRpb24NCiAgIHdpdGhvdXQgYW55IGRhdGEuDQoNCjQuIGV2ZW4gdGhlcmUg d2VyZSBubyBNQVAgYXQgYWxsLCBjdXJyZW50IGxldmVsIG9mIDRyZC1VIGlzIGZhciBwcmVtYXR1 cmUgdG8gYmUNCiAgIHRhbGtlZCBhYm91dCBhbnkgd29ya2luZyBncm91cCBhY2NlcHRpb24uDQoN CnRoZSBhdXRob3JzIGFuZCBzdXBwb3J0ZXJzIHdpbGwgYmUgYXBwcmVjaWF0ZWQgaWYgdGhleSB0 YWxrIGFib3V0IHRoZSBhY2NlcHRpb24NCmFmdGVyIHRoZWlyIGNvZGluZyBhbmQgdGVzdGluZyBh bmQgcmVmaW5lbWVudCBvbiB0aGUgZG9jdW1lbnQgYWNjb3JkaW5nIHRvIHRoZWlyDQpwcmFjdGlj YWwgZXhwZXJpZW5jZXMsIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBwcm9ibGVtIGFnYWluIGFuZCBh Z2Fpbi4NCg0KdGhhbmtzLA0KbWFva2UNCg0KMjAxMi80LzkgU2hlbmcgSmlhbmcgPGppYW5nc2hl bmdAaHVhd2VpLmNvbTxtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tPj4NCj4gSSBhbHNvIGZv bGxvd2VkIHRoZSBkaXNjdXNzaW9uLiBJIGFwcHJlY2lhdGUgYm90aCB0ZWFtcyBib3VnaHQgdXAg dGhlDQo+IHRlY2huaWNhbCBkZXRhaWxzIGZvciBib3RoIGRlc2lnbnMuIFRvIGJlIGhvbmVzdCwg SSBmYWlsIHRvIHNlZSB3aGljaA0KPiBvbmUgaXMgYmV0dGVyIHRoYW4gb3RoZXIgKHlldCkuIEkg bGlrZSB0aGUgZmFjdCB0aGF0IDRyZC11IGNhbiBkbyB3aGF0DQo+IE1BUC1UIGRvZXMgdy9vIGlu dHJvZHVjaW5nIGFueSBlbmNhcCBvdmVyaGVhZC4gQnV0IEkgdW5kZXJzdGFuZCB0aGUNCj4gY29u Y2VybnMgb3RoZXJzIGJyb3VnaHQgdXAgaW4gdGhlIE1MIHN1Y2ggYXMgVi1vY3RldC4gRm9yIE1B UC1ULCBJIGxpa2UNCj4gaXQgbm90IGludHJvZHVjaW5nIGFueSBuZXcgcmVxdWlyZW1lbnQgdG8g dGhlIElQdjYgaGVhZGVyLCBidXQgSSBuZWVkDQo+IG1vcmUgcHVibGlzaGVkIGRhdGEgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdGhlIGRvdWJsZS10cmFuc2xhdGlvbiB3b3VsZA0KPiBjYXVzZSBhbnkg dHJhbnNwYXJlbnQgaXNzdWUgb3Igbm90LiBGb3IgZXhhbXBsZTogSSB3b3VsZCB2ZXJ5DQo+IGFw cHJlY2lhdGUgaWYgc29tZWJvZHkgd2hvIHRyaWFsIE1BUCBjYW4gcHVibGlzaCBkYXRhIHN1Y2gg YXMgd2hhdA0KPiBhcHBsaWNhdGlvbnMgdGhleSBoYXZlIHRlc3RlZCwgd2hhdCBwYXNzIGFuZCB3 aGF0IGZhaWwuDQo+DQo+IFRoaXMgcGllY2Ugb2Ygd29yayBpcyB2ZXJ5IGltcG9ydGFudCBiZWNh dXNlIG9uY2Ugd2Ugc2VsZWN0IGl0LCB0aGlzDQo+IHRlY2hub2xvZ3kgd2lsbCBzdGF5IGZvciBs b25nIHRpbWUuIEkgZG8gbm90IHdhbnQgdG8gcnVzaCB0byBtYWtlIGENCj4gZGVjaXNpb24gYW5k IGNvbWUgYmFjayB0byByZWdyZXQgaW4gZnV0dXJlLg0KV2Ugd291bGQgbGlrZSB0byBzZWUgYm90 aCBzb2x1dGlvbiBwdWJsaXNoZWQuIFNvIHRoYXQsIG9wZXJhdG9ycyBjYW4gY2hvb3NlIGFjY29y ZGluZyB0byB0aGVpciBvd24gbmV0d29ya3MgYW5kIHByZWZlcmVuY2UuIFRoZXJlIGFyZSBlbm9y bW91cyBudW1iZXIgb2Ygb3BlcmF0b3JzLCB3aG8gZG8gbm90IGNvbWUgdG8gSUVURiBtZWV0aW5n IG9yIGRvIG5vdCBwYXJ0aWNpcGF0ZSBpbiBNTCBlaXRoZXIuIFRoZXkgYWxzbyBuZWVkIHRvIGNo b29zZSBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gVGhleSBzaG91bGQgYmUgcHJvdmlkZWQg ZW5vdWdoIHRlY2huaWNhbCBzdXBwb3J0cy4gVGhhdCdzIHRoZSByZXNwb25zZSBvZiBJRVRGLCBp biBvdXIgdW5kZXJzdGFuZGluZy4NCg0KPiBPbiA0LzYvMTIgNjowMCBBTSwgIkxpdWJpbmcgKExl bykiIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPG1haWx0bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29t Pj4gd3JvdGU6DQo+DQo+ID4rMQ0KPiA+DQo+ID5JJ3ZlIHJlYWQgdGhlIGVuZGxlc3MgZGlzY3Vz c2lvbiwgYW5kIGZvdW5kIHRoYXQgaXMgc2VlbXMgdGhlIE1BUCBhbHNvDQo+ID5oYXMgbm90IGZ1 bGx5IGNvbnZpbmNlZCB0aGUgSVNQIG9wZXJhdGlvbiBndXlzLg0KPiA+U2luY2UgdGhlcmUncyBl eHBsaWNpdCBjb250cm92ZXJzeSwgd2h5IG5vdCBqdXN0IHB1Ymxpc2ggdGhlbSBib3RoIGFzDQo+ ID5leHBlcmltZW50YWwuIHdoeSB3ZSBtdXN0IGNob3NlIG9uZSBhcyBhICJzdGFuZGFyZCB0cmFj ayI/IEJlaW5nIGENCj4gPnN0YW5kYXJkIHRyYWNrIGNhbiBlbGltaW5hdGUgb3BlcmF0b3JzJyBt aXNnaXZpbmc/DQo+ID4NCj4gPklmIHRoZSB0ZWNobm9sb2d5IGlzIHJlYWxseSBhcHByb3ByaWF0 ZSwgSSBkb24ndCB0aGluayB0aGUNCj4gImV4cGVyaW1lbnRhbCINCj4gPnN0YXR1cyB3b3VsZCBi ZSBhIGlzc3VlIGZvciB0aGUgb3BlcmF0b3JzIHRvIGFkb3B0LiBKdXN0IGxldCB0aGUNCj4gPm9w ZXJhdG9yIGRlY2lkZSBieSB0aGVtc2VsdmVzLg0KPiA+DQo+ID5JIHJlbWVtYmVyZWQgaW4gdGhl IG1lZXRpbmcgdmVudWUsIEpvZWwgSGFscGVybiB3aG8gY2hhaXJzIEthcnAgYW5kDQo+ID5saXNw IFdHLCBzdWdnZXN0ZWQgd2UgcHVibGlzaCBib3RoIG9mIHRoZW0gYXMgZXhwZXJpbWVudGFsLCBh bmQgdGhhdA0KPiA+d2FzIGV4YWN0bHkgaG93IHRoZXkgaGFuZGxlIHRoZSBzaW1pbGFyIHNpdHVh dGlvbiBpbiB0aGVpciBXRy4gSSB0aGluaw0KPiA+aGlzIHN1Z2dlc3Rpb24gaXMgcmVhc29uYWJs ZSB0byBiZSBjb25zaWRlcmVkLiAoVG8gSm9lbDogUGFyZG9uIG1lIGlmDQo+IEkNCj4gPmltcHJv cGVybHkgcXVvdGVkIHlvdXIgY29tbWVudCwgb3IgSSBqdXN0IG1pc3VuZGVyc3Rvb2QgeW91cg0K PiBzdWdnZXN0aW9uDQo+ID4pLg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPiA+Pk9uICBCZWhhbGYgT2YgU2ltb24g UGVycmVhdWx0DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDEyIDg6MTYgUE0NCj4g Pj4gVG86IHNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86c29mdHdpcmVzQGlldGYub3JnPg0KPiA+ PiBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTF oCA0cmQtVSBhcw0KPiA+PnRyYW5zcGFyZW50ICBhcyBNQVAtRQ0KPiA+Pg0KPiA+PiBPbiAyMDEy LTA0LTAzIDA1OjQwLCBPbGUgVHLDuGFuIHdyb3RlOg0KPiA+PiA+IDEpIE1BUC1FIHN1cHBvcnRz IGluZGVwZW5kZW5jZSBvZiBJUHY0IGFuZCBJUHY2IGFkZHJlc3NpbmcuIGJ5DQo+ID4+ID4gdXNp bmcNCj4gPj5odWINCj4gPj4gYW5kIHNwb2tlIG1vZGUgd2l0aCBhIHNlcGFyYXRlDQo+ID4+ID4g ICAgIG1hcHBpbmcgcnVsZSBwZXIgc3Vic2NyaWJlci4gaW4gdGhpcyBtb2RlIGUuZyBvbmx5IHBv cnRzIGNvdWxkDQo+ID4+ID4gYmUNCj4gPj4gZW1iZWRkZWQgaW4gdGhlIGFkZHJlc3MuIHRoaXMg aXMgbm90DQo+ID4+ID4gICAgIHBvc3NpYmxlIGluIGEgdHJhbnNsYXRpb24gc29sdXRpb24gbGlr ZSA0cmQtVS4NCj4gPj4NCj4gPj4gVGhpcyBtb2RlIG9mIG9wZXJhdGlvbiB3YXMgc3VnZ2VzdGVk IGxhc3Qgd2VlayBkdXJpbmcgdGhlIFNELU5BVA0KPiA+PiBwcmVzZW50YXRpb24uIFRoZXJlIHNl ZW1lZCB0byBiZSBjb25zZW5zdXMgYW1vbmcgb3BlcmF0b3JzIHRoYXQgaXQNCj4gPj4gd2FzIG5v dCBwcmFjdGljYWxseSBmZWFzaWJsZS4NCj4gPj4NCj4gPj4gPiAyKSBhIG5vZGUgaW5zaWRlIHRo ZSBuZXR3b3JrIHdpbGwgdHJlYXQgdHJhbnNsYXRlZCBwYWNrZXRzDQo+ID4+ID4gZGlmZmVyZW50 DQo+ID4+ZnJvbQ0KPiA+PiBlbmNhcHN1bGF0ZWQgb25lcy4NCj4gPj4gPiAgICAgZS5nLiBmb3Ig dGhlIHB1cnBvc2VzIG9mIGNvdW50aW5nIG9yIGZvciBhcHBseWluZyBmZWF0dXJlcy4NCj4gZm9y DQo+ID4+ID4gYW4NCj4gPj4gZW5jYXBzdWxhdGVkIHBhY2tldCBib3RoIHRoZSBjb21wbGV0ZQ0K PiA+PiA+ICAgICBJUHY0IGRhdGFncmFtIGFuZCB0aGUgSVB2NiBoZWFkZXIgaXMgYXZhaWxhYmxl LCBhbmQgZGlmZmVyZW50DQo+ID4+ZmVhdHVyZXMNCj4gPj4gY2FuIGJlIGFwcGxpZWQgdG8gYm90 aC4NCj4gPj4NCj4gPj4gSW4gcHJhY3RpY2UsIHRoZSBjb250ZW50cyBvZiBlbmNhcHN1bGF0ZWQg cGFja2V0cyBhcmUgcmFyZWx5DQo+ID4+IGluc3BlY3RlZCBieSBmaXJld2FsbHMgYW5kIG90aGVy IHN1Y2ggZGV2aWNlcy4NCj4gPj4NCj4gPj4NCj4gPj4gSU1ITyBhdCB0aGlzIHBvaW50IHdlIHNo b3VsZCBsZXQgdGhlIG1hcmtldCBkZWNpZGUuIFB1Ymxpc2ggYm90aCBhcw0KPiA+PiBleHBlcmlt ZW50YWwuIExldCdzIHdvcmsgb24gc29tZXRoaW5nIGVsc2Ugbm93Lg0KPiA+Pg0KPiA+PiBTaW1v bg0KPiA+PiAtLQ0KPiA+PiBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6 Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2ENCj4gPj4gTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2Ug ICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPiA+PiBTVFVOL1RVUk4gc2Vy dmVyICAgICAgICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFNvZnR3aXJl cyBtYWlsaW5nIGxpc3QNCj4gPj4gU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNA aWV0Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzDQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+U29mdHdpcmVzQGlldGYub3JnPG1haWx0 bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NvZnR3aXJlcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZzxtYWls dG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMNCg0KDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8szxeml509mbs_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDtmaW5lLiB3ZSdkIGxvdmUgdG8gc2VlIGl0IG91dCB3aXRoIGdvb2Qg YW1vdW50IG9mIGRhdGEgYW5kIGdvb2QgYW1vdW50IG9mIGZlZWRiYWNrIGZyb20gdGVzdGluZyBv cGVyYXRvcnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O2lmIHlvdSBpbnZpdGUgbWUgdG8gdGVzdCwgaSdkIGxvdmUg dG8gcHJvdmlkZSBjaGFsbGVuZ2luZyBzY2VuYXJpb3MuIDstKQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtidXQgaXQg ZG9lc24ndCBtZWFuIHdlIHNob3VsZCBwb3N0cG9uZSBjdXJyZW50IHByb2Nlc3Mgb2Ygc3RhbmRh cmRpemF0aW9uIG9mIE1BUCwgYmVjYXVzZSB0aGUgcmVzdWx0IG9mIDRyZC11IGlzIHN0aWxsIHVu c3VyZS4gLSBtYW9rZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J 4oCZZCBsb3ZlIHRvIHNlZSBvcGVyYXRvcnMgZmluZCBwcm9wZXIgbWVjaGFuaXNtcyByZXNwZWN0 aXZlbHkgYWNjb3JkaW5nIHRvIHRoZWlyIG93biBzaXR1YXRpb25zLCByYXRoZXIgdGhhbiBzb21l IG1lY2hhbmlzbXMgKjxiPm91dDwvYj4qLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgdHJhbnNpdGlvbiBtZWNoYW5pc21zIGFyZSBkZXZlbG9wZWQgZm9yIHRoZSBvcGVy YXRvcnMsIGJ1dCBpbiBteSBvYnNlcnZhdGlvbiwgdGhlIE1BUCBoYXNu4oCZdCAmbmJzcDtwcm92 ZWQgc3VmZmljaWVudGx5IGZvciBvcGVyYXRvcnPigJkgbG9uZy10ZXJtDQogc2VsZWN0aW9uLiBT byB3aHkgd2UgaGF2ZSB0byBydXNoIHRvIGEgKjxiPnN0YW5kIHRyYWNrPC9iPio/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gTWFva2UgW21haWx0bzpmaWJyaWJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXByaWwgMDksIDIwMTIgNTo1MiBQTTxicj4NCjxiPlRvOjwvYj4gU2hl bmcgSmlhbmc8YnI+DQo8Yj5DYzo8L2I+IExlZSwgWWl1OyBMaXViaW5nIChMZW8pOyBTaW1vbiBQ ZXJyZWF1bHQ7IHNvZnR3aXJlc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1Nv ZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoCA0cmQtVSBhcyB0cmFuc3Bh cmVudCBhcyBNQVAtRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yMDEyLzQvOSBTaGVuZyBK aWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbSI+amlhbmdzaGVu Z0BodWF3ZWkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRob3V0IGFueSBvYmplY3Rpb24gdG8gTUFQLCB3ZSBq dXN0IHN0YXJ0IHRvIGNvZGluZyA0cmQtdSBhbmQgaGVscCB0byBpbXByb3ZlIGl0Ljwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmZpbmUuIHdlJ2QgbG92ZSB0byBzZWUgaXQgb3V0IHdpdGggZ29v ZCBhbW91bnQgb2YgZGF0YSBhbmQgZ29vZCBhbW91bnQgb2YgZmVlZGJhY2sgZnJvbSB0ZXN0aW5n IG9wZXJhdG9ycy4gaWYgeW91IGludml0ZSBtZSB0byB0ZXN0LCBpJ2QgbG92ZSB0byBwcm92aWRl IGNoYWxsZW5naW5nIHNjZW5hcmlvcy4gOy0pIGJ1dCBpdCBkb2Vzbid0IG1lYW4gd2Ugc2hvdWxk IHBvc3Rwb25lDQogY3VycmVudCBwcm9jZXNzIG9mIHN0YW5kYXJkaXphdGlvbiBvZiBNQVAsIGJl Y2F1c2UgdGhlIHJlc3VsdCBvZiA0cmQtdSBpcyBzdGlsbCB1bnN1cmUuIC0gbWFva2UmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TXVsdGlwbGUgdHJhbnNpdGlvbiBtZWNoYW5pc21zIHdvdWxkIGNvLWV4 aXN0IGluIHRoZSB3b3JsZC4gTmVpdGhlciBNQVAgbm9yIDRyZC1VIGNhbg0KIHJlcGxhY2UgNnJk IGFuZCBEUy1MaXRlLiBUaGVyZSBpcyBubyBvbmUtc3VpdC1hbGwgc29sdXRpb24uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hb2tlDQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86 ZmlicmliQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZpYnJpYkBnbWFpbC5jb208L2E+XSA8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA1OjM5IFBNPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQo8Yj5Ubzo8L2I+IFNo ZW5nIEppYW5nPGJyPg0KPGI+Q2M6PC9iPiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24g UGVycmVhdWx0OyA8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpzb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb U29mdHdpcmVzXSBQYXRoIHRvIG1vdmUgZm9yd2FyZCB3aXRoIDRyZMWgIDRyZC1VIGFzIHRyYW5z cGFyZW50IGFzIE1BUC1FPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4yMDEyLzQvOSBTaGVu ZyBKaWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmppYW5nc2hlbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGFsbG93IG1l IHRvIGNsYXJpZnkgbXlzZWxmOiBJIHN1cHBvcnQgYm90aCBNQVAgYW5kIDRyZC11Ljwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUCBoYXMgYmVlbiBhIGdvb2QgZWZmb3J0IHdp dGggbWFueSBleHBlcnRzIHRvZ2V0aGVyIGluIElQdjQvSVB2NiB0cmFuc2l0aW9uIGFyZWEgYW5k DQogaGFzIGJlZW4gcHJvdmVkIGJ5IHJ1bm5pbmcgY29kZS4gSXQgYWxzbyBuZWVkIHRvIGltcHJv dmUgaXRzZWxmIGJlZm9yZSBiZWluZyBwdWJsaXNoZWQgYXMgYSBSRkMgbGF0ZXIuIFRoaXMgcHJv Y2VzcyB3aWxsIHRha2Ugc2V2ZXJhbCBtb250aHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UGVyc29uYWxseSwgSSB0aGluayA0cmQtdSBpcyBhIGxpdHRsZSBiaXQgYmVoaW5k IE1BUCBpbiBtYXR1cml0eSBhc3BlY3QgZm9yIG5vdy4gQnV0LA0KIGl0IGlzIG9ubHkgbWF0dGVy IG9mIHRpbWUuIFRoZSBhdXRob3JzIGhhdmUgYWdyZWVkIHRvIHJlbW92ZSB0aGUgYXJjaGl0ZWN0 dXJhbCBjb25mbGljdCwgaWYgdGhlcmUgd2FzIGFueS4gV2UgaGF2ZSBvZmZlcmVkIHRvIGhlbHAg b24gdGhlIGltcHJvdmVtZW50IGJ5IGltcGxlbWVudGF0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkdpdmluZyB0aW1lLCBib3RoIHNvbHV0aW9uIGNhbiBiZSBtYXR1cmUg ZW5vdWdoIGZvciBvcGVyYXRpb25zLiBJRVRGIGRvZXMgbm90IGhhdmUgdG8NCiBjaG9vc2Ugb25l IGJ5IG5vdy4gQW5kLCB0aGVzZSB0d28gc29sdXRpb25zIGFyZSBub3QgbmVjZXNzYXJ5IHRvIGJl IGEgc2FtZSBwYWNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj53aGF0IGlmLCBnaXZp bmcgdGltZSwgcGVvcGxlIGNhbiBiZSBtYXR1cmUgZW5vdWdoIHRvIGlkZW50aWZ5IDRyZC1VIGlz IHJlYWxseSBhIGZsYXdlZCBkb25rb3JzZT8gOy0pIGlmIHRoZSA0cmQtdSBkZXNpZ25lcnMgYXJl IHNvIGNvbmZpZGVudCwgd2h5IG5vdCBkbyB0aGUgcmVhbA0KIGNvZGluZyB3b3JrIGZpcnN0IGFu ZCB0aGVuIHByb3Bvc2UgaXQgYXMgYSByZXBsYWNlbWVudCBvZiBNQVAgc3VpdGU/IGkgZG9uJ3Qg c2VlIGFueSB1bmZhaXJuZXNzIGhlcmUuIC0gbWFva2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFv a2UNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmaWJyaWJAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZmlicmliQGdtYWlsLmNvbTwvYT5dIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFw cmlsIDA5LCAyMDEyIDM6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNoZW5nIEppYW5nPGJyPg0KPGI+ Q2M6PC9iPiBMZWUsIFlpdTsgTGl1YmluZyAoTGVvKTsgU2ltb24gUGVycmVhdWx0OyA8YSBocmVm PSJtYWlsdG86c29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzb2Z0d2lyZXNA aWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZv cndhcmQgd2l0aCA0cmTFoCA0cmQtVSBhcyB0cmFuc3BhcmVudCBhcyBNQVAtRTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+aGkgWWl1IGFuZCBvdGhlcnMsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+MS4gJnF1b3Q7Ym90aCBwdWJsaXNoZWQmcXVv dDsgZG9lcyBzdXJlbHkgY29uZmxpY3Qgd2l0aCB0aGUgZGVzaWduIGdvYWwgb2YgNHJkLVUgaXRz ZWxmOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJzcDt1bmlmaWNhdGlv biBvZiBtdWx0aXBsZSBzdGFuZGFyZHMuJm5ic3A7cG9saXRpY2FsbHkgc3BlYWtpbmcsIHRoZSA0 cmQtdSBhdXRob3JzJw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7ICZuYnNwO3Bvc2l0 aXRpb24gaXMgbm93IHF1aXRlIGNvbmZ1c2luZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4yLiBvcGVyYXRvcnMgc3VyZWx5IG5lZWQg dG8gY2hvb3NlIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc21zIGJ1dCBzdWNoIGEgY2hvaWNlJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7ICZuYnNwO2lzIGJhc2VkIG9uIHRoZWly IGRlbWFuZCBhbmQgdW5kZXJzdGFuZGluZyB0byB0aGUgZXhpc3RpbmcgYW5kIHdlbGwtdGVzdGVk LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJzcDt3ZWxsLXByYWN0aWNl ZCBidWlsZGluZyBibG9ja3MuIGkgZG9uJ3QgdGhpbmsgYW55IG9wZXJhdG9ycyBhcmUgd2FpdGlu ZyBmb3ImbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7YW4gb3B0aW9u IG9mIGNob2ljZSB0aGV5IG5ldmVyIHNlZSBhbmQgbmV2ZXIgdW5kZXJzdGFuZC4gYW5kIHRoZSAm cXVvdDtlbm91Z2gmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7dGVj aG5pY2FsIHN1cHBvcnRzJnF1b3Q7IGlzIG5vdyBzdGlsbCAmcXVvdDthIGNoZWNrIHdpdGhvdXQg c2lnbmF0dXJlJnF1b3Q7LiBpIGRvIHN1Z2dlc3QmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDsgJm5ic3A7dGhlIDRyZC11IGF1dGhvcnMgYW5kIHN1cHBvcnRlcnMgc2F5IHRoYXQg YWZ0ZXIgbWFraW5nIHNvbWV0aGluZyByZWFsLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJzcDtvbiB0aGUgb3RoZXIg aGFuZCwgNHJkLXUgbWFrZXMgYSB0aWdodCBjb3VwbGluZyBiZXR3ZWVuIHRoZSBhZGRyZXNzIGZv cm1hdCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJzcDthbmQgaXRzIG93 biBoZWFkZXIgbWFwcGluZyBtZWNoYW5pc20uIHRoaXMgbWFrZXMgYW4gb3BlcmF0b3IgdW5hYmxl IHRvIGhhdmUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7ZGlmZmVy ZW50IGNob2ljZXMgb2YgdHJhbnNpdGlvbiBtZWNoYW5pc20gYXMgbG9uZyBhcyBpdCBjaG9vc2Vz IDRyZC11LiBpZiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJzcDt5b3Ug Y29uY2VybiB0aGUgY2hvaWNlIG9mIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc20sIGkgZG8gcmVj b21tZW5kIE1BUCwgYXMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7 ZWl0aGVyIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRpb24gaXMgb3BlcmF0YWJsZSB3aXRoIE1B UCBhZGRyZXNzL3BvcnQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7 bWFwcGluZyB3aXRob3V0IGRpZmZpY3VsdHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+My4gc3VyZWx5IE1BUCBzdGlsbCBoYXMgcm9v bSBvZiBpbXByb3ZlbWVudCBidXQgaSBkb24ndCB0aGluayB0aGVyZSBhcmUmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7YXJjaGl0ZWN0dXJhbCB1bmNlcnRhaW50eSBh cyA0cmQtVSBoYXMuIHJlcXVlc3Qgb24gbW9yZSB0ZXN0aW5nIGRhdGEgaXMmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgJm5ic3A7c3VyZWx5IGFwcHJlY2lhdGVkIGJ1dCBwbGVh c2UgdGhpbmsgaXQgb3ZlciBhZ2FpbiBpZiBpdCBpcyBhIGNvcnJlY3Qgd2F5Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7ICZuYnNwO3RvIHJlcXVpcmUgZnVydGhlciBkYXRhIG9m IGEgY291bnRlcnBhcnQgaW4gb3JkZXIgdG8gZGVmZW5zZSBhIHNvbHV0aW9uJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7ICZuYnNwO3dpdGhvdXQgYW55IGRhdGEuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+NC4gZXZl biB0aGVyZSB3ZXJlIG5vIE1BUCBhdCBhbGwsIGN1cnJlbnQgbGV2ZWwgb2YgNHJkLVUgaXMgZmFy IHByZW1hdHVyZSB0byBiZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyAmbmJz cDt0YWxrZWQgYWJvdXQgYW55IHdvcmtpbmcgZ3JvdXAgYWNjZXB0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPnRoZSBhdXRob3JzIGFuZCBz dXBwb3J0ZXJzIHdpbGwgYmUgYXBwcmVjaWF0ZWQgaWYgdGhleSB0YWxrIGFib3V0IHRoZSBhY2Nl cHRpb24mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5hZnRlciB0aGVpciBjb2RpbmcgYW5k IHRlc3RpbmcgYW5kIHJlZmluZW1lbnQgb24gdGhlIGRvY3VtZW50IGFjY29yZGluZyB0byB0aGVp ciZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPnByYWN0aWNhbCBleHBlcmllbmNlcywgYW5k IHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0gYWdhaW4gYW5kIGFnYWluLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPnRoYW5rcywmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5tYW9rZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPjIwMTIvNC85IFNoZW5nIEppYW5nICZsdDs8YSBo cmVmPSJtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amlhbmdz aGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBJIGFsc28gZm9sbG93ZWQgdGhl IGRpc2N1c3Npb24uIEkgYXBwcmVjaWF0ZSBib3RoIHRlYW1zIGJvdWdodCB1cCB0aGU8YnI+DQom Z3Q7IHRlY2huaWNhbCBkZXRhaWxzIGZvciBib3RoIGRlc2lnbnMuIFRvIGJlIGhvbmVzdCwgSSBm YWlsIHRvIHNlZSB3aGljaDxicj4NCiZndDsgb25lIGlzIGJldHRlciB0aGFuIG90aGVyICh5ZXQp LiBJIGxpa2UgdGhlIGZhY3QgdGhhdCA0cmQtdSBjYW4gZG8gd2hhdDxicj4NCiZndDsgTUFQLVQg ZG9lcyB3L28gaW50cm9kdWNpbmcgYW55IGVuY2FwIG92ZXJoZWFkLiBCdXQgSSB1bmRlcnN0YW5k IHRoZTxicj4NCiZndDsgY29uY2VybnMgb3RoZXJzIGJyb3VnaHQgdXAgaW4gdGhlIE1MIHN1Y2gg YXMgVi1vY3RldC4gRm9yIE1BUC1ULCBJIGxpa2U8YnI+DQomZ3Q7IGl0IG5vdCBpbnRyb2R1Y2lu ZyBhbnkgbmV3IHJlcXVpcmVtZW50IHRvIHRoZSBJUHY2IGhlYWRlciwgYnV0IEkgbmVlZDxicj4N CiZndDsgbW9yZSBwdWJsaXNoZWQgZGF0YSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG91Ymxl LXRyYW5zbGF0aW9uIHdvdWxkPGJyPg0KJmd0OyBjYXVzZSBhbnkgdHJhbnNwYXJlbnQgaXNzdWUg b3Igbm90LiBGb3IgZXhhbXBsZTogSSB3b3VsZCB2ZXJ5PGJyPg0KJmd0OyBhcHByZWNpYXRlIGlm IHNvbWVib2R5IHdobyB0cmlhbCBNQVAgY2FuIHB1Ymxpc2ggZGF0YSBzdWNoIGFzIHdoYXQ8YnI+ DQomZ3Q7IGFwcGxpY2F0aW9ucyB0aGV5IGhhdmUgdGVzdGVkLCB3aGF0IHBhc3MgYW5kIHdoYXQg ZmFpbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHBpZWNlIG9mIHdvcmsgaXMgdmVyeSBpbXBv cnRhbnQgYmVjYXVzZSBvbmNlIHdlIHNlbGVjdCBpdCwgdGhpczxicj4NCiZndDsgdGVjaG5vbG9n eSB3aWxsIHN0YXkgZm9yIGxvbmcgdGltZS4gSSBkbyBub3Qgd2FudCB0byBydXNoIHRvIG1ha2Ug YTxicj4NCiZndDsgZGVjaXNpb24gYW5kIGNvbWUgYmFjayB0byByZWdyZXQgaW4gZnV0dXJlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+V2Ugd291bGQgbGlrZSB0byBzZWUgYm90aCBzb2x1dGlvbiBwdWJsaXNo ZWQuIFNvIHRoYXQsIG9wZXJhdG9ycyBjYW4gY2hvb3NlIGFjY29yZGluZyB0byB0aGVpciBvd24g bmV0d29ya3MgYW5kIHByZWZlcmVuY2UuIFRoZXJlIGFyZSBlbm9ybW91cyBudW1iZXIgb2Ygb3Bl cmF0b3JzLA0KIHdobyBkbyBub3QgY29tZSB0byBJRVRGIG1lZXRpbmcgb3IgZG8gbm90IHBhcnRp Y2lwYXRlIGluIE1MIGVpdGhlci4gVGhleSBhbHNvIG5lZWQgdG8gY2hvb3NlIElQdjYgdHJhbnNp dGlvbiBtZWNoYW5pc21zLiBUaGV5IHNob3VsZCBiZSBwcm92aWRlZCBlbm91Z2ggdGVjaG5pY2Fs IHN1cHBvcnRzLiBUaGF0J3MgdGhlIHJlc3BvbnNlIG9mIElFVEYsIGluIG91ciB1bmRlcnN0YW5k aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KJmd0OyBPbiA0LzYvMTIgNjowMCBBTSwg JnF1b3Q7TGl1YmluZyAoTGVvKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlby5saXViaW5n QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sZW8ubGl1YmluZ0BodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyYjNDM7MTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0O0kndmUgcmVhZCB0aGUgZW5kbGVzcyBkaXNjdXNzaW9uLCBhbmQgZm91bmQg dGhhdCBpcyBzZWVtcyB0aGUgTUFQIGFsc288YnI+DQomZ3Q7ICZndDtoYXMgbm90IGZ1bGx5IGNv bnZpbmNlZCB0aGUgSVNQIG9wZXJhdGlvbiBndXlzLjxicj4NCiZndDsgJmd0O1NpbmNlIHRoZXJl J3MgZXhwbGljaXQgY29udHJvdmVyc3ksIHdoeSBub3QganVzdCBwdWJsaXNoIHRoZW0gYm90aCBh czxicj4NCiZndDsgJmd0O2V4cGVyaW1lbnRhbC4gd2h5IHdlIG11c3QgY2hvc2Ugb25lIGFzIGEg JnF1b3Q7c3RhbmRhcmQgdHJhY2smcXVvdDs/IEJlaW5nIGE8YnI+DQomZ3Q7ICZndDtzdGFuZGFy ZCB0cmFjayBjYW4gZWxpbWluYXRlIG9wZXJhdG9ycycgbWlzZ2l2aW5nPzxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0O0lmIHRoZSB0ZWNobm9sb2d5IGlzIHJlYWxseSBhcHByb3ByaWF0ZSwg SSBkb24ndCB0aGluayB0aGU8YnI+DQomZ3Q7ICZxdW90O2V4cGVyaW1lbnRhbCZxdW90Ozxicj4N CiZndDsgJmd0O3N0YXR1cyB3b3VsZCBiZSBhIGlzc3VlIGZvciB0aGUgb3BlcmF0b3JzIHRvIGFk b3B0LiBKdXN0IGxldCB0aGU8YnI+DQomZ3Q7ICZndDtvcGVyYXRvciBkZWNpZGUgYnkgdGhlbXNl bHZlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtJIHJlbWVtYmVyZWQgaW4gdGhlIG1l ZXRpbmcgdmVudWUsIEpvZWwgSGFscGVybiB3aG8gY2hhaXJzIEthcnAgYW5kPGJyPg0KJmd0OyAm Z3Q7bGlzcCBXRywgc3VnZ2VzdGVkIHdlIHB1Ymxpc2ggYm90aCBvZiB0aGVtIGFzIGV4cGVyaW1l bnRhbCwgYW5kIHRoYXQ8YnI+DQomZ3Q7ICZndDt3YXMgZXhhY3RseSBob3cgdGhleSBoYW5kbGUg dGhlIHNpbWlsYXIgc2l0dWF0aW9uIGluIHRoZWlyIFdHLiBJIHRoaW5rPGJyPg0KJmd0OyAmZ3Q7 aGlzIHN1Z2dlc3Rpb24gaXMgcmVhc29uYWJsZSB0byBiZSBjb25zaWRlcmVkLiAoVG8gSm9lbDog UGFyZG9uIG1lIGlmPGJyPg0KJmd0OyBJPGJyPg0KJmd0OyAmZ3Q7aW1wcm9wZXJseSBxdW90ZWQg eW91ciBjb21tZW50LCBvciBJIGp1c3QgbWlzdW5kZXJzdG9vZCB5b3VyPGJyPg0KJmd0OyBzdWdn ZXN0aW9uPGJyPg0KJmd0OyAmZ3Q7KS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGcm9tOiA8YSBo cmVmPSJtYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z b2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86c29m dHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zb2Z0d2lyZXMtYm91bmNl c0BpZXRmLm9yZzwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0O09uICZuYnNwO0JlaGFsZiBPZiBTaW1v biBQZXJyZWF1bHQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAy MDEyIDg6MTYgUE08YnI+DQomZ3Q7ICZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c29mdHdp cmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4N CiZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFBhdGggdG8gbW92ZSBmb3J3 YXJkIHdpdGggNHJkxaAgNHJkLVUgYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7dHJhbnNwYXJlbnQgJm5i c3A7YXMgTUFQLUU8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiAyMDEy LTA0LTAzIDA1OjQwLCBPbGUgVHLDuGFuIHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAx KSBNQVAtRSBzdXBwb3J0cyBpbmRlcGVuZGVuY2Ugb2YgSVB2NCBhbmQgSVB2NiBhZGRyZXNzaW5n LiBieTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyB1c2luZzxicj4NCiZndDsgJmd0OyZndDtodWI8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGFuZCBzcG9rZSBtb2RlIHdpdGggYSBzZXBhcmF0ZTxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IG1hcHBpbmcgcnVsZSBwZXIgc3Vic2NyaWJl ci4gaW4gdGhpcyBtb2RlIGUuZyBvbmx5IHBvcnRzIGNvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IGJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbWJlZGRlZCBpbiB0aGUgYWRkcmVzcy4gdGhpcyBp cyBub3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBwb3NzaWJsZSBpbiBh IHRyYW5zbGF0aW9uIHNvbHV0aW9uIGxpa2UgNHJkLVUuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsgVGhpcyBtb2RlIG9mIG9wZXJhdGlvbiB3YXMgc3VnZ2VzdGVkIGxhc3Qg d2VlayBkdXJpbmcgdGhlIFNELU5BVDxicj4NCiZndDsgJmd0OyZndDsgcHJlc2VudGF0aW9uLiBU aGVyZSBzZWVtZWQgdG8gYmUgY29uc2Vuc3VzIGFtb25nIG9wZXJhdG9ycyB0aGF0IGl0PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyB3YXMgbm90IHByYWN0aWNhbGx5IGZlYXNpYmxlLjxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgMikgYSBub2RlIGluc2lkZSB0aGUgbmV0d29y ayB3aWxsIHRyZWF0IHRyYW5zbGF0ZWQgcGFja2V0czxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBk aWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ZnJvbTxicj4NCiZndDsgJmd0OyZndDsgZW5jYXBz dWxhdGVkIG9uZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgZS5nLiBm b3IgdGhlIHB1cnBvc2VzIG9mIGNvdW50aW5nIG9yIGZvciBhcHBseWluZyBmZWF0dXJlcy48YnI+ DQomZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBhbjxicj4NCiZndDsgJmd0OyZndDsg ZW5jYXBzdWxhdGVkIHBhY2tldCBib3RoIHRoZSBjb21wbGV0ZTxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7IElQdjQgZGF0YWdyYW0gYW5kIHRoZSBJUHY2IGhlYWRlciBpcyBh dmFpbGFibGUsIGFuZCBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ZmVhdHVyZXM8YnI+DQom Z3Q7ICZndDsmZ3Q7IGNhbiBiZSBhcHBsaWVkIHRvIGJvdGguPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgSW4gcHJhY3RpY2UsIHRoZSBjb250ZW50cyBvZiBlbmNhcHN1bGF0 ZWQgcGFja2V0cyBhcmUgcmFyZWx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbnNwZWN0ZWQgYnkgZmly ZXdhbGxzIGFuZCBvdGhlciBzdWNoIGRldmljZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IElNSE8gYXQgdGhpcyBwb2ludCB3ZSBzaG91 bGQgbGV0IHRoZSBtYXJrZXQgZGVjaWRlLiBQdWJsaXNoIGJvdGggYXM8YnI+DQomZ3Q7ICZndDsm Z3Q7IGV4cGVyaW1lbnRhbC4gTGV0J3Mgd29yayBvbiBzb21ldGhpbmcgZWxzZSBub3cuPGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgU2ltb248YnI+DQomZ3Q7ICZndDsmZ3Q7 IC0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0m Z3Q7IDxhIGhyZWY9Imh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2EiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8L2E+PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDst LSZndDsgPGEgaHJlZj0iaHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2EiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPC9hPjxicj4NCiZndDsgJmd0OyZndDsgU1RV Ti9UVVJOIHNlcnZlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLS0mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9udW1iLnZpYWdlbmllLmNhIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vbnVtYi52aWFnZW5pZS5jYTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U29mdHdpcmVzQGll dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48YnI+DQomZ3Q7ICZndDtf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg Jmd0O1NvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86 U29mdHdpcmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U29mdHdpcmVzQGlldGYub3JnPC9h Pjxicj4NCiZndDsgJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNvZnR3 aXJlc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292A03B8szxeml509mbs_-- From Bill.Armstrong@chartercom.com Tue Apr 10 08:32:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12D11E80FF for ; Tue, 10 Apr 2012 08:32:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoCkXKIeBvXZ for ; Tue, 10 Apr 2012 08:32:00 -0700 (PDT) Received: from mail.chartercom.com (mail.chartercom.com [24.217.29.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4811E80FC for ; Tue, 10 Apr 2012 08:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,399,1330927200"; d="scan'208";a="229283825" Received: from unknown (HELO KSTLMEXHTP01.CORP.CHARTERCOM.COM) ([192.168.31.33]) by mail.chartercom.com with ESMTP; 10 Apr 2012 10:31:59 -0500 Received: from KSTLMEXCP02MBX.CORP.CHARTERCOM.COM ([192.168.31.13]) by KSTLMEXHTP01.CORP.CHARTERCOM.COM ([192.168.31.33]) with mapi; Tue, 10 Apr 2012 10:31:59 -0500 From: "Armstrong, Bill R" To: Alain Durand , "softwires@ietf.org" Date: Tue, 10 Apr 2012 10:31:58 -0500 Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgEhBZnQ Message-ID: <1DB5A12D98EB024FA4A9D0355029655A2923368A@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 10 Apr 2012 08:49:03 -0700 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:32:01 -0000 Q1: Bill Armstrong, Charter Communications : Yes Q2: Bill Armstrong, Charter Communications : MAP -Bill -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Alain Durand Sent: Wednesday, April 04, 2012 4:14 PM To: softwires@ietf.org Cc: int-ads@tools.ietf.org; Softwire Chairs Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs M= AP Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a= whole) and 4rd-U. We got very strong feedback that we needed to select one solution to cover that full stateless case, not two, and that we should mak= e this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as st= andard track. Answering NO to this question means you want to see both advance on the sta= ndard track. ---------------------------------------------------------------------------- Your full name, your affiliation, your choice: YES or NO ---------------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ---------------------------------------------------------------------------= --- Your full name, your affiliation, your choice: 4rd-U or MAP ---------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please fill out the following form and reply to the list by Wednesday 4/10 5pm EDT. Note: Use this thread ONLY for expressing your support to one OR the other, and redirect any discussions to other threads. That would help up gauge consensus. Alain & Yong. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires E-MAIL CONFIDENTIALITY NOTICE:=20 The contents of this e-mail message and any attachments are intended solely= for the addressee(s) and may contain confidential and/or legally privilege= d information. If you are not the intended recipient of this message or if = this message has been addressed to you in error, please immediately alert t= he sender by reply e-mail and then delete this message and any attachments.= If you are not the intended recipient, you are notified that any use, diss= emination, distribution, copying, or storage of this message or any attachm= ent is strictly prohibited. From despres.remi@laposte.net Tue Apr 10 09:02:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBC721F85C7 for ; Tue, 10 Apr 2012 09:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU9p+nNfrtSn for ; Tue, 10 Apr 2012 09:02:39 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4021F860B for ; Tue, 10 Apr 2012 09:02:38 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id wG2c1i00137Y3f403G2c38; Tue, 10 Apr 2012 18:02:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F841F00.1050506@gmail.com> Date: Tue, 10 Apr 2012 18:02:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60440FF2-D9EA-4981-8A75-83F0E62CD3B2@laposte.net> References: <87158690-27BE-4777-B70E-5991DEDEA78C@laposte.net> <4F841F00.1050506@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:02:40 -0000 Hi, Tomek, AFAIK, deciding whether hub-and-spoke selection is implicit by mapping = rules or explicit with a parameter is a more general matter than an = option or sub-optiuon format. I know you can adapt to any choice made by the team in this respect. What remains is that we still don't know whether it is possible to make = it implicitly or not. Th fact that DHCPv6 provisioning hasn't been tested, if confirmed, isn't = a big deal at all IMHO, but the question was worth asking. What is more significant is that nobody seems to be able to say, today, = whether it can be implicit or not, and how it will work. Regards, RD =20 Le 2012-04-10 =E0 13:52, Tomek Mrugalski a =E9crit : > On 10.04.2012 11:51, Wojciech Dec wrote: >> you're apparently confusing matters. There is no need to have a = DHCPv6 >> option, or a million node deployment to test MAP implementations. >> DS-lite is a good example, with implementations and standards track >> before the DHCPv6 option. >=20 >> On 10 April 2012 11:37, R=E9mi Despr=E9s > > wrote: >> The difficulty is that: >> - The MAP-DHCPv6 draft has no parameter to indicate whether the >> ISP-chosen topology is mesh or hub-and-spoke. > Guys, > Please be reasonable. DHCP provisioning is trivial compared to other > MAP/4rd-U aspects. It is not relevant for core aspects of the = technology > comparisons. My advice to people who spend their time on "my solution = is > better than yours" discussions: Forget about DHCP for now and focus on > more important aspects. >=20 > My personal opinion is that DHCP does not matter at this stage. Sure, = it > will be needed eventually, but you can *now* test implementations that > are statically configured. >=20 > Now, to the actual question about hub&spoke. We assumed that CE can > detect on its own if it is running in hub&spoke or mesh topology by > analyzing received rules. See last paragraph of section 4.2 of > mdt-softwire-map-dhcp-option that explain this simple algorithm (if it > can be called an algorithm at all - it is a simple "if" statement). >=20 > Honestly speaking as a co-author of MAP DHCP option draft, I didn't = want > to spend too much time on this *yet*. That is also one of the reasons > why I didn't look at 4rd-U DHCP option yet. It changes too greatly > between revisions. >=20 > Cheers, > Tomek > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Tue Apr 10 09:28:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A567011E8102 for ; Tue, 10 Apr 2012 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJxsru3IITXg for ; Tue, 10 Apr 2012 09:28:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1EF11E80BE for ; Tue, 10 Apr 2012 09:28:39 -0700 (PDT) Received: by iazz13 with SMTP id z13so9155386iaz.31 for ; Tue, 10 Apr 2012 09:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=slXP42SM31ZEEfhVE/TXdEiZXxe9NKx4IiMRzUAOCb8=; b=OzOOizKp7SiLLwc80F7JtpCU3jT7BkdRVOdBBICerkXz6tw5Cx6wrrX6POPD1IiuvX TrQt1149grssv/nQCAnCx5/IqT/Ioh2Xn0P7PZ/x5cAudpGBMPiTfwWGHUnLS+NzA36b rz0LQGoOGqFdREb2Lz3K1xgyd2cmreInT4EVa/bt/OaPirrVYRHjxCjPhqtXf9jXVXeq bIRMoVcpE3agqNBZ+snu42c1NTREsbxxZPQ0sHlXHAn9GCyBwi4TwRISRWWYxU6gtUAI OSyCQzmSKtgRBOVyCPMuwnp8dm58PpzhXCw7AnL2f6UQBwPaQC5yOg1TWQ5qKOfb4mOd pdiw== MIME-Version: 1.0 Received: by 10.50.189.129 with SMTP id gi1mr3091874igc.16.1334075318601; Tue, 10 Apr 2012 09:28:38 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 10 Apr 2012 09:28:38 -0700 (PDT) In-Reply-To: <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> Date: Tue, 10 Apr 2012 11:28:38 -0500 Message-ID: From: Behcet Sarikaya To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires , "softwire-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:28:39 -0000 > I'm getting concerned that the working group is losing sight of the very = reason why we participate to the IETF; to promote good standards, not to fi= ght endlessly about which of the two or three solutions we have on the tabl= e (and that are 99% identical) is more "pure". Standardizing is about findi= ng common ground, not about ego, fighting for whose name is on the draft, c= haracter assassination, using disparaging language, threatening appeals, bo= ycotting, or ballot stuffing. +1. Why don't we ask Remi and Ole to come together and come up with a "unified" solution and do that in one week? They both leave in Europe and can even arrange f2f meetings. Behcet From wdec.ietf@gmail.com Tue Apr 10 09:54:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232E421F8661 for ; Tue, 10 Apr 2012 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEKmuHR+ISjQ for ; Tue, 10 Apr 2012 09:54:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5787021F8688 for ; Tue, 10 Apr 2012 09:54:04 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4286qcs.31 for ; Tue, 10 Apr 2012 09:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xCYjlXU8J+d9Q8ybeu2vSUY32TUkVzG5hSRZ3UKzXbI=; b=L98WNHd9XN8RtH2AjuVsbTxX81PjqpjWbf+YfMUg73S7P1gPYz4olavdrsv/YU3JNl ZjL+LNSwKKPj6T7uKxhy5bcvDdYT62b57Vi1syRHai1NkGbM/oJDuCNfZH7RJomYSdsw +o+pCwtzkB7JSR1blrmSZzfjADdIdu+8/uS4FmpH9hxX8f7rYqONIT4S5GRaN5RSm/Zv SOf8dR0pgNBEJ56DT1WRNZZ6cmc3ZtX3bimdyTwppBcwz804NXfXGwJGnhZUQnWnvfhp 4xFOhmXJAYM6tIyyh+EknLO6TpRkURIYriQXA2tVclLj+Mu1hoF8gK7VMdfWwMknVQnY vsKQ== MIME-Version: 1.0 Received: by 10.224.179.201 with SMTP id br9mr15576981qab.34.1334076841165; Tue, 10 Apr 2012 09:54:01 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Tue, 10 Apr 2012 09:54:01 -0700 (PDT) In-Reply-To: References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> Date: Tue, 10 Apr 2012 18:54:01 +0200 Message-ID: From: Wojciech Dec To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf30334fd938850804bd55f88b Cc: softwires , "softwire-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:54:10 -0000 --20cf30334fd938850804bd55f88b Content-Type: text/plain; charset=ISO-8859-1 On 10 April 2012 18:28, Behcet Sarikaya wrote: > > I'm getting concerned that the working group is losing sight of the very > reason why we participate to the IETF; to promote good standards, not to > fight endlessly about which of the two or three solutions we have on the > table (and that are 99% identical) is more "pure". Standardizing is about > finding common ground, not about ego, fighting for whose name is on the > draft, character assassination, using disparaging language, threatening > appeals, boycotting, or ballot stuffing. > > > +1. > > Why don't we ask Remi and Ole to come together and come up with a > "unified" solution and do that in one week? > > They both leave in Europe and can even arrange f2f meetings. > -1 That, at best will only get a solution that truly nobody understands. We need solutions that work, solve problems and can get into products in a timely manner, not an endless stream of rehashed "unified" drafts. -Woj. > Behcet > --20cf30334fd938850804bd55f88b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 10 April 2012 18:28, Behcet Sarikaya = <sarikaya201= 2@gmail.com> wrote:
> I'm getting concerned that the working group is = losing sight of the very reason why we participate to the IETF; to promote = good standards, not to fight endlessly about which of the two or three solu= tions we have on the table (and that are 99% identical) is more "pure&= quot;. Standardizing is about finding common ground, not about ego, fightin= g for whose name is on the draft, character assassination, using disparagin= g language, threatening appeals, boycotting, or ballot stuffing.


+1.

Why don't we ask Remi and Ole to come together and come up with a
"unified" solution and do that in one week?

They both leave in Europe and can even arrange f2f meetings.

-1
That, at best will only get a solution that truly nobody = understands. We need solutions that work, solve problems and can get into p= roducts in a timely manner, not an endless stream of rehashed "unified= " drafts.

-Woj.



Behcet

--20cf30334fd938850804bd55f88b-- From sarikaya2012@gmail.com Tue Apr 10 10:10:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E911E80E8 for ; Tue, 10 Apr 2012 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvupcAj-+rQb for ; Tue, 10 Apr 2012 10:10:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65DE111E80DF for ; Tue, 10 Apr 2012 10:10:50 -0700 (PDT) Received: by iazz13 with SMTP id z13so25639iaz.31 for ; Tue, 10 Apr 2012 10:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=kqzAISgBmEUbmFj17qcfEhaJ+0Hqf8wjslfGJdS+RUg=; b=vf6f4RdwSyvUtgIV8jqbAyNNW3gl79bjhuTPg5iHFEBYi4yCy7/S2zavnyv9wuvAqi zREbqPmZbs98JQ3o7rcxohor+aL87XZnEnOZxfVOe52t+v6/4GLgi/4SMeE/Tsw+MWEA JYnQzWt+GDzkxhORKtFsJJePfnlV7ZyZHYAtu3xpOMj8wxEN5cOK/VhUJMpJpx04jecV kNIVS1yLbFklY+9xWTdAh5/ZH/IOQZif7FgPUPsrzldwww4gbYWXvVpNfCgOxh48rDur QGabPfbQe4gkSkV+c9SvYXUf0Z4GyVmpUHBueH5wV8ksCmHau9fpCai8FG4TaXtLhij+ XA3g== MIME-Version: 1.0 Received: by 10.50.159.202 with SMTP id xe10mr3149813igb.66.1334077849983; Tue, 10 Apr 2012 10:10:49 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 10 Apr 2012 10:10:49 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 12:10:49 -0500 Message-ID: From: Behcet Sarikaya To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:10:54 -0000 Hi Maoke, Thank you for your efforts in technical details of one specific proposal on the table. However, I for one think that probably it is time to concentrate on commonalities rather than the differences. As Alain indicated, these proposals do have a lot of common points. Why don't (whoever) write a draft putting together all the common points concentrating on CE to BR and abstracting out BIH, XLAT, etc.? Such a draft can be of great value at this point, I think. Regards, Behcet On Tue, Apr 10, 2012 at 4:53 AM, Maoke wrote: > hi all, > > i made an internet-draft discussing the semantics issue of 4rd-U. comment= s, > recommendations, technical discussions are welcome. > > http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 > > thanks and regards, > maoke > > ---------- Forwarded message ---------- > From: > Date: 2012/4/10 > Subject: New Version Notification for > draft-chen-softwire-4rd-u-comment-00.txt > To: fibrib@gmail.com > > > A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been > successfully submitted by Maoke Chen and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-chen-softwire-4rd-u-comment > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 A Commentary on 4rd-U Architecture and Semanti= cs > Creation date: =A0 2012-04-10 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 19 > > Abstract: > =A0 4rd-U is proposed as an effort of unifying encapsulation and double > =A0 translation solutions for the softwire of IPv4 over IPv6 domain. > =A0 This attempt introduces new behaviors in the Internet transition > =A0 architecture as well as semantics other than that of well-known > =A0 Internet protocols. =A0This documents provides a commentary on the > =A0 semantic changes and their impacts. > > > > > The IETF Secretariat > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From akaliwod@cisco.com Tue Apr 10 10:36:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587AF21F85CC for ; Tue, 10 Apr 2012 10:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5xr73UDOsqm for ; Tue, 10 Apr 2012 10:36:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 667CA21F851E for ; Tue, 10 Apr 2012 10:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2068; q=dns/txt; s=iport; t=1334079384; x=1335288984; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=qumIxqsrnaMTp19EdTuE++SGY5u3WgEzYet20UC9qKo=; b=Il7+1QzIX+45oNFZiYJruf9zBpsbaesh9Dr49/kLHzkinEJemokGMdvN qHnOkHyS9US+1yi2u+kOi8qFqYe2Ks4utfvt0SIe5MKpkRdA0JYBjaRe6 CiLfl8AgKPRJ8wTduCgqZSjTRY0ywrvZNe98KY3z0dw912pZ4CaH4DgrQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGNuhE+tJV2c/2dsb2JhbABEuSuBB4IJAQEBBBIBHQo0CwwGAQgOFAYYB1cBBAEaEweHbJpwoECPfmMEiFqbX4FpgwU X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="70528869" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 10 Apr 2012 17:36:23 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3AHaNiZ024262; Tue, 10 Apr 2012 17:36:23 GMT Received: from xmb-rcd-102.cisco.com ([72.163.62.144]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 12:36:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 12:36:12 -0500 Message-ID: <4BA1E714C21CFA4990B50B4A56DB12A40769D44C@XMB-RCD-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0Sp+DEKHPhzCIgTeeucayZuFOhbgEmB5EQ From: "Arkadiusz Kaliwoda (akaliwod)" To: "Alain Durand" , X-OriginalArrivalTime: 10 Apr 2012 17:36:13.0932 (UTC) FILETIME=[6D191AC0:01CD1740] Cc: int-ads@tools.ietf.org, Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:36:25 -0000 -----Original Message----- Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a whole) and 4rd-U. We got very strong feedback that we needed to select one solution to cover that full stateless case, not two, and that we should make this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ------------------------------------------------------------------------ ---- Arkadiusz Kaliwoda, Cisco, YES ------------------------------------------------------------------------ ---- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? ------------------------------------------------------------------------ ------ Arkadiusz Kaliwoda, Cisco, MAP ------------------------------------------------------------------------ ------ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Tina.Tsou.Zouting@huawei.com Tue Apr 10 11:48:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4911E8133 for ; Tue, 10 Apr 2012 11:48:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzjpRg2Hu6Xr for ; Tue, 10 Apr 2012 11:48:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38F11E80B8 for ; Tue, 10 Apr 2012 11:48:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC58388; Tue, 10 Apr 2012 14:48:32 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 11:46:32 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 11:46:35 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 11 Apr 2012 02:46:27 +0800 From: Tina TSOU To: "" Thread-Topic: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt Thread-Index: AQHNFwALtKacIc/PMk+3LYQ8lS1R4JaTxaOAgACg1Ek= Date: Tue, 10 Apr 2012 18:46:27 +0000 Message-ID: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:48:34 -0000 Sent from my iPad On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" wr= ote: > Hi Maoke, >=20 > Thank you for your efforts in technical details of one specific > proposal on the table. >=20 > However, I for one think that probably it is time to concentrate on > commonalities rather than the differences. As Alain indicated, these > proposals do have a lot of common points. >=20 > Why don't (whoever) write a draft putting together all the common > points concentrating on CE to BR and abstracting out BIH, XLAT, etc.? > Such a draft can be of great value at this point, I think. That's MAP-D document. >=20 > Regards, >=20 > Behcet >=20 > On Tue, Apr 10, 2012 at 4:53 AM, Maoke wrote: >> hi all, >>=20 >> i made an internet-draft discussing the semantics issue of 4rd-U. commen= ts, >> recommendations, technical discussions are welcome. >>=20 >> http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 >>=20 >> thanks and regards, >> maoke >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: 2012/4/10 >> Subject: New Version Notification for >> draft-chen-softwire-4rd-u-comment-00.txt >> To: fibrib@gmail.com >>=20 >>=20 >> A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been >> successfully submitted by Maoke Chen and posted to the IETF repository. >>=20 >> Filename: draft-chen-softwire-4rd-u-comment >> Revision: 00 >> Title: A Commentary on 4rd-U Architecture and Semantics >> Creation date: 2012-04-10 >> WG ID: Individual Submission >> Number of pages: 19 >>=20 >> Abstract: >> 4rd-U is proposed as an effort of unifying encapsulation and double >> translation solutions for the softwire of IPv4 over IPv6 domain. >> This attempt introduces new behaviors in the Internet transition >> architecture as well as semantics other than that of well-known >> Internet protocols. This documents provides a commentary on the >> semantic changes and their impacts. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jan@go6.si Tue Apr 10 12:55:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44B411E8144 for ; Tue, 10 Apr 2012 12:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKrr+MtixN04 for ; Tue, 10 Apr 2012 12:55:01 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2697F11E814A for ; Tue, 10 Apr 2012 12:55:01 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2a00:ee0:3:4a00:749f:f8af:23d4:17cc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 6BD2622B4069; Tue, 10 Apr 2012 21:54:57 +0200 (CEST) Message-ID: <4F849017.9080901@go6.si> Date: Tue, 10 Apr 2012 21:55:03 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Fuyu (Eleven)" References: <4F83E358.1090409@go6.si> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:55:01 -0000 On 4/10/12 10:01 AM, Fuyu (Eleven) wrote: > Hi Jan, > > ISPs can't deploy MAP-E/T and use the two mechanism to transmit IPv4 > traffic in their network at the same time. So I aggree with Gang that > MAP-E and MAP-T should be treated as separate solutions. Dear Fuyu. Please read my message again and try to parse it correctly. What you understood is not what I said. Cheers, Jan Zorz From jan@go6.si Tue Apr 10 12:56:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1611E814C for ; Tue, 10 Apr 2012 12:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chF0nTG-7aHM for ; Tue, 10 Apr 2012 12:56:21 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7711E8144 for ; Tue, 10 Apr 2012 12:56:21 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 1D96922B4069 for ; Tue, 10 Apr 2012 21:56:19 +0200 (CEST) Message-ID: <4F849068.5050505@go6.si> Date: Tue, 10 Apr 2012 21:56:24 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> In-Reply-To: <674BB7AB-1E6F-4961-8755-3CC8C521BC0D@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Call for restrain and reason on the mailing list X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:56:22 -0000 On 4/10/12 2:18 PM, Alain Durand wrote: > Remi, Woj: > > We have heard a number of times that you both think the "other" > solution is broken. Technical points have been made, no need for > personal attacks. > > I'm getting concerned that the working group is losing sight of the > very reason why we participate to the IETF; to promote good > standards, not to fight endlessly about which of the two or three > solutions we have on the table (and that are 99% identical) is more > "pure". Standardizing is about finding common ground, not about ego, > fighting for whose name is on the draft, character assassination, > using disparaging language, threatening appeals, boycotting, or > ballot stuffing. +1 Too much repeating noise on the ml. lately :) Cheers, Jan From yiu_lee@cable.comcast.com Tue Apr 10 12:57:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0221F8539 for ; Tue, 10 Apr 2012 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.258 X-Spam-Level: X-Spam-Status: No, score=-100.258 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEvta+5eRnjQ for ; Tue, 10 Apr 2012 12:57:32 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id E259221F84B8 for ; Tue, 10 Apr 2012 12:57:31 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.8800732; Tue, 10 Apr 2012 15:50:49 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 15:56:48 -0400 From: "Lee, Yiu" To: Simon Perreault , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E&T vs 4rd-U Thread-Index: AQHNF1QnradQYZyGG0aCbdQ270mJWA== Date: Tue, 10 Apr 2012 19:57:26 +0000 Message-ID: In-Reply-To: <4F8430A5.2010108@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416918245_1649831" MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:57:32 -0000 --B_3416918245_1649831 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1. If the WG decided to standardize both MAP-T and MAT-E, there would be two standards. Operators still needed to make the choice between them. On 4/10/12 9:07 AM, "Simon Perreault" wrote: >On 2012-04-10 04:21, GangChen wrote: >>> I see MAP-E/T combo as one solution, where you "turn the knob" when >>> implementing it - you choose encap *or* translation mode. >> >> You could combo 100 solultions as you want. However, that is still >> seems to me separated solutions. > >+1 > > From a deployment point of view, it makes no sense to treat them as >one. You would need to evaluate T and E separately for *everything*: >routers, provisioning, customer equipment, accounting, etc. So it makes >no sense to treat T and E as a single protocol. > >Simon >-- >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3416918245_1649831 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBThlR1L fL9fZZjLswOdjfd9Hy23RTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MTAxOTU3MjRaMA0GCSqGSIb3DQEBAQUABIIBAEAtibPIPzjX0jqJIuFGre0M iLvAqnyU0L5XwB8MEE+5GF7mgomYAT0NYwNwOOY4VehJcmPBIrTrP+ObY8w/7an8GeMN+AN0 Sokxh/HpE0N8LtS4ZQwpnMOx+pxySPQIkk9CwpPPPzOL+UaLUPN0zoHYoO77vq37jGuooDyd wVi9OcplkqUGhaPYtWC1qdlSJP0uFDbkrWCYxIpSpxWxY9P4B+kgqvv5jMekubAqoOIZTxr7 e76r1GqW9805+AxpELwGjrp1fVGIzDqc//kqm54FyC69I86x+qfR2Cys8GPX+MfsLiUVFYmP DWJt0a9uyAq2yfYz03L9dakQg9beksI= --B_3416918245_1649831-- From Tetsuya.Murakami@ipinfusion.com Tue Apr 10 13:51:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EE11E8148 for ; Tue, 10 Apr 2012 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.483 X-Spam-Level: X-Spam-Status: No, score=-4.483 tagged_above=-999 required=5 tests=[AWL=1.815, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbgFJhebL3QL for ; Tue, 10 Apr 2012 13:51:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61311E8147 for ; Tue, 10 Apr 2012 13:51:08 -0700 (PDT) Received: from mail158-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 20:51:03 +0000 Received: from mail158-tx2 (localhost [127.0.0.1]) by mail158-tx2-R.bigfish.com (Postfix) with ESMTP id 2A87840315; Tue, 10 Apr 2012 20:51:03 +0000 (UTC) X-SpamScore: 2 X-BigFish: PS2(zzc85dh4015Izz1202hzz8275bhz2fh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail158-tx2: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail158-tx2 (localhost.localdomain [127.0.0.1]) by mail158-tx2 (MessageSwitch) id 1334091061210884_549; Tue, 10 Apr 2012 20:51:01 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.246]) by mail158-tx2.bigfish.com (Postfix) with ESMTP id 2A85D100116; Tue, 10 Apr 2012 20:51:01 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 20:50:56 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.250]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0135.002; Tue, 10 Apr 2012 20:50:42 +0000 From: Tetsuya Murakami To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] MAP-E&T vs 4rd-U Thread-Index: AQHNF1uX+S06AIhTcEWm71zAEvCT7g== Date: Tue, 10 Apr 2012 20:50:42 +0000 Message-ID: <4C442912-71FB-4041-BB6B-7BFBC1A0FAF7@ipinfusion.com> References: <18AF6BEE-BF2B-47E7-9720-F096175AF295@laposte.net> <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> In-Reply-To: <4941DF1A-0AE7-461A-B9EF-5C8FB0D67FF3@laposte.net> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_4C44291271FB4041BB6B7BFBC1A0FAF7ipinfusioncom_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT002.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT002.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: softwires , Softwire Chairs Subject: Re: [Softwires] MAP-E&T vs 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:51:09 -0000 --_000_4C44291271FB4041BB6B7BFBC1A0FAF7ipinfusioncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Remi, What more, given that 4rd-U needs to be combined with BIH, the claim of it = offering some "unified" solution, different operationally from MAP is bogus= . If anything this combination and the fact that there is a IPv6.1 being cr= eated actually makes 4rd-u operations a major challenge in comparison to wh= at we know of as IPinIP tunnelling or NAT64 with MAP. The need for an IPv6 6.1 is AFAIK an invention of yours, not something need= ed by 4rd-U. 4rd-u does change the basic semantics of fields in IPv6, ??? (If you would have evidence that everything isn't backward compatible, plea= se share this information.) For example, the existing implementation for processing the fragment header= is not working on your definition of the fragment header. MAP-E/T does not= require any change of existing process of IPv6 header. Thanks, Tetsuya Murakami --_000_4C44291271FB4041BB6B7BFBC1A0FAF7ipinfusioncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3688223EE0DDB14A8D9A942A52D76639@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Remi,

What more, given that 4rd-U needs to be combined with BIH, the claim o= f it offering some "unified" solution, different operationally fr= om MAP is bogus. If anything this combination and the fact that there is a = IPv6.1 being created actually makes 4rd-u operations a major challenge in comparison to what we know of as IPinIP tu= nnelling or NAT64 with MAP.

The need for an IPv6 6.1 is AFAIK an invention of yours, not something= needed by 4rd-U.

 4rd-u does change the basic semantics of fields in IPv6,

???
(If you would have evidence that everything isn't backward compatible,= please share this information.)

For example, the existing implementation for processing the fragment h= eader is not working on your definition of the fragment header. MAP-E/T doe= s not require any change of existing process of IPv6 header.

Thanks,
Tetsuya Murakami

--_000_4C44291271FB4041BB6B7BFBC1A0FAF7ipinfusioncom_-- From yiu_lee@cable.comcast.com Tue Apr 10 17:02:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE56611E80DE for ; Tue, 10 Apr 2012 17:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.082 X-Spam-Level: X-Spam-Status: No, score=-100.082 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P757m9XGJ2W7 for ; Tue, 10 Apr 2012 17:02:13 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4011E8081 for ; Tue, 10 Apr 2012 17:02:13 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12891337; Tue, 10 Apr 2012 17:49:07 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 20:02:09 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Tomek Mrugalski Thread-Topic: [Softwires] Provisioning Hub-and-spoke in MAP - How? Thread-Index: AQHNF3ZV5v9rignhBUyvLUEj49S/og== Date: Wed, 11 Apr 2012 00:02:08 +0000 Message-ID: In-Reply-To: <60440FF2-D9EA-4981-8A75-83F0E62CD3B2@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416932926_469082" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:02:14 -0000 --B_3416932926_469082 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Remi, I think Woj has answered the question that MAP-E will require explicit provision. He may not answer very clearly YES or NO, but saying it is durable. IMNO, explicit or implicit is very critical. Implicit is definitely better but it isn't a real concern if we have to provision a parameter. IMHo, we should stop here and don't give other people we are dog-fighting. I think slowly we will build up more support by showing others we are willing to work with others. Thanks, Yiu=20 P.S. I will real Maoke's draft about 4rd-u. On 4/10/12 12:02 PM, "R=E9mi Despr=E9s" wrote: >Hi, Tomek, > >AFAIK, deciding whether hub-and-spoke selection is implicit by mapping >rules or explicit with a parameter is a more general matter than an >option or sub-optiuon format. > >I know you can adapt to any choice made by the team in this respect. > >What remains is that we still don't know whether it is possible to make >it implicitly or not. > >Th fact that DHCPv6 provisioning hasn't been tested, if confirmed, isn't >a big deal at all IMHO, but the question was worth asking. > >What is more significant is that nobody seems to be able to say, today, >whether it can be implicit or not, and how it will work. > >Regards, >RD > > =20 > >Le 2012-04-10 =E0 13:52, Tomek Mrugalski a =E9crit : > >> On 10.04.2012 11:51, Wojciech Dec wrote: >>> you're apparently confusing matters. There is no need to have a DHCPv6 >>> option, or a million node deployment to test MAP implementations. >>> DS-lite is a good example, with implementations and standards track >>> before the DHCPv6 option. >>=20 >>> On 10 April 2012 11:37, R=E9mi Despr=E9s >> > wrote: >>> The difficulty is that: >>> - The MAP-DHCPv6 draft has no parameter to indicate whether the >>> ISP-chosen topology is mesh or hub-and-spoke. >> Guys, >> Please be reasonable. DHCP provisioning is trivial compared to other >> MAP/4rd-U aspects. It is not relevant for core aspects of the technology >> comparisons. My advice to people who spend their time on "my solution is >> better than yours" discussions: Forget about DHCP for now and focus on >> more important aspects. >>=20 >> My personal opinion is that DHCP does not matter at this stage. Sure, it >> will be needed eventually, but you can *now* test implementations that >> are statically configured. >>=20 >> Now, to the actual question about hub&spoke. We assumed that CE can >> detect on its own if it is running in hub&spoke or mesh topology by >> analyzing received rules. See last paragraph of section 4.2 of >> mdt-softwire-map-dhcp-option that explain this simple algorithm (if it >> can be called an algorithm at all - it is a simple "if" statement). >>=20 >> Honestly speaking as a co-author of MAP DHCP option draft, I didn't want >> to spend too much time on this *yet*. That is also one of the reasons >> why I didn't look at 4rd-U DHCP option yet. It changes too greatly >> between revisions. >>=20 >> Cheers, >> Tomek >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3416932926_469082 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQGch9R AG7Kc9mtLudgzdCBo721WzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MTEwMDAyMDVaMA0GCSqGSIb3DQEBAQUABIIBAC/zfDiaP2Gzg2oIf1im+JEN DcWTLH3UfdODS0yUiw4o7Tp+LDFyIrSJ5FrED9P1YwCzcZmnlQOKUKCUrsZq7WW3aOpaSVZc +ZKdll2CkHIahMYF3LkUfIYRiTY7mc6+AlsjST3PBqEwsPkOZcpknZ6UJ43Wmu6yTqWHGOUS qvO3snG6fOADaXsetOM03Gf1SRf6F3yWpIamzO5vErTb7ns4Hrv6fsG+aH59+qYG1nJerZQA HrbpJriTSji07Rjpd9ySNgSbAy12R19KdxWtsujlVJ0aOA+7V3NpyBei36mP1pHDOg+zksTR tMYROBnP0/zu0zNW1iajl/K9hoeSEvQ= --B_3416932926_469082-- From yiu_lee@cable.comcast.com Tue Apr 10 17:18:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ECA21F860E for ; Tue, 10 Apr 2012 17:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.117 X-Spam-Level: X-Spam-Status: No, score=-100.117 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ith9oejzxV41 for ; Tue, 10 Apr 2012 17:18:52 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 618B621F860D for ; Tue, 10 Apr 2012 17:18:52 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12892383; Tue, 10 Apr 2012 18:05:47 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 20:18:47 -0400 From: "Lee, Yiu" To: "Lee, Yiu" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Tomek Mrugalski Thread-Topic: [Softwires] Provisioning Hub-and-spoke in MAP - How? Thread-Index: AQHNF3ipHKTcXIB6Ck24zwSY7FSYkQ== Date: Wed, 11 Apr 2012 00:18:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416933925_553853" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:18:53 -0000 --B_3416933925_553853 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I didn't mean to send this to the ML. I still don't know why it did. I apologize if it offends anybody. Anyway, my position reminds the same. I would like to work with others to improve technology, not arguing for the sake of arguing.=20 Yiu On 4/10/12 8:02 PM, "Lee, Yiu" wrote: >Hi Remi, > >I think Woj has answered the question that MAP-E will require explicit >provision. He may not answer very clearly YES or NO, but saying it is >durable. IMNO, explicit or implicit is very critical. Implicit is >definitely better but it isn't a real concern if we have to provision a >parameter. IMHo, we should stop here and don't give other people we are >dog-fighting. I think slowly we will build up more support by showing >others we are willing to work with others. > >Thanks, >Yiu=20 > >P.S. I will real Maoke's draft about 4rd-u. > > >On 4/10/12 12:02 PM, "R=E9mi Despr=E9s" wrote: > >>Hi, Tomek, >> >>AFAIK, deciding whether hub-and-spoke selection is implicit by mapping >>rules or explicit with a parameter is a more general matter than an >>option or sub-optiuon format. >> >>I know you can adapt to any choice made by the team in this respect. >> >>What remains is that we still don't know whether it is possible to make >>it implicitly or not. >> >>Th fact that DHCPv6 provisioning hasn't been tested, if confirmed, isn't >>a big deal at all IMHO, but the question was worth asking. >> >>What is more significant is that nobody seems to be able to say, today, >>whether it can be implicit or not, and how it will work. >> >>Regards, >>RD >> >> =20 >> >>Le 2012-04-10 =E0 13:52, Tomek Mrugalski a =E9crit : >> >>> On 10.04.2012 11:51, Wojciech Dec wrote: >>>> you're apparently confusing matters. There is no need to have a DHCPv6 >>>> option, or a million node deployment to test MAP implementations. >>>> DS-lite is a good example, with implementations and standards track >>>> before the DHCPv6 option. >>>=20 >>>> On 10 April 2012 11:37, R=E9mi Despr=E9s >>> > wrote: >>>> The difficulty is that: >>>> - The MAP-DHCPv6 draft has no parameter to indicate whether the >>>> ISP-chosen topology is mesh or hub-and-spoke. >>> Guys, >>> Please be reasonable. DHCP provisioning is trivial compared to other >>> MAP/4rd-U aspects. It is not relevant for core aspects of the >>>technology >>> comparisons. My advice to people who spend their time on "my solution >>>is >>> better than yours" discussions: Forget about DHCP for now and focus on >>> more important aspects. >>>=20 >>> My personal opinion is that DHCP does not matter at this stage. Sure, >>>it >>> will be needed eventually, but you can *now* test implementations that >>> are statically configured. >>>=20 >>> Now, to the actual question about hub&spoke. We assumed that CE can >>> detect on its own if it is running in hub&spoke or mesh topology by >>> analyzing received rules. See last paragraph of section 4.2 of >>> mdt-softwire-map-dhcp-option that explain this simple algorithm (if it >>> can be called an algorithm at all - it is a simple "if" statement). >>>=20 >>> Honestly speaking as a co-author of MAP DHCP option draft, I didn't >>>want >>> to spend too much time on this *yet*. That is also one of the reasons >>> why I didn't look at 4rd-U DHCP option yet. It changes too greatly >>> between revisions. >>>=20 >>> Cheers, >>> Tomek >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3416933925_553853 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTZ2s/I 8fLmxEJzPku+pflcFK8UpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MTEwMDE4NDRaMA0GCSqGSIb3DQEBAQUABIIBAD9XdkpzzCvigv97GJwtYTAO H66EdPN8WYMqGBdR3vhOpBXoF4DPLFKzyZ1uy7CV1FHXW+SsT62lzUOiQGEHAWm/eQ+IfSBe 7B3j5fucZG2o8eDK6USLbU/fn02DKqcXBsi2ZnNCMoApAlNv4FV5fE1ftzEwTIphApxCDhKF k/K8VmrgClvOhs1kF63nWV5Js4qDmBPHhxy1DCn1lJxSV1mPzYDltRefaXX/g/8a4+Pioz3n Ibhaz/tli4qPE77nwua5602mOzy+5fjaseOXPDCra7eMej1QDfuO00X6kkIbBqirttnz8Kux bXDcG6qLMaDWeP0LpREl6G8UGxuk3N8= --B_3416933925_553853-- From fibrib@gmail.com Tue Apr 10 20:29:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2311E8096 for ; Tue, 10 Apr 2012 20:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BA9nl1PMDJn for ; Tue, 10 Apr 2012 20:29:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 798F011E8081 for ; Tue, 10 Apr 2012 20:29:49 -0700 (PDT) Received: by qcsq13 with SMTP id q13so361994qcs.31 for ; Tue, 10 Apr 2012 20:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yvSAiDrsvojmic1Hzlh+xbRGhlHXYo9MUnl4RHUdQO8=; b=ucjSxCoQaBP3vwqbVdLnjvbgVGzqmJnKw9O+0MP0u613eRzDPde34v1ACjJFCHq74y mUWlUe/mTS4+dL+UNJTwqdKVDyR9jRvJtDzuZbVnAUZba7jXeLaLii19naPev3a3DTRT 6D2swLG1S4+oYVPY/MHR0kPWZymF9rHqZbvSGDjmna14acLOnHaVFCJjjt25zldEUke2 3nqN1pNvwh7EHPDX5zZ7pvozwZxEoaNq6fWPSLoCU9eudPhYOrVl8STis8cgrrc6uIhx Ze5+l+a86Zg+8/RsMXSLMlhvAvsPBpHOvP+NJ8PM1cLWr3bDxio1lNWf5mxp65C2RIUd JtlQ== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr17694530qao.23.1334114988971; Tue, 10 Apr 2012 20:29:48 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 10 Apr 2012 20:29:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 03:29:48 +0000 Message-ID: From: Maoke To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=20cf3074b41a01d72504bd5edab4 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:29:50 -0000 --20cf3074b41a01d72504bd5edab4 Content-Type: text/plain; charset=ISO-8859-1 hi Yiu, sorry but i just found i missed a technical issue you left in this message. 2012/4/9 Lee, Yiu > > on the other hand, 4rd-u makes a tight coupling between the address > format > and its own header mapping mechanism. this makes an operator unable to > have > different choices of transition mechanism as long as it chooses 4rd-u. > if > you concern the choice of IPv6 transition mechanism, i do recommend > MAP, as > either encapsulation or translation is operatable with MAP address/port > mapping without difficulty. > > [YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupling > address format and header mapping? > tight coupling here, i mean, that 4rd-u header mapping mechanism sometimes depends on features of the address format, like the CNP and the V-octet. for example, it removes the L4 checksum adjustment, this makes the whole system MUST following the addressing with CNP. for the MAP, things are different. boxes are implemented with existing header processing modules but only need to add MAP address mapping module into them. once the operator deploys MAP following its addressing plan paradigm (we are still working on a better guidance for this in the MAP deployment draft), the operator can choose either MAP-T or MAP-E for the header mapping without the need of changing their addressing plan. if the operator find translation is suitable for this part after a certain period of practice on encapsulation, it can switch the mode by informing the CE to change the mode of working (surely sometimes such an action of informing is not easy in practice for, e.g., the home CE subscribers but it is feasible for enterprise networking). another example of de-coupling is translation approach: RFC6052 defines a stateless address mapping while RFC6145 defines the header processing which is usable for both stateless and stateful solutions, both 1:1 case for non-renumbering transition and residual deployment of MAP. implementation does also benefit from the de-coupling. the RFC6145 translation module can directly work with address mapping module of MAP or RFC6052. the MAP address module can work with header processing module of RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T). it doesn't mean the tight coupling doesn't work. like the Burton snowboard, it works fantastically with its own system of bindings, not interchangable for other brands ;-) however, in most of time, we really think interchangability, supported by loose coupling, is preferred. cheers, maoke --20cf3074b41a01d72504bd5edab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Yiu,=A0

sorry but i just found i misse= d a technical issue you left in this message.=A0

2012/4/9 Lee, Yiu <Yiu_Lee@cable.comcast.com>

=A0 =A0on the other hand, 4rd-u makes a tight coupling between t= he address format=A0
=A0 =A0and its own header mapping mechanism.= this makes an operator unable to have=A0
=A0 =A0different choice= s of transition mechanism as long as it chooses 4rd-u. if=A0
=A0 =A0you concern the choice of IPv6 transition mechanism, i do recom= mend MAP, as=A0
=A0 =A0either encapsulation or translation is ope= ratable with MAP address/port=A0
=A0 =A0mapping without difficult= y.=A0

[YL] Sorry for my lack of knowledge. Please explain ho= w MAP isn't coupling address format and header mapping?

tight coupling here, i mean, that 4rd-u header= mapping mechanism sometimes depends on features of the address format, lik= e the CNP and the V-octet. for example, it removes the L4 checksum adjustme= nt, this makes the whole system MUST following the addressing with CNP.=A0<= /div>

for the MAP, things are different. boxes are implemente= d with existing header processing modules but only need to add MAP address = mapping module into them. once the operator deploys MAP following its addre= ssing plan paradigm (we are still working on a better guidance for this in = the MAP deployment draft), the operator can choose either MAP-T or MAP-E fo= r the header mapping without the need of changing their addressing plan. if= the operator find translation is suitable for this part after a certain pe= riod of practice on encapsulation, it can switch the mode by informing the = CE to change the mode of working (surely sometimes such an action of inform= ing is not easy in practice for, e.g., the home CE subscribers but it is fe= asible for enterprise networking). another example of de-coupling is transl= ation approach: RFC6052 defines a stateless address mapping while RFC6145 d= efines the header processing which is usable for both stateless and statefu= l solutions, both 1:1 case for non-renumbering transition and residual depl= oyment of MAP.=A0

implementation does also benefit from the de-coupling. = the RFC6145 translation module can directly work with address mapping modul= e of MAP or RFC6052. the MAP address module can work with header processing= module of RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T)= .=A0

it doesn't mean the tight coupling doesn't work= . like the Burton snowboard, it works fantastically with its own system of = bindings, not interchangable for other brands ;-) however, in most of time,= we really think interchangability, supported by loose coupling, is preferr= ed.=A0
=A0
cheers,
maoke
--20cf3074b41a01d72504bd5edab4-- From chow@zju.edu.cn Tue Apr 10 20:43:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8DE11E80F6 for ; Tue, 10 Apr 2012 20:43:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_HEADER_CTYPE_ONLY=0.56, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_RECV_IP_FROMIP1=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe21vwy8up2r for ; Tue, 10 Apr 2012 20:43:15 -0700 (PDT) Received: from csc.zju.edu.cn (zjuem.zju.edu.cn [210.32.0.5]) by ietfa.amsl.com (Postfix) with SMTP id DCAFC11E809B for ; Tue, 10 Apr 2012 20:43:13 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: X-EMDG-VER: 2009-11-28 Received: (eyou anti_spam gateway 3.0); Wed, 11 Apr 2012 11:43:09 +0800 Message-ID: <534115789.32054@csc.zju.edu.cn> Received: from 10.10.8.51 by 10.10.8.55 with SMTP; Wed, 11 Apr 2012 11:43:09 +0800 Received: (eyou send program); Wed, 11 Apr 2012 11:43:09 +0800 Received: from 10.15.108.125 by mail.zju.edu.cn with HTTP; Wed, 11 Apr 2012 11:43:09 +0800 X-WebMAIL-MUA: [10.15.108.125] From: "chow" To: adurand@juniper.net Date: Wed, 11 Apr 2012 11:43:09 +0800 Message-ID: X-Priority: 3 Content-Type: multipart/alternative; boundary="----=_1334115789_30403.html" Cc: softwires@ietf.org, int-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chow List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:43:15 -0000 ------=_1334115789_30403.html Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IERlYXIgU29mdHdpcmUgd2cgbWVtYmVyczoNCiA9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBRdWVzdGlv biAxOiBEbyB5b3UgYWdyZWUgdGhhdCB0aGUgd2cgc2hvdWxkIHB1dCBFSVRIRVIgNHJkLVUg T1IgTUFQIChhcyBhIHdob2xlKSBvbiB0aGUgc3RhbmRhcmQgdHJhY2ssDQogdGhlIG90aGVy IGJlaW5nIHB1Ymxpc2hlZCBhcyBleHBlcmltZW50YWwgb3IgaW5mb3JtYXRpb25hbC4NCiBB bnN3ZXJpbmcgWUVTIHRvIHRoaXMgcXVlc3Rpb24gbWVhbnMgeW91IGFncmVlIHdlIGNhbm5v dCBwdWJsaXNoIGJvdGggYXMgc3RhbmRhcmQgdHJhY2suDQogQW5zd2VyaW5nIE5PIHRvIHRo aXMgcXVlc3Rpb24gbWVhbnMgeW91IHdhbnQgdG8gc2VlIGJvdGggYWR2YW5jZSBvbiB0aGUg c3RhbmRhcmQgdHJhY2suDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2hvdywgWmhlamlh bmcgVW5pdmVyc2l0eSwgWUVTDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KIFF1ZXN0aW9ucyAyOiBXaGljaCBvbmUgZG8geW91IHdhbnQgdG8gc2VlIHBs YWNlZCBvbiB0aGUgU3RhbmRhcmRzIFRyYWNrOg0KIDRyZC1VIG9yIE1BUD8NCiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCmNob3csIFpoZWppYW5nIFVuaXZlcnNpdHksIE1BUA0KIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFBsZWFzZSBmaWxs IG91dCB0aGUgZm9sbG93aW5nIGZvcm0gYW5kIHJlcGx5IHRvIHRoZSBsaXN0DQogYnkgV2Vk bmVzZGF5IDQvMTAgNXBtIEVEVC4NCiBOb3RlOiBVc2UgdGhpcyB0aHJlYWQgT05MWSBmb3Ig ZXhwcmVzc2luZyB5b3VyIHN1cHBvcnQgdG8NCiBvbmUgT1IgdGhlIG90aGVyLCBhbmQgcmVk aXJlY3QgYW55IGRpc2N1c3Npb25zIHRvIG90aGVyIHRocmVhZHMuDQogVGhhdCB3b3VsZCBo ZWxwIHVwIGdhdWdlIGNvbnNlbnN1cy4NCiBBbGFpbiYgIFlvbmcuDQogX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiBTb2Z0d2lyZXMgbWFpbGlu ZyBsaXN0DQogU29mdHdpcmVzQGlldGYub3JnDQogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KCg== ------=_1334115789_30403.html Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGRpdj4mbmJzcDtEZWFyIFNvZnR3aXJlIHdnIG1lbWJlcnM6PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4mbmJzcDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2Rpdj48ZGl2PiZuYnNwO1F1ZXN0aW9u IDE6IERvIHlvdSBhZ3JlZSB0aGF0IHRoZSB3ZyBzaG91bGQgcHV0IEVJVEhFUiA0cmQtVSBP UiBNQVAgKGFzIGEgd2hvbGUpIG9uIHRoZSBzdGFuZGFyZCB0cmFjayw8L2Rpdj48ZGl2PiZu YnNwO3RoZSBvdGhlciBiZWluZyBwdWJsaXNoZWQgYXMgZXhwZXJpbWVudGFsIG9yIGluZm9y bWF0aW9uYWwuPC9kaXY+PGRpdj4mbmJzcDtBbnN3ZXJpbmcgWUVTIHRvIHRoaXMgcXVlc3Rp b24gbWVhbnMgeW91IGFncmVlIHdlIGNhbm5vdCBwdWJsaXNoIGJvdGggYXMgc3RhbmRhcmQg dHJhY2suPC9kaXY+PGRpdj4mbmJzcDtBbnN3ZXJpbmcgTk8gdG8gdGhpcyBxdWVzdGlvbiBt ZWFucyB5b3Ugd2FudCB0byBzZWUgYm90aCBhZHZhbmNlIG9uIHRoZSBzdGFuZGFyZCB0cmFj ay48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L2Rpdj48ZGl2PmNob3csIFpoZWppYW5nIFVuaXZlcnNpdHksIFlFUzwvZGl2PjxkaXY+ Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+Jm5ic3A7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4mbmJzcDtRdWVzdGlvbnMgMjogV2hpY2ggb25lIGRvIHlvdSB3YW50IHRvIHNl ZSBwbGFjZWQgb24gdGhlIFN0YW5kYXJkcyBUcmFjazo8L2Rpdj48ZGl2PiZuYnNwOzRyZC1V IG9yIE1BUD88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvZGl2PjxkaXY+Y2hvdywgWmhlamlhbmcgVW5pdmVyc2l0eSwgTUFQPC9k aXY+PGRpdj4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PiZuYnNwOz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7 UGxlYXNlIGZpbGwgb3V0IHRoZSBmb2xsb3dpbmcgZm9ybSBhbmQgcmVwbHkgdG8gdGhlIGxp c3Q8L2Rpdj48ZGl2PiZuYnNwO2J5IFdlZG5lc2RheSA0LzEwIDVwbSBFRFQuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj4mbmJzcDtOb3RlOiBVc2UgdGhpcyB0aHJlYWQgT05MWSBmb3Ig ZXhwcmVzc2luZyB5b3VyIHN1cHBvcnQgdG88L2Rpdj48ZGl2PiZuYnNwO29uZSBPUiB0aGUg b3RoZXIsIGFuZCByZWRpcmVjdCBhbnkgZGlzY3Vzc2lvbnMgdG8gb3RoZXIgdGhyZWFkcy48 L2Rpdj48ZGl2PiZuYnNwO1RoYXQgd291bGQgaGVscCB1cCBnYXVnZSBjb25zZW5zdXMuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDtBbGFpbiZhbXA7ICZuYnNwO1lvbmcuPC9k aXY+PGRpdj4mbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvZGl2PjxkaXY+Jm5ic3A7U29mdHdpcmVzIG1haWxpbmcgbGlzdDwvZGl2Pjxk aXY+Jm5ic3A7U29mdHdpcmVzQGlldGYub3JnPC9kaXY+PGRpdj4mbmJzcDtodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvZGl2PjxkaXY+PGJyPjwv ZGl2Pg== ------=_1334115789_30403.html-- From fibrib@gmail.com Tue Apr 10 21:28:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435B711E809B for ; Tue, 10 Apr 2012 21:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWaOHeiFL3h9 for ; Tue, 10 Apr 2012 21:28:55 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9298D11E8079 for ; Tue, 10 Apr 2012 21:28:53 -0700 (PDT) Received: by qafi31 with SMTP id i31so3237949qaf.15 for ; Tue, 10 Apr 2012 21:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TsDptgaPBTPpA2e5FHNjv05m7VZtjNeHcb3jyC5Y8eI=; b=UUJrmSHvLT7eZ2dHzCSQ3AeKAmVZO7VP50PYsD09cOyHHIXQkkqYbB3Byci1jsvATj oyUWgVgGpfIVFoetKh/abUVGJrqknf/E4wEAojtk+a9ZDBQm5SUZ81YrdV1EF5iOEqxX 86HLOFb3MRkY/7XeyFoxdQ/l4ooBOAUA9WUxjS1rRM+WxFX5X+10NLNqbbfzSE/LJsEM nu8FYMXZrCBpDWxgWQ1mfSopmKvAEyFFR93WBEi4DPJh8ryH90oy0VBBOK0Omq5OWS9i PDmt6q2Vq4eoZuxbNoJQYcC/yls+s/XOnhPtdWpY9RpO26NrkC0QsyK6WV19LTdNo6kM ZQrQ== MIME-Version: 1.0 Received: by 10.224.211.72 with SMTP id gn8mr18116049qab.10.1334118533116; Tue, 10 Apr 2012 21:28:53 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 10 Apr 2012 21:28:53 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 04:28:53 +0000 Message-ID: From: Maoke To: "" Content-Type: multipart/alternative; boundary=20cf300fac9741340d04bd5fad36 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:28:56 -0000 --20cf300fac9741340d04bd5fad36 Content-Type: text/plain; charset=ISO-8859-1 hi Behcet, 2012/4/10 Tina TSOU > > > Sent from my iPad > > On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" > wrote: > > > Hi Maoke, > > > > Thank you for your efforts in technical details of one specific > > proposal on the table. > > > > However, I for one think that probably it is time to concentrate on > > commonalities rather than the differences. As Alain indicated, these > > proposals do have a lot of common points. > > > that proposal is basically of a response to people's call for "describing technical concerns in mind" about 4rd-U. commonality and difference is the two sides of the same coin. if we don't understand what makes them exactly different, we are also hard to understand how common they are. this document is purposed in sharing such an understanding and therefore it focuses only on the essential concerns -- the concerns regarding architecture and protocol semantics. > > Why don't (whoever) write a draft putting together all the common > > points concentrating on CE to BR and abstracting out BIH, XLAT, etc.? > > Such a draft can be of great value at this point, I think. > That's MAP-D document. > > > yes. as Tina points out, MAP deployment draft that we are working on plays the role of clarifying the common deployment considerations with MAP series. thanks! best, maoke > > Regards, > > > > Behcet > > > > --20cf300fac9741340d04bd5fad36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Behcet,=A0

2012/4/10 Tina TSOU <Tina.Tsou.Zo= uting@huawei.com>


Sent from my iPad

On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

> Hi Maoke,
>
> Thank you for your efforts in technical details of one specific
> proposal on the table.
>
> However, I for one think that probably it is time to concentrate on > commonalities rather than the differences. As Alain indicated, these > proposals do have a lot of common points.
>

that proposal is basically o= f a response to people's call for "describing technical concerns i= n mind" about 4rd-U. commonality and difference is the two sides of th= e same coin. if we don't understand what makes them exactly different, = we are also hard to understand how common they are. this document is purpos= ed in sharing such an understanding and therefore it focuses only on the es= sential concerns -- the concerns regarding architecture and protocol semant= ics.=A0
=A0
> Why don't (whoever) write a draft putting together all the common<= br> > points concentrating on CE to BR and abstracting out BIH, XLAT, etc.?<= br> > Such a draft can be of great value at this point, I think.
That's MAP-D document.
>

yes. as Tina points out, MAP deployment draft that we are working on plays= the role of clarifying the common deployment considerations with MAP serie= s. thanks!

best,
maoke
=A0
> Regards,
>
> Behcet
>
=A0
--20cf300fac9741340d04bd5fad36-- From satoru.matsushima@gmail.com Wed Apr 11 00:37:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5521521F858F for ; Wed, 11 Apr 2012 00:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS9Ge7OIWyDk for ; Wed, 11 Apr 2012 00:37:31 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id AF66A21F851E for ; Wed, 11 Apr 2012 00:37:31 -0700 (PDT) Received: by dady13 with SMTP id y13so1126913dad.27 for ; Wed, 11 Apr 2012 00:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zXpibbtPYz5l3cOhmBPjBPWRxjUpgvRke4UVMeVohBs=; b=r8LKCfCyKHt+Mvc0SzRuGNAxUYlshlGEpwy3EQTm3NUxn1qQ72TVgyvzOwfS9fEQBK A7qK6+xN8SegzO9dxY5PfKoaU/OWCRhdDFFUfkJi752OWRh9GNeRLnhS+hG0eug5WqZS KU9DfDVIw/SCMg5cVjiiDcGmMdg0z2QMzZUg3HHW47WThiRUyuUyEcz1eV75MW61na4K MTvJ+cFtTBGhMLAz2LZx3sKZQ0DGkcsfMotVDAwcdPi9W8iD2bIisUivGvH2PFtcHp8e +w7hQlTdlLDSGxzbD4+UGKTil2BCs79gQuDgmvfDm8mr72+yKUXAZgIXITQhX+uXQKHs DlrQ== Received: by 10.68.225.132 with SMTP id rk4mr12987011pbc.157.1334129851520; Wed, 11 Apr 2012 00:37:31 -0700 (PDT) Received: from [10.201.82.237] ([202.45.12.141]) by mx.google.com with ESMTPS id w10sm2159789pbk.30.2012.04.11.00.37.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 00:37:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 11 Apr 2012 16:37:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7E7806B6-673C-4B4E-8519-5A506FF00570@gmail.com> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> To: Maoke X-Mailer: Apple Mail (2.1257) Cc: Softwires-wg Subject: Re: [Softwires] New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:37:32 -0000 First, thanks Maoke for publishing this document.=20 It is very helpful to qualify 4rd-u that is a new type IPv4-over-IPv6 = tunneling variant with several semantics changes. I think that it is = very exciting proposal for all IETF participants because they shall be = interested into defining new tunneling work. Once that work will have = been done, I suppose that all of products of the working group shall be = considered, such as RFC6333, ongoing 4over6 work and RFC5512 as BGP = signaling to indicate new tunnel type for softwire mesh scenario, when = we get the outcome of that work. I can't wait that exciting future work, but not now. cheers, --satoru On 2012/04/11, at 13:28, Maoke wrote: > hi Behcet,=20 >=20 > 2012/4/10 Tina TSOU >=20 >=20 > Sent from my iPad >=20 > On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" = wrote: >=20 > > Hi Maoke, > > > > Thank you for your efforts in technical details of one specific > > proposal on the table. > > > > However, I for one think that probably it is time to concentrate on > > commonalities rather than the differences. As Alain indicated, these > > proposals do have a lot of common points. > > >=20 > that proposal is basically of a response to people's call for = "describing technical concerns in mind" about 4rd-U. commonality and = difference is the two sides of the same coin. if we don't understand = what makes them exactly different, we are also hard to understand how = common they are. this document is purposed in sharing such an = understanding and therefore it focuses only on the essential concerns -- = the concerns regarding architecture and protocol semantics.=20 > =20 > > Why don't (whoever) write a draft putting together all the common > > points concentrating on CE to BR and abstracting out BIH, XLAT, = etc.? > > Such a draft can be of great value at this point, I think. > That's MAP-D document. > > >=20 > yes. as Tina points out, MAP deployment draft that we are working on = plays the role of clarifying the common deployment considerations with = MAP series. thanks! >=20 > best, > maoke > =20 > > Regards, > > > > Behcet > > > =20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Apr 11 05:30:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613DA21F865D for ; Wed, 11 Apr 2012 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OscaXrRtu9Oy for ; Wed, 11 Apr 2012 05:30:39 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9006D21F8656 for ; Wed, 11 Apr 2012 05:30:37 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id wcWb1i00A37Y3f403cWbgu; Wed, 11 Apr 2012 14:30:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--642049743 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 11 Apr 2012 14:30:35 +0200 Message-Id: <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:30:40 -0000 --Apple-Mail-1--642049743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Good to see that at least one who has read the 4rd-u draft still = considers that technical considerations are worth working on. Thanks. IMHO, you did a great job to structure this (useful) discussion. Here are quick comments/suggestions/corrections I propose:=20 4.1. (M2) Rather than "simplification of L4 protocol treatment" the = motivation is "Full IPv4 transparency, with never modified payloads and = IPv4 fragmentation semantics" 4.1. (M4) a motivation to be added: "No constraint on subnet-ID = assignments in customer sites" 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as = ensured as in MAP-E" instead of "4rd-U argues it should be supported no = matter how minor it is observed in practice". 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they = prefer, concerning DiffServ architecture, provided users cannot make the = difference" instead of "4rd-U argues ToS should be kept unchanged when = the packet traverses the IPv6 domain, except the ECN bits". 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet = validity of IPv4 tunneled packets, for all present and future protocols = that have ports as the same place as TCP and the same checksum = algorithm, without being concerned with where these protocols have their = checksum fields" instead of "it also argues checksum validity should be = ensured through address in order to simplify L4 processing" 4.2. (O6)- to be added=20 "UDP null checksums: [RFC6145] can be configured either to drop all IPv4 = packets having null checksums, or drop only those that are fragmented. = 4rd-u argues that this lack of IPv4 transparency should be avoided." 4.2. (O7)- to be added=20 "Free assignment of subnet IDs: subnet IDs that follow customer-site = prefixes in native IPv6 addresses are so far freely chosen for each = customer site. 4rd-u argues that this freedom should not be lost, = despite the need to distinguish IPv4-originated packets from native IPv6 = packets at customer-site entrances.=20 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), = and (07), should IMHO be considered in scope (if a new version is = issued). 5.1 Impact - "Since [RFC6145] is already such that middle boxes see = unfragmented IPv6 packets having fragment headers, there is no new = impact" instead of "always seeing fragment header is strange to middle = boxes in the IPv6 domain. The system administrators of any middle box = SHOULD be informed on the deployment of 4rd-U". 5.2 Impact - a. This, not being a concern between 4rd-u nodes, isn't = needed here. 5.2 Impact - b. Not understood. 5.3 4rd-u semantics - (1) you make a VALUABLE POINT. "hop limit = exceeded" should be translated to "host unreachable" as in RFC2473 = (sorry for this (small) bug in 4rd-u-06). Then, the the semantics is = equivalent to that of RFC2473. The only practical difference is that, if = the received TTL is < 128, routing problems are detected after 127 hops = within the ISP domain instead of 255 (negligible IMHO provided it is = known). 5.3 Impact d. - Unless you can elaborate what you would fear, I think = there is no such impact. 5.4 Impact a. - Add ", instead of protocol 4 (IPv4) in RFC2473" after = "IPv6 domain MUST set all filters in middle boxes to pass protocol 1 = (ICMP) as IPv6 payload in order to support 4rd-U functionality". =20 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 = message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But = this integrity can be ensured at tunnel exit by checking that CNPs do = preserve checksum neutrality. This can be clarified by a complement in = the 4rd-u security section. 6. The statement that "double translation is also a sort of tunneling in = general sense" is IMHO confusing in view of its lack of IPv4 end-to-end = transparency. The statement that "It needs further investigation to = ensure if 4rd-U is qualified to be called as a tunnel in the narrow = sense" expresses a doubt without substance to justify it. 4rd-U only = claims that IPv4 packets traverse ISP domains transparently (unless they = have IPv4 options in which case the domain signals it doesn't support = them). 7. Similar to encapsulation - Add "UPP datagrams with null checksum are tunneled".=20 - Delete "Middle boxes in the tunnel are unable to check if ICMPv4 = message is sent to correct destination". (There is no beed for this = since tunnel-exit endpoints can ensure correct destinations - see 5.4 = impact c.) 7. Similar to double translation - Add "Middle boxes can treat tunneled IPv4 packets as valid IPv6 = packets for all protocols that have port positions and checksum = algorithm of TCP".=20 - What you mean by "without protocol layering, position of IPv4 fields = are changed" is unclear to me. To be deleted or explained. - "IPv4 options are not supported" instead of "IPv4 options are removed" 7. Never seen ... - Add "Residual IPv4 service can be supported in sites that use subnet = ID =3D 0". - Fragmented packets addressed to shared-address customer sites can be = tunneled without packet reassembly at domain entry." =20 Kind regards, RD Le 2012-04-10 =E0 11:53, Maoke a =E9crit : > hi all,=20 >=20 > i made an internet-draft discussing the semantics issue of 4rd-U. = comments, recommendations, technical discussions are welcome.=20 >=20 > http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 >=20 > thanks and regards, > maoke >=20 > ---------- Forwarded message ---------- > From: > Date: 2012/4/10 > Subject: New Version Notification for = draft-chen-softwire-4rd-u-comment-00.txt > To: fibrib@gmail.com >=20 >=20 > A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has = been successfully submitted by Maoke Chen and posted to the IETF = repository. >=20 > Filename: draft-chen-softwire-4rd-u-comment > Revision: 00 > Title: A Commentary on 4rd-U Architecture and Semantics > Creation date: 2012-04-10 > WG ID: Individual Submission > Number of pages: 19 >=20 > Abstract: > 4rd-U is proposed as an effort of unifying encapsulation and double > translation solutions for the softwire of IPv4 over IPv6 domain. > This attempt introduces new behaviors in the Internet transition > architecture as well as semantics other than that of well-known > Internet protocols. This documents provides a commentary on the > semantic changes and their impacts. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-1--642049743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

4.1. (M4) a motivation to be added: =  "No constraint on subnet-ID assignments in customer = sites"

4.2. (O1) "4rd-U argues that IPv4 = end-to-end transparency should be as ensured as in MAP-E" instead of = "4rd-U argues it should be supported no matter how minor it is observed = in practice".

4.2. (O1) "4rd-u leaves it to = ISPs to decide which kind of tunnel they prefer, concerning DiffServ = architecture, provided users cannot make the difference" instead of = "4rd-U argues ToS should be kept unchanged when the packet traverses the = IPv6 domain, except the ECN bits".

4.2. (O5) = "it also argues that checksum transparency ensures IPv6 packet validity = of IPv4 tunneled packets, for all present and future protocols that have = ports as the same place as TCP and the same checksum algorithm, without = being concerned with where these protocols have their checksum fields" =  instead of "it also argues checksum validity should be ensured = through address in order to simplify L4 = processing"

4.2. (O6)- to be = added 
"UDP null checksums: [RFC6145] can be configured = either to drop all IPv4 packets having null checksums, or drop only = those that are fragmented. 4rd-u argues that this lack of IPv4 = transparency should be avoided."

4.2. (O7)- to = be added 
"Free assignment of subnet IDs:  subnet = IDs that follow customer-site prefixes in native IPv6 addresses are so = far freely chosen for each customer site. 4rd-u argues that this freedom = should not be lost, despite the need to distinguish IPv4-originated = packets from native IPv6 packets at customer-site = entrances. 

4.2. after (T6) CNP and V = octet, because they are related to (M4), (O6), and (07), should IMHO be = considered in scope (if a new version is = issued).

5.1 Impact - "Since [RFC6145] is = already such that middle boxes see unfragmented IPv6 packets having = fragment headers, there is no new impact" instead of "always seeing = fragment header is strange to middle boxes in the IPv6 domain.  The = system administrators of any middle box SHOULD be informed on the = deployment of 4rd-U".

5.2 Impact - a. This, not = being a concern between 4rd-u nodes, isn't needed = here.

5.2 Impact - b. Not = understood.

5.3 4rd-u semantics - (1) you make = a VALUABLE POINT. "hop limit exceeded" should be translated to "host = unreachable" as in RFC2473 (sorry for this (small) bug in 4rd-u-06). = Then, the the semantics is equivalent to that of RFC2473. The only = practical difference is that, if the received TTL is < 128, routing = problems are detected after 127 hops within the ISP domain instead of = 255 (negligible IMHO provided it is known).

5.3 = Impact d. - Unless you can elaborate what you would fear, I think there = is no such impact.

5.4 Impact a. - Add ", = instead of protocol 4 (IPv4) in RFC2473" after "IPv6 domain MUST set all = filters in middle boxes to pass protocol 1 (ICMP) as IPv6 payload in = order to support 4rd-U functionality". =   

5.4 Impact c. - it is true that, = in the IPv6 packet of a tunneled ICMPv4 message, the ICMPv4 checksum = doesn't ensure IPv6 address integrity. But this integrity can be ensured = at tunnel exit by checking that CNPs do preserve checksum neutrality. = This can be clarified by a complement in the 4rd-u security = section.

6. The statement that "double = translation is also a sort of tunneling in general sense" is IMHO = confusing in view of its lack of IPv4 end-to-end transparency. The = statement that "It needs further investigation to ensure if 4rd-U is = qualified to be called as a tunnel in the narrow sense" expresses a = doubt without substance to justify it. 4rd-U only claims that IPv4 = packets traverse ISP domains transparently (unless they have IPv4 = options in which case the domain signals it doesn't support = them).

7. Similar to encapsulation
- = Add "UPP datagrams with null checksum are tunneled". 
- = Delete "Middle boxes in the tunnel are unable to check if ICMPv4 message = is sent to correct destination". (There is no beed for this since = tunnel-exit endpoints can ensure correct destinations - see 5.4 impact = c.)

7. Similar to double = translation
- Add "Middle boxes can treat tunneled IPv4 = packets as valid IPv6 packets for all protocols that have port positions = and checksum algorithm of TCP". 
- What you mean by = "without protocol layering, position of IPv4 fields are changed" is = unclear to me. To be deleted or explained.
- "IPv4 options are = not supported" instead of "IPv4 options are = removed"


7. Never seen = ...
- Add "Residual IPv4 service can be supported in sites = that use subnet ID =3D 0".
- Fragmented packets addressed to = shared-address customer sites can be tunneled without packet reassembly = at domain entry."  


Kind = regards,
RD





Le 2012-04-10 =E0 11:53, Maoke a = =E9crit :

hi all, 

i made an = internet-draft discussing the semantics issue of 4rd-U. comments, = recommendations, technical discussions are = welcome. 


thanks and regards,
maoke

---------- Forwarded message ----------
From: = <internet-drafts@ietf.org><= /span>
Date: 2012/4/10
Subject: New Version Notification for = draft-chen-softwire-4rd-u-comment-00.txt
To: fibrib@gmail.com


A new = version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been = successfully submitted by Maoke Chen and posted to the IETF = repository.

Filename:       =  draft-chen-softwire-4rd-u-comment
Revision:        00
Title:           A Commentary on 4rd-U = Architecture and Semantics
Creation date:   2012-04-10
WG ID:           Individual Submission
Number of pages: 19

Abstract:
  4rd-U is proposed as an effort of unifying encapsulation and = double
  translation solutions for the softwire of IPv4 over IPv6 = domain.
  This attempt introduces new behaviors in the Internet = transition
  architecture as well as semantics other than that of = well-known
  Internet protocols.  This documents provides a commentary = on the
  semantic changes and their impacts.




The IETF Secretariat

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-1--642049743-- From despres.remi@laposte.net Wed Apr 11 05:53:43 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4090921F86E0 for ; Wed, 11 Apr 2012 05:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0KZvAVMKSmS for ; Wed, 11 Apr 2012 05:53:42 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 471FD21F86D8 for ; Wed, 11 Apr 2012 05:53:41 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id wctX1i00437Y3f403ctXsp; Wed, 11 Apr 2012 14:53:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Wed, 11 Apr 2012 14:53:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:53:43 -0000 Le 2012-04-04 =E0 23:14, Alain Durand a =E9crit : > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we = should make this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. Not the same first question, in view of what is now meant by "Answering = NO" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP = (as a whole) on the standard track, > the other being published as experimental or informational. As already said, I can't agree with this (the need for the WG to better = understand the two proposals befrore a rather long term decision has = become clear).=20 > Answering YES to this question means you agree we cannot publish both = as standard track. > Answering NO to this question means you want to see both advance on = the standard track. As said many times, I can't agree with this. The goal is ONE standard, = not three.=20 With this, I have NO ALTERNATIVE but NOT answering this question.=20 >=20 > = --------------------------------------------------------------------------= -- > Your full name, your affiliation, your choice: YES or NO > = --------------------------------------------------------------------------= -- R=E9mi Despr=E9s, RD-IPtech, neither YES nor NO (both impossible) Regards, RD =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards = Track: > 4rd-U or MAP? >=20 > = --------------------------------------------------------------------------= ---- > Your full name, your affiliation, your choice: 4rd-U or MAP > = --------------------------------------------------------------------------= ---- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Wed Apr 11 06:44:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACC521F8594 for ; Wed, 11 Apr 2012 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRwge46hUAOI for ; Wed, 11 Apr 2012 06:44:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4A21F8570 for ; Wed, 11 Apr 2012 06:44:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so667379qcs.31 for ; Wed, 11 Apr 2012 06:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=029sxOq9dB0zGRUSmAjc4u4MKOzq2XVzjHaG7kAmNzU=; b=SlVvSqHMJ4M14G8zkz+5MjD0gZAHIOZPcQoEOTb4E3VgS4TAxW4jmCMNCpcilJ5doG 5T3Gz0cl/K4ETVdS3G/vYfiZQ4fWNxBSg9Cj4FOWFtM4f175b4rJT4yGuRjdCADRtTWx 3C/OX7G2WItqpDT7zlBYGU8RsD13yY15VV6Uhi4OL/mEMZRMPDehp+ZzTBpKN3J/iEBA SNieRCnyTvhkBNq9F/vSDH7mSpJrir+WmnW+LMzAV0T5VX+LARGe4zyjFnj4UHU1HRHy UbHBZTin7hHw1D11V0HbDW4Y2DqBT2eztBhAAK9Ofdpquo/xSYx6gJ1kI60Jxgn00oM/ JoYA== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr20033319qab.36.1334151888446; Wed, 11 Apr 2012 06:44:48 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 06:44:48 -0700 (PDT) In-Reply-To: <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> Date: Wed, 11 Apr 2012 22:44:48 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300faff563237b04bd677191 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:44:50 -0000 --20cf300faff563237b04bd677191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable postpone other parts, but focus on the checksum issue. 2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net > > 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 > message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But > this integrity can be ensured at tunnel exit by checking that CNPs do > preserve checksum neutrality. This can be clarified by a complement in th= e > 4rd-u security section. > > 1. this introduces another new semantics/logic of protocol stack processing at exit CE. it is really hard to call it either IPv4 or IPv6. 2. even though this CNP works for the address integrity, unfortunately, however, the checksum still provides integrity protection for packet length and payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in ICMPv6 checksum, which covers the pseudo-header of IPv6. how could CNP protect these? thanks for mentioning CNP here. i need to modify the concern for "address integrity" to the concern for "integrity of addresses, packet length and payload protocol type". - maoke --20cf300faff563237b04bd677191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
postpone other parts, but focus on the checksum issue.
2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net
=A0
5.4 Impact c. - it i= s true that, in the IPv6 packet of a tunneled ICMPv4 message, the ICMPv4 ch= ecksum doesn't ensure IPv6 address integrity. But this integrity can be= ensured at tunnel exit by checking that CNPs do preserve checksum neutrali= ty. This can be clarified by a complement in the 4rd-u security section.
=A0
=A0
1. this introduces anot= her new semantics/logic of protocol stack processing=A0at exit CE. it is re= ally hard to call it either IPv4 or IPv6.=A0=A0
=A0
2. = even though=A0this CNP works for the address integrity, unfortunately, howe= ver, the checksum still=A0provides integrity=A0protection for=A0packet leng= th and payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair.= they are involved either in=A0IPv4 header checksum or in ICMPv6 checksum, = which covers the pseudo-header of IPv6.=A0how could CNP protect these?
=A0
thanks for mentioning CNP here. i need to modify the con= cern for "address integrity" to the concern for "integrity o= f addresses, packet length and payload protocol type".
=A0<= /div>
- maoke
--20cf300faff563237b04bd677191-- From fernando.vela@ono.es Wed Apr 11 06:50:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676F111E8158 for ; Wed, 11 Apr 2012 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1AeLf6ntXgt for ; Wed, 11 Apr 2012 06:50:38 -0700 (PDT) Received: from correo.ono.es (correo2.ono.es [62.42.227.11]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE611E816A for ; Wed, 11 Apr 2012 06:50:37 -0700 (PDT) Received: from M1-CORREO02.corp.ono.es ([172.17.1.228]) by correo.ono.es with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 15:50:35 +0200 Received: from M1-HUB01.corp.ono.es ([172.17.10.63]) by M1-CORREO02.corp.ono.es with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:50:35 +0200 Content-Transfer-Encoding: 7bit Received: from M1-HUB02.corp.ono.es (172.17.10.88) by M1-HUB01.corp.ono.es (172.17.10.63) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 11 Apr 2012 15:50:34 +0200 Content-Class: urn:content-classes:message Received: from M1-CORREO05.corp.ono.es ([fe80::3559:62db:dda5:bd19]) by M1-HUB02.corp.ono.es ([::1]) with mapi; Wed, 11 Apr 2012 15:50:33 +0200 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2001 From: To: Date: Wed, 11 Apr 2012 15:50:30 +0200 Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0X6g78yo57o5nvSHOEKv43YoONgA== Message-ID: <337C9646C13B9B4EB49BA36C48570C260760D0B5BC@M1-CORREO05.corp.ono.es> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_337C9646C13B9B4EB49BA36C48570C260760D0B5BCM1CORREO05cor_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2012 13:50:35.0066 (UTC) FILETIME=[11B7D9A0:01CD17EA] Cc: int-ads@tools.ietf.org Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:52:20 -0000 This is a multi-part message in MIME format. --_000_337C9646C13B9B4EB49BA36C48570C260760D0B5BCM1CORREO05cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as = standard track. Answering NO to this question means you want to see both advance on the = standard track. -------------------------------------------------------------------------= --- Fernando Vela, ONO: YES -------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? -------------------------------------------------------------------------= ----- Fernando vela, ONO: MAP -------------------------------------------------------------------------= ----- ---------- Forwarded message ---------- From: Alain Durand Date: 4 April 2012 23:14 Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U = vs MAP To: "softwires@ietf.org WG" Cc: "int-ads@tools.ietf.org" , Softwire Chairs = Dear Softwire wg members: At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole) and 4rd-U. We got very strong feedback that we needed to select one solution to cover that full stateless case, not two, and that we should = make this decision relatively quickly. During Paris meeting, we asked the following additional question: Do you prefer MAP or 4rd-U? We got about 1/3 support for 4rd-U and 2/3 for MAP. The real gauge of consensus is the mailing list, so we would like to ask the same questions to the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as = standard track. Answering NO to this question means you want to see both advance on the = standard track. -------------------------------------------------------------------------= --- Your full name, your affiliation, your choice: YES or NO -------------------------------------------------------------------------= --- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? -------------------------------------------------------------------------= ----- Your full name, your affiliation, your choice: 4rd-U or MAP -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please fill out the following form and reply to the list by Wednesday 4/10 5pm EDT. Note: Use this thread ONLY for expressing your support to one OR the other, and redirect any discussions to other threads. That would help up gauge consensus. Alain & Yong. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Este mensaje es CONFIDENCIAL, siendo para uso exclusivo de su = destinatario. Si usted no es el destinatario, por favor, reenvie el = mensaje inmediatamente a la direccion remitente y proceda a su borrado. CABLEUROPA, S.A.U. (ONO) incluira su direccion de correo electronico, = asi como los datos de contacto que le facilite, en un fichero con el fin = de gestionar el envio de comunicaciones profesionales y/o personales de = sus empleados y personal externo. Para ejercitar sus derechos de acceso, = rectificacion, cancelacion y oposicion, remita su solicitud al Dpto. = Asesoria Juridica, calle Basauri, 7-9, urb. La Florida, Aravaca 28023 = Madrid. --_000_337C9646C13B9B4EB49BA36C48570C260760D0B5BCM1CORREO05cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as standard track.
Answering NO to this question means you want to see both advance on the standard track.

-------------------------------------------------------------------------= ---
Fernando Vela, ONO:             &= nbsp;   YES
-------------------------------------------------------------------------= ---


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards = Track:
4rd-U or MAP?

-------------------------------------------------------------------------= -----
Fernando vela, ONO:             &= nbsp;   MAP
-------------------------------------------------------------------------= -----

 

 

 

 

 

        &= nbsp;       ---------- Forwarded = message ----------
From: Alain Durand <adurand@juniper.net>
Date: 4 April 2012 23:14
Subject: [Softwires] Mailing list question to gauge consensus on 4rd-U = vs MAP
To: "softwires@ietf.org WG" = <softwires@ietf.org>
Cc: "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, = Softwire Chairs <softwire-chairs@tools.ietf.org>


Dear Softwire wg members:

At the Paris IETF Softwire meeting, we had presentations on MAP (taken = as a whole)  and
4rd-U. We got very strong feedback that we needed to select one
solution to cover that full stateless case, not two, and that we should = make this
decision relatively quickly.

During Paris meeting, we asked the following additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 for MAP.

The real gauge of consensus is the mailing list, so we would like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as = a whole) on the standard track,
the other being published as experimental or informational.
Answering YES to this question means you agree we cannot publish both as standard track.
Answering NO to this question means you want to see both advance on the standard track.

-------------------------------------------------------------------------= ---
Your full name, your affiliation, your choice: YES or NO
-------------------------------------------------------------------------= ---


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Questions 2: Which one do you want to see placed on the Standards = Track:
4rd-U or MAP?

-------------------------------------------------------------------------= -----
Your full name, your affiliation, your choice: 4rd-U or MAP
-------------------------------------------------------------------------= -----

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Please fill out the following form and reply to the list
by Wednesday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your support to
one OR the other, and redirect any discussions to other threads.
That would help up gauge consensus.

Alain & Yong.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf= .org/mailman/listinfo/softwires

 

 

 


Este mensaje es CONFIDENCIAL, siendo para uso exclusivo de su = destinatario. Si usted no es el destinatario, por favor, reenvie el = mensaje inmediatamente a la direccion remitente y proceda a su borrado. =

CABLEUROPA, S.A.U. (ONO) incluira su direccion de correo = electronico, asi como los datos de contacto que le facilite, en un = fichero con el fin de gestionar el envio de comunicaciones profesionales = y/o personales de sus empleados y personal externo. Para ejercitar sus = derechos de acceso, rectificacion, cancelacion y oposicion, remita su = solicitud al Dpto. Asesoria Juridica, c/ Basauri, 7-9, urb. La Florida, = Aravaca 28023 Madrid. --_000_337C9646C13B9B4EB49BA36C48570C260760D0B5BCM1CORREO05cor_-- From denghui02@gmail.com Wed Apr 11 07:39:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7DB11E80C4 for ; Wed, 11 Apr 2012 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyoqN+EX1gy9 for ; Wed, 11 Apr 2012 07:39:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3011E80C1 for ; Wed, 11 Apr 2012 07:39:32 -0700 (PDT) Received: by yhkk25 with SMTP id k25so526550yhk.31 for ; Wed, 11 Apr 2012 07:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ocgLCZYClLbkj9DFCeLJc7ys1rW7UrttvKR2c2ipbx0=; b=s5EtMEgwfILiYMFltNr0+cKHrHgccpsjbMiMKAjJc4J56ZhcOt5MTYQSiBRnUlQiGK W+bW3v+DKmjFHTd3OuP/p5oBuv6sAEoyFQd1pnOb0OlhdaH6Q6LvOLWCpWYnhTgPI5cU gUzRddiS9RhZb68XvaCV5itkNEpzusNtu505g9lKsw9D/ja7OX2PvluwVWzK4LXRvTmc ItFJDUN/JFVKxsK98HbDca7AxBZPJ5gB/YXkmbOXGykCXZbsJXYCbe5z6krGZQGH6/TW pC8iJskOgaPAppm8pxMcoocgrgm5RNz3LmVcYx7Ako9D496B/OTb3PDxZg3DK3kwGZS8 v7hQ== MIME-Version: 1.0 Received: by 10.236.176.197 with SMTP id b45mr13304894yhm.72.1334155172526; Wed, 11 Apr 2012 07:39:32 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Wed, 11 Apr 2012 07:39:32 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Wed, 11 Apr 2012 22:39:32 +0800 Message-ID: From: Hui Deng To: Alain Durand Content-Type: multipart/alternative; boundary=20cf305b1286223b3f04bd683571 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:39:34 -0000 --20cf305b1286223b3f04bd683571 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. After carefully reading the documents and mailing list discussion, especially from this one: http://www.ietf.org/mail-archive/web/softwires/current/msg04135.html I understand MAP as a whole is two solutions=A3=AC I fail to answer yes or = no, It is Triple solutions, sorry, I couldn't convince myself to answer here. If chair could kindly help to rephrase like "all of three" other than "both", then I may say "yes". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Questions 2: Which one do you want to see placed on the Standards Track: 4rd-U or MAP? Same as above. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best, -Hui 2012/4/5 Alain Durand > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as > a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should > make this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > > -------------------------------------------------------------------------= --- > Your full name, your affiliation, your choice: YES or NO > > -------------------------------------------------------------------------= --- > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > > -------------------------------------------------------------------------= ----- > Your full name, your affiliation, your choice: 4rd-U or MAP > > -------------------------------------------------------------------------= ----- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf305b1286223b3f04bd683571 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1:= Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on th= e standard track, the other being published as experimental or informationa= l.
Answering YES to this question means you agree we cannot publish both as st= andard track.
Answering NO to this question means you want to see both a= dvance on the standard track.

After carefully reading the documents and mailing list discussion, especially from this one:
http://www.ietf.org/mail-archive/web/so= ftwires/current/msg04135.html
I understand MAP as a whole is two solutions=A3=AC I fail to answer yes or = no,
It is Triple solutions, sorry, I couldn't convince myself to ans= wer here.

If chair could kindly help to rephrase like "all of three" other than "both", then I may say "yes".

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questions 2= : Which one do you want to see placed on the Standards Track:
4rd-U or M= AP?

Same as above.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Best,

-Hui

2012/4/5 Alain Durand <adurand@juniper.net>
Dear Softwire wg members:

At t= he Paris IETF Softwire meeting, we had presentations on MAP (taken as a who= le)  and
4rd-U. We got very strong feedback that we needed to select one
solution= to cover that full stateless case, not two, and that we should make thisdecision relatively quickly.

During Paris meeting, we asked the fo= llowing additional question:
Do you prefer MAP or 4rd-U?
We got about 1/3 support for 4rd-U and 2/3 f= or MAP.

The real gauge of consensus is the mailing list, so we would= like
to ask the same questions to the list.

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a w= hole) on the standard track,
the other being published as experimental o= r informational.
Answering YES to this question means you agree we canno= t publish both as standard track.
Answering NO to this question means you want to see both advance on the sta= ndard track.

-------------------------------------------------------= ---------------------
Your full name, your affiliation, your choice: YES= or NO
---------------------------------------------------------------------------= -


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questions 2: Which one do you want to see placed on the Standards Trac= k:
4rd-U or MAP?

------------------------------------------------------= ------------------------
Your full name, your affiliation, your choice: = 4rd-U or MAP
-----------------------------------------------------------= -------------------

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=

Please fill out the following form and reply to the list
by Wedn= esday 4/10 5pm EDT.

Note: Use this thread ONLY for expressing your s= upport to
one OR the other, and redirect any discussions to other threads.
That wo= uld help up gauge consensus.

Alain & Yong.
__________________= _____________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf305b1286223b3f04bd683571-- From despres.remi@laposte.net Wed Apr 11 08:06:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090D11E815A for ; Wed, 11 Apr 2012 08:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwMlSdhnlbyf for ; Wed, 11 Apr 2012 08:06:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6932F11E814E for ; Wed, 11 Apr 2012 08:06:23 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 974C2940139; Wed, 11 Apr 2012 17:06:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--632711443 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 11 Apr 2012 17:06:13 +0200 Message-Id: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:06:44 -0000 --Apple-Mail-2--632711443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-11 =E0 15:44, Maoke a =E9crit : >=20 > postpone other parts, but focus on the checksum issue.=20 > 2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net > =20 > 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled = ICMPv4 message, the ICMPv4 checksum doesn't ensure IPv6 address = integrity. But this integrity can be ensured at tunnel exit by checking = that CNPs do preserve checksum neutrality. This can be clarified by a = complement in the 4rd-u security section. > =20 > =20 > 1. this introduces another new semantics/logic of protocol stack = processing at exit CE. it is really hard to call it either IPv4 or IPv6.=20= How it is called is IMHO secondary, what is a fact is that it ensures = address security.=20 =20 > 2. even though this CNP works for the address integrity, (which was the listed point) > unfortunately, however, the checksum still provides integrity = protection for packet length and payload protocol type in both = IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. they are involved either in IPv4 = header checksum or in ICMPv6 checksum, which covers the pseudo-header of = IPv6.=20 > how could CNP protect these? No way, of course. (Are we now in the technical discussion, or still in deliberate = controversy?). > thanks for mentioning CNP here. > i need to modify the concern for "address integrity" to the concern = for "integrity of addresses, packet length and payload protocol type". - Addresses have been covered AFAIAC. - No test scenario I can imagine can reveal an ICMPv4 security problem = concerning protocol type or packet length. (A simulated hardware failure = would AFAIK be needed, and with that, many other security problems can = be considered to exist.)=20 =3D> Unless you come up with new facts, end of this subject for me. RD > =20 > - maoke --Apple-Mail-2--632711443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

postpone= other parts, but focus on the checksum issue.
2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net
 
5.4 Impact c. = - it is true that, in the IPv6 packet of a tunneled ICMPv4 message, the = ICMPv4 checksum doesn't ensure IPv6 address integrity. But this = integrity can be ensured at tunnel exit by checking that CNPs do = preserve checksum neutrality. This can be clarified by a complement in = the 4rd-u security section.
 
 
1. this = introduces another new semantics/logic of protocol stack = processing at exit CE. it is really hard to call it either IPv4 or = IPv6. 

How it is called = is IMHO secondary, what is a fact is that it ensures address = security. 
 
2. even though this CNP works for the = address integrity,

(which was the = listed point)

unfortunately, however, the checksum = still provides integrity protection for packet length and = payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. = they are involved either in IPv4 header checksum or in ICMPv6 = checksum, which covers the pseudo-header of = IPv6. 


how could CNP protect = these?

No way, of = course.
(Are we now in the technical discussion, or still in = deliberate controversy?).

thanks for mentioning CNP here. =

i need to modify the concern for "address = integrity" to the concern for "integrity of addresses, packet length and = payload protocol type".

- = Addresses have been covered AFAIAC.
- No test scenario I can = imagine can reveal an ICMPv4 security problem concerning = protocol type or packet length. (A simulated hardware failure would = AFAIK be needed, and with that, many other security problems can be = considered to exist.) 
=3D> Unless you come up = with new facts, end of this subject for = me.

RD






 
- maoke

= --Apple-Mail-2--632711443-- From zehn.cao@gmail.com Wed Apr 11 08:49:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB66F11E8085 for ; Wed, 11 Apr 2012 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEYh7rU67Xi9 for ; Wed, 11 Apr 2012 08:49:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0634E11E8076 for ; Wed, 11 Apr 2012 08:49:09 -0700 (PDT) Received: by iazz13 with SMTP id z13so1736308iaz.31 for ; Wed, 11 Apr 2012 08:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TtaB0yT32E2KAbzOYzlgIDd239oS87N4j6LZ7OILvt0=; b=I9kfwkQl4Q2e36FY6XIlBSeATjl9p2QQah/dpQhaJdup0t2w04f6JvH7LMk3uLdadh KJrt8OhOrxTleu0GFKkoR4pkXjo24wqS4NCaEFm8Vdc/TZD58hoHZ4La8SumPMzt6/5W gNW3lgQWpys8hAICZf6wqEIRkhWM15Dj14KDw12Afp/2qjpzqQ4jE8VClDvvpcBuOPwI KE6O4wzVRMF353fgMuS3tqc24lGW5xrBT9VGIoLn4MmYwF+06111hZBrT94t1C+Q4VrQ aTUNC+IBabm834vTBemh+atYWIQVulvt0F/lbWkUAGtti39BJtsVwoaUkyuA7nZM0/2r Yetg== MIME-Version: 1.0 Received: by 10.50.158.166 with SMTP id wv6mr6163800igb.39.1334159349706; Wed, 11 Apr 2012 08:49:09 -0700 (PDT) Received: by 10.42.76.72 with HTTP; Wed, 11 Apr 2012 08:49:09 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Wed, 11 Apr 2012 23:49:09 +0800 Message-ID: From: Zhen Cao To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:49:10 -0000 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. As I can remind, this is not the same 'first' question as the one that was asked on the Friday softwire meeting. The question asked on Friday was something like: "do you think we should make a decision...". The Friday audio archive is not online via http://www.ietf.org/audio/ietf83/, but we can check later. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as standard track. > Answering NO to this question means you want to see both advance on the standard track. > ---------------------------------------------------------------------------- Zhen Cao, China Mobile, other options ---------------------------------------------------------------------------- > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > Since this was to gauge consensus, I restate the one I voted on that Friday. ------------------------------------------------------------------------------ Zhen Cao, China Mobile, 4RD-U ------------------------------------------------------------------------------ From fibrib@gmail.com Wed Apr 11 08:54:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C211E809F for ; Wed, 11 Apr 2012 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT5-leen-sM2 for ; Wed, 11 Apr 2012 08:54:46 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2611E8085 for ; Wed, 11 Apr 2012 08:54:46 -0700 (PDT) Received: by qcsq13 with SMTP id q13so779758qcs.31 for ; Wed, 11 Apr 2012 08:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AnGooqx/unvQe6mzHnWgpuJMYwq/CIAhFjGMJ6RgMzk=; b=aD1wDdY9Soivk/GF2RPyy/8HmzxM8M+fTf88l6X3OIGAnHrcd9YKGYpuxNMXOR6dLL yb1N1N88thE60BkDmj91XpGU5MQLqoW5fBCNZseIYcQqOTfWBaKkgLptnWEZ3NeyqnUA TYvu2szVQd1QgI8a752P0/hdNQzVdyb2lIBHtgDqrIPAjXhK3Sn8J8tSbxrdpCr3MS5U H7sJRvhJM56BQhsNHBngHL/0lsaKRysYgxJtEAmNJstI0vyC97h73Gm3L1iSaPa8X4x+ Wr03JNurow6uzwK7qp7ehe9vKje0x7dZGKRvBrDBfqm4/ZG7g2xs16w34hdwD5Q2QcIJ OO0Q== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr20371245qao.23.1334159686078; Wed, 11 Apr 2012 08:54:46 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 08:54:46 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> Date: Thu, 12 Apr 2012 00:54:46 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b41a29937b04bd6942e8 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:54:47 -0000 --20cf3074b41a29937b04bd6942e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/12 R=E9mi Despr=E9s > > Le 2012-04-11 =E0 15:44, Maoke a =E9crit : > > > postpone other parts, but focus on the checksum issue. > 2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net > >> >> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 >> message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But >> this integrity can be ensured at tunnel exit by checking that CNPs do >> preserve checksum neutrality. This can be clarified by a complement in t= he >> 4rd-u security section. >> >> > > 1. this introduces another new semantics/logic of protocol stack > processing at exit CE. it is really hard to call it either IPv4 or IPv6. > > > How it is called is IMHO secondary, what is a fact is that it ensures > address security. > > > 2. even though this CNP works for the address integrity, > > > (which was the listed point) > > unfortunately, however, the checksum still provides integrity protection > for packet length and payload protocol type in both IPv4/ICMPv4 pair and > IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in > ICMPv6 checksum, which covers the pseudo-header of IPv6. > > > > how could CNP protect these? > > > No way, of course. > (Are we now in the technical discussion, or still in deliberate > controversy?). > > technical discussion results in problem understanding instead of certainly a support for or an objection to a work politically. so i don't understand what is the so-called "deliberate controversy" here. i suppose my draft is written very neutral. as you raised a new solution regarding a concern while i found it not complete, i surely need to confirm if you would design a more comprehensive solution for that issue, and if the already-designed mechanism has had the functionality but i was not aware of that. > thanks for mentioning CNP here. > > > i need to modify the concern for "address integrity" to the concern for > "integrity of addresses, packet length and payload protocol type". > > > - Addresses have been covered AFAIAC. > - No test scenario I can imagine can reveal an ICMPv4 security problem > concerning protocol type or packet length. (A simulated hardware failure > would AFAIK be needed, and with that, many other security problems can be > considered to exist.) > > =3D> Unless you come up with new facts, end of this subject for me. > > i don't think it is needed to provide new facts here, at this stage. the test scenario is the next step. the draft is purposed on clarifying these semantics and their direct impact. judgment on the severity of the impacts is remained to the readers. i don't think 4rd-u is scoped within networks with reliable L2 links, isn't it? then, in a generic physical environment, one may think only address checksum is enough, one may think it is not enough, one may think checksum is anyway too weak to provide so-called protection, etc. --- all of these sort of asserts of severity judgment are out of the scope the draft (sec 5 para 1). fine to close this subject for me too because you have clarified "no way". that's enough. a refined statement on this issue will appear in the revision. tomorrow let me clarify another. thanks, maoke > > > RD > > > --20cf3074b41a29937b04bd6942e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/12 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-04-11 =E0 15:44, = Maoke a =E9crit :


= postpone other parts, but focus on the checksum issue.
2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net
=A0
5.4 Impact c. - it i= s true that, in the IPv6 packet of a tunneled ICMPv4 message, the ICMPv4 ch= ecksum doesn't ensure IPv6 address integrity. But this integrity can be= ensured at tunnel exit by checking that CNPs do preserve checksum neutrali= ty. This can be clarified by a complement in the 4rd-u security section.
=A0
=A0
1. this introduces anot= her new semantics/logic of protocol stack processing=A0at exit CE. it is re= ally hard to call it either IPv4 or IPv6.=A0
<= br>
How it is called is IMHO secondary,=A0what is a fact is th= at it ensures address security.=A0
=A0
2. even though=A0thi= s CNP works for the address integrity,

(which was the listed point)
<= div>

unfortunately,=A0however, the checksum still=A0provides integrity= =A0protection for=A0packet length and payload protocol type in both IPv4/IC= MPv4 pair and IPv6/ICMPv6 pair. they are involved either in=A0IPv4 header c= hecksum or in ICMPv6 checksum, which covers the pseudo-header of IPv6.=A0


how could CNP protect these?
=

No way, of course.
(Are we now in the t= echnical discussion, or still in deliberate controversy?).

=A0
tec= hnical discussion results in problem understanding instead of certainly a s= upport for or an=A0objection to a work politically. so i don't understa= nd what is the so-called "deliberate controversy" here. i suppose= my draft is written very neutral. as you raised a new solution regarding a= concern=A0while i found it not complete,=A0i surely need to confirm if you= =A0would design=A0a more=A0comprehensive solution for that issue, and if th= e already-designed mechanism has had the functionality but i was not aware = of that.
thanks for mentioning CNP here.

i need to modify the conce= rn for "address integrity" to the concern for "integrity of = addresses, packet length and payload protocol type".

- Addresses have been covered = AFAIAC.
- No test scenario I can imagine can reveal an=A0ICMPv4= =A0security problem concerning protocol type or packet length. (A simulated= hardware failure would AFAIK be needed, and with that, many other security= problems can be considered to exist.)=A0
=A0
=3D>=A0Unless you come up with new facts, end of= this subject for me.
=A0
=A0= =A0
i don't think it is needed to provide new facts here, at = this stage. the test scenario is the next step.=A0the=A0draft is purposed o= n clarifying these semantics and their direct impact. judgment on the sever= ity of the impacts is remained to the readers.
=A0
i don't think 4rd-u is scoped within networks with r= eliable L2 links, isn't it? then,=A0in a generic physical environment, = one may think only address checksum is enough, one may think it is not enou= gh, one may think checksum is anyway too=A0weak to provide so-called protec= tion, etc. --- all of these sort of asserts of severity judgment are out of= the scope the draft (sec 5 para 1).
=A0
fine to close this subject for me too because you h= ave clarified "no way". that's enough.=A0a=A0refined statemen= t on this issue will appear in the revision.
=A0
tomor= row let me clarify another.
=A0
thanks,
maoke
=A0
=A0

= RD

=A0
--20cf3074b41a29937b04bd6942e8-- From maxpassion@gmail.com Wed Apr 11 09:11:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6521F8454 for ; Wed, 11 Apr 2012 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ5rR-EOS6DQ for ; Wed, 11 Apr 2012 09:11:35 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9D0821F853A for ; Wed, 11 Apr 2012 09:11:34 -0700 (PDT) Received: by yenm5 with SMTP id m5so625080yen.31 for ; Wed, 11 Apr 2012 09:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nwoAvSvZC+3Zyruyk3WeAB4RQe3zB03bWh9cdJBQXfM=; b=I/FNenMYTcShKsvnglrPIKxSZV1ZLAJa5kBc/UC6PJagm1/jKv1FnWZ6PuJ9Ax3vLn ca70roTwvtCVNqbyUZR6rOY6rQUpYQVZKLTq33L56/x0bi8ATLKmTy8Aw20wEbj1LMUC Axf2ZEbmOX4oZnsyO7Dfjfc66d2opFT4bzfQnvRRSHqaWx7OnO+8c5Z8EDOZJ/0neFN4 ZjbxhzEJZXW5n+pQOwO/fDYYK7wWC+jRw4sXotnn661BvMMhyATYqoDQQWGYprHiGMhk QsQEa6iSltPNM9l3xQDHtlTKX1L3x6fKXs39kaafap5IMmzekI0evkVhJYCvDphlehSz y0aA== MIME-Version: 1.0 Received: by 10.50.183.137 with SMTP id em9mr3114211igc.58.1334160693582; Wed, 11 Apr 2012 09:11:33 -0700 (PDT) Received: by 10.42.196.200 with HTTP; Wed, 11 Apr 2012 09:11:33 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 12 Apr 2012 00:11:33 +0800 Message-ID: From: liu dapeng To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:11:40 -0000 2012/4/5, Alain Durand : > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a > whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make > this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- Is there any ohter options? for example, why not put both on experimental/informational and according to the real deployment then changing one to standard track? > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ 4RD-U, If we decide do not allow other options. Dapeng Liu, China Mobile > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ------ Best Regards, Dapeng Liu From sarikaya2012@gmail.com Wed Apr 11 09:18:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA311E8089 for ; Wed, 11 Apr 2012 09:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw-kwV1LsY1i for ; Wed, 11 Apr 2012 09:18:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D679211E8074 for ; Wed, 11 Apr 2012 09:18:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so631211yen.31 for ; Wed, 11 Apr 2012 09:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b7bOep5OrwCikOByl7fjSylwux6KXyXwZ8Va8fZ+d0A=; b=fMAvsil5Rr/DD8L0lqzTCKNgq9srPkv1TEz+yZrOLUTDpR/SMiyWBBeQ57sX3ocYnU JgBUTbNX9cNHVTn32BpgvZIFGFf90kTEghmRl7JpeidmchuWexjccqlZ5jOwjV8i4KGX n4rMEwINkp6XHIzREgYX2NzXG+q7VdC0naDM0oXx0GPdTpkQbz3P3DFtMppY7QMSOWIi M/qSVcNE2E2C0eRkAULXYWgAZGD7RqwBEtmewpO/m5x1/WssUt1zGyqMC8OxZUwg2OC6 5c96O/AVPZrAerZU2T3WAmOHkK7/wFvvVFhG36D8PhVv5m83FZuopljx22YF5gXduN6+ 4mRg== MIME-Version: 1.0 Received: by 10.50.85.232 with SMTP id k8mr2812412igz.16.1334161100241; Wed, 11 Apr 2012 09:18:20 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 11 Apr 2012 09:18:20 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 11:18:20 -0500 Message-ID: From: Behcet Sarikaya To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:18:25 -0000 On Tue, Apr 10, 2012 at 11:28 PM, Maoke wrote: > hi Behcet, > > 2012/4/10 Tina TSOU >> >> >> >> Sent from my iPad >> >> On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" >> wrote: >> >> > Hi Maoke, >> > >> > Thank you for your efforts in technical details of one specific >> > proposal on the table. >> > >> > However, I for one think that probably it is time to concentrate on >> > commonalities rather than the differences. As Alain indicated, these >> > proposals do have a lot of common points. >> > > > > that proposal is basically of a response to people's call for "describing > technical concerns in mind" about 4rd-U. commonality and difference is the > two sides of the same coin. if we don't understand what makes them exactly > different, we are also hard to understand how common they are. this document > is purposed in sharing such an understanding and therefore it focuses only > on the essential concerns -- the concerns regarding architecture and > protocol semantics. > >> >> > Why don't (whoever) write a draft putting together all the common >> > points concentrating on CE to BR and abstracting out BIH, XLAT, etc.? >> > Such a draft can be of great value at this point, I think. >> That's MAP-D document. >> > > > > yes. as Tina points out, MAP deployment draft that we are working on plays > the role of clarifying the common deployment considerations with MAP series. > thanks! > I would prefer calling a document that unifies both 4rd-u and MAP's 4rd. This is what this whole Softwire work is aimed at, i.e. define 4rd protocol. Regards, Behcet From fibrib@gmail.com Wed Apr 11 09:24:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347D521F8582 for ; Wed, 11 Apr 2012 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbjeD8UNcJ7C for ; Wed, 11 Apr 2012 09:24:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A720511E8074 for ; Wed, 11 Apr 2012 09:24:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so803844qcs.31 for ; Wed, 11 Apr 2012 09:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qKhmkhWrL9ejg8+IDrPSgWD0nd/Hzzy/x6O5Ifkfhi0=; b=eybeU30Tw3ra9Z8yxBYO1eoEbYPT01qO5x18NRGi8V50HzKz8Gtqjk3NHnt517ZzwX DHv6r4wBEaELXJLaUdMcnComR7y8rkF+vp+ZuZ2rZ1RyORFg364A3xGgFYLg2AOUnMRF DBIWEc0w4xFLitjygwq6j8V8epSdbFNisJWU3xoiFxzyhTXkvUCQ7uewKKh++JdW4YZq FrF6r2p3tbe8gmascb+yXoB4iovjBlzP0wDishcDpQpS0c/afDXdwRnrnY7Ep/7HbYlj fpvRN7UGC6Pd9gRdMNsUKpqQAzluGYOBvoClS8wwS6l/XLW4fsCz4M/bKwPSPlKPgYZb W8hA== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr20941049qab.36.1334161439362; Wed, 11 Apr 2012 09:23:59 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 09:23:59 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 01:23:59 +0900 Message-ID: From: Maoke To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf300faff5aa8f3104bd69aaf6 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:24:05 -0000 --20cf300faff5aa8f3104bd69aaf6 Content-Type: text/plain; charset=ISO-8859-1 2012/4/12 Behcet Sarikaya > On Tue, Apr 10, 2012 at 11:28 PM, Maoke wrote: > > hi Behcet, > > > > 2012/4/10 Tina TSOU > >> > >> > >> > >> Sent from my iPad > >> > >> On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" > > >> wrote: > >> > >> > Hi Maoke, > >> > > >> > Thank you for your efforts in technical details of one specific > >> > proposal on the table. > >> > > >> > However, I for one think that probably it is time to concentrate on > >> > commonalities rather than the differences. As Alain indicated, these > >> > proposals do have a lot of common points. > >> > > > > > > > that proposal is basically of a response to people's call for "describing > > technical concerns in mind" about 4rd-U. commonality and difference is > the > > two sides of the same coin. if we don't understand what makes them > exactly > > different, we are also hard to understand how common they are. this > document > > is purposed in sharing such an understanding and therefore it focuses > only > > on the essential concerns -- the concerns regarding architecture and > > protocol semantics. > > > >> > >> > Why don't (whoever) write a draft putting together all the common > >> > points concentrating on CE to BR and abstracting out BIH, XLAT, etc.? > >> > Such a draft can be of great value at this point, I think. > >> That's MAP-D document. > >> > > > > > > > yes. as Tina points out, MAP deployment draft that we are working on > plays > > the role of clarifying the common deployment considerations with MAP > series. > > thanks! > > > > I would prefer calling a document that unifies both 4rd-u and MAP's 4rd. > unfortunately, we were on that track, as i member. - maoke > > This is what this whole Softwire work is aimed at, i.e. define 4rd > protocol. > > Regards, > > Behcet > --20cf300faff5aa8f3104bd69aaf6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/12 Behcet Sarikaya <sarikaya2012@gmail.com>
On Tue, Apr 10, 2012 at 11:28 PM, Maoke &= lt;fibrib@gmail.com> wrote:
> hi Behcet,
>
> 2012/4/10 Tina TSOU <Tina.Tsou.Zouting@huawei.com>
>>
>>
>>
>> Sent from my iPad
>>
>> On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com>
>> wrote:
>>
>> > Hi Maoke,
>> >
>> > Thank you for your efforts in technical details of one specif= ic
>> > proposal on the table.
>> >
>> > However, I for one think that probably it is time to concentr= ate on
>> > commonalities rather than the differences. As Alain indicated= , these
>> > proposals do have a lot of common points.
>> >
>
>
> that proposal is basically of a response to people's call for &quo= t;describing
> technical concerns in mind" about 4rd-U. commonality and differen= ce is the
> two sides of the same coin. if we don't understand what makes them= exactly
> different, we are also hard to understand how common they are. this do= cument
> is purposed in sharing such an understanding and therefore it focuses = only
> on the essential concerns -- the concerns regarding architecture and > protocol semantics.
>
>>
>> > Why don't (whoever) write a draft putting together all th= e common
>> > points concentrating on CE to BR and abstracting out BIH, XLA= T, etc.?
>> > Such a draft can be of great value at this point, I think. >> That's MAP-D document.
>> >
>
>
> yes. as Tina points out, MAP deployment draft that we are working on p= lays
> the role of clarifying the common deployment considerations with MAP s= eries.
> thanks!
>

I would prefer calling a document that unifies both 4rd-u and M= AP's 4rd.
=A0
unfortunately, we were on = that track, as i member. - maoke
=A0

This is what this whole Softwire work is aimed at, i.e. define 4rd protocol= .

Regards,

Behcet

--20cf300faff5aa8f3104bd69aaf6-- From despres.remi@laposte.net Wed Apr 11 09:25:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2CF21F8585 for ; Wed, 11 Apr 2012 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFDaYKBVR4El for ; Wed, 11 Apr 2012 09:25:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 507AE21F8577 for ; Wed, 11 Apr 2012 09:25:48 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id wgRl1i00F37Y3f403gRlcJ; Wed, 11 Apr 2012 18:25:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--627939728 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 11 Apr 2012 18:25:45 +0200 Message-Id: <74D95FF4-2DC4-4502-A9F3-49EF1E72E0AD@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:25:49 -0000 --Apple-Mail-3--627939728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-11 =E0 17:54, Maoke a =E9crit : >=20 >=20 > 2012/4/12 R=E9mi Despr=E9s >=20 > Le 2012-04-11 =E0 15:44, Maoke a =E9crit : >=20 >>=20 >> postpone other parts, but focus on the checksum issue.=20 >> 2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net >> =20 >> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled = ICMPv4 message, the ICMPv4 checksum doesn't ensure IPv6 address = integrity. But this integrity can be ensured at tunnel exit by checking = that CNPs do preserve checksum neutrality. This can be clarified by a = complement in the 4rd-u security section. >> =20 >> =20 >> 1. this introduces another new semantics/logic of protocol stack = processing at exit CE. it is really hard to call it either IPv4 or IPv6.=20= >=20 > How it is called is IMHO secondary, what is a fact is that it ensures = address security.=20 > =20 >> 2. even though this CNP works for the address integrity, >=20 > (which was the listed point) >=20 >> unfortunately, however, the checksum still provides integrity = protection for packet length and payload protocol type in both = IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. they are involved either in IPv4 = header checksum or in ICMPv6 checksum, which covers the pseudo-header of = IPv6.=20 >=20 >=20 >> how could CNP protect these? >=20 > No way, of course. > (Are we now in the technical discussion, or still in deliberate = controversy?). >=20 > =20 > technical discussion results in problem understanding instead of = certainly a support for or an objection to a work politically. so i = don't understand what is the so-called "deliberate controversy" here. I supposed it was evident to you too that CNP cannot protect protocol = and/or packet length. Then, asking how it would do that sounded to me as a non technical = question. Sorry if this wasn't the case. =20 > i suppose my draft is written very neutral. Full of good level technical analysis, I am pleased to acknowledge. Although I believe anyone asked to guess whether you are in favor of 4rd = or MAP would easily find the answer, I can also acknowledge that the = draft is neutral to a good enough extent. > as you raised a new solution regarding a concern while i found it not = complete, i surely need to confirm if you would design a more = comprehensive solution for that issue, and if the already-designed = mechanism has had the functionality but i was not aware of that. >> thanks for mentioning CNP here. >=20 >> i need to modify the concern for "address integrity" to the concern = for "integrity of addresses, packet length and payload protocol type". >=20 > - Addresses have been covered AFAIAC. > - No test scenario I can imagine can reveal an ICMPv4 security problem = concerning protocol type or packet length. (A simulated hardware failure = would AFAIK be needed, and with that, many other security problems can = be considered to exist.)=20 > =20 > =3D> Unless you come up with new facts, end of this subject for me. > =20 > =20 > i don't think it is needed to provide new facts here, at this stage. > the test scenario is the next step.=20 OK. > the draft is purposed on clarifying these semantics and their direct = impact. judgment on the severity of the impacts is remained to the = readers. OK. > i don't think 4rd-u is scoped within networks with reliable L2 links, = isn't it? It is scoped under the common assumption that: (1) L2 isn't reliable in = that it can loose packets; (2) L2 is reliable in that it never delivers = corrupted packets without corruption being detected. AFAIK, IPv6 has been specified under this assumption. RD > then, in a generic physical environment, one may think only address = checksum is enough, one may think it is not enough, one may think = checksum is anyway too weak to provide so-called protection, etc. --- = all of these sort of asserts of severity judgment are out of the scope = the draft (sec 5 para 1). > =20 > fine to close this subject for me too because you have clarified "no = way". that's enough. a refined statement on this issue will appear in = the revision. > =20 > tomorrow let me clarify another. > =20 > thanks, > maoke > =20 > =20 >=20 > RD >=20 > =20 --Apple-Mail-3--627939728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/4/12 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-04-11 =E0 = 15:44, Maoke a =E9crit :


postpone other parts, but focus on the checksum issue. =
2012/4/11 R=E9mi Despr=E9s despres.remi@laposte.net
 
5.4 Impact c. = - it is true that, in the IPv6 packet of a tunneled ICMPv4 message, the = ICMPv4 checksum doesn't ensure IPv6 address integrity. But this = integrity can be ensured at tunnel exit by checking that CNPs do = preserve checksum neutrality. This can be clarified by a complement in = the 4rd-u security section.
 
 
1. this = introduces another new semantics/logic of protocol stack = processing at exit CE. it is really hard to call it either IPv4 or = IPv6. 

How it is called is IMHO secondary, what is a fact = is that it ensures address security. 
 
2. even though this CNP works for the = address integrity,

(which was the listed = point)

unfortunately, however, the checksum = still provides integrity protection for packet length and = payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. = they are involved either in IPv4 header checksum or in ICMPv6 = checksum, which covers the pseudo-header of IPv6. 


how could CNP protect = these?

No way, of = course.
(Are we now in the technical discussion, or still in = deliberate controversy?).

 
tech= nical discussion results in problem understanding instead of certainly a = support for or an objection to a work politically. so i don't = understand what is the so-called "deliberate controversy" here. =

I supposed it was evident = to you too that CNP cannot protect protocol and/or packet = length.
Then, asking how it would do that sounded to me as a = non technical question.
Sorry if this wasn't the case. =  

i suppose my draft is written very neutral. =

Full of good = level technical analysis, I am pleased to = acknowledge.
Although I believe anyone asked to guess whether = you are in favor of 4rd or MAP would easily find the answer, I can also = acknowledge that the draft is neutral to a good enough = extent.


as you raised a new = solution regarding a concern while i found it not complete, i = surely need to confirm if you would design a = more comprehensive solution for that issue, and if the = already-designed mechanism has had the functionality but i was not aware = of that.
thanks for mentioning CNP here. =

i need to modify the concern for "address = integrity" to the concern for "integrity of addresses, packet length and = payload protocol type".

- Addresses have been = covered AFAIAC.
- No test scenario I can imagine can reveal = an ICMPv4 security problem concerning protocol type or packet = length. (A simulated hardware failure would AFAIK be needed, and with = that, many other security problems can be considered to = exist.) 
 
=3D> Unless you come up with new = facts, end of this subject for = me.
 
  
=
i don't think it is needed to provide new facts here, at this = stage.

the test scenario is the next = step. 

OK.

the draft is = purposed on clarifying these semantics and their direct impact. judgment = on the severity of the impacts is remained to the readers. =

OK.

i don't think 4rd-u is scoped within networks with reliable L2 = links, isn't it?

It is = scoped under the common assumption that: (1) L2 isn't reliable in that = it can loose packets; (2) L2 is reliable in that it never delivers = corrupted packets without corruption being detected.
AFAIK, = IPv6 has been specified under this = assumption.

RD


then, in = a generic physical environment, one may think only address checksum is = enough, one may think it is not enough, one may think checksum is anyway = too weak to provide so-called protection, etc. --- all of these = sort of asserts of severity judgment are out of the scope the draft (sec = 5 para 1).
 
fine to close this subject for me too because = you have clarified "no way". that's enough. a refined = statement on this issue will appear in the revision. =
 
tomorrow let me clarify another.
=
 
thanks,
maoke
 
=
 

R= D

 

= --Apple-Mail-3--627939728-- From sarikaya2012@gmail.com Wed Apr 11 09:30:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2721F8594 for ; Wed, 11 Apr 2012 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W8CurpQFmzo for ; Wed, 11 Apr 2012 09:30:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4677521F858E for ; Wed, 11 Apr 2012 09:30:25 -0700 (PDT) Received: by iazz13 with SMTP id z13so1786029iaz.31 for ; Wed, 11 Apr 2012 09:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=O51OwtK8/YzkPwjAC0l5+UDhyzK5OPFbKhznhIVMARY=; b=v3wOPmH9N8SqNHX20FBy8oqqJmgL6iB+EOwHREU66ntwR1tiHwEpw6sfxqyOjdNV1D A1Ukk7EEkNhggOgUNZZapKOnkaLHwtTSzIkNUOE95pnw3YPKvrDkSKCMPpHuqiW+0rrD kmtopLm40qEfeWgXGrUG4UIFLsG5f7ck/Xsc+WwGQGaO9jW9ZtC0ZQgBPx/9WQZjy/sQ j9YrMUAuI3CIEZIFq17+fx+e42TAR6+Oqv5WldTQHskmbTTKJObJqr56Lw2TMwdK2rNV /pdISq8Gw7cYYwu9MRnQJZrB11GTlbMjyODozzE4Y8aYcOrNzEqFbaiiqXx73d7EMGv6 rZvw== MIME-Version: 1.0 Received: by 10.50.159.202 with SMTP id xe10mr6304372igb.66.1334161824853; Wed, 11 Apr 2012 09:30:24 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 11 Apr 2012 09:30:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 11:30:24 -0500 Message-ID: From: Behcet Sarikaya To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:30:26 -0000 On Tue, Apr 10, 2012 at 10:29 PM, Maoke wrote: > hi Yiu, > > sorry but i just found i missed a technical issue you left in this messag= e. > > 2012/4/9 Lee, Yiu > >> >> =A0 =A0on the other hand, 4rd-u makes a tight coupling between the addre= ss >> format >> =A0 =A0and its own header mapping mechanism. this makes an operator unab= le to >> have >> =A0 =A0different choices of transition mechanism as long as it chooses 4= rd-u. >> if >> =A0 =A0you concern the choice of IPv6 transition mechanism, i do recomme= nd >> MAP, as >> =A0 =A0either encapsulation or translation is operatable with MAP >> address/port >> =A0 =A0mapping without difficulty. >> >> [YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupli= ng >> address format and header mapping? > > > tight coupling here, i mean, that 4rd-u header mapping mechanism sometime= s > depends on features of the address format, like the CNP and the V-octet. = for > example, it removes the L4 checksum adjustment, this makes the whole syst= em > MUST following the addressing with CNP. > > for the MAP, things are different. boxes are implemented with existing > header processing modules but only need to add MAP address mapping module > into them. once the operator deploys MAP following its addressing plan > paradigm (we are still working on a better guidance for this in the MAP > deployment draft), the operator can choose either MAP-T or MAP-E for the > header mapping without the need of changing their addressing plan. if the > operator find translation is suitable for this part after a certain perio= d > of practice on encapsulation, it can switch the mode by informing the CE = to > change the mode of working (surely sometimes such an action of informing = is > not easy in practice for, e.g., the home CE subscribers but it is feasibl= e > for enterprise networking). another example of de-coupling is translation > approach: RFC6052 defines a stateless address mapping while RFC6145 defin= es > the header processing which is usable for both stateless and stateful > solutions, both 1:1 case for non-renumbering transition and residual > deployment of MAP. > > implementation does also benefit from the de-coupling. the RFC6145 > translation module can directly work with address mapping module of MAP o= r > RFC6052. the MAP address module can work with header processing module of > RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T). > > it doesn't mean the tight coupling doesn't work. like the Burton snowboar= d, > it works fantastically with its own system of bindings, not interchangabl= e > for other brands ;-) however, in most of time, we really think > interchangability, supported by loose coupling, is preferred. > I fail to understand why there is so much hype around these standards, 6145 is the good old SIIT 6052 defines NAT64 prefixes. Behcet From phdgang@gmail.com Wed Apr 11 09:42:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF21B11E809A for ; Wed, 11 Apr 2012 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExpAtJSMi3va for ; Wed, 11 Apr 2012 09:42:13 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA911E8089 for ; Wed, 11 Apr 2012 09:42:12 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4003043wib.13 for ; Wed, 11 Apr 2012 09:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OAGHOnXKq6QjqYSGbKR96tj+sHkA42tglTujC133gnU=; b=iuNuxSDVlNVlRBxvA3Ghi8/ixIOvH8tHe1UYDQb04O9410IGCb8aWJix1XR5qrunl7 aRxOqlZBFdBBXbF2AvBkynFO0yX9z9TpPq55RQzugHzmc4q/dkwpMEKesO5jKTAYhZPE hG+BVJYa4iVfNi6R/4iVG/Rg94WCsmL6LoO5w/KzV/RL+8Uq7A0sXg13ZM1+cRZz8Q45 MGAd0H1qLceXar7jpUXyAiYnaN9Tq55HRxV8Xkda6IzleRL8/PGDtVVk6ZZx7AJMkJZ8 YAaXu1ucwCtM+1gTnXmj9Wr6Uuh8ORoc9b71x1/YHYEZVpTEsBYEeDzwlolwfsVsOjGm 2tBQ== MIME-Version: 1.0 Received: by 10.180.88.169 with SMTP id bh9mr17981066wib.5.1334162532156; Wed, 11 Apr 2012 09:42:12 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Wed, 11 Apr 2012 09:42:12 -0700 (PDT) In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Date: Thu, 12 Apr 2012 00:42:12 +0800 Message-ID: From: GangChen To: "softwires@ietf.org WG" , "int-ads@tools.ietf.org" , Softwire Chairs , Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:42:13 -0000 ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. ---------------------------------------------------------------------------- Full name: Gang Chen Affiliation: China Mobile neither YES nor NO(*) (*)Assuming there is alternative choice. It would be preferable to advance all going to experimental at this stage. ---------------------------------------------------------------------------- 2012/4/5, Alain Durand : > Dear Softwire wg members: > > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a > whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should make > this > decision relatively quickly. > > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. > > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. > > ===================================================================== > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a > whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as > standard track. > Answering NO to this question means you want to see both advance on the > standard track. > > ---------------------------------------------------------------------------- > Your full name, your affiliation, your choice: YES or NO > ---------------------------------------------------------------------------- > > > ===================================================================== > > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? > > ------------------------------------------------------------------------------ > Your full name, your affiliation, your choice: 4rd-U or MAP > ------------------------------------------------------------------------------ > > ===================================================================== > > > > > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. > > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. > > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From yiu_lee@cable.comcast.com Wed Apr 11 10:03:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6514A21F8507 for ; Wed, 11 Apr 2012 10:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.594 X-Spam-Level: X-Spam-Status: No, score=-100.594 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcRhjDUTew8W for ; Wed, 11 Apr 2012 10:03:16 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BC40821F8504 for ; Wed, 11 Apr 2012 10:03:15 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.12979276; Wed, 11 Apr 2012 10:50:09 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 13:03:12 -0400 From: "Lee, Yiu" To: Alain Durand , "softwires@ietf.org WG" Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: AQHNGAT5LiblsLv050eGcrzPHLsxiQ== Date: Wed, 11 Apr 2012 17:03:10 +0000 Message-ID: In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416994188_996553" MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:03:16 -0000 --B_3416994188_996553 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ===================================================================== Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish both as standard track. Answering NO to this question means you want to see both advance on the standard track. --------------------------------------------------------------------------- - Your full name, your affiliation, your choice: YES or NO --------------------------------------------------------------------------- - Yiu Lee, Comcast, Neither YES or No because IMHO I don't think we are ready to make the choice. On 4/4/12 5:14 PM, "Alain Durand" wrote: >Dear Softwire wg members: > >At the Paris IETF Softwire meeting, we had presentations on MAP (taken as >a whole) and >4rd-U. We got very strong feedback that we needed to select one >solution to cover that full stateless case, not two, and that we should >make this >decision relatively quickly. > >During Paris meeting, we asked the following additional question: >Do you prefer MAP or 4rd-U? >We got about 1/3 support for 4rd-U and 2/3 for MAP. > >The real gauge of consensus is the mailing list, so we would like >to ask the same questions to the list. > >===================================================================== >Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a >whole) on the standard track, >the other being published as experimental or informational. >Answering YES to this question means you agree we cannot publish both as >standard track. >Answering NO to this question means you want to see both advance on the >standard track. > >-------------------------------------------------------------------------- >-- >Your full name, your affiliation, your choice: YES or NO >-------------------------------------------------------------------------- >-- > > >===================================================================== > >Questions 2: Which one do you want to see placed on the Standards Track: >4rd-U or MAP? > >-------------------------------------------------------------------------- >---- >Your full name, your affiliation, your choice: 4rd-U or MAP >-------------------------------------------------------------------------- >---- > >===================================================================== > > > > >Please fill out the following form and reply to the list >by Wednesday 4/10 5pm EDT. > >Note: Use this thread ONLY for expressing your support to >one OR the other, and redirect any discussions to other threads. >That would help up gauge consensus. > >Alain & Yong. >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3416994188_996553 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQPiuUU zmcINFiGHuJLQ3NYXDwcLTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MTExNzAzMDdaMA0GCSqGSIb3DQEBAQUABIIBAHrJuOXtaFZ0b7I34g+MpQ4q ge1sYsWik3QN9i/8IyXrj49vdqBh8wUVzgjnaC5TOrgc5Q6qNuLcEasV0UYGX+q2UhsB1dvW sVsWUWIeWZwoewSsgunjHS2AToo54FkYyAl9JD9Hiffbm8HZXlbGLI83qUQUq6IIX4l88mvi aypansh7XlbZU701xpcvcZ6TA6qD4YxqPtGI4qTCg5HPunqPA9p6E90tJ1lEztbG2p5+0e6n IfN6cJ8ojoFOcKqmybpg+2Az+yCWpzX8AJgXHZOHOzNMGD85HWFGk8PkL0qs/uVtMNMDG+BO ATYAyGxt9DJvHVUR4k1pBSl/tdfCDUM= --B_3416994188_996553-- From adurand@juniper.net Wed Apr 11 14:05:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4182411E80B8 for ; Wed, 11 Apr 2012 14:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5i1zKjGtpgu for ; Wed, 11 Apr 2012 14:05:07 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0D611E80DB for ; Wed, 11 Apr 2012 14:04:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT4Xx91BSsW8IcaV2wWYBXETD4AKnY44v@postini.com; Wed, 11 Apr 2012 14:05:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 11 Apr 2012 14:04:53 -0700 From: Alain Durand To: "softwires@ietf.org WG" Date: Wed, 11 Apr 2012 14:04:53 -0700 Thread-Topic: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP Thread-Index: Ac0YJr2ugscyC7+OStSpRIyQu8Farw== Message-ID: References: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> In-Reply-To: <3B4C6C74-C766-4CC2-9722-64603926AC29@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" , Softwire Chairs Subject: Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:05:08 -0000 The poll is now closed. The chairs will get together with the ADs and get b= ack shortly to the mailing list of what we think the next step is. Alain. On Apr 4, 2012, at 5:14 PM, Alain Durand wrote: > Dear Softwire wg members: >=20 > At the Paris IETF Softwire meeting, we had presentations on MAP (taken as= a whole) and > 4rd-U. We got very strong feedback that we needed to select one > solution to cover that full stateless case, not two, and that we should m= ake this > decision relatively quickly. >=20 > During Paris meeting, we asked the following additional question: > Do you prefer MAP or 4rd-U? > We got about 1/3 support for 4rd-U and 2/3 for MAP. >=20 > The real gauge of consensus is the mailing list, so we would like > to ask the same questions to the list. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a= whole) on the standard track, > the other being published as experimental or informational. > Answering YES to this question means you agree we cannot publish both as = standard track. > Answering NO to this question means you want to see both advance on the s= tandard track. >=20 > -------------------------------------------------------------------------= --- > Your full name, your affiliation, your choice: YES or NO > -------------------------------------------------------------------------= --- >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Questions 2: Which one do you want to see placed on the Standards Track: > 4rd-U or MAP? >=20 > -------------------------------------------------------------------------= ----- > Your full name, your affiliation, your choice: 4rd-U or MAP > -------------------------------------------------------------------------= ----- >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > Please fill out the following form and reply to the list > by Wednesday 4/10 5pm EDT. >=20 > Note: Use this thread ONLY for expressing your support to > one OR the other, and redirect any discussions to other threads. > That would help up gauge consensus. >=20 > Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Wed Apr 11 15:14:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817A511E8087 for ; Wed, 11 Apr 2012 15:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZXZdAfhwbJG for ; Wed, 11 Apr 2012 15:14:51 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CE11E8073 for ; Wed, 11 Apr 2012 15:14:48 -0700 (PDT) Received: by qaea16 with SMTP id a16so1097995qae.10 for ; Wed, 11 Apr 2012 15:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k/rFnSs4Vh32Ud+5afW8UKOlEKflUBDkXbaAwO9Grek=; b=OE4usxasB81E0GqpVHN2w1Ez6KrogvpO1QBFdQgwtMxyNjqiQBi3eKdPqpidGcu4gt ++JDQnIzZBzsaJP0S529OOTEqAUf14SH2It/BTbamft4pG5OrqXOGdGbghNJzwuigRil gqQA4Ok9wJN9j4z37VDUtNdGZX7IFNjpjiWO7M0JZlgN7xIhKfqx2POmDe49ahz/qKul ZAKl+4JeTp7nLGTbIH5iulU0dl+Vr0TWKiIEqRNUMsVBoUz3XmbZDB4xDsS7xBnmbfy1 +C3f1nYb++Am8xjnRqhZvQvBdcoHMeGXOcQbbZKqOWdLoIMgd5iedCoQPfXFglWPoxWi caMA== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr923252qao.23.1334182488047; Wed, 11 Apr 2012 15:14:48 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 15:14:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 07:14:47 +0900 Message-ID: From: Maoke To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf3074b41a44005504bd6e9156 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:14:52 -0000 --20cf3074b41a44005504bd6e9156 Content-Type: text/plain; charset=ISO-8859-1 2012/4/12 Behcet Sarikaya > On Tue, Apr 10, 2012 at 10:29 PM, Maoke wrote: > > hi Yiu, > > > > sorry but i just found i missed a technical issue you left in this > message. > > > > 2012/4/9 Lee, Yiu > > > >> > >> on the other hand, 4rd-u makes a tight coupling between the address > >> format > >> and its own header mapping mechanism. this makes an operator unable > to > >> have > >> different choices of transition mechanism as long as it chooses > 4rd-u. > >> if > >> you concern the choice of IPv6 transition mechanism, i do recommend > >> MAP, as > >> either encapsulation or translation is operatable with MAP > >> address/port > >> mapping without difficulty. > >> > >> [YL] Sorry for my lack of knowledge. Please explain how MAP isn't > coupling > >> address format and header mapping? > > > > > > tight coupling here, i mean, that 4rd-u header mapping mechanism > sometimes > > depends on features of the address format, like the CNP and the V-octet. > for > > example, it removes the L4 checksum adjustment, this makes the whole > system > > MUST following the addressing with CNP. > > > > for the MAP, things are different. boxes are implemented with existing > > header processing modules but only need to add MAP address mapping module > > into them. once the operator deploys MAP following its addressing plan > > paradigm (we are still working on a better guidance for this in the MAP > > deployment draft), the operator can choose either MAP-T or MAP-E for the > > header mapping without the need of changing their addressing plan. if the > > operator find translation is suitable for this part after a certain > period > > of practice on encapsulation, it can switch the mode by informing the CE > to > > change the mode of working (surely sometimes such an action of informing > is > > not easy in practice for, e.g., the home CE subscribers but it is > feasible > > for enterprise networking). another example of de-coupling is translation > > approach: RFC6052 defines a stateless address mapping while RFC6145 > defines > > the header processing which is usable for both stateless and stateful > > solutions, both 1:1 case for non-renumbering transition and residual > > deployment of MAP. > > > > implementation does also benefit from the de-coupling. the RFC6145 > > translation module can directly work with address mapping module of MAP > or > > RFC6052. the MAP address module can work with header processing module of > > RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T). > > > > it doesn't mean the tight coupling doesn't work. like the Burton > snowboard, > > it works fantastically with its own system of bindings, not > interchangable > > for other brands ;-) however, in most of time, we really think > > interchangability, supported by loose coupling, is preferred. > > > > > > I fail to understand why there is so much hype around these standards, > > 6145 is the good old SIIT > 6052 defines NAT64 prefixes. > 2765 is the old SIIT. 6145 changes it to a certain extent. the above is just my understanding on the content separation of 6052, 6144, 6145, 6146. what i said was only one point -- "decoupling". and i like these standards having this. i don't see where there is "so much". as to the "hype", well, no comment. out of technical discussion. ;-) - maoke > > Behcet > --20cf3074b41a44005504bd6e9156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/4/12 Behcet Sarikaya = <sarikaya2012@gmail.com>= ;
On Tue, Apr 10, 2012 at 10:29 PM, Maoke &= lt;fibrib@gmail.com> wrote:
> hi Yiu,
>
> sorry but i just found i missed a technical issue you left in this mes= sage.
>
> 2012/4/9 Lee, Yiu <Yiu= _Lee@cable.comcast.com>
>
>>
>> =A0 =A0on the other hand, 4rd-u makes a tight coupling between the= address
>> format
>> =A0 =A0and its own header mapping mechanism. this makes an operato= r unable to
>> have
>> =A0 =A0different choices of transition mechanism as long as it cho= oses 4rd-u.
>> if
>> =A0 =A0you concern the choice of IPv6 transition mechanism, i do r= ecommend
>> MAP, as
>> =A0 =A0either encapsulation or translation is operatable with MAP<= br> >> address/port
>> =A0 =A0mapping without difficulty.
>>
>> [YL] Sorry for my lack of knowledge. Please explain how MAP isn= 9;t coupling
>> address format and header mapping?
>
>
> tight coupling here, i mean, that 4rd-u header mapping mechanism somet= imes
> depends on features of the address format, like the CNP and the V-octe= t. for
> example, it removes the L4 checksum adjustment, this makes the whole s= ystem
> MUST following the addressing with CNP.
>
> for the MAP, things are different. boxes are implemented with existing=
> header processing modules but only need to add MAP address mapping mod= ule
> into them. once the operator deploys MAP following its addressing plan=
> paradigm (we are still working on a better guidance for this in the MA= P
> deployment draft), the operator can choose either MAP-T or MAP-E for t= he
> header mapping without the need of changing their addressing plan. if = the
> operator find translation is suitable for this part after a certain pe= riod
> of practice on encapsulation, it can switch the mode by informing the = CE to
> change the mode of working (surely sometimes such an action of informi= ng is
> not easy in practice for, e.g., the home CE subscribers but it is feas= ible
> for enterprise networking). another example of de-coupling is translat= ion
> approach: RFC6052 defines a stateless address mapping while RFC6145 de= fines
> the header processing which is usable for both stateless and stateful<= br> > solutions, both 1:1 case for non-renumbering transition and residual > deployment of MAP.
>
> implementation does also benefit from the de-coupling. the RFC6145
> translation module can directly work with address mapping module of MA= P or
> RFC6052. the MAP address module can work with header processing module= of
> RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T).
>
> it doesn't mean the tight coupling doesn't work. like the Burt= on snowboard,
> it works fantastically with its own system of bindings, not interchang= able
> for other brands ;-) however, in most of time, we really think
> interchangability, supported by loose coupling, is preferred.
>



I fail to understand why there is so much hype around these sta= ndards,

6145 is the good old SIIT
6052 defines NAT64 prefixes.
=A0
2765 is the= old SIIT. 6145 changes it to a certain extent.=A0
=A0
= the above is just my understanding on the content separation=A0of 6052, 614= 4, 6145, 6146.=A0what i said=A0was only one point -- "decoupling"= . and=A0i like these standards having this.=A0i don't see where there i= s "so much".=A0=A0as to the "hype", well, no comment. o= ut of technical discussion. ;-)
=A0
- maoke
=A0

Behcet

--20cf3074b41a44005504bd6e9156-- From fibrib@gmail.com Wed Apr 11 18:13:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E417E11E8108 for ; Wed, 11 Apr 2012 18:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSlUTaxS78h5 for ; Wed, 11 Apr 2012 18:13:58 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 273D811E80FD for ; Wed, 11 Apr 2012 18:13:58 -0700 (PDT) Received: by qafi31 with SMTP id i31so4072727qaf.15 for ; Wed, 11 Apr 2012 18:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uIgZHeJFYOaMbf2ap1hvJwKCOehWDLcPspZnlivKG3g=; b=uTTlz4893oPsryWx+RlBT/ibcVN8uvvMSFCwndGZQcEc8mOewLc9Zx89w1QVGvFa3X nfsNcCQkKy1x6VjHqt6Vc7O5H2kg417l4Bpf0OkF8lB+fz1/W9KrGcn6V3OVNPNj4B8C hj0OHu9l4WFlslEArLzkxQrpOzMyr/mERyTGgiC932C1HZe9hVwmNLvnrf2CUNhRKGpB RhbaMR0gIK50PZMlvrnes1L15sgV12pBREP1g+cBMFStz7hP67dxs0c1zGpVmCsq+YGI GsEdOjQWO/LL0J3qWssHqC6t201zniERg9gRfXDUKSdUTROBzUNwWWkwQxtUn3g0SB1I SV6g== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr1414654qab.49.1334193237741; Wed, 11 Apr 2012 18:13:57 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 18:13:57 -0700 (PDT) In-Reply-To: <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> Date: Thu, 12 Apr 2012 01:13:57 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dcfc9ff4fd004bd7111b7 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 01:13:59 -0000 --485b397dcfc9ff4fd004bd7111b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable second point, on tunnel and transparency. 2012/4/11 R=E9mi Despr=E9s > 6. The statement that "double translation is also a sort of tunneling in > general sense" is IMHO confusing in view of its lack of IPv4 end-to-end > transparency. > limited to the definition of "a source route that circumvents conventional routing mechanisms", IMHO, it has no business with the end-to-end transparency and therefore not confusing with explictly specifying "in general sense". > The statement that "It needs further investigation to ensure if 4rd-U is > qualified to be called as a tunnel in the narrow sense" expresses a doubt > without substance to justify it. > because 4rd-u draft calls itself a "tunnel". the commentary identifies it is surely a general-sense tunnel. the commentary tries to understand whether it is also a narrow-sense tunnel but did not yet concluded at the time of writing. now it looks we can conclude that 4rd-u is hard to be called as a tunnel in the narrow sense. see below, regarding the transparency. > 4rd-U only claims that IPv4 packets traverse ISP domains transparently > (unless they have IPv4 options in which case the domain signals it doesn'= t > support them). > now we have clearified the checksum end-to-end transparency covering payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will continue, to reflect this understanding too, by explicitly claiming that 4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum covering payload length and payload protocol type (instead of only mentioning options) when the payload is ICMPv4, less than the transparency provided by encapsulation. commentary document will include this understanding in next revision, without judging how severe this concern is in practice. if no further significant dissent, this subsubject is closed. - maoke --485b397dcfc9ff4fd004bd7111b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable second point, on tunnel and transparency. =A0

2012/4/11 R=E9mi Despr=E9s <despres.remi@laposte.net>
6. The statement that "double= translation is also a sort of tunneling in general sense" is IMHO con= fusing in view of its lack of IPv4 end-to-end transparency.

limited to the definition of "a source route that = circumvents conventional routing mechanisms", IMHO, it has no business= with the end-to-end transparency and therefore not confusing with explictl= y specifying "in general sense".=A0
=A0
The statement that "It needs further investigation to ensur= e if 4rd-U is qualified to be called as a tunnel in the narrow sense" = expresses a doubt without substance to justify it.

because 4rd-u draft calls itself a &= quot;tunnel". the commentary identifies it is surely a general-sense t= unnel. the commentary tries to understand whether it is also a narrow-sense= tunnel but did not yet concluded at the time of writing. now it looks we c= an conclude that 4rd-u is hard to be called as a tunnel in the narrow sense= . see below, regarding the transparency.=A0
=A0
4rd-U only claims that IPv4 packets traverse ISP domains transpa= rently (unless they have IPv4 options in which case the domain signals it d= oesn't support them).

now we have clearified the che= cksum end-to-end transparency covering payload length and payload protocol = type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is r= evised, if anyway the work will continue, to reflect this understanding too= , by explicitly claiming that 4rd-u keeps end-to-end transparency for most = of IPv4 fields but checksum covering payload length and payload protocol ty= pe (instead of only mentioning options) when the payload is ICMPv4, less th= an the transparency provided by encapsulation.=A0

commentary document will include this understanding in = next revision, without judging how severe this concern is in practice.=A0

if no further significant dissent, this subsubj= ect is closed.=A0

- maoke
--485b397dcfc9ff4fd004bd7111b7-- From fibrib@gmail.com Wed Apr 11 19:04:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1011E810B for ; Wed, 11 Apr 2012 19:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOrdquH04DOp for ; Wed, 11 Apr 2012 19:04:14 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 76B5C11E8108 for ; Wed, 11 Apr 2012 19:04:14 -0700 (PDT) Received: by qafi31 with SMTP id i31so4097455qaf.15 for ; Wed, 11 Apr 2012 19:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MM+QWwvp3w8Nm8s/tLmRefOt9UU+DFl+KariiJudxC4=; b=tu1Tjybqf5IEtwN6pwPqUct4a8vYe+LLjEyoO/pocGvoA/8gtoZjooIgRIwkq+/fy6 YbhUiMq8umVg0Up/TmwcrfrPYZyEIwiEPRG5Mt1Ut1CkhFUxfQL3VAmqf3MQFlIkmLbj BNfLem14IBZO5f866zybHE0AmrNzXDnvv7yvZx8XJpm5O7ESjJmUFh4fgPXyj78z0Jz0 8WaCrJd6ao+NypGkms2LTFfU2PwDZy/hFVknMn7vpLUhPs/G4U/4tMUylCy6X1OV15Jx o4UHqw6bGSOsgpPq/wpLgI+NkB/p10GQmHG0cTAgVuMnaBcc6Z3rldsGYlyqRUL2FvDP GM1A== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr1615238qao.23.1334196253962; Wed, 11 Apr 2012 19:04:13 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 19:04:13 -0700 (PDT) In-Reply-To: <74D95FF4-2DC4-4502-A9F3-49EF1E72E0AD@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <74D95FF4-2DC4-4502-A9F3-49EF1E72E0AD@laposte.net> Date: Thu, 12 Apr 2012 02:04:13 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b41ac730c204bd71c508 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 02:04:15 -0000 --20cf3074b41ac730c204bd71c508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/4/11 R=E9mi Despr=E9s > > > technical discussion results in problem understanding instead of certainl= y > a support for or an objection to a work politically. so i don't understan= d > what is the so-called "deliberate controversy" here. > > > I supposed it was evident to you too that CNP cannot protect protocol > and/or packet length. > Then, asking how it would do that sounded to me as a non technical > question. > Sorry if this wasn't the case. > sorry but my way of asking was possibly confusing. i really thought CNP itself couldn't do that but i worried if i missed some thing or some straightforward possibility of easy refinement, and therefore i asked you for confirmation. > > i suppose my draft is written very neutral. > > > Full of good level technical analysis, I am pleased to acknowledge. > Although I believe anyone asked to guess whether you are in favor of 4rd > or MAP would easily find the answer, I can also acknowledge that the draf= t > is neutral to a good enough extent. > > this draft is written quite earlier but i postpone its submission, trying to avoid an impression that i attempt to bias people's selection, until the vote was close to the end while you and others also called for technical details about the semantics concerns in my mind. i would like to say, in the program of the wg, i am in favor of MAP, but this favor is essentially for now, supporting MAP as wg doc in standard track. in the term of problem understanding, i am in favor of any serious explorations. to this extent, facing the future, i think a neutral but pure technical commentary is needed. we haven't seen the wg decision. however, no matter the decision is, there is a possibility that the work or similar exploration of 4rd-u would continue. if the 4rd-u becomes historical, we must learn something from the history and clearly understand why it is considered not working well enough; if 4rd-u becomes experimental, we are obliged to tell the community that there are something changed but we still, moderately, recommend it in the case that these changes do not severely impact the practice. were there no MAP, i would do the same. that's the purpose. thanks for understanding, maoke --20cf3074b41ac730c204bd71c508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,=A0

2012/4/11 R=E9mi Des= pr=E9s <de= spres.remi@laposte.net>


technical disc= ussion results in problem understanding instead of certainly a support for = or an=A0objection to a work politically. so i don't understand what is = the so-called "deliberate controversy" here.

I supposed it was evident to y= ou too that CNP cannot protect protocol and/or packet length.
The= n, asking how it would do that sounded to me as a non technical question.
Sorry if this wasn't the case. =A0
<= div>
sorry but my way of asking was possibly confusing. i rea= lly thought CNP itself couldn't do that but i worried if i missed some = thing or some straightforward possibility of easy refinement, and therefore= i asked you for confirmation.=A0
=A0

i suppose my draft is written very neutral.
<= div>
Full of good level=A0technical analysis, I am pleased t= o acknowledge.
Although I believe anyone asked to guess whether y= ou are in favor of 4rd or MAP would easily find the answer, I can also ackn= owledge that the draft is=A0neutral to a good enough extent.


this draft is w= ritten quite earlier but i postpone its submission, trying to avoid an impr= ession that i attempt to bias people's selection, until the vote was cl= ose to the end while you and others also called for technical details about= the semantics concerns in my mind. i would like to say, in the program of = the wg, i am in favor of MAP, but this favor is essentially for now, suppor= ting MAP as wg doc in standard track. in the term of problem understanding,= i am in favor of any serious explorations. to this extent, facing the futu= re, i think a neutral but pure technical commentary is needed.=A0

we haven't seen the wg decision. however, no matter= the decision is, there is a possibility that the work or similar explorati= on of 4rd-u would continue. if the 4rd-u becomes historical, we must learn = something from the history and clearly understand why it is considered not = working well enough; if 4rd-u becomes experimental, we are obliged to tell = the community that there are something changed but we still, moderately, re= commend it in the case that these changes do not severely impact the practi= ce. were there no MAP, i would do the same.=A0

that's the purpose.=A0

thanks for understanding,=A0
maoke
--20cf3074b41ac730c204bd71c508-- From sarikaya2012@gmail.com Wed Apr 11 19:35:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B77211E80E3 for ; Wed, 11 Apr 2012 19:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuOGO-pVHiLh for ; Wed, 11 Apr 2012 19:35:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBDC011E80BF for ; Wed, 11 Apr 2012 19:35:39 -0700 (PDT) Received: by iazz13 with SMTP id z13so2507345iaz.31 for ; Wed, 11 Apr 2012 19:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=vPIosALPUzJtnc82Oysq1vMQG/kVLJH0l6/7YdAP4ro=; b=gFvIO3PzUpTiVr4UdvMWhjplyPJDplEnSpjiyBNPFOGv3H7wRI9tjcI+G2SBcN01BJ 2jCTfLw1xcJwP9W0nsdgTGmEoCQR7Dv/ocbPnrimmxoBSlS5zeJdW6gIb5ZlYg5D83Rd ydxhPxPjgVCezp7Ye19+5djW3EU+SoLTym5vlJVjk5bOAKpN/1JHGl7IfOsnpzzfGcBO zm1ONUwWsNQaKSW/gZSX8ucASLxhWWeuD914BHtntadIbeL4HgJXkYL5NOnf6se8l+rs Q/up/JT9QoliuMro1NDXuszvMm8p8iOvlhhwFYHhFeeDUbwNIiNuxBDiQrZeOI63fGIm 77FA== MIME-Version: 1.0 Received: by 10.50.159.202 with SMTP id xe10mr560139igb.66.1334198139538; Wed, 11 Apr 2012 19:35:39 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 11 Apr 2012 19:35:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 21:35:39 -0500 Message-ID: From: Behcet Sarikaya To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 02:35:40 -0000 On Wed, Apr 11, 2012 at 5:14 PM, Maoke wrote: > > 2012/4/12 Behcet Sarikaya >> >> On Tue, Apr 10, 2012 at 10:29 PM, Maoke wrote: >> > hi Yiu, >> > >> > sorry but i just found i missed a technical issue you left in this >> > message. >> > >> > 2012/4/9 Lee, Yiu >> > >> >> >> >> =A0 =A0on the other hand, 4rd-u makes a tight coupling between the ad= dress >> >> format >> >> =A0 =A0and its own header mapping mechanism. this makes an operator u= nable >> >> to >> >> have >> >> =A0 =A0different choices of transition mechanism as long as it choose= s >> >> 4rd-u. >> >> if >> >> =A0 =A0you concern the choice of IPv6 transition mechanism, i do reco= mmend >> >> MAP, as >> >> =A0 =A0either encapsulation or translation is operatable with MAP >> >> address/port >> >> =A0 =A0mapping without difficulty. >> >> [Behcet] So you see MAP as a single protocol and say that the operator can start with either one and then change it to the other one? Then you negate yourself saying that it may not be so easy. My simple argument then is why not start with three as some people suggested and interchange between the three? All these three are different flavors of the 4rd protocol. Somehow you don't like to hear the words 4rd. From fibrib@gmail.com Wed Apr 11 20:30:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312AB21F8476 for ; Wed, 11 Apr 2012 20:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHLcq-yvXQT5 for ; Wed, 11 Apr 2012 20:30:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 067B621F8472 for ; Wed, 11 Apr 2012 20:30:34 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1186364qcs.31 for ; Wed, 11 Apr 2012 20:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KWpk8ofHpwUWn4Xq5yWQfV9ly5KZc/KzAEk8sJcJsps=; b=sJoj3gRMclhtQ4XzDSzmiWUAzoBmeM5ulGmx/ELuv3PnJGVl/0QaUUjYYxfcYNE+2k SKN9yFuDjw5YSASNHj6G2Ut7h8DXygkkymXkZfWHTa7SfI8t+MkFViYE89an4VALUs7b BQFRZY7giyJsB/ATZv1mUJrsl2sscZnNlnsyWwfJxSrrbWEu7Bm2xJ0u31IUZ2tl3La9 HGADoB2hAVoHrcLCuNSQAAGqepb/AUhy7G2Tt17eJanrpLfQq/q/Wwkw9Gv/yW4pcY1k YMtmIuS1Zoffxadndvlxc3rzEP8TzjyobYOnkCRSnFZQAHFBEO7xOXEVIMKLr9YVMxcf +h6w== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr1788235qab.49.1334201434439; Wed, 11 Apr 2012 20:30:34 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 20:30:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 03:30:34 +0000 Message-ID: From: Maoke To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=485b397dcfc98f014a04bd72fa50 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0_4rd-U_a?= =?utf-8?q?s_transparent_as_MAP-E?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 03:30:36 -0000 --485b397dcfc98f014a04bd72fa50 Content-Type: text/plain; charset=ISO-8859-1 2012/4/12 Behcet Sarikaya > >> > 2012/4/9 Lee, Yiu > >> > > >> >> > >> >> on the other hand, 4rd-u makes a tight coupling between the > address > >> >> format > >> >> and its own header mapping mechanism. this makes an operator > unable > >> >> to > >> >> have > >> >> different choices of transition mechanism as long as it chooses > >> >> 4rd-u. > >> >> if > >> >> you concern the choice of IPv6 transition mechanism, i do > recommend > >> >> MAP, as > >> >> either encapsulation or translation is operatable with MAP > >> >> address/port > >> >> mapping without difficulty. > >> >> > > [Behcet] > So you see MAP as a single protocol and say that the operator can > start with either one and then change it to the other one? > well, easy to change in the term that the device support both and only a switch-on/off is enough to work. > Then you negate yourself saying that it may not be so easy. > not easy to change in the term that in some deployment cases (like home network), CPE are controlled by users rather than the provider, so informing them to do the switch-on/off might be a sort of work. ;-) > My simple argument then is why not start with three as some people suggested and interchange between the three? > interchangeability between the three is fine but costs. MAP modules for header processings have been ready but 4rd-u header processing module must be code and administered separately. MAP address scheme is different from 4rd-u and therefore the address mapping modules are also needed to separate. you may wonder why the address format cannot be unified. i wonder too. the story is, MAP design team was aiming to make a unified address mapping format and it has reached a rough consensus on the format, as we see now in MAP draft, where V-octet and CNP are decided by the team not to include. however, some insist they are critically important. > > All these three are different flavors of the 4rd protocol. > > Somehow you don't like to hear the words 4rd. > :) well, actually, i was the one who wrote in the MAP deployment draft that MAP is defined for IPv4 residual deployment. i like the 4rd word very much because this word helps the understanding of MAP addressing plan starting from IPv6 prefix delegation, (which is quite different from the typical use case of RFC6052). recently i avoid using 4rd (but clearly MAP and 4rd-u) just because some people recently mentioning 4rd actually refer to 4rd-u only. i respect this way of calling but avoid to make any confusion by myself. hope it clarifies. - maoke --485b397dcfc98f014a04bd72fa50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/12 Behcet Sarikaya <sarikaya2012@gmail.com>
>> > 2012/4/9 Lee, Yiu <Yiu_Lee@cable.comcast.com>
>> >
>> >>
>> >> =A0 =A0on the other hand, 4rd-u makes a tight coupling be= tween the address
>> >> format
>> >> =A0 =A0and its own header mapping mechanism. this makes a= n operator unable
>> >> to
>> >> have
>> >> =A0 =A0different choices of transition mechanism as long = as it chooses
>> >> 4rd-u.
>> >> if
>> >> =A0 =A0you concern the choice of IPv6 transition mechanis= m, i do recommend
>> >> MAP, as
>> >> =A0 =A0either encapsulation or translation is operatable = with MAP
>> >> address/port
>> >> =A0 =A0mapping without difficulty.
>> >>

[Behcet]
So you see MAP as a single protocol and say that the operator can
start with either one and then change it to the other one?
=

well, easy to change in the term that the device suppor= t both and only a switch-on/off is enough to work.=A0
=A0
Then you negate yourself saying that it may not be so easy.

not easy to change in the term that in some deployment= cases (like home network), CPE are controlled by users rather than the pro= vider, so informing them to do the switch-on/off might be a sort of work. ;= -)
=A0=A0
=A0My simple argument then = is why not start with three as some people=A0
suggested and interchange between the three?

interchangeability between the three is fine but costs. MAP modules f= or header processings have been ready but 4rd-u header processing module mu= st be code and administered separately. MAP address scheme is different fro= m 4rd-u and therefore the address mapping modules are also needed to separa= te. you may wonder why the address format cannot be unified. i wonder too. = the story is, MAP design team was aiming to make a unified address mapping = format and it has reached a rough consensus on the format, as we see now in= MAP draft, where V-octet and CNP are decided by the team not to include. h= owever, some insist they are critically important.=A0
=A0

All these three are different flavors of the 4rd protocol.

Somehow you don't like to hear the words 4rd.

:) well, actually, i was the one who= wrote in the MAP deployment draft that MAP is defined for IPv4 residual de= ployment. i like the 4rd word very much because this word helps the underst= anding of MAP addressing plan starting from IPv6 prefix delegation, (which = is quite different from the typical use case of RFC6052). recently i avoid = using 4rd (but clearly MAP and 4rd-u) just because some people recently men= tioning 4rd actually refer to 4rd-u only. i respect this way of calling but= avoid to make any confusion by myself.=A0

hope it clarifies.=A0

- = maoke
--485b397dcfc98f014a04bd72fa50-- From despres.remi@laposte.net Thu Apr 12 00:43:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E95D21F85D4 for ; Thu, 12 Apr 2012 00:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sB4eWEmb8lV for ; Thu, 12 Apr 2012 00:43:34 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 19B7B21F85D1 for ; Thu, 12 Apr 2012 00:43:33 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id wvjU1i00737Y3f403vjUok; Thu, 12 Apr 2012 09:43:29 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--572877066 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 12 Apr 2012 09:43:28 +0200 Message-Id: <08D30916-0E04-4132-A624-7550D491EC1A@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:43:37 -0000 --Apple-Mail-4--572877066 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, We haven't reached common understanding on "tunnel and transparency" = yet. Please see below. 2012-04-12 03:13, Maoke: > second point, on tunnel and transparency. =20 >=20 > 2012/4/11 R=E9mi Despr=E9s > 6. The statement that "double translation is also a sort of tunneling = in general sense" is IMHO confusing in view of its lack of IPv4 = end-to-end transparency. >=20 > limited to the definition of "a source route that circumvents = conventional routing mechanisms", IMHO, it has no business with the = end-to-end transparency and therefore not confusing with explictly = specifying "in general sense". Your draft says "General-sense tunnel can be a one-hop virtual link or a = multi-hop participant in the delivery path", and doesn't say that it MAY = MODIFY packets . I still consider that calling "tunnel" a mechanism whereby packets may = be modified (DF, ICMPv4, UDP checksums) should be avoided. This is however a minor issue compared to (1) below. > The statement that "It needs further investigation to ensure if 4rd-U = is qualified to be called as a tunnel in the narrow sense" expresses a = doubt without substance to justify it. >=20 > because 4rd-u draft calls itself a "tunnel". the commentary identifies = it is surely a general-sense tunnel. the commentary tries to understand = whether it is also a narrow-sense tunnel but did not yet concluded at = the time of writing. now it looks we can conclude that 4rd-u is hard to = be called as a tunnel in the narrow sense. see below, regarding the = transparency.=20 You draft says "Narrow-sense tunnel, in architecture, behaves as a = one-hop virtual link". This is the case with 4rd-u tunnels.=20 > =20 > 4rd-U only claims that IPv4 packets traverse ISP domains transparently = (unless they have IPv4 options in which case the domain signals it = doesn't support them). >=20 > now we have clearified the checksum end-to-end transparency covering = payload length and payload protocol type is lost for IPv4/ICMPv4 = datagrams in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work = will continue, to reflect this understanding too, by explicitly claiming = that > 4rd-u keeps end-to-end transparency for most of IPv4 fields but = checksum covering payload length and payload protocol type (instead of = only mentioning options) when the payload is ICMPv4, less than the = transparency provided by encapsulation. (1) I already made the point that it is impossible to run a test that would = show, "when the payload is ICMPv4", that a received "checksum covering = payload length and payload protocol type" has been modified.=20 This would need a simulated hardware failure, i.e. an open door to = proving anything. If we don't agree on this, lets first understand why. (2) If one would assume that packets can be corrupted at L2 without being = discarded (which you seem to assume), then RFC6145 could translate a = corrupted IPv4 packet having no UDP checksum into a corrupted packet = having corrupted data and valid checksum.=20 This would be much worse, as far as security is concerned, than ICMPv4 = packets whose data would have been corrupted.=20 =20 > commentary document will include this understanding in next revision, = without judging how severe this concern is in practice. Before point 1 above is clarified, including what you said above in the = next version of your draft would be AFAIK misleading. Regards, RD =20 > =20 >=20 > if no further significant dissent, this subsubject is closed.=20 >=20 > - maoke --Apple-Mail-4--572877066 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Please see = below.


2012-04-12  03:13, = Maoke:

second point, on = tunnel and transparency.  

2012/4/11 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
6. The statement that "double = translation is also a sort of tunneling in general sense" is IMHO = confusing in view of its lack of IPv4 end-to-end transparency. =

limited to the definition of "a source route that = circumvents conventional routing mechanisms", IMHO, it has no business = with the end-to-end transparency and therefore not confusing with = explictly specifying "in general = sense".

Your draft says = "General-sense tunnel can be a one-hop virtual link or a multi-hop = participant in the delivery path", and doesn't say that it MAY MODIFY = packets .
I still consider that calling "tunnel" a mechanism = whereby packets may be modified (DF, ICMPv4, UDP = checksums) should be avoided.
This is however a minor = issue compared to (1) below.


The = statement that "It needs further investigation to ensure if 4rd-U is = qualified to be called as a tunnel in the narrow sense" expresses a = doubt without substance to justify it.

because 4rd-u draft calls itself = a "tunnel". the commentary identifies it is surely a general-sense = tunnel. the commentary tries to understand whether it is also a = narrow-sense tunnel but did not yet concluded at the time of writing. = now it looks we can conclude that 4rd-u is hard to be called as a tunnel = in the narrow sense. see below, regarding the = transparency. 

You draft = says "Narrow-sense tunnel, in architecture, behaves as a one-hop virtual link".
This is the case with 4rd-u tunnels. =

 
4rd-U only claims that IPv4 packets = traverse ISP domains transparently (unless they have IPv4 options in = which case the domain signals it doesn't support them).

now we have clearified the = checksum end-to-end transparency covering payload length and payload = protocol type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest = 4rd-u draft is revised, if anyway the work will continue, to reflect = this understanding too, by explicitly claiming that =

4rd-u keeps = end-to-end transparency for most of IPv4 fields but checksum covering = payload length and payload protocol type (instead of only mentioning = options) when the payload is ICMPv4, less than the transparency provided = by encapsulation.

(1)
I = already made the point that it is impossible to run a test that would = show, "when the payload is ICMPv4", that a received "checksum covering = payload length and payload protocol type" has been = modified. 

This would need a simulated = hardware failure, i.e. an open door to proving = anything.

If we don't agree on this, lets first = understand why.

(2)
If one would = assume that packets can be corrupted at L2 without being discarded = (which you seem to assume), then RFC6145 could translate a corrupted = IPv4 packet having no UDP checksum into a corrupted packet = having corrupted data and valid checksum. 
This = would be much worse, as far as security is concerned, than ICMPv4 = packets whose data would have been = corrupted. 
  
commentary document will include this understanding = in next revision, without judging how severe this concern is in = practice.

Before point 1 above is = clarified, including what you said above in the next version of your = draft would be AFAIK = misleading.

Regards,
RD

<= /div>
 
 

if no further = significant dissent, this subsubject is closed. 

- maoke

= --Apple-Mail-4--572877066-- From fibrib@gmail.com Thu Apr 12 03:33:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B788321F859A for ; Thu, 12 Apr 2012 03:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30YVyy+VsVSj for ; Thu, 12 Apr 2012 03:33:10 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2321F8581 for ; Thu, 12 Apr 2012 03:33:10 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1373153qcs.31 for ; Thu, 12 Apr 2012 03:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dU6ULaoQ3HH+ZdBRxGXQu6/mtV7CK928Ubgg+/K/jB4=; b=v+3IGUccDoq7iiEyTl1+VY82Utazj12KEMCzEIQDIA/dI5OXbtILJcBd9a5Rog4gzR QC4W1WxSxTxDksobxdfXgCfckM6ewLFANeFNXHlNxy8EuSeo0atq043ufgWSTo9DPtoP dgumplbxzQ6tgaB23AVojeINkLuiEmQdVT5UAoGmvtVcB1ebqZBfqik14qV/+nfNWCY7 C7MV1Ptwkk9zMm9V+o1uhPGIYvwagrEDW53+ijXe6PQjSdVPAEhlvg+MSjRfaaDlCAO7 ze6LNM7O65wUqhgefAPcG4MpXXfsdIplxk24po3JhSmRbeTZl8opVAMz/3gQiYKSgm6J mPvg== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr3112022qao.23.1334226784862; Thu, 12 Apr 2012 03:33:04 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 12 Apr 2012 03:33:04 -0700 (PDT) In-Reply-To: <08D30916-0E04-4132-A624-7550D491EC1A@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <08D30916-0E04-4132-A624-7550D491EC1A@laposte.net> Date: Thu, 12 Apr 2012 10:33:04 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b41a8fc1d804bd78e1d8 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:33:11 -0000 --20cf3074b41a8fc1d804bd78e1d8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/12 R=E9mi Despr=E9s > Maoke, > > We haven't reached common understanding on "tunnel and transparency" yet= . > Please see below. > ok. > > > 2012-04-12 03:13, Maoke: > > second point, on tunnel and transparency. > > 2012/4/11 R=E9mi Despr=E9s > >> 6. The statement that "double translation is also a sort of tunneling in >> general sense" is IMHO confusing in view of its lack of IPv4 end-to-end >> transparency. >> > > limited to the definition of "a source route that circumvents conventiona= l > routing mechanisms", IMHO, it has no business with the end-to-end > transparency and therefore not confusing with explictly specifying "in > general sense". > > > Your draft says "General-sense tunnel can be a one-hop virtual link or a > multi-hop participant in the delivery path", and doesn't say that it MAY > MODIFY packets . > it doesn't say it MAY NOT. > I still consider that calling "tunnel" a mechanism whereby packets may be > modified (DF, ICMPv4, UDP checksums) should be avoided. > for the narrow-sense "tunnel", it is correct. but on the other hand, it should be a strict "no-modification" instead of only no-modification on the selected fields. (well, i think we may stop this philosophical debate here because the 'general sense', 'narrow sense', ... are only my definition with "let's call it" within this very specific draft) > This is however a minor issue compared to (1) below. > > > The statement that "It needs further investigation to ensure if 4rd-U is >> qualified to be called as a tunnel in the narrow sense" expresses a doub= t >> without substance to justify it. >> > > because 4rd-u draft calls itself a "tunnel". the commentary identifies it > is surely a general-sense tunnel. the commentary tries to understand > whether it is also a narrow-sense tunnel but did not yet concluded at the > time of writing. now it looks we can conclude that 4rd-u is hard to be > called as a tunnel in the narrow sense. see below, regarding the > transparency. > > > You draft says "Narrow-sense tunnel, in architecture, behaves as a > one-hop virtual link". > This is the case with 4rd-u tunnels. > no. with the TTL preserver, 4rd-u reaches the one-hop but not all the virtual link behaviors. details are related to other parts and let me postponse this topic. > > > >> 4rd-U only claims that IPv4 packets traverse ISP domains transparently >> (unless they have IPv4 options in which case the domain signals it doesn= 't >> support them). >> > > now we have clearified the checksum end-to-end transparency covering > payload length and payload protocol type is lost for IPv4/ICMPv4 datagram= s > in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will > continue, to reflect this understanding too, by explicitly claiming that > > > 4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum > covering payload length and payload protocol type (instead of only > mentioning options) when the payload is ICMPv4, less than the transparenc= y > provided by encapsulation. > > > (1) > I already made the point that it is impossible to run a test that would > show, "when the payload is ICMPv4", that a received "checksum covering > payload length and payload protocol type" has been modified. > > This would need a simulated hardware failure, i.e. an open door to provin= g > anything. > in logic, first of all, do you also mean it is impossible to run a test that would show any checksum has been modified unless simulated hardware failure is introduced? and, (because it is impossible to run this), do you plan to claim that checksum covering payload length and protocol type is actually a useless design in ICMPv6/TCP/UDP? if you argue this, i may shut up as soon as possible. second, you argued no matter how it is minor, a tunnel solution should cover it. test scenario having not repeat the checksum error doesn't mean it never happens. it might be strange to me that you attach special importance to the trasparency of DF=3DMF=3D1 but think checksum transparenc= y is not a concern. in practice, unfortunately, nobody can do such a conclusion to say them useless, either nobody can say the checksum error is "minor". even on the Earth rather than the spacecraft, there are a lot reason causing bit-errors not yet well-protected by link layer. you might be interested in a paper published in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=3D347561&bnc=3D1 it is basically about TCP/UDP checksum error statistics while i believe you do agree the understanding is also applicable for the IPv4/ICMPv6 case. the checksum error happens with the frequency between 1/1100 ~ 1/32000, and reaches 1/400 in some circumstances, even though the link layer CRC is there. to save your time, you may read http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf instead, for a quick understanding on why protocol needs to include its own checksum even if the link layer has had CRC mechanism. > > If we don't agree on this, lets first understand why. > > (2) > If one would assume that packets can be corrupted at L2 without being > discarded (which you seem to assume), then RFC6145 could translate a > corrupted IPv4 packet having no UDP checksum into a corrupted packet > having corrupted data and valid checksum. > ok, this talk is limited to the case where corruption happens inside in the UDP protocol data unit. A. native IPv4: if corrupted packet having no UDP checksum arrives at destination, the destination anyway accepts the corrupted data; B. acrossing IPv6 RFC6145 domain: B.1 if corruption happens before entering the IPv6 domain, yes, corrupted data with valid checksum is generated, and delivered to destination, which will accept the corrupted data; B.2 if corruption happens in the IPv6 domain, the translation with checksum provides a certain extent of protection. RFC6145 don't make B.1 worse than A while improves B.2. don't you think it is a pros instead of a cons? > This would be much worse, as far as security is concerned, than ICMPv4 > packets whose data would have been corrupted. > (on the other hand, if you would like to make a commentary for RFC6145 detailed behavior, i'd love to offer assistance as i happend to make some humble observations on it too, but this is not the scope of this thread.) > > > commentary document will include this understanding in next revision, > without judging how severe this concern is in practice. > > > Before point 1 above is clarified, including what you said above in the > next version of your draft would be AFAIK misleading. > in the term of stating the semantic changes with leaving judgement to readers, i don't think there will be any misleading. i only write the fact and the concern. some of them might be significant and severe, some of them might be only trivial FUD. but even FUD, we are obliged to let the community know it. - maoke --20cf3074b41a8fc1d804bd78e1d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/12 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Maoke,

We haven'= t reached common understanding on "tunnel and transparency" =A0ye= t.
Please see below.

ok.=A0
=A0



second point, on= tunnel and transparency. =A0

2012/4/11 R= =E9mi Despr=E9s <despres.remi@laposte.net>
6. The statement that "double= translation is also a sort of tunneling in general sense" is IMHO con= fusing in view of its lack of IPv4 end-to-end transparency.

limited to the definition of "a source route that = circumvents conventional routing mechanisms", IMHO, it has no business= with the end-to-end transparency and therefore not confusing with explictl= y specifying "in general sense".

Your draft says "General-= sense tunnel can be a one-hop virtual link or a multi-hop participant in th= e delivery path", and doesn't say that it MAY MODIFY packets .

it doesn't say it MA= Y NOT.=A0
=A0
I still consider that calling "tunnel" a mechanism= whereby packets may be modified=A0(DF, ICMPv4, UDP checksums)=A0should be = avoided.

for the na= rrow-sense "tunnel", it is correct. but on the other hand, it sho= uld be a strict "no-modification" instead of only no-modification= on the selected fields.=A0

(well, i think we may stop this philosophical debate he= re because the 'general sense', 'narrow sense', ... are onl= y my definition with "let's call it" within this very specifi= c draft)
=A0
This is however a minor issue compared to (1) below.


The statement that "It needs further investigation to ensure if 4rd-U = is qualified to be called as a tunnel in the narrow sense" expresses a= doubt without substance to justify it.

because 4rd-u draft calls itself a &= quot;tunnel". the commentary identifies it is surely a general-sense t= unnel. the commentary tries to understand whether it is also a narrow-sense= tunnel but did not yet concluded at the time of writing. now it looks we c= an conclude that 4rd-u is hard to be called as a tunnel in the narrow sense= . see below, regarding the transparency.=A0

You draft says "Narrow-sense tunnel, in archit= ecture, b= ehaves as a one-hop virtual link".
This is the= case with 4rd-u tunnels.

no. with the TTL preserver, 4rd-u reaches the one-hop but not all = the virtual link behaviors. details are related to other parts and let me p= ostponse this topic.=A0
=A0

=
=A0
4rd-U only claims that IPv4 packets traverse ISP domains transpa= rently (unless they have IPv4 options in which case the domain signals it d= oesn't support them).

now we have clearified the che= cksum end-to-end transparency covering payload length and payload protocol = type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is r= evised, if anyway the work will continue, to reflect this understanding too= , by explicitly claiming that

4rd-u keeps end-to-end tran= sparency for most of IPv4 fields but checksum covering payload length and p= ayload protocol type (instead of only mentioning options) when the payload = is ICMPv4, less than the transparency provided by encapsulation.

(1)
I already made the poi= nt that it is impossible to run a test that would show, "when the payl= oad is ICMPv4", that a received "checksum covering payload length= and payload protocol type" has been modified.=A0

This would need a simulated hardware failure, i.e. an o= pen door to proving anything.

=
in logic,

first of all, do you al= so mean it is impossible to run a test that would show any checksum has bee= n modified unless simulated hardware failure is introduced? and, (because i= t is impossible to run this), do you plan to claim that checksum covering p= ayload length and protocol type is actually a useless design in ICMPv6/TCP/= UDP? if you argue this, i may shut up as soon as possible.=A0

second, you argued no matter how it is minor, a tunnel = solution should cover it. test scenario having not repeat the checksum erro= r doesn't mean it never happens. it might be strange to me that you att= ach special importance to the trasparency of DF=3DMF=3D1 but think checksum= transparency is not a concern.=A0

in practice,

unfortunately, n= obody can do such a conclusion to say them useless, either nobody can say t= he checksum error is "minor". even on the Earth rather than the s= pacecraft, there are a lot reason causing bit-errors not yet well-protected= by link layer. you might be interested in a paper published in SIGCOMM'= ;00: htt= p://dl.acm.org/citation.cfm?id=3D347561&bnc=3D1 it is basically abo= ut TCP/UDP checksum error statistics while i believe you do agree the under= standing is also applicable for the IPv4/ICMPv6 case. the checksum error ha= ppens with the frequency between 1/1100 ~ 1/32000, and reaches 1/400 in som= e circumstances, even though the link layer CRC is there.=A0

to save your time, you may read http://elf.cs.= pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf instead, for a quic= k understanding on why protocol needs to include its own checksum even if t= he link layer has had CRC mechanism.=A0
=A0

If we don't agree on this, lets fir= st understand why.

(2)
If one would assume that packets can be c= orrupted at L2 without being discarded (which you seem to assume), then RFC= 6145 could translate a corrupted IPv4 packet having no UDP checksum into a = corrupted packet having=A0corrupted data=A0and valid checksum.=A0

ok, this talk is limited= to the case where corruption happens inside in the UDP protocol data unit.= =A0

A. native IPv4: if corrupted packet having no = UDP checksum arrives at destination, the destination anyway accepts the cor= rupted data;=A0
B. acrossing IPv6 RFC6145 domain:=A0
=A0 =A0B.1 if corruptio= n happens before entering the IPv6 domain, yes, corrupted data with valid c= hecksum is generated, and delivered to destination, which will accept the c= orrupted data; =A0
=A0 =A0B.2 if corruption happens in the IPv6 domain, the translation w= ith checksum provides a certain extent of protection.=A0

RFC6145 don't make B.1 worse than A while improves B.2. don'= t you think it is a pros instead of a cons?=A0
=A0
This would be much worse, as far as security is concer= ned, than ICMPv4 packets whose data would have been corrupted. =A0

(on the other hand, if y= ou would like to make a commentary for RFC6145 detailed behavior, i'd l= ove to offer assistance as i happend to make some humble observations on it= too, but this is not the scope of this thread.)
=A0
=A0=A0
commentary document will include this understanding in next revision= , without judging how severe this concern is in practice.

Before point 1 above is clarified, includ= ing what you said above in the next version of your draft would be AFAIK mi= sleading.

in the term of = stating the semantic changes with leaving judgement to readers, i don't= think there will be any misleading. i only write the fact and the concern.= some of them might be significant and severe, some of them might be only t= rivial FUD. but even FUD, we are obliged to let the community know it.=A0

- maoke=A0

--20cf3074b41a8fc1d804bd78e1d8-- From despres.remi@laposte.net Thu Apr 12 06:52:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD51C21F85D1 for ; Thu, 12 Apr 2012 06:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEjIc5ZH-Axp for ; Thu, 12 Apr 2012 06:52:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBCE21F8531 for ; Thu, 12 Apr 2012 06:52:14 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 761C6940126; Thu, 12 Apr 2012 15:52:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--550760457 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 12 Apr 2012 15:52:04 +0200 Message-Id: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <08D30916-0E04-4132-A624-7550D491EC1A@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 13:52:26 -0000 --Apple-Mail-5--550760457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-04-12 =E0 12:33, Maoke: >=20 >=20 > 2012/4/12 R=E9mi Despr=E9s > Maoke, >=20 > We haven't reached common understanding on "tunnel and transparency" = yet. > Please see below. >=20 > ok.=20 > =20 >=20 >=20 > 2012-04-12 03:13, Maoke: >=20 >> second point, on tunnel and transparency. =20 >>=20 >> 2012/4/11 R=E9mi Despr=E9s >> 6. The statement that "double translation is also a sort of tunneling = in general sense" is IMHO confusing in view of its lack of IPv4 = end-to-end transparency. >>=20 >> limited to the definition of "a source route that circumvents = conventional routing mechanisms", IMHO, it has no business with the = end-to-end transparency and therefore not confusing with explictly = specifying "in general sense". >=20 > Your draft says "General-sense tunnel can be a one-hop virtual link or = a multi-hop participant in the delivery path", and doesn't say that it = MAY MODIFY packets . >=20 > it doesn't say it MAY NOT.=20 > =20 > I still consider that calling "tunnel" a mechanism whereby packets may = be modified (DF, ICMPv4, UDP checksums) should be avoided. >=20 > for the narrow-sense "tunnel", it is correct. but on the other hand, = it should be a strict "no-modification" instead of only no-modification = on the selected fields.=20 Are you claiming that 4rd-u can modify ICMPv4 packets that are tunneled? If yes, could you please be kind enough provide a scenario that supports = the claim? > (well, i think we may stop this philosophical debate here because the = 'general sense', 'narrow sense', ... are only my definition with "let's = call it" within this very specific draft) > =20 > This is however a minor issue compared to (1) below. >=20 >=20 >> The statement that "It needs further investigation to ensure if 4rd-U = is qualified to be called as a tunnel in the narrow sense" expresses a = doubt without substance to justify it. >>=20 >> because 4rd-u draft calls itself a "tunnel". the commentary = identifies it is surely a general-sense tunnel. the commentary tries to = understand whether it is also a narrow-sense tunnel but did not yet = concluded at the time of writing. now it looks we can conclude that = 4rd-u is hard to be called as a tunnel in the narrow sense. see below, = regarding the transparency.=20 >=20 > You draft says "Narrow-sense tunnel, in architecture, behaves as a = one-hop virtual link". > This is the case with 4rd-u tunnels.=20 >=20 > no. with the TTL preserver, 4rd-u reaches the one-hop but not all the = virtual link behaviors. details are related to other parts and let me = postponse this topic.=20 OK, let's wait and see but, at least, there is no identified problem so = far. In any case, the goal of 4rd is IPv4 transparency, not support of some = "virtual link" having more implications than transparency. >> 4rd-U only claims that IPv4 packets traverse ISP domains = transparently (unless they have IPv4 options in which case the domain = signals it doesn't support them). >>=20 >> now we have clearified the checksum end-to-end transparency covering = payload length and payload protocol type is lost for IPv4/ICMPv4 = datagrams in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work = will continue, to reflect this understanding too, by explicitly claiming = that >=20 >> 4rd-u keeps end-to-end transparency for most of IPv4 fields but = checksum covering payload length and payload protocol type (instead of = only mentioning options) when the payload is ICMPv4, less than the = transparency provided by encapsulation. >=20 > (1) > I already made the point that it is impossible to run a test that = would show, "when the payload is ICMPv4", that a received "checksum = covering payload length and payload protocol type" has been modified.=20 >=20 > This would need a simulated hardware failure, i.e. an open door to = proving anything. >=20 > in logic, >=20 > first of all, do you also mean it is impossible to run a test that = would show any checksum has been modified unless simulated hardware = failure is introduced? Yes, I mean that an ICMPv4 packet that is tunneled across a 4rd-u domain = has its ICMP checksum unchanged. Evidence of the contrary would be new to me. > and, (because it is impossible to run this), > do you plan to claim that checksum covering payload length and = protocol type is actually a useless design in ICMPv6/TCP/UDP? No. (BTW, note that in the pdf presentation you suggest below I should read = deals not only with hardware failures but also with "end-host software = errors". These are out of scope for 4rd, but well in scope for UDP/TCP)=20= > if you argue this, i may shut up as soon as possible.=20 No need, since I haven't argued this. (BTW, this sounds like suspicion that trying to understand what I mean, = and explain why I am wrong if I am, isn't worth the effort. I have had my share of that. Disappointed to see your seeming to join = this view.) > second, you argued no matter how it is minor, a tunnel solution should = cover it. test scenario having not repeat the checksum error doesn't = mean it never happens. > it might be strange to me that you attach special importance to the = trasparency of DF=3DMF=3D1 but think checksum transparency is not a = concern.=20 Yet, a test that shows that DF=3DMF=3D1 becomes DF=3D1/MF=3D0 after = double RFC6145 translation is trivial, with 100% guaranteed success. The same for a test that No UDP checksum is translated into a computed = UDP checksum. > in practice, >=20 > unfortunately, nobody can do such a conclusion to say them useless, = either nobody can say the checksum error is "minor". even on the Earth = rather than the spacecraft, there are a lot reason causing bit-errors = not yet well-protected by link layer. you might be interested in a paper = published in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=3D347561&bnc=3D= 1 it is basically about TCP/UDP checksum error statistics while i = believe you do agree the understanding is also applicable for the = IPv4/ICMPv6 case. the checksum error happens with the frequency between = 1/1100 ~ 1/32000, and reaches 1/400 in some circumstances, even though = the link layer CRC is there.=20 >=20 > to save your time, you may read = http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf = instead, for a quick understanding on why protocol needs to include its = own checksum even if the link layer has had CRC mechanism.=20 The only router induced errors I saw in this presentation are due to - buggy network interfaces - memory errors - bus malfunctions=20 All of these are hardware failures. > If we don't agree on this, lets first understand why. >=20 > (2) > If one would assume that packets can be corrupted at L2 without being = discarded (which you seem to assume), then RFC6145 could translate a = corrupted IPv4 packet having no UDP checksum into a corrupted packet = having corrupted data and valid checksum.=20 >=20 > ok, > this talk is limited to the case where corruption happens inside in = the UDP protocol data unit.=20 Right. > A. native IPv4: if corrupted packet having no UDP checksum arrives at = destination, the destination anyway accepts the corrupted data;=20 Yes, but in native IPv4 (and across 4rd-u tunnels) destination hosts = know there is no checksum. > B. acrossing IPv6 RFC6145 domain:=20 > B.1 if corruption happens before entering the IPv6 domain, yes, > corrupted data with valid checksum is generated, and delivered to = destination, which will accept the corrupted data; The point is that corrupted data are accepted with the supposed = guarantee that they were protected by a checksum. > B.2 if corruption happens in the IPv6 domain, the translation with = checksum provides a certain extent of protection.=20 Not the subject (and in any case possible only with a supposed hardware = failure). > RFC6145 don't make B.1 worse than A while improves B.2. - Receiving erroneous data with a checksum that assures they are valid = is WORSE than receiving corrupted data with a warning that they haven't = been verified. I hope you can agree on this. > don't you think it is a pros instead of a cons?=20 Neither pro nor con, because the implied assumption of hardware failure = remains AFAIAC out of scope. > =20 > This would be much worse, as far as security is concerned, than ICMPv4 = packets whose data would have been corrupted. =20 >=20 > (on the other hand, if you would like to make a commentary for RFC6145 = detailed behavior, No wish to comment RFC6145 other than in the context of double = translation. > i'd love to offer assistance as i happend to make some humble = observations on it too, but this is not the scope of this thread.) > =20 > =20 >> commentary document will include this understanding in next revision, = without judging how severe this concern is in practice. >=20 > Before point 1 above is clarified, including what you said above in = the next version of your draft would be AFAIK misleading. >=20 > in the term of stating the semantic changes with leaving judgement to = readers, i don't think there will be any misleading. i only write the = fact and the concern. some of them might be significant and severe, some = of them might be only trivial FUD. but even FUD, we are obliged to let = the community know it.=20 Let's then see what you will write, hopefully with preliminary = consideration of the above. Regards, RD >=20 > - maoke=20 >=20 --Apple-Mail-5--550760457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/4/12 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Maoke,

We haven't = reached common understanding on "tunnel and transparency" =  yet.
Please see = below.

ok. 
 


2012-04-12  03:13, Maoke:

second point, = on tunnel and transparency.  

2012/4/11 R=E9mi Despr=E9s <despres.remi@laposte.net>
6. The statement that "double = translation is also a sort of tunneling in general sense" is IMHO = confusing in view of its lack of IPv4 end-to-end transparency. =

limited to the definition of "a source route that = circumvents conventional routing mechanisms", IMHO, it has no business = with the end-to-end transparency and therefore not confusing with = explictly specifying "in general sense".

Your draft says = "General-sense tunnel can be a one-hop virtual link or a multi-hop = participant in the delivery path", and doesn't say that it MAY MODIFY = packets .

it doesn't say it MAY = NOT. 
 
I still consider that calling "tunnel" a mechanism = whereby packets may be modified (DF, ICMPv4, UDP = checksums) should be = avoided.

for the = narrow-sense "tunnel", it is correct. but on the other hand, it should = be a strict "no-modification" instead of only no-modification on the = selected fields. 

Are = you claiming that 4rd-u can modify ICMPv4 packets that are = tunneled?
If yes, could you please be kind enough provide a = scenario that supports the = claim?


(well, i think we may stop this philosophical debate here because = the 'general sense', 'narrow sense', ... are only my definition with = "let's call it" within this very specific draft)
 
This is however a minor = issue compared to (1) below.


The statement that "It needs further investigation to ensure if 4rd-U is = qualified to be called as a tunnel in the narrow sense" expresses a = doubt without substance to justify it.

because 4rd-u draft calls itself = a "tunnel". the commentary identifies it is surely a general-sense = tunnel. the commentary tries to understand whether it is also a = narrow-sense tunnel but did not yet concluded at the time of writing. = now it looks we can conclude that 4rd-u is hard to be called as a tunnel = in the narrow sense. see below, regarding the transparency. 

You draft says "Narrow-sense = tunnel, in architecture, behaves as a = one-hop virtual link".
This is = the case with 4rd-u tunnels. =

no. with the = TTL preserver, 4rd-u reaches the one-hop but not all the virtual link = behaviors. details are related to other parts and let me postponse this = topic. 

OK, let's wait and = see but, at least, there is no identified problem so = far.

In any case, the goal of 4rd is IPv4 = transparency, not support of some "virtual link" having more = implications than transparency.


4rd-U only claims that IPv4 packets = traverse ISP domains transparently (unless they have IPv4 options in = which case the domain signals it doesn't support them).

now we have clearified the = checksum end-to-end transparency covering payload length and payload = protocol type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest = 4rd-u draft is revised, if anyway the work will continue, to reflect = this understanding too, by explicitly claiming that

4rd-u keeps end-to-end = transparency for most of IPv4 fields but checksum covering payload = length and payload protocol type (instead of only mentioning options) = when the payload is ICMPv4, less than the transparency provided by = encapsulation.

(1)
I already made the = point that it is impossible to run a test that would show, "when the = payload is ICMPv4", that a received "checksum covering payload length = and payload protocol type" has been modified. 

This would need a simulated hardware failure, i.e. = an open door to proving = anything.

in = logic,

first of all, do you also mean it is = impossible to run a test that would show any checksum has been modified = unless simulated hardware failure is = introduced?

Yes, I mean = that an ICMPv4 packet that is tunneled across a 4rd-u domain has its = ICMP checksum unchanged.
Evidence of the contrary would be new = to me.

and, (because it is impossible to run = this),

do you plan to claim that checksum = covering payload length and protocol type is actually a useless design = in ICMPv6/TCP/UDP? =

No.

(BTW, note that in the pdf presentation you suggest below I should read = deals not only with hardware failures but also with "end-host software = errors". These are out of scope for 4rd, but well in scope for = UDP/TCP) 

if you argue this, i may shut up as soon = as possible. 

No need, = since I haven't argued this.

(BTW, this sounds = like suspicion that trying to understand what I mean, and explain why I = am wrong if I am, isn't worth the effort.
I have had my share = of that. Disappointed to see your seeming to join this = view.)


second, you argued no matter how it is minor, a tunnel solution = should cover it. test scenario having not repeat the checksum error = doesn't mean it never = happens.

it might be strange to me that you = attach special importance to the trasparency of DF=3DMF=3D1 but think = checksum transparency is not a = concern. 

Yet, a test = that shows that DF=3DMF=3D1 becomes DF=3D1/MF=3D0 after double RFC6145 = translation is trivial, with = 100% guaranteed success.
The same for a test that No = UDP checksum is translated into a computed UDP = checksum.


in practice,

unfortunately, nobody can do = such a conclusion to say them useless, either nobody can say the = checksum error is "minor". even on the Earth rather than the spacecraft, = there are a lot reason causing bit-errors not yet well-protected by link = layer. you might be interested in a paper published in SIGCOMM'00: http://dl.= acm.org/citation.cfm?id=3D347561&bnc=3D1 it is basically about = TCP/UDP checksum error statistics while i believe you do agree the = understanding is also applicable for the IPv4/ICMPv6 case. the checksum = error happens with the frequency between 1/1100 ~ 1/32000, and reaches = 1/400 in some circumstances, even though the link layer CRC is = there. 

to save your time, you may read http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf = instead, for a quick understanding on why protocol needs to include its = own checksum even if the link layer has had CRC = mechanism. 

The only = router induced errors I saw in this presentation are due to
- = buggy network interfaces
- memory errors
- bus = malfunctions 
All of these are hardware = failures.

If we don't = agree on this, lets first understand why.

(2)
If one would assume that packets can = be corrupted at L2 without being discarded (which you seem to assume), = then RFC6145 could translate a corrupted IPv4 packet having no UDP = checksum into a corrupted packet having corrupted data and = valid checksum. 

ok, =

this talk is limited to the case where = corruption happens inside in the UDP protocol data = unit. 

Right.

A. native IPv4: = if corrupted packet having no UDP checksum arrives at destination, the = destination anyway accepts the corrupted = data; 

Yes, but in native = IPv4 (and across 4rd-u tunnels) destination hosts know there is no = checksum.

B. acrossing IPv6 RFC6145 domain: 
   B.1 = if corruption happens before entering the IPv6 domain, yes, =

corrupted data with valid checksum is = generated, and delivered to destination, which will accept the corrupted = data;

The point is that corrupted = data are accepted with the supposed guarantee that they were protected = by a checksum.

   B.2 if corruption happens in the IPv6 domain, the = translation with checksum provides a certain extent of = protection. 

Not the subject = (and in any case possible only with a supposed hardware = failure).

RFC6145 don't make B.1 worse than A while = improves B.2.

- Receiving = erroneous data with a checksum that assures they are valid is WORSE than = receiving corrupted data with a warning that they haven't been = verified.

I hope you can agree on = this.


don't you think it is a = pros instead of a = cons? 

Neither pro nor con, = because the implied assumption of hardware failure remains AFAIAC out of = scope.

=
 
This would be much worse, = as far as security is concerned, than ICMPv4 packets whose data would = have been corrupted.  

(on the other hand, = if you would like to make a commentary for RFC6145 detailed = behavior,

No wish to comment = RFC6145 other than in the context of double = translation.

i'd love to offer assistance as i happend to = make some humble observations on it too, but this is not the scope of = this thread.)
 
  
commentary document will include this understanding = in next revision, without judging how severe this concern is in = practice.

Before point 1 above is clarified, = including what you said above in the next version of your draft would be = AFAIK misleading.

in = the term of stating the semantic changes with leaving judgement to = readers, i don't think there will be any misleading. i only write the = fact and the concern. some of them might be significant and severe, some = of them might be only trivial FUD. but even FUD, we are obliged to let = the community know = it. 

Let's then see = what you will write, hopefully with preliminary consideration of the = above.

Regards,
RD


- maoke 


= --Apple-Mail-5--550760457-- From fibrib@gmail.com Thu Apr 12 08:36:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693021F869E for ; Thu, 12 Apr 2012 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFFs0lgAHHYo for ; Thu, 12 Apr 2012 08:36:00 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9180121F8693 for ; Thu, 12 Apr 2012 08:36:00 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1596011qcs.31 for ; Thu, 12 Apr 2012 08:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uFNFz+VQ48SeSR02t4d+TOu3uw6OVr4OCxpfM6FlynY=; b=qtSZWEbZhDKQoDWSsHktZpH8i489PZg10Sk6rQQpOigEsEdtUD/oDPWyXdVzDBIo3C RuwY3hBxh2jom2lnAI+/atZ8YWOtnQA1vLOqZwfCOWz9Hpnfv9IHIGCNMGSfJu10OD61 Faq7CK6VzRsHF0xUg9rTMF4ivKWQx2siXcq7HvWueSn9VyHca+NAlltWOEGV9ux2LEe8 LWGryB1XmspTbYt8smD0gOeR6O6WEq7fXIDo7olARe/4sizql1CUVi/mBYtFPcUE+yL+ gGxAb37FDDVdj5rtLU07D7Eaw+acCliZT9e/YG2KamFzBhqnuSMydyh6nl9l/Nn5t3RK 6eZw== MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr4682884qab.36.1334244959976; Thu, 12 Apr 2012 08:35:59 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 12 Apr 2012 08:35:59 -0700 (PDT) In-Reply-To: References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <08D30916-0E04-4132-A624-7550D491EC1A@laposte.net> Date: Fri, 13 Apr 2012 00:35:59 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300faff5e1ff9704bd7d1c77 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:36:02 -0000 --20cf300faff5e1ff9704bd7d1c77 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable a summary: 1. on the IPv6/ICMPv4 checksum issue, yes i talk about hardware failure essentially. surely the paper i cited "also" contains other sources of bit-error like host software. i suppose that the 4rd-u box can deal with that before doing the header processing. regarding the IPv6/ICMPv4 checksum issue, the main concern is hardware error in IPv6 routers. 2. on the null checksum, again the checksum because of hardware error in IPv6 routers (btw, IMC'07 paper argued that the DF=3DMF=3D1 was a software failure due t= o poor implementation of IP stack. i really want to say software failure is out of scope but i won't ;-) - a btw fyi but out of service of this topic) so the key dissent between you and me is: you think hardware failure is out of scope but i think it is essential, because CRC in link layer is not enough to deal with that and because a lot of error has happened before the data is put into the physical link, and checksum is an important way to detect such kind of failure. Stone and Partridge concluded: what TCP checksum cannot detect are only 1 of 10 billion about, reflecting how important the checksum is. unless 4rd-u co-authors makes out a statistics on ICMPv6 checksum error rate is definitely below a low-enough level (e.g., 10^-6 among ICMPv6 messages) in a test with multihop environment with high workload and sometimes working in high temporature or in high radioactive environment, the statement "4rd-u can keep transparency as the same as MAP-E" would be AFAIK a misleading, at least irresponsible statement! or, may you please gently say 4rd-u doesn't concern any environment where IPv6 routers may have any hardware error, as you think hardware error is out of scope. though i doubt you are really want to make a protocol for Internet use. and i really think further discussion might be very hard, if we are in totally different understandings regarding the most essential assumption about the Internet. i prepared further reply to your comments but it looks not significant now. because all of them are related to this or that of errors, that could be out-of-scoped by you. - maoke 2012/4/12 R=E9mi Despr=E9s > > 2012-04-12 =E0 12:33, Maoke: > > > > 2012/4/12 R=E9mi Despr=E9s > >> Maoke, >> >> We haven't reached common understanding on "tunnel and transparency" ye= t. >> Please see below. >> > > ok. > > >> >> >> 2012-04-12 03:13, Maoke: >> >> second point, on tunnel and transparency. >> >> 2012/4/11 R=E9mi Despr=E9s >> >>> 6. The statement that "double translation is also a sort of tunneling i= n >>> general sense" is IMHO confusing in view of its lack of IPv4 end-to-end >>> transparency. >>> >> >> limited to the definition of "a source route that circumvents >> conventional routing mechanisms", IMHO, it has no business with the >> end-to-end transparency and therefore not confusing with explictly >> specifying "in general sense". >> >> >> Your draft says "General-sense tunnel can be a one-hop virtual link or a >> multi-hop participant in the delivery path", and doesn't say that it MAY >> MODIFY packets . >> > > it doesn't say it MAY NOT. > > >> I still consider that calling "tunnel" a mechanism whereby packets may b= e >> modified (DF, ICMPv4, UDP checksums) should be avoided. >> > > for the narrow-sense "tunnel", it is correct. but on the other hand, it > should be a strict "no-modification" instead of only no-modification on t= he > selected fields. > > > Are you claiming that 4rd-u can modify ICMPv4 packets that are tunneled? > If yes, could you please be kind enough provide a scenario that supports > the claim? > > > (well, i think we may stop this philosophical debate here because the > 'general sense', 'narrow sense', ... are only my definition with "let's > call it" within this very specific draft) > > >> This is however a minor issue compared to (1) below. >> >> >> The statement that "It needs further investigation to ensure if 4rd-U is >>> qualified to be called as a tunnel in the narrow sense" expresses a dou= bt >>> without substance to justify it. >>> >> >> because 4rd-u draft calls itself a "tunnel". the commentary identifies i= t >> is surely a general-sense tunnel. the commentary tries to understand >> whether it is also a narrow-sense tunnel but did not yet concluded at th= e >> time of writing. now it looks we can conclude that 4rd-u is hard to be >> called as a tunnel in the narrow sense. see below, regarding the >> transparency. >> >> >> You draft says "Narrow-sense tunnel, in architecture, behaves as a >> one-hop virtual link". >> This is the case with 4rd-u tunnels. >> > > no. with the TTL preserver, 4rd-u reaches the one-hop but not all the > virtual link behaviors. details are related to other parts and let me > postponse this topic. > > > OK, let's wait and see but, at least, there is no identified problem so > far. > > In any case, the goal of 4rd is IPv4 transparency, not support of some > "virtual link" having more implications than transparency. > > > 4rd-U only claims that IPv4 packets traverse ISP domains transparently >>> (unless they have IPv4 options in which case the domain signals it does= n't >>> support them). >>> >> >> now we have clearified the checksum end-to-end transparency covering >> payload length and payload protocol type is lost for IPv4/ICMPv4 datagra= ms >> in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will >> continue, to reflect this understanding too, by explicitly claiming that >> >> >> 4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum >> covering payload length and payload protocol type (instead of only >> mentioning options) when the payload is ICMPv4, less than the transparen= cy >> provided by encapsulation. >> >> >> (1) >> I already made the point that it is impossible to run a test that would >> show, "when the payload is ICMPv4", that a received "checksum covering >> payload length and payload protocol type" has been modified. >> >> This would need a simulated hardware failure, i.e. an open door to >> proving anything. >> > > in logic, > > first of all, do you also mean it is impossible to run a test that would > show any checksum has been modified unless simulated hardware failure is > introduced? > > > Yes, I mean that an ICMPv4 packet that is tunneled across a 4rd-u domain > has its ICMP checksum unchanged. > Evidence of the contrary would be new to me. > > and, (because it is impossible to run this), > > > do you plan to claim that checksum covering payload length and protocol > type is actually a useless design in ICMPv6/TCP/UDP? > > > No. > > (BTW, note that in the pdf presentation you suggest below I should read > deals not only with hardware failures but also with "end-host software > errors". These are out of scope for 4rd, but well in scope for UDP/TCP) > > if you argue this, i may shut up as soon as possible. > > > No need, since I haven't argued this. > > (BTW, this sounds like suspicion that trying to understand what I mean, > and explain why I am wrong if I am, isn't worth the effort. > I have had my share of that. Disappointed to see your seeming to join thi= s > view.) > > > second, you argued no matter how it is minor, a tunnel solution should > cover it. test scenario having not repeat the checksum error doesn't mean > it never happens. > > > it might be strange to me that you attach special importance to the > trasparency of DF=3DMF=3D1 but think checksum transparency is not a conce= rn. > > > Yet, a test that shows that DF=3DMF=3D1 becomes DF=3D1/MF=3D0 after doubl= e RFC6145 > translation is trivial, with 100% guaranteed success. > The same for a test that No UDP checksum is translated into a computed UD= P > checksum. > > > in practice, > > unfortunately, nobody can do such a conclusion to say them useless, eithe= r > nobody can say the checksum error is "minor". even on the Earth rather th= an > the spacecraft, there are a lot reason causing bit-errors not yet > well-protected by link layer. you might be interested in a paper publishe= d > in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=3D347561&bnc=3D1 it is > basically about TCP/UDP checksum error statistics while i believe you do > agree the understanding is also applicable for the IPv4/ICMPv6 case. the > checksum error happens with the frequency between 1/1100 ~ 1/32000, and > reaches 1/400 in some circumstances, even though the link layer CRC is > there. > > to save your time, you may read > http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdfinstead,= for a quick understanding on why protocol needs to include its own > checksum even if the link layer has had CRC mechanism. > > > The only router induced errors I saw in this presentation are due to > - buggy network interfaces > - memory errors > - bus malfunctions > All of these are hardware failures. > > If we don't agree on this, lets first understand why. >> >> (2) >> If one would assume that packets can be corrupted at L2 without being >> discarded (which you seem to assume), then RFC6145 could translate a >> corrupted IPv4 packet having no UDP checksum into a corrupted packet >> having corrupted data and valid checksum. >> > > ok, > > > this talk is limited to the case where corruption happens inside in the > UDP protocol data unit. > > > Right. > > A. native IPv4: if corrupted packet having no UDP checksum arrives at > destination, the destination anyway accepts the corrupted data; > > > Yes, but in native IPv4 (and across 4rd-u tunnels) destination hosts know > there is no checksum. > > B. acrossing IPv6 RFC6145 domain: > B.1 if corruption happens before entering the IPv6 domain, yes, > > > corrupted data with valid checksum is generated, and delivered to > destination, which will accept the corrupted data; > > > The point is that corrupted data are accepted with the supposed guarantee > that they were protected by a checksum. > > B.2 if corruption happens in the IPv6 domain, the translation with > checksum provides a certain extent of protection. > > > Not the subject (and in any case possible only with a supposed hardware > failure). > > RFC6145 don't make B.1 worse than A while improves B.2. > > > - Receiving erroneous data with a checksum that assures they are valid is > WORSE than receiving corrupted data with a warning that they haven't been > verified. > > I hope you can agree on this. > > > don't you think it is a pros instead of a cons? > > > Neither pro nor con, because the implied assumption of hardware failure > remains AFAIAC out of scope. > > > >> This would be much worse, as far as security is concerned, than ICMPv4 >> packets whose data would have been corrupted. >> > > (on the other hand, if you would like to make a commentary for RFC6145 > detailed behavior, > > > No wish to comment RFC6145 other than in the context of double translatio= n. > > i'd love to offer assistance as i happend to make some humble observation= s > on it too, but this is not the scope of this thread.) > > >> >> >> commentary document will include this understanding in next revision, >> without judging how severe this concern is in practice. >> >> >> Before point 1 above is clarified, including what you said above in the >> next version of your draft would be AFAIK misleading. >> > > in the term of stating the semantic changes with leaving judgement to > readers, i don't think there will be any misleading. i only write the fac= t > and the concern. some of them might be significant and severe, some of th= em > might be only trivial FUD. but even FUD, we are obliged to let the > community know it. > > > Let's then see what you will write, hopefully with preliminary > consideration of the above. > > Regards, > RD > > > - maoke > > > --20cf300faff5e1ff9704bd7d1c77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
a summary:
=A0
1. on the IPv6/ICMPv4 checksum iss= ue, yes i talk about hardware failure essentially. surely the paper i cited= "also" contains other sources of bit-error like host software. i= suppose that the 4rd-u box can deal with that before doing the header proc= essing. regarding the IPv6/ICMPv4 checksum issue, the main concern is hardw= are=A0error in IPv6=A0routers.
=A0
2. on the null checksum, again the checksum because of h= ardware=A0error in IPv6 routers
=A0
(btw, IMC'07 pa= per argued that the DF=3DMF=3D1 was a software failure due to poor implemen= tation of IP stack. i really want to say software failure is out of scope b= ut i won't =A0;-) - a btw=A0fyi but out of service of this topic)
so the key dissent between you and me=A0is:=A0you think hardware= failure is out of scope but i think it is essential, because CRC in link l= ayer is not enough to deal with that and because a lot of error has happene= d before the data is put into the physical link, and checksum is an importa= nt way to detect such kind of failure. Stone and Partridge concluded: what= =A0TCP checksum cannot detect are only 1 of 10 billion about, reflecting ho= w important the checksum is. unless 4rd-u co-authors makes out a statistics= on ICMPv6 checksum error rate is definitely below a low-enough level=A0(e.= g., 10^-6 among=A0ICMPv6 messages)=A0in a test with multihop environment wi= th high workload and sometimes working in high temporature or in high radio= active environment, the statement "4rd-u can keep transparency as the = same as MAP-E" would be AFAIK a=A0misleading, at least irresponsible s= tatement!
=A0
or,=A0may=A0you=A0please gently say 4rd-u doesn't co= ncern any environment where IPv6 routers may have any hardware error,=A0as = you think hardware error is out of scope.=A0though i doubt you are really w= ant to make a protocol for Internet use. and i really think further discuss= ion might be very hard, if we are in totally different understandings regar= ding=A0the most essential assumption=A0about=A0the Internet.
=A0
i prepared further reply to your comments but it looks n= ot significant now. because all of them are related to this or that of erro= rs, that could be out-of-scoped by you.
=A0
- maoke
=A0
2012/4/12 R=E9mi Despr=E9s <despres.remi@lap= oste.net>

2012-04-12 =E0 12:33, Mao= ke:



2012/4/12 R=E9mi Despr=E9s <despres.remi@laposte= .net>
Maoke,

We haven'= t reached common understanding on "tunnel and transparency" =A0ye= t.
Please see below.

ok.=A0
=A0


2012-04-12 =A003:13, Maoke:

second point, on tunnel and t= ransparency. =A0

2012/4/11 R=E9mi Despr= =E9s <despres.remi@laposte.net>
6. The statement that "double= translation is also a sort of tunneling in general sense" is IMHO con= fusing in view of its lack of IPv4 end-to-end transparency.

limited to the definition of "a source route that = circumvents conventional routing mechanisms", IMHO, it has no business= with the end-to-end transparency and therefore not confusing with explictl= y specifying "in general sense".

Your draft says "General-= sense tunnel can be a one-hop virtual link or a multi-hop participant in th= e delivery path", and doesn't say that it MAY MODIFY packets .

it doesn't say it MA= Y NOT.=A0
=A0
I still consider that calling "tunnel" a mechanism= whereby packets may be modified=A0(DF, ICMPv4, UDP checksums)=A0should be = avoided.

for the na= rrow-sense "tunnel", it is correct. but on the other hand, it sho= uld be a strict "no-modification" instead of only no-modification= on the selected fields.=A0

Are you claiming that=A04rd-u= =A0can modify ICMPv4 packets that are tunneled?
If yes, could you= please be kind enough provide a scenario that supports the claim?


(well, i think we may stop this philosophical debate here because the = 'general sense', 'narrow sense', ... are only my definition= with "let's call it" within this very specific draft)
=A0
This is however a minor issue compared to (1) below.


The statement that "It needs further investigation to ensure if 4rd-U = is qualified to be called as a tunnel in the narrow sense" expresses a= doubt without substance to justify it.

because 4rd-u draft calls itself a &= quot;tunnel". the commentary identifies it is surely a general-sense t= unnel. the commentary tries to understand whether it is also a narrow-sense= tunnel but did not yet concluded at the time of writing. now it looks we c= an conclude that 4rd-u is hard to be called as a tunnel in the narrow sense= . see below, regarding the transparency.=A0

You draft says "Narrow-sense tunnel, in archit= ecture, b= ehaves as a one-hop virtual link".
This is the= case with 4rd-u tunnels.

no. with the TTL preserver, 4rd-u reaches the one-hop but not all = the virtual link behaviors. details are related to other parts and let me p= ostponse this topic.=A0

OK, let's wait and see but, at = least, there is no identified problem so far.

In a= ny case, the goal of 4rd is IPv4 transparency, not support of some "vi= rtual link" having more implications than transparency.


4rd-U only claims that IPv4 packets traverse ISP domains transparently= (unless they have IPv4 options in which case the domain signals it doesn&#= 39;t support them).

now we have clearified the che= cksum end-to-end transparency covering payload length and payload protocol = type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is r= evised, if anyway the work will continue, to reflect this understanding too= , by explicitly claiming that

4rd-u keeps end-to-end tran= sparency for most of IPv4 fields but checksum covering payload length and p= ayload protocol type (instead of only mentioning options) when the payload = is ICMPv4, less than the transparency provided by encapsulation.

(1)
I already made the poi= nt that it is impossible to run a test that would show, "when the payl= oad is ICMPv4", that a received "checksum covering payload length= and payload protocol type" has been modified.=A0

This would need a simulated hardware failure, i.e. an o= pen door to proving anything.

=
in logic,

first of all, do you al= so mean it is impossible to run a test that would show any checksum has bee= n modified unless simulated hardware failure is introduced?

Yes, I mean that an ICMPv4 pa= cket that is tunneled across a 4rd-u domain has its ICMP checksum unchanged= .
Evidence of the contrary would be new to me.

and, (b= ecause it is impossible to run this),

do you plan to= claim that checksum covering payload length and protocol type is actually = a useless design in ICMPv6/TCP/UDP?

No.

= (BTW, note that in the pdf presentation you suggest below I should read dea= ls not only with hardware failures but also with "end-host software er= rors". These are out of scope for 4rd, but well in scope for UDP/TCP)= =A0

if you argue this, i may shut up as soon as possible.=A0

No need, since I haven'= t argued this.

(BTW, this sounds like suspicion that trying to underst= and what I mean, and explain why I am wrong if I am, isn't worth the ef= fort.
I have had my share of that.=A0Disappointed to see your see= ming to join this view.)


second, you argued no matter how it is minor, a tunnel solution should= cover it. test scenario having not repeat the checksum error doesn't m= ean it never happens.

it might be strange to me that you at= tach special importance to the trasparency of DF=3DMF=3D1 but think checksu= m transparency is not a concern.=A0

=
Yet, a test that shows that DF=3DMF=3D1 becomes DF=3D1/MF=3D0 after d= ouble RFC6145 translation is trivial, with 100%=A0guaranteed=A0success.
The same for a test that No UDP checksum is translated into a comput= ed UDP checksum.


in practice,

unfortunately, nobody can do su= ch a conclusion to say them useless, either nobody can say the checksum err= or is "minor". even on the Earth rather than the spacecraft, ther= e are a lot reason causing bit-errors not yet well-protected by link layer.= you might be interested in a paper published in SIGCOMM'00: = http://dl.acm.org/citation.cfm?id=3D347561&bnc=3D1 it is basically = about TCP/UDP checksum error statistics while i believe you do agree the un= derstanding is also applicable for the IPv4/ICMPv6 case. the checksum error= happens with the frequency between 1/1100 ~ 1/32000, and reaches 1/400 in = some circumstances, even though the link layer CRC is there.=A0

to save your time, you may read http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf i= nstead, for a quick understanding on why protocol needs to include its own = checksum even if the link layer has had CRC mechanism.=A0

The only router induced errors= I saw in this presentation are due to
- buggy network interfaces=
- memory errors
- bus malfunctions=A0
All of= these are hardware failures.

If we d= on't agree on this, lets first understand why.

(2)
If one would assume that packets can be c= orrupted at L2 without being discarded (which you seem to assume), then RFC= 6145 could translate a corrupted IPv4 packet having no UDP checksum into a = corrupted packet having=A0corrupted data=A0and valid checksum.=A0

ok,

this tal= k is limited to the case where corruption happens inside in the UDP protoco= l data unit.=A0

Right.
=
A. native IPv= 4: if corrupted packet having no UDP checksum arrives at destination, the d= estination anyway accepts the corrupted data;=A0

Yes, but in native IPv4 (and across= 4rd-u tunnels) destination hosts know there is no checksum.

B. acrossing IPv6 RFC6145 domain:=A0
=A0 =A0B.1 if corruptio= n happens before entering the IPv6 domain, yes,
corrupted data = with valid checksum is generated, and delivered to destination, which will = accept the corrupted data;

The point is that corrupted data ar= e accepted with the supposed guarantee that they were protected by a checks= um.

=A0 =A0B.2 if corruption happens in the IPv6 domain, the translation w= ith checksum provides a certain extent of protection.=A0

Not the subject (and in any case possible only w= ith a supposed hardware failure).

RFC6145 don't make B.1 worse than A while improves B.2.
=

- Receiving erroneous data with a c= hecksum that assures they are valid is WORSE than receiving corrupted data = with a warning that they haven't been verified.

I hope you can agree on this.

=
don't you think it is a pros instead of a cons?=A0

Neither pro nor con, because the implied = assumption of hardware failure remains AFAIAC out of scope.

=A0
This would be much worse, as far as security is concerned, than ICMPv4 pack= ets whose data would have been corrupted. =A0

(on the other hand, if y= ou would like to make a commentary for RFC6145 detailed behavior,

No wish to comment RFC6145 other than i= n the context of double translation.

i'd love to offer assistance as i happend to make some humbl= e observations on it too, but this is not the scope of this thread.)
=A0
=A0=A0
commentary document will in= clude this understanding in next revision, without judging how severe this = concern is in practice.

Before point 1 above is clarified, includ= ing what you said above in the next version of your draft would be AFAIK mi= sleading.

in the term of = stating the semantic changes with leaving judgement to readers, i don't= think there will be any misleading. i only write the fact and the concern.= some of them might be significant and severe, some of them might be only t= rivial FUD. but even FUD, we are obliged to let the community know it.=A0

Let's then see what you wi= ll write, hopefully with preliminary consideration of the above.
=
Regards,
RD


- maoke=A0



--20cf300faff5e1ff9704bd7d1c77-- From fibrib@gmail.com Thu Apr 12 09:15:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650DF21F86A6 for ; Thu, 12 Apr 2012 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGkPvlBH7-zP for ; Thu, 12 Apr 2012 09:15:51 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC221F869E for ; Thu, 12 Apr 2012 09:15:51 -0700 (PDT) Received: by qafi31 with SMTP id i31so4620312qaf.15 for ; Thu, 12 Apr 2012 09:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4IuTMUc1inhcPuJ2UCcj3BzXPhQz+FRCGfcnfu6ryC0=; b=zEBbpXEKPDeA3R8sbDCzr8Ptwvjk3h8J/gBjkU9l0q1HTrCGkgQqS+Zuey+9DXhovy q0DHGYKD9RlEFiTrU76+OAq2Cmg2OPN77SMxFc17Ug2iqC+9xHOKIY0mfHHULkRGXcHJ 2jeoEFXxc+gCiPeOX1fGy2oBbiSk2/if2QyMg4fuLeRcJq+mDfHdFHfgSM4DT2ziIOp9 R95G0M3NmdDga5KmRETnXxwOQ4AoZpaOZj1jh79iybG8PMnQAz6ywKH+oOuGyf6RLXui nFirF29pW66zZwGAbAsM6nDgBjFlxwkH4ultyMYia3A9cwpF4cOyQ83xvPodAyEtGlG6 nqYw== MIME-Version: 1.0 Received: by 10.229.135.18 with SMTP id l18mr1230793qct.18.1334247350864; Thu, 12 Apr 2012 09:15:50 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 12 Apr 2012 09:15:50 -0700 (PDT) In-Reply-To: <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> Date: Fri, 13 Apr 2012 01:15:50 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00032556550a640a9304bd7dabc4 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:15:52 -0000 --00032556550a640a9304bd7dabc4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, this acknowledges the part not belonging to technical issues. 2012/4/11 R=E9mi Despr=E9s > Maoke, > > Good to see that at least one who has read the 4rd-u draft still consider= s > that technical considerations are worth working on. > > sorry if you mean the "at least one" is me, i don't consider the technical considerations are worth working on but i only share understanding for others' judgement on the worthness. > > Thanks. > > IMHO, you did a great job to structure this (useful) discussion. > Here are quick comments/suggestions/corrections I propose: > > thanks for comments. basically the commentary is straightforward and any statement with metaphysics should be avoided. from Mx to Tx, the author appreciate any comments but the wording will based on what the author understands. on the other hand, repeating what 4rd-u draft has stated in another draft is trivial. in details, the following comments (regarding section 4) will be reviewed but the author won't adopt some of them, especially when it contains metaphysics beyond the context. thanks and regards, maoke > > > > 4.1. (M2) Rather than "simplification of L4 protocol treatment" the > motivation is "Full IPv4 transparency, with never modified payloads and > IPv4 fragmentation semantics" > > 4.1. (M4) a motivation to be added: "No constraint on subnet-ID > assignments in customer sites" > > 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as > ensured as in MAP-E" instead of "4rd-U argues it should be supported no > matter how minor it is observed in practice". > > 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they > prefer, concerning DiffServ architecture, provided users cannot make the > difference" instead of "4rd-U argues ToS should be kept unchanged when th= e > packet traverses the IPv6 domain, except the ECN bits". > > 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet > validity of IPv4 tunneled packets, for all present and future protocols > that have ports as the same place as TCP and the same checksum algorithm, > without being concerned with where these protocols have their checksum > fields" instead of "it also argues checksum validity should be ensured > through address in order to simplify L4 processing" > > 4.2. (O6)- to be added > "UDP null checksums: [RFC6145] can be configured either to drop all IPv4 > packets having null checksums, or drop only those that are fragmented. > 4rd-u argues that this lack of IPv4 transparency should be avoided." > > 4.2. (O7)- to be added > "Free assignment of subnet IDs: subnet IDs that follow customer-site > prefixes in native IPv6 addresses are so far freely chosen for each > customer site. 4rd-u argues that this freedom should not be lost, despite > the need to distinguish IPv4-originated packets from native IPv6 packets = at > customer-site entrances. > > 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), > and (07), should IMHO be considered in scope (if a new version is issued)= . > > --00032556550a640a9304bd7dabc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

hi Remi,
=A0
this=A0acknowledges the part not = belonging to technical issues.
2012/4/= 11 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,
=
Good to see that at least one who has read the 4rd-u draft still= considers that technical considerations are worth working on.
= =A0
=A0
sorry if you mean the "= at least one" is me, i don't consider the technical considerations= are worth working on but i only=A0share understanding for others' judg= ement on the worthness.
=A0
=A0=
Thanks.

IMHO, you did a great job to structur= e this (useful) discussion.
Here are quick comments/suggestions/c= orrections I propose:=A0
=A0
=A0
thanks for comments.=A0basically the commentary is straightforward and= any statement with metaphysics should be avoided. from Mx to Tx, the autho= r appreciate any comments but the wording will based on what the author und= erstands. on the other hand, repeating what 4rd-u draft has stated in anoth= er draft is trivial.
=A0
in details,=A0the following comments (regarding section = 4) will be reviewed but the author won't adopt=A0some of them, especial= ly when=A0it contains metaphysics beyond the context.
=A0
<= div>thanks and regards,
maoke
=A0
=A0


4.1. (M2) Rather than &quo= t;simplification of L4 protocol treatment" the motivation is "Ful= l IPv4 transparency, with never modified payloads and IPv4 fragmentation se= mantics"

4.1. (M4) a motivation to be added: =A0"No constra= int on subnet-ID assignments in customer sites"

4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be= as ensured as in MAP-E" instead of "4rd-U argues it should be su= pported no matter how minor it is observed in practice".

4.2. (O1) "4rd-u leaves it to ISPs to decide which= kind of tunnel they prefer, concerning DiffServ architecture, provided use= rs cannot make the difference" instead of "4rd-U argues ToS shoul= d be kept unchanged when the packet traverses the IPv6 domain, except the E= CN bits".

4.2. (O5) "it also argues that checksum transparen= cy ensures IPv6 packet validity of IPv4 tunneled packets, for all present a= nd future protocols that have ports as the same place as TCP and the same c= hecksum algorithm, without being concerned with where these protocols have = their checksum fields" =A0instead of "it also argues checksum val= idity should be ensured through address in order to simplify L4 processing&= quot;

4.2. (O6)- to be added=A0
"UDP null chec= ksums: [RFC6145] can be configured either to drop all IPv4 packets having n= ull checksums, or drop only those that are fragmented. 4rd-u argues that th= is lack of IPv4 transparency should be avoided."

4.2. (O7)- to be added=A0
"Free assignme= nt of subnet IDs: =A0subnet IDs that follow customer-site prefixes in nativ= e IPv6 addresses are so far freely chosen for each customer site. 4rd-u arg= ues that this freedom should not be lost, despite the need to distinguish I= Pv4-originated packets from native IPv6 packets at customer-site entrances.= =A0

4.2. after (T6) CNP and V octet, because they are relat= ed to (M4), (O6), and (07), should IMHO be considered in scope (if a new ve= rsion is issued).

--00032556550a640a9304bd7dabc4-- From despres.remi@laposte.net Thu Apr 12 09:36:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921BB21F86AB for ; Thu, 12 Apr 2012 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO8+kbfNhB9o for ; Thu, 12 Apr 2012 09:36:28 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5D21F86A8 for ; Thu, 12 Apr 2012 09:36:27 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id x4cR1i00A37Y3f4034cRyP; Thu, 12 Apr 2012 18:36:25 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--540900892 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 12 Apr 2012 18:36:24 +0200 Message-Id: <9DD221DC-9EAE-40B7-B424-9D2282DF1ABE@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:36:29 -0000 --Apple-Mail-6--540900892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-12 =E0 18:15, Maoke a =E9crit : >=20 > hi Remi, > =20 > this acknowledges the part not belonging to technical issues.=20 > 2012/4/11 R=E9mi Despr=E9s > Maoke, >=20 > Good to see that at least one who has read the 4rd-u draft still = considers that technical considerations are worth working on. > =20 > =20 > sorry if you mean the "at least one" is me, > i don't consider the technical considerations are worth working on Sorry to learn that. > but i only share understanding for others' judgement on the worthness. > =20 > =20 > Thanks. >=20 > IMHO, you did a great job to structure this (useful) discussion. > Here are quick comments/suggestions/corrections I propose:=20 > =20 > =20 > thanks for comments. basically the commentary is straightforward and = any statement with metaphysics should be avoided. Agreed. > from Mx to Tx, the author appreciate any comments but the wording will = based on what the author understands. Of course. > on the other hand, repeating what 4rd-u draft has stated in another = draft is trivial. > =20 > in details, the following comments (regarding section 4) will be = reviewed but the author won't adopt some of them, especially when it = contains metaphysics beyond the context. Why you consider points below to be metaphysics is obscure to me. They are believed to be operational and/or technical. Your listing your own view of 4rd-u motivations, while refusing mine, = remains your responsibility. RD > =20 > thanks and regards, > maoke > =20 > =20 >=20 >=20 > 4.1. (M2) Rather than "simplification of L4 protocol treatment" the = motivation is "Full IPv4 transparency, with never modified payloads and = IPv4 fragmentation semantics" >=20 > 4.1. (M4) a motivation to be added: "No constraint on subnet-ID = assignments in customer sites" >=20 > 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as = ensured as in MAP-E" instead of "4rd-U argues it should be supported no = matter how minor it is observed in practice". >=20 > 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they = prefer, concerning DiffServ architecture, provided users cannot make the = difference" instead of "4rd-U argues ToS should be kept unchanged when = the packet traverses the IPv6 domain, except the ECN bits". >=20 > 4.2. (O5) "it also argues that checksum transparency ensures IPv6 = packet validity of IPv4 tunneled packets, for all present and future = protocols that have ports as the same place as TCP and the same checksum = algorithm, without being concerned with where these protocols have their = checksum fields" instead of "it also argues checksum validity should be = ensured through address in order to simplify L4 processing" >=20 > 4.2. (O6)- to be added=20 > "UDP null checksums: [RFC6145] can be configured either to drop all = IPv4 packets having null checksums, or drop only those that are = fragmented. 4rd-u argues that this lack of IPv4 transparency should be = avoided." >=20 > 4.2. (O7)- to be added=20 > "Free assignment of subnet IDs: subnet IDs that follow customer-site = prefixes in native IPv6 addresses are so far freely chosen for each = customer site. 4rd-u argues that this freedom should not be lost, = despite the need to distinguish IPv4-originated packets from native IPv6 = packets at customer-site entrances.=20 >=20 > 4.2. after (T6) CNP and V octet, because they are related to (M4), = (O6), and (07), should IMHO be considered in scope (if a new version is = issued). >=20 --Apple-Mail-6--540900892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

hi = Remi,
 
this acknowledges the part not = belonging to technical issues.
2012/4/11 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Maoke,

Good to see that at least one who has read the 4rd-u draft = still considers that technical considerations are worth working = on.
 
 
sorry = if you mean the "at least one" is me, =

i don't consider the technical considerations = are worth working on

Sorry = to learn that.

but i only share understanding for = others' judgement on the worthness.
 
 
Thanks.

IMHO, you did a great job to = structure this (useful) discussion.
Here are quick = comments/suggestions/corrections I = propose: 
 
 
thanks for comments. basically the commentary is = straightforward and any statement with metaphysics should be avoided. =

Agreed.

from Mx to Tx, the author = appreciate any comments but the wording will based on what the author = understands.

Of = course.


on the other hand, repeating what 4rd-u draft = has stated in another draft is trivial.
 
in details, the following comments (regarding = section 4) will be reviewed but the author won't adopt some of = them, especially when it contains metaphysics beyond the context. =

Why you consider points below to = be metaphysics is obscure to me.
They are believed to be = operational and/or technical.

Your listing your = own view of 4rd-u motivations, while refusing mine, remains your = responsibility.


RD

<= /div>

 
thanks and regards,
maoke
 
 


4.1. (M2) Rather = than "simplification of L4 protocol treatment" the motivation is "Full = IPv4 transparency, with never modified payloads and IPv4 fragmentation = semantics"

4.1. (M4) a motivation to be added:  "No = constraint on subnet-ID assignments in customer = sites"

4.2. (O1) "4rd-U argues that IPv4 = end-to-end transparency should be as ensured as in MAP-E" instead of = "4rd-U argues it should be supported no matter how minor it is observed = in practice".

4.2. (O1) "4rd-u leaves it to ISPs to decide which = kind of tunnel they prefer, concerning DiffServ architecture, provided = users cannot make the difference" instead of "4rd-U argues ToS should be = kept unchanged when the packet traverses the IPv6 domain, except the ECN = bits".

4.2. (O5) "it also argues that checksum transparency = ensures IPv6 packet validity of IPv4 tunneled packets, for all present = and future protocols that have ports as the same place as TCP and the = same checksum algorithm, without being concerned with where these = protocols have their checksum fields"  instead of "it also argues = checksum validity should be ensured through address in order to simplify = L4 processing"

4.2. (O6)- to be added 
"UDP null = checksums: [RFC6145] can be configured either to drop all IPv4 packets = having null checksums, or drop only those that are fragmented. 4rd-u = argues that this lack of IPv4 transparency should be avoided."

4.2. (O7)- to be added 
"Free = assignment of subnet IDs:  subnet IDs that follow customer-site = prefixes in native IPv6 addresses are so far freely chosen for each = customer site. 4rd-u argues that this freedom should not be lost, = despite the need to distinguish IPv4-originated packets from native IPv6 = packets at customer-site entrances. 

4.2. after (T6) CNP and V octet, because they are = related to (M4), (O6), and (07), should IMHO be considered in scope (if = a new version is issued).


= --Apple-Mail-6--540900892-- From fibrib@gmail.com Thu Apr 12 09:50:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFB221F865C for ; Thu, 12 Apr 2012 09:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRJBFo7xoTkZ for ; Thu, 12 Apr 2012 09:50:12 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AC12D21F863E for ; Thu, 12 Apr 2012 09:50:12 -0700 (PDT) Received: by qaea16 with SMTP id a16so1646278qae.10 for ; Thu, 12 Apr 2012 09:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9XALP66Vc63pQYOzeJ8CyI6AElrFfRSs88FWWssL810=; b=K94VE/hecDC6vjRA6B7GMlQEN6CikMZ/yFrOcC1HHhT9iZ0sr0vPU78/1/B2RStrBM 3tPyIcqI3QfOIrgQftSWzLLtGYWBmlqB5HrhBYkE72mV5FxQWNnXAz9Rd2b8SUw1gHUp ThVuRrzPGzgbxmukjv3pz0jF1oTfLou4CUFoOXMFfNcSgehvp/3gv++qHApIF0f41Cjq 80sA006fRfABXF6hAYPnUCASpki1AIxTRjcuC6onzv0qQOTrsfqDlqNjs6drcfqKVtFB 3/ZpbnYckUnfV31Qt+vwpxpesu3HTFYqxpq154/nog2Ng1serPwSNAOtbv1GRGjRGMTX I3hQ== MIME-Version: 1.0 Received: by 10.224.181.69 with SMTP id bx5mr4982034qab.49.1334249412143; Thu, 12 Apr 2012 09:50:12 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 12 Apr 2012 09:50:11 -0700 (PDT) In-Reply-To: <9DD221DC-9EAE-40B7-B424-9D2282DF1ABE@laposte.net> References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <9DD221DC-9EAE-40B7-B424-9D2282DF1ABE@laposte.net> Date: Fri, 13 Apr 2012 01:50:11 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dcfc940a9cf04bd7e2602 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:50:14 -0000 --485b397dcfc940a9cf04bd7e2602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/13 R=E9mi Despr=E9s > > on the other hand, repeating what 4rd-u draft has stated in another draft > is trivial. > > > in details, the following comments (regarding section 4) will be reviewed > but the author won't adopt some of them, especially when it contains > metaphysics beyond the context. > > > Why you consider points below to be metaphysics is obscure to me. > They are believed to be operational and/or technical. > > Your listing your own view of 4rd-u motivations, while refusing mine, > remains your responsibility. > > i said "won't adopt some of them" but all will be reviewed and referenced. the text, sure, as signed by me, is my responsibility. - maoke > > > > RD > > > > thanks and regards, > maoke > > >> >> >> >> 4.1. (M2) Rather than "simplification of L4 protocol treatment" the >> motivation is "Full IPv4 transparency, with never modified payloads and >> IPv4 fragmentation semantics" >> >> 4.1. (M4) a motivation to be added: "No constraint on subnet-ID >> assignments in customer sites" >> >> 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as >> ensured as in MAP-E" instead of "4rd-U argues it should be supported no >> matter how minor it is observed in practice". >> >> 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they >> prefer, concerning DiffServ architecture, provided users cannot make the >> difference" instead of "4rd-U argues ToS should be kept unchanged when t= he >> packet traverses the IPv6 domain, except the ECN bits". >> >> 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet >> validity of IPv4 tunneled packets, for all present and future protocols >> that have ports as the same place as TCP and the same checksum algorithm= , >> without being concerned with where these protocols have their checksum >> fields" instead of "it also argues checksum validity should be ensured >> through address in order to simplify L4 processing" >> >> 4.2. (O6)- to be added >> "UDP null checksums: [RFC6145] can be configured either to drop all IPv4 >> packets having null checksums, or drop only those that are fragmented. >> 4rd-u argues that this lack of IPv4 transparency should be avoided." >> >> 4.2. (O7)- to be added >> "Free assignment of subnet IDs: subnet IDs that follow customer-site >> prefixes in native IPv6 addresses are so far freely chosen for each >> customer site. 4rd-u argues that this freedom should not be lost, despit= e >> the need to distinguish IPv4-originated packets from native IPv6 packets= at >> customer-site entrances. >> >> 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), >> and (07), should IMHO be considered in scope (if a new version is issued= ). >> >> > --485b397dcfc940a9cf04bd7e2602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/13 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

on the other hand, repeat= ing what 4rd-u draft has stated in another draft is trivial.
=A0
in details,=A0the following comments (regarding section = 4) will be reviewed but the author won't adopt=A0some of them, especial= ly when=A0it contains metaphysics beyond the context.

Why you consider points below to be metaphysics is obs= cure to me.
They are believed to be operational and/or technical.=

Your listing your own view of 4rd-u motivations, = while refusing mine, remains your responsibility.
=A0
=A0
i said "won't = adopt some of them" but all will be reviewed and referenced. the text,= sure,=A0as signed by me, is my responsibility.
=A0
- = maoke
=A0
=A0=


RD
<= div class=3D"im">


=A0
thanks and regards,
maoke
=A0
=A0


4.1. (M2) Rather than &quo= t;simplification of L4 protocol treatment" the motivation is "Ful= l IPv4 transparency, with never modified payloads and IPv4 fragmentation se= mantics"

4.1. (M4) a motivation to be added: =A0"No constra= int on subnet-ID assignments in customer sites"

4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be= as ensured as in MAP-E" instead of "4rd-U argues it should be su= pported no matter how minor it is observed in practice".

4.2. (O1) "4rd-u leaves it to ISPs to decide which= kind of tunnel they prefer, concerning DiffServ architecture, provided use= rs cannot make the difference" instead of "4rd-U argues ToS shoul= d be kept unchanged when the packet traverses the IPv6 domain, except the E= CN bits".

4.2. (O5) "it also argues that checksum transparen= cy ensures IPv6 packet validity of IPv4 tunneled packets, for all present a= nd future protocols that have ports as the same place as TCP and the same c= hecksum algorithm, without being concerned with where these protocols have = their checksum fields" =A0instead of "it also argues checksum val= idity should be ensured through address in order to simplify L4 processing&= quot;

4.2. (O6)- to be added=A0
"UDP null chec= ksums: [RFC6145] can be configured either to drop all IPv4 packets having n= ull checksums, or drop only those that are fragmented. 4rd-u argues that th= is lack of IPv4 transparency should be avoided."

4.2. (O7)- to be added=A0
"Free assignme= nt of subnet IDs: =A0subnet IDs that follow customer-site prefixes in nativ= e IPv6 addresses are so far freely chosen for each customer site. 4rd-u arg= ues that this freedom should not be lost, despite the need to distinguish I= Pv4-originated packets from native IPv6 packets at customer-site entrances.= =A0

4.2. after (T6) CNP and V octet, because they are relat= ed to (M4), (O6), and (07), should IMHO be considered in scope (if a new ve= rsion is issued).



--485b397dcfc940a9cf04bd7e2602-- From jiangdong345@gmail.com Tue Apr 17 20:09:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF44411E80E2 for ; Tue, 17 Apr 2012 20:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umNgCOUdnj58 for ; Tue, 17 Apr 2012 20:08:58 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BD74111E807F for ; Tue, 17 Apr 2012 20:08:58 -0700 (PDT) Received: by dady13 with SMTP id y13so12701878dad.27 for ; Tue, 17 Apr 2012 20:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=csoMY9NeamkmmNQh4ak6aw2rH3Wof4LH3eMVxKbaX1E=; b=WFfyIxVCqPtiNk6PC+tLjC6uDMC6kVEw+RRVNGs+nuE+OaWEmk7bPW+wWMFkYA/8Ik bT6mHF3bCR0trUOv+ZYYMEDIfJGzG8r42t0dT5760ShEFQfmWpszytfetVCNSSxdAvpR yNKRlon/TUbTsICqjgR2xw+4bYUlH8anM2g1obg9aGcrb4kvKBMEuhETAojeWpw/zlX0 nohkm8EVSL5jeMRe5F5rDY8dp4J32IOhpuRoXy5b+E5C8GSwEafDT0Hjv29HhfP+EEL4 tcVxgph3guiHanaLzdxu/kms8zDnvu8nS91BRTSfQ2JG7MFJKdD1fHc28XulzSR9I7Ae TlcA== Received: by 10.68.216.129 with SMTP id oq1mr2477970pbc.62.1334718538381; Tue, 17 Apr 2012 20:08:58 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id oh2sm15837195pbb.45.2012.04.17.20.08.55 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 20:08:57 -0700 (PDT) Date: Wed, 18 Apr 2012 11:08:58 +0800 From: "Jiang Dong" To: shtsuchi References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> <2012032621591809758988@gmail.com>, <4F707AE1.2000802@cisco.com> X-Priority: 3 X-GUID: FB25F7AE-8C53-45FE-8E10-C03A9D6FEBA6 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012041811085634958730@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart811858570118_=----" Cc: "cai.lei3" , Softwires WG Subject: Re: [Softwires] Comments about 6rd MIB X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 03:09:02 -0000 This is a multi-part message in MIME format. ------=_001_NextPart811858570118_=---- Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 SGkgU2hpc2hpbywNCg0KSXQgc2VlbXMgdGhlIGRlZmluaXRpb24gb2YgNnJkIE1JQiBpcyBtb3Jl IGFjY2VwdGFibGUgdGhhbiB0aGUgZXh0ZW5zaW9uIG9mIElQIHR1bm5lbCBNSUIgYWNjb3JkaW5n IHRvIHRoZSAgU29mdHdpcmUgbWVldGluZyBpbiBQYXJpcy4NCg0KU2luY2UgdGhlIDZyZCBNSUIg ZHJhZnQgaXRzZWxmIGlzIHF1aXRlIGNsZWFyLCBhIGNsYXJpZmljYXRpb24gb2YgdXNpbmcgb25l IHNwZWNpZmljIHdheSB3b3VsZCBiZSBoZWxwZnVsIDogKQ0KDQpSZWdhcmRzIQ0KSmlhbmcgRG9u Zw0KMjAxMi0wNC0xOA0KDQpGcm9tOiBTaGlzaGlvIFRzdWNoaXlhDQpEYXRlOiAyMDEyLTAzLTI2 IDIyOjE5DQpUbzogamlhbmdkb25nMzQ1DQpDQzogY2FpLmxlaTM7IGphY25pOyBzb2Z0d2lyZXM7 IGN1aXlvbmcNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXUNvbW1lbnRzIGFib3V0IDZyZCBNSUIN CkppYW5nDQpUaGFua3MgZm9yIGNvbW1lbnRzLg0KSSB3aWxsIGRvIHByZXNlbnRhdGlvbiB0aGlz IGRyYWZ0IGF0IEZyaWRheSxhbmQgSSB3aWxsIGFzayB3aGljaCBpZGVhIGlzIGJldHRlciB0byB0 aGUgYXVkaWVuY2UgYW5kIGNoYWlycy4NCklmIElQIHR1bm5lbCBNSUIgZXh0ZW5kZWQgaXMgYmV0 dGVyIHRoYW4gNnJkTUlCLHNvIHdlIHdvdWxkIHVwZGF0ZSBhbmQgZGVmaW5lIGV4dGVuc2lvbiBv ZiBJUCB0dW5uZWwgTUlCLg0KNnJkIE1JQiBpcyBjb21wbGV0ZWx5IHJlZmxlY3RpbmcgdG8gNnJk IGNvbmZpZ3VyYXRpb24uDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTY5I3NlY3Rp b24tNw0KInNpeFJkSXB2NE1hc2tMZW4gIiAgaXMgc2FtZSBmdW5jdGlvbiBhcyBJUHY0TWFza0xl bi4NCg0KSVB2NE1hc2tMZW4gICAgICAgICBUaGUgbnVtYmVyIG9mIGhpZ2gtb3JkZXIgYml0cyB0 aGF0IGFyZSBpZGVudGljYWwNCiAgICAgICAgICAgICAgICAgICAgICAgYWNyb3NzIGFsbCBDRSBJ UHY0IGFkZHJlc3NlcyB3aXRoaW4gYSBnaXZlbiA2cmQNCiAgICAgICAgICAgICAgICAgICAgICAg ZG9tYWluLiAgRm9yIGV4YW1wbGUsIGlmIHRoZXJlIGFyZSBubyBpZGVudGljYWwNCiAgICAgICAg ICAgICAgICAgICAgICAgYml0cywgSVB2NE1hc2tMZW4gaXMgMCBhbmQgdGhlIGVudGlyZSBDRSBJ UHY0DQogICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgaXMgdXNlZCB0byBjcmVhdGUgdGhl IDZyZCBkZWxlZ2F0ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgcHJlZml4LiAgSWYgdGhlcmUg YXJlIDggaWRlbnRpY2FsIGJpdHMgKGUuZy4sIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICBQ cml2YXRlIElQdjQgYWRkcmVzcyByYW5nZSAxMC4wLjAuMC84IGlzIGJlaW5nDQogICAgICAgICAg ICAgICAgICAgICAgIHVzZWQpLCBJUHY0TWFza0xlbiBpcyBlcXVhbCB0byA4IGFuZCBJUHY0TWFz a0xlbg0KICAgICAgICAgICAgICAgICAgICAgICBoaWdoLW9yZGVyIGJpdHMgYXJlIHN0cmlwcGVk IGZyb20gdGhlIElQdjQNCiAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzcyBiZWZvcmUgY29u c3RydWN0aW5nIHRoZSBjb3JyZXNwb25kaW5nIDZyZA0KICAgICAgICAgICAgICAgICAgICAgICBk ZWxlZ2F0ZWQgcHJlZml4Lg0KDQpSZWdhcmRzLA0KLVNoaXNoaW8NCg0KKDIwMTIvMDMvMjYgMTU6 NTkpLCBKaWFuZyBEb25nIHdyb3RlOg0KPiBIaSxhdXRob3JzIG9mIDZyZCBNSUIsDQo+IEkgZ2V0 IHNvbWUgY29tbWVudHMgYWJvdXQgNnJkIE1JQiBkcmFmdC4NCj4gMSkgWW91IG1lbnRpb25lZCB0 aGUgInR1bm5lbElmWFRhYmxlIiBpbiBzZWN0aW9uIDUuMi4gSSB0aGluayBpdCBpcyBhIGdvb2Qg aWRlYSB0byBleHRlbmQgdGhlIHR1bm5lbCBNSUIsIHNvbWUgc2NlbmFyaW8gY2Fubm90IGJlIGlu Y2x1ZGVkIGluIFJGQzQwODcsIHN1Y2ggYXMgcG9pbnQgdG8gbXVsdGktcG9pbnQgdHVubmVsIGxp a2Ugc29mdHdpcmUgbWVzaC4NCj4gMikgSXQgc2VlbXMgeW91IG1pc3MgdGhlIGNvbmZvcm1hbmNl IHBhcnQgaW4gdGhlIGRlZmluaXRpb24uDQo+IDMpIEknbSBub3QgcXVpdGUgc3VyZSB3aGF0J3Mg dGhlICJzaXhSZElwdjRNYXNrTGVuICIgdXNlZCBmb3IsIGNhbiB5b3UgZXhwbGFpbiBpdD8NCj4g UmVnYXJkcyENCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEppYW5nIERvbmcNCj4gVHNpbmdo dWEgVW5pdmVyc2l0eQ0KPiA= ------=_001_NextPart811858570118_=---- Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
Date: 2012-03-26 22:19
To: jiangdong345
CC: cai.lei3; = jacni; softwires; cuiyong
Subject: Re: [Softwires]Comments about 6rd=20 MIB
Jiang
Thanks for comments.
I will do presentation this draft at&nb= sp;Friday,and I will ask which idea is = better to the audience and chairs.
If IP tunnel MIB extended is better&nbs= p;than 6rdMIB,so we would update and define&= nbsp;extension of IP tunnel MIB.
6rd MIB is completely reflecting to 6rd=  configuration.
http://tools.ietf.org/html/rfc5969#section-7
"sixRdIpv4MaskLen "  is same function a= s IPv4MaskLen.
 
IPv4MaskLen         The&= nbsp;number of high-order bits that are iden= tical
           &nb= sp;           acros= s all CE IPv4 addresses within a given&= nbsp;6rd
           &nb= sp;           domai= n.  For example, if there are no i= dentical
           &nb= sp;           bits,=  IPv4MaskLen is 0 and the entire CE&nbs= p;IPv4
           &nb= sp;           addre= ss is used to create the 6rd delegated<= /DIV>
           &nb= sp;           prefi= x.  If there are 8 identical bits = (e.g., the
           &nb= sp;           Priva= te IPv4 address range 10.0.0.0/8 is being
           &nb= sp;           used)= , IPv4MaskLen is equal to 8 and IPv4Mas= kLen
           &nb= sp;           high-= order bits are stripped from the IPv4
           &nb= sp;           addre= ss before constructing the corresponding 6rd
           &nb= sp;           deleg= ated prefix.
 
Regards,
-Shishio
 
(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> I get some comments about 6rd = ;MIB draft.
> 1) You mentioned the "tunnelIfXTable"&n= bsp;in section 5.2. I think it is a&nbs= p;good idea to extend the tunnel MIB, s= ome scenario cannot be included in RFC4087,&= nbsp;such as point to multi-point tunnel lik= e softwire mesh.
> 2) It seems you miss the conf= ormance part in the definition.
> 3) I'm not quite sure what's = the "sixRdIpv4MaskLen " used for, can you&nb= sp;explain it?
> Regards!
> -----------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= -------------------------------------------
> Jiang Dong
> Tsinghua University
> 
 
 
------=_001_NextPart811858570118_=------ From jacni@jacni.com Wed Apr 18 00:28:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDD021F85A5 for ; Wed, 18 Apr 2012 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dekhV+hPs5xa for ; Wed, 18 Apr 2012 00:28:09 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9F21F85A0 for ; Wed, 18 Apr 2012 00:28:09 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id DD546380078 for ; Wed, 18 Apr 2012 03:28:07 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 6CFFA340121 for ; Wed, 18 Apr 2012 15:28:06 +0800 (CST) Received: from [10.140.20.170] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJDrH40DbY5PGajLAA--.49077S2; Wed, 18 Apr 2012 15:28:05 +0800 (CST) Message-ID: <4F8E6D01.4060409@jacni.com> Date: Wed, 18 Apr 2012 15:28:01 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: jiangdong345 References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> <2012032621591809758988@gmail.com>, <4F707AE1.2000802@cisco.com> <2012041811085634958730@gmail.com> In-Reply-To: <2012041811085634958730@gmail.com> Content-Type: multipart/alternative; boundary="------------040404010600050608050003" X-CM-TRANSID: +AWowJDrH40DbY5PGajLAA--.49077S2 X-Coremail-Antispam: 1UD129KBjvJXoWxArWxWFWDAry8Jw4rKryDKFg_yoW5ZFW8pr 13Jr17Jr1UJr1UJr1UJr1UJr1UJr1UJr1UJr1UJr18Jr1UAr1UJr1UJry8JryUJry8Jr1U Jr1UJr1UJr1UJrUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnGAYjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67 AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07Al zVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI4 8JYxBIdaVFxhVjvjDU0xZFpf9x07jzD73UUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAGEko7lQrv+QAOsj Cc: "cai.lei3" , Softwires WG Subject: Re: [Softwires] Comments about 6rd MIB X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:28:13 -0000 This is a multi-part message in MIME format. --------------040404010600050608050003 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Re-, Thanks Jiang Dong, for your comments, I'll discuss with the authors about it. Cheers, Jacni On 4/18/2012 Wednesday 11:08 AM, Jiang Dong wrote: > HiShishio, > It seems the definition of 6rd MIB is more acceptable than the > extension of IP tunnel MIB according to the Softwire meeting in Paris. > Since the 6rd MIB draft itself is quite clear, a clarification of > using one specific way would be helpful : ) > Regards! > Jiang Dong > 2012-04-18 > *From:* Shishio Tsuchiya > *Date:* 2012-03-26 22:19 > *To:* jiangdong345 > *CC:* cai.lei3 ; jacni > ; softwires ; > cuiyong > *Subject:* Re: [Softwires]Comments about 6rd MIB > Jiang > Thanks for comments. > I will do presentation this draft at Friday,and I will ask which idea > is better to the audience and chairs. > If IP tunnel MIB extended is better than 6rdMIB,so we would update and > define extension of IP tunnel MIB. > 6rd MIB is completely reflecting to 6rd configuration. > http://tools.ietf.org/html/rfc5969#section-7 > "sixRdIpv4MaskLen " is same function as IPv4MaskLen. > IPv4MaskLen The number of high-order bits that are identical > across all CE IPv4 addresses within a given 6rd > domain. For example, if there are no identical > bits, IPv4MaskLen is 0 and the entire CE IPv4 > address is used to create the 6rd delegated > prefix. If there are 8 identical bits (e.g., the > Private IPv4 address range 10.0.0.0/8 is being > used), IPv4MaskLen is equal to 8 and IPv4MaskLen > high-order bits are stripped from the IPv4 > address before constructing the corresponding 6rd > delegated prefix. > Regards, > -Shishio > (2012/03/26 15:59), Jiang Dong wrote: > > Hi,authors of 6rd MIB, > > I get some comments about 6rd MIB draft. > > 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is > a good idea to extend the tunnel MIB, some scenario cannot be included > in RFC4087, such as point to multi-point tunnel like softwire mesh. > > 2) It seems you miss the conformance part in the definition. > > 3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can > you explain it? > > Regards! > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > Jiang Dong > > Tsinghua University > > --------------040404010600050608050003 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Re-,
Thanks Jiang Dong, for your comments, I'll discuss with the authors about it.

Cheers,
Jacni

On 4/18/2012 Wednesday 11:08 AM, Jiang Dong wrote:
Hi Shishio,
 
It seems the definition of 6rd MIB is more acceptable than the extension of IP tunnel MIB according to the  Softwire meeting in Paris.
 
Since the 6rd MIB draft itself is quite clear, a clarification of using one specific way would be helpful : )
 
Regards!
Jiang Dong
2012-04-18
 
Date: 2012-03-26 22:19
Subject: Re: [Softwires]Comments about 6rd MIB
Jiang
Thanks for comments.
I will do presentation this draft at Friday,and I will ask which idea is better to the audience and chairs.
If IP tunnel MIB extended is better than 6rdMIB,so we would update and define extension of IP tunnel MIB.
6rd MIB is completely reflecting to 6rd configuration.
"sixRdIpv4MaskLen "  is same function as IPv4MaskLen.
 
IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8 and IPv4MaskLen
                       high-order bits are stripped from the IPv4
                       address before constructing the corresponding 6rd
                       delegated prefix.
 
Regards,
-Shishio
 
(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> I get some comments about 6rd MIB draft.
> 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is a good idea to extend the tunnel MIB, some scenario cannot be included in RFC4087, such as point to multi-point tunnel like softwire mesh.
> 2) It seems you miss the conformance part in the definition.
> 3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can you explain it?
> Regards!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------- ----------------
> Jiang Dong
> Tsinghua University
> 
 
 
--------------040404010600050608050003-- From internet-drafts@ietf.org Wed Apr 18 00:45:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95C21F8623; Wed, 18 Apr 2012 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKGEioPJ+ctO; Wed, 18 Apr 2012 00:45:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCBC21F861D; Wed, 18 Apr 2012 00:45:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120418074529.32324.83570.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 00:45:29 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:45:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : Dayong Guo Sheng Jiang Remi Despres Roberta Maglione Filename : draft-ietf-softwire-6rd-radius-attrib-05.txt Pages : 10 Date : 2012-04-18 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-0= 5.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-05= .txt From internet-drafts@ietf.org Wed Apr 18 03:01:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9143B21F862A; Wed, 18 Apr 2012 03:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la2ndyrY5T1C; Wed, 18 Apr 2012 03:01:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCF421F85A2; Wed, 18 Apr 2012 03:01:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120418100144.10426.5286.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 03:01:44 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:01:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Mesh Multicast Author(s) : Mingwei Xu Yong Cui Shu Yang Jianping Wu Chris Metz Greg Shepherd Filename : draft-ietf-softwire-mesh-multicast-02.txt Pages : 27 Date : 2012-04-18 The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwires mesh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-mesh-multicast-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-mesh-multicast-02.txt From internet-drafts@ietf.org Sun Apr 22 08:51:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5368221F8552; Sun, 22 Apr 2012 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsDNB-7ubXH1; Sun, 22 Apr 2012 08:51:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8783F21F84DC; Sun, 22 Apr 2012 08:51:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120422155109.10602.27529.idtracker@ietfa.amsl.com> Date: Sun, 22 Apr 2012 08:51:09 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-gateway-init-ds-lite-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 15:51:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Gateway Initiated Dual-Stack Lite Deployment Author(s) : Frank Brockners Sri Gundavelli Sebastian Speicher David Ward Filename : draft-ietf-softwire-gateway-init-ds-lite-07.txt Pages : 14 Date : 2012-04-22 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lit= e-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lite= -07.txt From adurand@juniper.net Wed Apr 25 18:42:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A542521E801B for ; Wed, 25 Apr 2012 18:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28sXIh7BOUFJ for ; Wed, 25 Apr 2012 18:42:20 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8F11E80AE for ; Wed, 25 Apr 2012 18:42:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT5in+9+LdiC1yrViu09b1ejPY0MfPa//@postini.com; Wed, 25 Apr 2012 18:42:19 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 25 Apr 2012 18:41:25 -0700 From: Alain Durand To: "softwires@ietf.org WG" Date: Wed, 25 Apr 2012 18:41:23 -0700 Thread-Topic: Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: Ac0jTbBMgro6fzYwRbWon7NwOa/mEg== Message-ID: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:42:20 -0000 The chairs and ADs met to look at the results of the consensus call that en= ded Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from= the consensus call: - We had a number of people responding more than once, sometime with differ= ent email addresses. Having their name and affiliation in the response helped us removed those= duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about= 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in= Paris when the same question was asked have not participated in this conse= nsus call.=20 b) the number of MAP responses seem to be inflated, we see a disproportiona= te number of response from some particular organizations. We also see a lar= ge number of responses coming from people who have not participated before = in the working group. Also, it is apparent that a number of people have joi= ned the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need= participation in the official call for consensus from all the active parti= cipants of the working group. As we mentioned before, in such calls, silenc= e is consent. Also, the inflated participation in the consensus call from '= new' members that have never participate in the discussion before, creates = noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of b= oth solutions did continue, and missing elements on both sides have been po= inted out. We also observed a willingness of various participants to improv= e those specs to bring them to a level where we could start a working group= last call. As a result, we have decided to approve both MAP and 4rd-U as working group= work items. As work items, each document can be further refined until the= working group reaches consensus about advancing the documents for IETF rev= iew. Because of the history of MAP and 4rd-U, we will designate independent team= s of volunteer reviewers to advise the working group about the state of the= document sets. Each set will be reviewed by an independent team who are n= ot authors of the MAP and 4rd-U documents. Each review team will consist of= three members and will determine when its document set is ready for workin= g group last call. If you are interested in volunteering for one of the rev= iew teams, please respond directly to the chairs, indicating your preferenc= e for which document to review if you have one. The appointment of the revi= ew teams will be entirely up to the chairs. Aside from these appointed revi= ews, the chairs would naturally appreciate any and all reviews provided, re= gardless of whether the reviewer(s) participate on a review team. When the document sets are ready for working group last call, the working g= roup will reconsider the question of the publication status: Proposed Stand= ard or Experimental. We will try to consider all document sets for advance= ment at the same time, but we will not allow a delay in completing one docu= ment to hold up the working group indefinitely.=20 - Alain & Yong, WG co-chairs - Ralph & Biran, ADs= From leaf.y.yeh@huawei.com Wed Apr 25 20:02:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FC721E8018 for ; Wed, 25 Apr 2012 20:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmMmFPuY1hpY for ; Wed, 25 Apr 2012 20:02:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B689A11E80B8 for ; Wed, 25 Apr 2012 20:02:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF60145; Wed, 25 Apr 2012 23:02:11 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:58:11 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:58:16 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 10:58:08 +0800 From: Leaf yeh To: 'Ole Troan' , =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: Ac0jTbBMgro6fzYwRbWon7NwOa/mEgACktdA Date: Thu, 26 Apr 2012 02:58:08 +0000 Message-ID: References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org WG" , "map-dt@external.cisco.com" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 03:02:12 -0000 QWxhbiAtIEFzIGEgcmVzdWx0LCB3ZSBoYXZlIGRlY2lkZWQgdG8gYXBwcm92ZSBib3RoIE1BUCBh bmQgNHJkLVUgYXMgd29ya2luZyBncm91cCB3b3JrIGl0ZW1zLiAgQXMgd29yayBpdGVtcywgZWFj aCBkb2N1bWVudCBjYW4gYmUgZnVydGhlciByZWZpbmVkIHVudGlsIHRoZSB3b3JraW5nIGdyb3Vw IHJlYWNoZXMgY29uc2Vuc3VzIGFib3V0IGFkdmFuY2luZyB0aGUgZG9jdW1lbnRzIGZvciBJRVRG IHJldmlldy4NCg0KQ29uZ3JhdHVsYXRpb25zIQ0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFs YWluIER1cmFuZA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDI2LCAyMDEyIDk6NDEgQU0NClRvOiBz b2Z0d2lyZXNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIFJlc3VsdCBmcm9tIHRo ZSBjb25zZW5zdXMgY2FsbCBvbiBNYXAgdnMgNHJkLVUgYW5kIG9mZmljaWFsIHdheSBmb3J3YXJk DQoNClRoZSBjaGFpcnMgYW5kIEFEcyBtZXQgdG8gbG9vayBhdCB0aGUgcmVzdWx0cyBvZiB0aGUg Y29uc2Vuc3VzIGNhbGwgdGhhdCBlbmRlZCBXZWRuZXNkYXkgYW5kIGRlY2lkZSB0aGUgd2F5IGZv cndhcmQuDQoNCkZpcnN0LCB3ZSB3b3VsZCBsaWtlIHRvIG9mZmVyIGEgY291cGxlIG9ic2VydmF0 aW9ucyBvbiB0aGUgcmF3IHJlc3VsdHMgZnJvbSB0aGUgY29uc2Vuc3VzIGNhbGw6DQoNCi0gV2Ug aGFkIGEgbnVtYmVyIG9mIHBlb3BsZSByZXNwb25kaW5nIG1vcmUgdGhhbiBvbmNlLCBzb21ldGlt ZSB3aXRoIGRpZmZlcmVudCBlbWFpbCBhZGRyZXNzZXMuDQogIEhhdmluZyB0aGVpciBuYW1lIGFu ZCBhZmZpbGlhdGlvbiBpbiB0aGUgcmVzcG9uc2UgaGVscGVkIHVzIHJlbW92ZWQgdGhvc2UgZHVw bGljYXRlL3RyaXBsaWNhdGUvLi4uDQotIE51bWJlciBvZiB1bmlxdWUgcmVzcG9uc2U6IDc1DQot IFF1ZXN0aW9uIDE6IDc1IHllcywgMCBObywgZmV3ICByZXNwb25kZWQgcHV0IGJvdGggb24gZXhw ZXJpbWVudGFsIHRyYWNrDQotIFF1ZXN0aW9uIDI6IDczIE1BUCAyIDRyZC1VDQoNClRoaXMgZG9l cyBub3QgcmVmbGVjdCBhdCBhbGwgdGhlIHJlc3VsdHMgd2UgaGFkIGluIHRoZSBQYXJpcyBtZWV0 aW5nIChhYm91dCAzMCBNQVAgYW5kIDIwIDRyZC1VKToNCmEpIEl0IHNlZW1zIHRoYXQgc29tZSBv ZiB0aGUgNHJkLVUgcGVvcGxlIHdobyBkaWQgZXhwcmVzcyBzdXBwb3J0IGZvciBpdCBpbiBQYXJp cyB3aGVuIHRoZSBzYW1lIHF1ZXN0aW9uIHdhcyBhc2tlZCBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQg aW4gdGhpcyBjb25zZW5zdXMgY2FsbC4gDQpiKSB0aGUgbnVtYmVyIG9mIE1BUCByZXNwb25zZXMg c2VlbSB0byBiZSBpbmZsYXRlZCwgd2Ugc2VlIGEgZGlzcHJvcG9ydGlvbmF0ZSBudW1iZXIgb2Yg cmVzcG9uc2UgZnJvbSBzb21lIHBhcnRpY3VsYXIgb3JnYW5pemF0aW9ucy4gV2UgYWxzbyBzZWUg YSBsYXJnZSBudW1iZXIgb2YgcmVzcG9uc2VzIGNvbWluZyBmcm9tIHBlb3BsZSB3aG8gaGF2ZSBu b3QgcGFydGljaXBhdGVkIGJlZm9yZSBpbiB0aGUgd29ya2luZyBncm91cC4gQWxzbywgaXQgaXMg YXBwYXJlbnQgdGhhdCBhIG51bWJlciBvZiBwZW9wbGUgaGF2ZSBqb2luZWQgdGhlIG1haWxpbmcg bGlzdCBmb3IgdGhlIHNvbGUgcHVycG9zZSBvZiBleHByZXNzaW5nIHN1cHBvcnQgZm9yIE1BUC4N Cg0KTm9uZSBvZiB0aGUgYWJvdmUgYmVoYXZpb3JzIGRvIGFueSBmYXZvcnMgZm9yIHRoZSB3b3Jr aW5nIGdyb3VwLiBXZSBkbyBuZWVkIHBhcnRpY2lwYXRpb24gaW4gdGhlIG9mZmljaWFsIGNhbGwg Zm9yIGNvbnNlbnN1cyBmcm9tIGFsbCB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBvZiB0aGUgd29y a2luZyBncm91cC4gQXMgd2UgbWVudGlvbmVkIGJlZm9yZSwgaW4gc3VjaCBjYWxscywgc2lsZW5j ZSBpcyBjb25zZW50LiBBbHNvLCB0aGUgaW5mbGF0ZWQgcGFydGljaXBhdGlvbiBpbiB0aGUgY29u c2Vuc3VzIGNhbGwgZnJvbSAnbmV3JyBtZW1iZXJzIHRoYXQgaGF2ZSBuZXZlciBwYXJ0aWNpcGF0 ZSBpbiB0aGUgZGlzY3Vzc2lvbiBiZWZvcmUsIGNyZWF0ZXMgbm9pc2UgdGhhdCBtYWtlcyB0aGUg cmVzdWx0cyBoYXJkZXIgdG8gcmVhZC4NCg0KRnVydGhlcm1vcmUsIHdlIGhhdmUgb2JzZXJ2ZWQg dGhhdCwgZXZlbiBkdXJpbmcgdGhlIGNhbGwsIHRoZSBhbmFseXNpcyBvZiBib3RoIHNvbHV0aW9u cyBkaWQgY29udGludWUsIGFuZCBtaXNzaW5nIGVsZW1lbnRzIG9uIGJvdGggc2lkZXMgaGF2ZSBi ZWVuIHBvaW50ZWQgb3V0LiBXZSBhbHNvIG9ic2VydmVkIGEgd2lsbGluZ25lc3Mgb2YgdmFyaW91 cyBwYXJ0aWNpcGFudHMgdG8gaW1wcm92ZSB0aG9zZSBzcGVjcyB0byBicmluZyB0aGVtIHRvIGEg bGV2ZWwgd2hlcmUgd2UgY291bGQgc3RhcnQgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0K QXMgYSByZXN1bHQsIHdlIGhhdmUgZGVjaWRlZCB0byBhcHByb3ZlIGJvdGggTUFQIGFuZCA0cmQt VSBhcyB3b3JraW5nIGdyb3VwIHdvcmsgaXRlbXMuICBBcyB3b3JrIGl0ZW1zLCBlYWNoIGRvY3Vt ZW50IGNhbiBiZSBmdXJ0aGVyIHJlZmluZWQgdW50aWwgdGhlIHdvcmtpbmcgZ3JvdXAgcmVhY2hl cyBjb25zZW5zdXMgYWJvdXQgYWR2YW5jaW5nIHRoZSBkb2N1bWVudHMgZm9yIElFVEYgcmV2aWV3 Lg0KDQpCZWNhdXNlIG9mIHRoZSBoaXN0b3J5IG9mIE1BUCBhbmQgNHJkLVUsIHdlIHdpbGwgZGVz aWduYXRlIGluZGVwZW5kZW50IHRlYW1zIG9mIHZvbHVudGVlciByZXZpZXdlcnMgdG8gYWR2aXNl IHRoZSB3b3JraW5nIGdyb3VwIGFib3V0IHRoZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQgc2V0cy4g IEVhY2ggc2V0IHdpbGwgYmUgcmV2aWV3ZWQgYnkgYW4gaW5kZXBlbmRlbnQgdGVhbSB3aG8gYXJl IG5vdCBhdXRob3JzIG9mIHRoZSBNQVAgYW5kIDRyZC1VIGRvY3VtZW50cy4gRWFjaCByZXZpZXcg dGVhbSB3aWxsIGNvbnNpc3Qgb2YgdGhyZWUgbWVtYmVycyBhbmQgd2lsbCBkZXRlcm1pbmUgd2hl biBpdHMgZG9jdW1lbnQgc2V0IGlzIHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4g SWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHZvbHVudGVlcmluZyBmb3Igb25lIG9mIHRoZSByZXZp ZXcgdGVhbXMsIHBsZWFzZSByZXNwb25kIGRpcmVjdGx5IHRvIHRoZSBjaGFpcnMsIGluZGljYXRp bmcgeW91ciBwcmVmZXJlbmNlIGZvciB3aGljaCBkb2N1bWVudCB0byByZXZpZXcgaWYgeW91IGhh dmUgb25lLiBUaGUgYXBwb2ludG1lbnQgb2YgdGhlIHJldmlldyB0ZWFtcyB3aWxsIGJlIGVudGly ZWx5IHVwIHRvIHRoZSBjaGFpcnMuIEFzaWRlIGZyb20gdGhlc2UgYXBwb2ludGVkIHJldmlld3Ms IHRoZSBjaGFpcnMgd291bGQgbmF0dXJhbGx5IGFwcHJlY2lhdGUgYW55IGFuZCBhbGwgcmV2aWV3 cyBwcm92aWRlZCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSByZXZpZXdlcihzKSBwYXJ0aWNp cGF0ZSBvbiBhIHJldmlldyB0ZWFtLg0KDQpXaGVuIHRoZSBkb2N1bWVudCBzZXRzIGFyZSByZWFk eSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcmVj b25zaWRlciB0aGUgcXVlc3Rpb24gb2YgdGhlIHB1YmxpY2F0aW9uIHN0YXR1czogUHJvcG9zZWQg U3RhbmRhcmQgb3IgRXhwZXJpbWVudGFsLiBXZSB3aWxsIHRyeSB0byAgY29uc2lkZXIgYWxsIGRv Y3VtZW50IHNldHMgZm9yIGFkdmFuY2VtZW50IGF0IHRoZSBzYW1lIHRpbWUsIGJ1dCB3ZSB3aWxs IG5vdCBhbGxvdyBhIGRlbGF5IGluIGNvbXBsZXRpbmcgb25lIGRvY3VtZW50IHRvIGhvbGQgdXAg dGhlIHdvcmtpbmcgZ3JvdXAgaW5kZWZpbml0ZWx5LiANCg0KICAgLSBBbGFpbiAmIFlvbmcsIFdH IGNvLWNoYWlycw0KICAgLSBSYWxwaCAmIEJpcmFuLCBBRHMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0 d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzDQo= From christian.jacquenet@orange.com Thu Apr 26 00:50:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4A821F845F for ; Thu, 26 Apr 2012 00:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID6JPHIIBbeB for ; Thu, 26 Apr 2012 00:50:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2A21F8443 for ; Thu, 26 Apr 2012 00:50:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 754A73B4213; Thu, 26 Apr 2012 09:50:52 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4C81F2380B7; Thu, 26 Apr 2012 09:50:52 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 26 Apr 2012 09:50:52 +0200 From: To: Alain Durand , "softwires@ietf.org WG" Date: Thu, 26 Apr 2012 09:50:50 +0200 Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: Ac0jTbBMgro6fzYwRbWon7NwOa/mEgAMX06Q Message-ID: <13357_1335426652_4F98FE5C_13357_244_21_983A1D8DA0DA5F4EB747BF34CBEE5CD15A0540D94D@PUEXCB1C.nanterre.francetelecom.fr> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 07:50:55 -0000 Chairs, ADs, I regret this decision. *Whatever* the results of the poll, your text below= explicitly suggests a discrimination between voters.=20 Basically, you seem to distinguish between people who are entitled to vote = because they have supposedly participated to the stateless specification ef= fort (whatever the flavour) and people who are not entitled to vote because= you clearly assume they have not participated to the said specification ef= fort, let alone the discussions. I think this decision is a shame for the IETF precisely because of this dis= crimination. We all perfectly know how the IETF procedures have been working for many ye= ars. And we all perfectly know what kind of side effect the rough consensus= motto can sometimes lead to. But I don't think this is a good enough reason to speculate on the degree o= f participation to the WG effort of the people who have expressed an opinio= n. I, for one, never sent a comment on either the MAP or the 4rd-U stuff on th= is list. Yet, I can assure you that I have extensively discussed both appro= aches with my colleagues internally. Does that make me ineligible to respond to this poll? I certainly don't thi= nk so. I don't think anyone of us is entitled to decide who has the right to vote = and who hasn't. Your corrected math clearly reflect a strong consensus to (1) standardize o= ne and only one approach and (2) adopt the MAP effort as a softwire WG item. Your decision contradicts the results of this poll. I therefore strongly encourage you to revisit your position and accept the = results of this poll. If you stick to this decision, you will not only do any favor to the softwi= re WG, but also to the whole IETF.=20 Cheers, Christian. -----Message d'origine----- De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Alain Durand Envoy=E9 : jeudi 26 avril 2012 03:41 =C0 : softwires@ietf.org WG Objet : [Softwires] Result from the consensus call on Map vs 4rd-U and offi= cial way forward The chairs and ADs met to look at the results of the consensus call that en= ded Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from= the consensus call: - We had a number of people responding more than once, sometime with differ= ent email addresses. Having their name and affiliation in the response helped us removed those= duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about= 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in= Paris when the same question was asked have not participated in this conse= nsus call.=20 b) the number of MAP responses seem to be inflated, we see a disproportiona= te number of response from some particular organizations. We also see a lar= ge number of responses coming from people who have not participated before = in the working group. Also, it is apparent that a number of people have joi= ned the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need= participation in the official call for consensus from all the active parti= cipants of the working group. As we mentioned before, in such calls, silenc= e is consent. Also, the inflated participation in the consensus call from '= new' members that have never participate in the discussion before, creates = noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of b= oth solutions did continue, and missing elements on both sides have been po= inted out. We also observed a willingness of various participants to improv= e those specs to bring them to a level where we could start a working group= last call. As a result, we have decided to approve both MAP and 4rd-U as working group= work items. As work items, each document can be further refined until the= working group reaches consensus about advancing the documents for IETF rev= iew. Because of the history of MAP and 4rd-U, we will designate independent team= s of volunteer reviewers to advise the working group about the state of the= document sets. Each set will be reviewed by an independent team who are n= ot authors of the MAP and 4rd-U documents. Each review team will consist of= three members and will determine when its document set is ready for workin= g group last call. If you are interested in volunteering for one of the rev= iew teams, please respond directly to the chairs, indicating your preferenc= e for which document to review if you have one. The appointment of the revi= ew teams will be entirely up to the chairs. Aside from these appointed revi= ews, the chairs would naturally appreciate any and all reviews provided, re= gardless of whether the reviewer(s) participate on a review team. When the document sets are ready for working group last call, the working g= roup will reconsider the question of the publication status: Proposed Stand= ard or Experimental. We will try to consider all document sets for advance= ment at the same time, but we will not allow a delay in completing one docu= ment to hold up the working group indefinitely.=20 - Alain & Yong, WG co-chairs - Ralph & Biran, ADs _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From mohamed.boucadair@orange.com Thu Apr 26 01:36:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E0421F85EA for ; Thu, 26 Apr 2012 01:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWQBlvsHBSSo for ; Thu, 26 Apr 2012 01:36:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4506C21F8549 for ; Thu, 26 Apr 2012 01:36:04 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B69A23B44B3; Thu, 26 Apr 2012 10:36:02 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9D1A727C077; Thu, 26 Apr 2012 10:36:02 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 26 Apr 2012 10:36:02 +0200 From: To: Alain Durand , "softwires@ietf.org WG" Date: Thu, 26 Apr 2012 10:36:01 +0200 Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: Ac0jTbBMgro6fzYwRbWon7NwOa/mEgANoS8g Message-ID: <94C682931C08B048B7A8645303FDC9F36E295A8702@PUEXCB1B.nanterre.francetelecom.fr> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:36:05 -0000 Dear all, I personally regret this decision and reject the justifications provided. I= f you don't want people to contribute and express their opinion, it is easy= : make it a close community. If you insist to ignore what expressed the majority of individuals who part= icipated to the poll, may I suggest: we stop all this stateless A+P work. I= t does not make sense at all to continue work on two parallel efforts havin= g 90% of similarities. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Alain Durand >Envoy=E9 : jeudi 26 avril 2012 03:41 >=C0 : softwires@ietf.org WG >Objet : [Softwires] Result from the consensus call on Map vs=20 >4rd-U and official way forward > >The chairs and ADs met to look at the results of the consensus=20 >call that ended Wednesday and decide the way forward. > >First, we would like to offer a couple observations on the raw=20 >results from the consensus call: > >- We had a number of people responding more than once,=20 >sometime with different email addresses. > Having their name and affiliation in the response helped us=20 >removed those duplicate/triplicate/... >- Number of unique response: 75 >- Question 1: 75 yes, 0 No, few responded put both on=20 >experimental track >- Question 2: 73 MAP 2 4rd-U > >This does not reflect at all the results we had in the Paris=20 >meeting (about 30 MAP and 20 4rd-U): >a) It seems that some of the 4rd-U people who did express=20 >support for it in Paris when the same question was asked have=20 >not participated in this consensus call.=20 >b) the number of MAP responses seem to be inflated, we see a=20 >disproportionate number of response from some particular=20 >organizations. We also see a large number of responses coming=20 >from people who have not participated before in the working=20 >group. Also, it is apparent that a number of people have=20 >joined the mailing list for the sole purpose of expressing=20 >support for MAP. > >None of the above behaviors do any favors for the working=20 >group. We do need participation in the official call for=20 >consensus from all the active participants of the working=20 >group. As we mentioned before, in such calls, silence is=20 >consent. Also, the inflated participation in the consensus=20 >call from 'new' members that have never participate in the=20 >discussion before, creates noise that makes the results harder to read. > >Furthermore, we have observed that, even during the call, the=20 >analysis of both solutions did continue, and missing elements=20 >on both sides have been pointed out. We also observed a=20 >willingness of various participants to improve those specs to=20 >bring them to a level where we could start a working group last call. > >As a result, we have decided to approve both MAP and 4rd-U as=20 >working group work items. As work items, each document can be=20 >further refined until the working group reaches consensus=20 >about advancing the documents for IETF review. > >Because of the history of MAP and 4rd-U, we will designate=20 >independent teams of volunteer reviewers to advise the working=20 >group about the state of the document sets. Each set will be=20 >reviewed by an independent team who are not authors of the MAP=20 >and 4rd-U documents. Each review team will consist of three=20 >members and will determine when its document set is ready for=20 >working group last call. If you are interested in volunteering=20 >for one of the review teams, please respond directly to the=20 >chairs, indicating your preference for which document to=20 >review if you have one. The appointment of the review teams=20 >will be entirely up to the chairs. Aside from these appointed=20 >reviews, the chairs would naturally appreciate any and all=20 >reviews provided, regardless of whether the reviewer(s)=20 >participate on a review team. > >When the document sets are ready for working group last call,=20 >the working group will reconsider the question of the=20 >publication status: Proposed Standard or Experimental. We will=20 >try to consider all document sets for advancement at the same=20 >time, but we will not allow a delay in completing one document=20 >to hold up the working group indefinitely.=20 > > - Alain & Yong, WG co-chairs > - Ralph & Biran, ADs >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From mark@townsley.net Thu Apr 26 02:50:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ECD21F8627 for ; Thu, 26 Apr 2012 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgfpe9HmwT2c for ; Thu, 26 Apr 2012 02:50:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAFBF21F85F9 for ; Thu, 26 Apr 2012 02:50:26 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so672544wgb.13 for ; Thu, 26 Apr 2012 02:50:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=44negKnUF5Ki7LJx187ixujKmbUOfhSOBYaiv+0Zi3c=; b=KgikpDhKMC7XIxxDajnfGcpgCEkkoSt6FwWmDRPsYG0JpQWj/jsuGsJ5IVcGGwekNh rEmN6dpJh9K611JakN6bRh88QGX6HudBjqJqmSX8v23n9yBaJxqqNGwqRC1pmw7KF3Ci hX8tBmYfISyp9HJBhiYuWctMeRqKwiypgIzP/4cjf6qRVk6bYy8jlz6EpGLtYcI82E7s jkyorX5elZtih/72CDUS0NHD3jhS16GpBKTdFfw6man1n9HHwJzjj/wKeaxn5KuofXYx R6IAlAh8JSIbdutPxAOTJ5Z1vBmXaws6Qdt9wlEcfsPdggcX6T047qaVv0lTLQ4GOinS /Cng== Received: by 10.180.78.164 with SMTP id c4mr48808811wix.10.1335433823915; Thu, 26 Apr 2012 02:50:23 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ev10sm43719772wid.10.2012.04.26.02.50.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 02:50:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Date: Thu, 26 Apr 2012 11:50:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkOlenVfC37QSREdKS9WkBZ+OFj/JHvUnojipzZXsFZIQHCIVXQEKyqOCVeE4w87jWgdhmY Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:50:27 -0000 > Because of the history of MAP and 4rd-U, we will designate independent = teams of volunteer reviewers to advise the working group about the state = of the document sets. Each set will be reviewed by an independent team = who are not authors of the MAP and 4rd-U documents. Each review team = will consist of three members and will determine when its document set = is ready for working group last call. If you are interested in = volunteering for one of the review teams, please respond directly to the = chairs, indicating your preference for which document to review if you = have one. The appointment of the review teams will be entirely up to the = chairs. Aside from these appointed reviews, the chairs would naturally = appreciate any and all reviews provided, regardless of whether the = reviewer(s) participate on a review team. Seems like a pending procedural quagmire.=20 Perhaps we would have been better off with the coin toss.=20 - Mark= From ecordeiro@nic.br Thu Apr 26 05:09:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8C21F8773 for ; Thu, 26 Apr 2012 05:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrXVlHVtSfRS for ; Thu, 26 Apr 2012 05:09:36 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD4721F8772 for ; Thu, 26 Apr 2012 05:09:36 -0700 (PDT) Received: from [IPv6:2001:12ff:0:5::107] (unknown [IPv6:2001:12ff:0:5::107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 240C120801C2 for ; Thu, 26 Apr 2012 09:09:31 -0300 (BRT) Message-ID: <4F993AFB.20205@nic.br> Date: Thu, 26 Apr 2012 09:09:31 -0300 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> In-Reply-To: <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:09:37 -0000 I'm new to the group, but I made my vote because I have studied both solutions. I was unable to find any running code for 4rd-U that I could test and verify, while I was able to do that with MAP. I voted based on the quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". As I was unable to find 4rd-U running code I voted against 4rd-U. I believe that the author of 4rd-U should explore his idea and have running code to prove it works. When the 4rd-U comes to this stage come back to the group. This is similar to what happened with 6rd. If this code already exist, please make it public so it could be verified. Edwin Cordeiro Em 26-04-2012 06:50, Mark Townsley escreveu: >> Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. > > Seems like a pending procedural quagmire. > > Perhaps we would have been better off with the coin toss. > > - Mark > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jan@go6.si Thu Apr 26 07:51:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CC721F8581 for ; Thu, 26 Apr 2012 07:51:00 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeZD-i5uMYoX for ; Thu, 26 Apr 2012 07:50:58 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1621F853B for ; Thu, 26 Apr 2012 07:50:57 -0700 (PDT) Received: from jan-mac.local (unknown [80.187.201.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id D8F5222B4069 for ; Thu, 26 Apr 2012 16:50:52 +0200 (CEST) Message-ID: <4F9960D2.8060208@go6.si> Date: Thu, 26 Apr 2012 16:50:58 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> In-Reply-To: <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:51:00 -0000 On 4/26/12 11:50 AM, Mark Townsley wrote: > Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? From sarikaya2012@gmail.com Thu Apr 26 08:40:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41B121E80DC for ; Thu, 26 Apr 2012 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wilNxCqAFGvs for ; Thu, 26 Apr 2012 08:40:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 268E721E8089 for ; Thu, 26 Apr 2012 08:40:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1178399ghb.31 for ; Thu, 26 Apr 2012 08:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UYPy8FJ9sErtVbSeEqxBY4k2O9sV8bf6Xv3PntIg5l8=; b=b1fpFeyWkNYP0MfB6B5h+Uj8djK45T5l0clw6ur3GV9/d1Y8glMTNS1y3OcXJD0BBX OtoamuID1BWK/Rqd1mTcD2BAIJjzSHX3DO6+Ct3SwGmVq4HW9p2mZ/I9tcsFBcc8ciqM PLoAW0hI5vGYvwtVWb7adMyWheu4ILiLt8xtIZ5rnP7sqteL6jN/bkLVor2QV3wkXdFc cicbOA0AjmvrC0wGpee2Y25k16ZDlCb0duUIoTX9DSs0njIGBnP/lDe0o2ecnKg27n1T +U45mFP1Sjb+j1jdE/8vklRYtb/ov/UgwMJdRJ0UgPF6rh85Em++K9CK+KlcmVgwvY9y TqKw== MIME-Version: 1.0 Received: by 10.50.189.129 with SMTP id gi1mr7452671igc.16.1335454815293; Thu, 26 Apr 2012 08:40:15 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Thu, 26 Apr 2012 08:40:15 -0700 (PDT) In-Reply-To: <4F9960D2.8060208@go6.si> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <5F89C77D-E910-4602-9DC8-29F5ABC18FFB@townsley.net> <4F9960D2.8060208@go6.si> Date: Thu, 26 Apr 2012 10:40:15 -0500 Message-ID: From: Behcet Sarikaya To: "Jan Zorz @ go6.si" Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:40:16 -0000 Hi Jan, > > P.P.S: Should we deprecate RFC6346? A+P is in MAP T, MAP E and 4rd-U. I don't understand why you are worried about it? Having said that I for one think that A+P should be restricted to the CPEs. Otherwise you are creating another NAT. Regards, Behcet From moreiras@nic.br Thu Apr 26 11:14:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE51221E8049 for ; Thu, 26 Apr 2012 11:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC1TCWi6PjNl for ; Thu, 26 Apr 2012 11:14:55 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D961C21E8089 for ; Thu, 26 Apr 2012 11:14:54 -0700 (PDT) Received: from [IPv6:2001:12ff:0:5::96] (unknown [IPv6:2001:12ff:0:5::96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id DE1F520801BF for ; Thu, 26 Apr 2012 15:14:49 -0300 (BRT) Message-ID: <4F999098.3040402@nic.br> Date: Thu, 26 Apr 2012 15:14:48 -0300 From: "Antonio M. Moreiras" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: softwires@ietf.org References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> X-Enigmail-Version: 1.4.1 OpenPGP: id=18627EC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:14:57 -0000 On 25-04-2012 22:41, Alain Durand wrote: > b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. > > None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. I regret so much this decision. I, personaly, and also my team, have been following the work of this IETF WG, and others regarding IPv6, for quite a long time. We are involved with IPv6 dissemination. We do not participate actively here, because we choose to prioritize other tasks. Sadly, the time and other resources are always limited, and we can't contribute in all ways we would like to. I did choose to sign the list with this email address recently solely in order to vote in this matter, because it is important and urgent, and I wanted to express my support to MAP (but, more important than that, to express my support on advancing only one of the options, MAP or 4rd-U), and help the group to make the decision in a timely way. If I had the slightest idea that this kind of behavior could prejudice the vote and decision in any way, as it seems to have done, I wouldn't have voted. I honestly thought the IETF was more open, and that newcomers were more welcome. I am really, really sorry because I didn't know that it was not expected that newcomers in a WG expressed their opnions, and that it would be considered "noise", "inflating" the numbers. Maybe it could be a bit more clear, when the vote was called, that newcomers were not expected to express their opinions, and that only those already discussing the question in the list for some time should participate. I am not criticizing the process in anyway, just stating that I could not understand it correctly before now. Said that, I must add that I've not voted lightly. It was a choose based on a careful reading and analysis of the proposals, of a technical point of view, and on a good understanding of the current state of the IPv6 implementation, and current planning, in the local Internet market of the country I live on, including local ISPs and local equipment manufacturers. I apologize for trying to contribute, helping the group to make what I considered a very needed choose, based on my limited experience, and ending up being just a noise generator, inflating the numbers. I am feeling really bad about that. Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a decision that lead us to more indefinition regarding a usable stateless transition technique based on A+P is very, very, disappointing. It seems to me that with this new way forward we will loose the timing. We will end up with an optimal and very elegant solution that will not be used by anyone. Sadly, it seems to be better to forget the whole idea, and put our efforts elsewhere. Antonio M. Moreiras. From jmh@joelhalpern.com Thu Apr 26 12:42:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191C621E8190 for ; Thu, 26 Apr 2012 12:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-oT-TkoO3ES for ; Thu, 26 Apr 2012 12:42:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9A721E8185 for ; Thu, 26 Apr 2012 12:42:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 03D93558175 for ; Thu, 26 Apr 2012 12:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C15D21BC7B4B; Thu, 26 Apr 2012 12:42:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C27251BC7B45; Thu, 26 Apr 2012 12:42:11 -0700 (PDT) Message-ID: <4F99A520.5070102@joelhalpern.com> Date: Thu, 26 Apr 2012 15:42:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Antonio M. Moreiras" References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <4F999098.3040402@nic.br> In-Reply-To: <4F999098.3040402@nic.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:42:14 -0000 If I may, it seems to me that several of these replies miss some important points in the message from the chairs. 1) It became clear during the WG poll that the documents were not complete. This is not a bad thing. We need to finish them. 2) The poll did indicate that there is interest in the documents. 3) Given that the documents are not complete, they can not be sent to the IESG at this time. Until they are complete, a final decision on what status they will be labelled with can not be made. Hence, what can be done is either to adopt the documents as WG documents, or not. Even if the chairs were to state an intended status for the documents upon completion, that would have to be verified when the final content was available. The most important thing actually is the call for reviewers. If you want to see any of the documents adopted by the working group, and worked on, we need folks to step forward as reviewers. Folks who are not the authors. Yours, Joel M. Halpern An observer without a preference on outcomes. PS: I think there is also some confusion about IETF processes. However, I will not belabor the list with a rant on that. I will happily answer off-list questions if it i helpful to individuals. On 4/26/2012 2:14 PM, Antonio M. Moreiras wrote: > On 25-04-2012 22:41, Alain Durand wrote: >> b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. >> >> None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. > > I regret so much this decision. > > I, personaly, and also my team, have been following the work of this > IETF WG, and others regarding IPv6, for quite a long time. We are > involved with IPv6 dissemination. We do not participate actively here, > because we choose to prioritize other tasks. Sadly, the time and other > resources are always limited, and we can't contribute in all ways we > would like to. > > I did choose to sign the list with this email address recently solely in > order to vote in this matter, because it is important and urgent, and I > wanted to express my support to MAP (but, more important than that, to > express my support on advancing only one of the options, MAP or 4rd-U), > and help the group to make the decision in a timely way. If I had the > slightest idea that this kind of behavior could prejudice the vote and > decision in any way, as it seems to have done, I wouldn't have voted. I > honestly thought the IETF was more open, and that newcomers were more > welcome. I am really, really sorry because I didn't know that it was not > expected that newcomers in a WG expressed their opnions, and that it > would be considered "noise", "inflating" the numbers. > > Maybe it could be a bit more clear, when the vote was called, that > newcomers were not expected to express their opinions, and that only > those already discussing the question in the list for some time should > participate. I am not criticizing the process in anyway, just stating > that I could not understand it correctly before now. > > Said that, I must add that I've not voted lightly. It was a choose based > on a careful reading and analysis of the proposals, of a technical point > of view, and on a good understanding of the current state of the IPv6 > implementation, and current planning, in the local Internet market of > the country I live on, including local ISPs and local equipment > manufacturers. > > I apologize for trying to contribute, helping the group to make what I > considered a very needed choose, based on my limited experience, and > ending up being just a noise generator, inflating the numbers. I am > feeling really bad about that. > > Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a > decision that lead us to more indefinition regarding a usable stateless > transition technique based on A+P is very, very, disappointing. > > It seems to me that with this new way forward we will loose the timing. > We will end up with an optimal and very elegant solution that will not > be used by anyone. Sadly, it seems to be better to forget the whole > idea, and put our efforts elsewhere. > > Antonio M. Moreiras. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From fibrib@gmail.com Thu Apr 26 15:37:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38421E8041 for ; Thu, 26 Apr 2012 15:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emPbB8xPT+H9 for ; Thu, 26 Apr 2012 15:37:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0136A11E808D for ; Thu, 26 Apr 2012 15:37:46 -0700 (PDT) Received: by qadz3 with SMTP id z3so16991qad.10 for ; Thu, 26 Apr 2012 15:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k+PRljQ6PRxkR0mCmCpJZQ1CkBJ8hjTp7MafA3Zg36E=; b=bEt91aDlxrM70xrH9OJ+XVtT73KHyuDmAlAXQ8Ozl8LOGRW7cbCR8QOYwNDqYfVF2z eAur/z5ErH7RVHuj9EKXHkHrqrMWz0z52rfnI0QDLqwDdGEUqBGXhi9AUV5bZW6YMjZr 7eakrDTlSs5HBKZjpo1NfdRuDyoTmTfv0P8JvtZ1z7Jjt+4Cvv4PdB7eUY0aT0Lrt4Nj Skpuar3zGVd02ipOo+ssdNYFCeR6ApIhtAwyH6bMRI1xnpsrtOdBTnWBHbvPyIdYrchK xjWkYpysCMRFXFZb4mBgz/xCuoQ/i95tMLOvN9VWEbbbUSayTTY8He8qEf5BqamtQg6n sHBQ== MIME-Version: 1.0 Received: by 10.229.136.3 with SMTP id p3mr2086765qct.8.1335479866481; Thu, 26 Apr 2012 15:37:46 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 26 Apr 2012 15:37:46 -0700 (PDT) In-Reply-To: <4F99A520.5070102@joelhalpern.com> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <4F999098.3040402@nic.br> <4F99A520.5070102@joelhalpern.com> Date: Fri, 27 Apr 2012 07:37:46 +0900 Message-ID: From: Maoke To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=00248c70fe790bdcd904be9ca3eb Cc: softwires@ietf.org Subject: Re: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 22:37:48 -0000 --00248c70fe790bdcd904be9ca3eb Content-Type: text/plain; charset=ISO-8859-1 the problems here are: 1. a lot of people were hurt by the chairs, IMHO, disparaging language. wording like "inflate" "generate noise" is unfair and impolite. 2. it has been well known that documents were not complete. it was not needed to make a poll to indicate it. they are not complete != they are not mature at *same* level. 3. "call for reviewer", just like the previously "call for poll", sounds to me another political trick of the chair. logically, "independent" vs. "we will designate" are contradictory. if the majority poll failed to indicate consensus, how the minority reviews can? - maoke 2012/4/27 Joel M. Halpern > If I may, it seems to me that several of these replies miss some important > points in the message from the chairs. > > 1) It became clear during the WG poll that the documents were not > complete. This is not a bad thing. We need to finish them. > 2) The poll did indicate that there is interest in the documents. > 3) Given that the documents are not complete, they can not be sent to the > IESG at this time. Until they are complete, a final decision on what > status they will be labelled with can not be made. > > Hence, what can be done is either to adopt the documents as WG documents, > or not. Even if the chairs were to state an intended status for the > documents upon completion, that would have to be verified when the final > content was available. > > The most important thing actually is the call for reviewers. If you want > to see any of the documents adopted by the working group, and worked on, we > need folks to step forward as reviewers. Folks who are not the authors. > > Yours, > Joel M. Halpern > An observer without a preference on outcomes. > > PS: I think there is also some confusion about IETF processes. However, I > will not belabor the list with a rant on that. I will happily answer > off-list questions if it i helpful to individuals. > > > On 4/26/2012 2:14 PM, Antonio M. Moreiras wrote: > >> On 25-04-2012 22:41, Alain Durand wrote: >> >>> b) the number of MAP responses seem to be inflated, we see a >>> disproportionate number of response from some particular organizations. We >>> also see a large number of responses coming from people who have not >>> participated before in the working group. Also, it is apparent that a >>> number of people have joined the mailing list for the sole purpose of >>> expressing support for MAP. >>> >>> None of the above behaviors do any favors for the working group. We do >>> need participation in the official call for consensus from all the active >>> participants of the working group. As we mentioned before, in such calls, >>> silence is consent. Also, the inflated participation in the consensus call >>> from 'new' members that have never participate in the discussion before, >>> creates noise that makes the results harder to read. >>> >> >> I regret so much this decision. >> >> I, personaly, and also my team, have been following the work of this >> IETF WG, and others regarding IPv6, for quite a long time. We are >> involved with IPv6 dissemination. We do not participate actively here, >> because we choose to prioritize other tasks. Sadly, the time and other >> resources are always limited, and we can't contribute in all ways we >> would like to. >> >> I did choose to sign the list with this email address recently solely in >> order to vote in this matter, because it is important and urgent, and I >> wanted to express my support to MAP (but, more important than that, to >> express my support on advancing only one of the options, MAP or 4rd-U), >> and help the group to make the decision in a timely way. If I had the >> slightest idea that this kind of behavior could prejudice the vote and >> decision in any way, as it seems to have done, I wouldn't have voted. I >> honestly thought the IETF was more open, and that newcomers were more >> welcome. I am really, really sorry because I didn't know that it was not >> expected that newcomers in a WG expressed their opnions, and that it >> would be considered "noise", "inflating" the numbers. >> >> Maybe it could be a bit more clear, when the vote was called, that >> newcomers were not expected to express their opinions, and that only >> those already discussing the question in the list for some time should >> participate. I am not criticizing the process in anyway, just stating >> that I could not understand it correctly before now. >> >> Said that, I must add that I've not voted lightly. It was a choose based >> on a careful reading and analysis of the proposals, of a technical point >> of view, and on a good understanding of the current state of the IPv6 >> implementation, and current planning, in the local Internet market of >> the country I live on, including local ISPs and local equipment >> manufacturers. >> >> I apologize for trying to contribute, helping the group to make what I >> considered a very needed choose, based on my limited experience, and >> ending up being just a noise generator, inflating the numbers. I am >> feeling really bad about that. >> >> Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a >> decision that lead us to more indefinition regarding a usable stateless >> transition technique based on A+P is very, very, disappointing. >> >> It seems to me that with this new way forward we will loose the timing. >> We will end up with an optimal and very elegant solution that will not >> be used by anyone. Sadly, it seems to be better to forget the whole >> idea, and put our efforts elsewhere. >> >> Antonio M. Moreiras. >> ______________________________**_________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/**listinfo/softwires >> >> ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --00248c70fe790bdcd904be9ca3eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
the problems= here are:
=A0
1. a lot of people were hurt by the chairs, IMHO, disparaging language.= =A0wording like "inflate" "generate noise"=A0is unfair = and impolite.
2. it=A0has been=A0well known that documents wer= e not complete. it=A0was not needed to make a poll to indicate it. they are= not complete !=3D they are not mature=A0at *same* level.
3. "call for reviewer", just like the previously "call for p= oll",=A0sounds to me another political trick of the chair. logically, = "independent" vs. "we will designate" are contradictory= . if the majority poll failed to indicate consensus, how the minority revie= ws can?
=A0
- maoke
=
2012/4/27 Joel M. Halpern <jmh@joelhalp= ern.com>
If I may, it seems to me that several of these replies mis= s some important points in the message from the chairs.

1) It became clear during the WG poll that the documents were not complete.= =A0This is not a bad thing. =A0We need to finish them.
2) The poll did indicate that there is interest in the documents.
3) Given that the documents are not complete, they can not be sent to the I= ESG at this time. =A0Until they are complete, a final decision on what stat= us they will be labelled with can not be made.

Hence, what can be done is either to adopt the documents as WG documents, o= r not. =A0Even if the chairs were to state an intended status for the docum= ents upon completion, that would have to be verified when the final content= was available.

The most important thing actually is the call for reviewers. =A0If you want= to see any of the documents adopted by the working group, and worked on, w= e need folks to step forward as reviewers. =A0Folks who are not the authors= .

Yours,
Joel M. Halpern
An observer without a preference on outcomes.

PS: I think there is also some confusion about IETF processes. =A0However, = I will not belabor the list with a rant on that. =A0I will happily answer o= ff-list questions if it i helpful to individuals.


On 4/26/2012 2:14 PM, Antonio M. Moreiras wrote:
On 25-04-2012 22:41, Alain Durand wrote:
b) the number of MAP responses seem to be inflated, we see a disproportiona= te number of response from some particular organizations. We also see a lar= ge number of responses coming from people who have not participated before = in the working group. Also, it is apparent that a number of people have joi= ned the mailing list for the sole purpose of expressing support for MAP.
None of the above behaviors do any favors for the working group. We do need= participation in the official call for consensus from all the active parti= cipants of the working group. As we mentioned before, in such calls, silenc= e is consent. Also, the inflated participation in the consensus call from &= #39;new' members that have never participate in the discussion before, = creates noise that makes the results harder to read.

I regret so much this decision.

I, personaly, and also my team, have been following the work of this
IETF WG, and others regarding IPv6, for quite a long time. We are
involved with IPv6 dissemination. We do not participate actively here,
because we choose to prioritize other tasks. Sadly, the time and other
resources are always limited, and we can't contribute in all ways we would like to.

I did choose to sign the list with this email address recently solely in order to vote in this matter, because it is important and urgent, and I
wanted to express my support to MAP (but, more important than that, to
express my support on advancing only one of the options, MAP or 4rd-U),
and help the group to make the decision in a timely way. If I had the
slightest idea that this kind of behavior could prejudice the vote and
decision in any way, as it seems to have done, I wouldn't have voted. I=
honestly thought the IETF was more open, and that newcomers were more
welcome. I am really, really sorry because I didn't know that it was no= t
expected that newcomers in a WG expressed their opnions, and that it
would be considered "noise", "inflating" the numbers.
Maybe it could be a bit more clear, when the vote was called, that
newcomers were not expected to express their opinions, and that only
those already discussing the question in the list for some time should
participate. I am not criticizing the process in anyway, just stating
that I could not understand it correctly before now.

Said that, I must add that I've not voted lightly. It was a choose base= d
on a careful reading and analysis of the proposals, of a technical point of view, and on a good understanding of the current state of the IPv6
implementation, and current planning, in the local Internet market of
the country I live on, including local ISPs and local equipment
manufacturers.

I apologize for trying to contribute, helping the group to make what I
considered a very needed choose, based on my limited experience, and
ending up being just a noise generator, inflating the numbers. =A0I am
feeling really bad about that.

Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a decision that lead us to more indefinition regarding a usable stateless
transition technique based on A+P is very, very, disappointing.

It seems to me that with this new way forward we will loose the timing.
We will end up with an optimal and very elegant solution that will not
be used by anyone. Sadly, it seems to be better to forget the whole
idea, and put our efforts elsewhere.

Antonio M. Moreiras.
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--00248c70fe790bdcd904be9ca3eb-- From wdec.ietf@gmail.com Thu Apr 26 23:36:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8571E21F86CA for ; Thu, 26 Apr 2012 23:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmu3L0o5lMBT for ; Thu, 26 Apr 2012 23:36:50 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 285CE21F86C7 for ; Thu, 26 Apr 2012 23:36:50 -0700 (PDT) Received: by qaea16 with SMTP id a16so40669qae.10 for ; Thu, 26 Apr 2012 23:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P5mZvdith99fvUnE+BsXnE9W+XgV7x8G/fS6cnnCWSU=; b=cg+l8DOdvmiDyyHw000RGVGpp0YWztob8Bqy21w55Qs26PveVZgaU2JK/THxQc16As WW5DXL7JubomLvsUWA/VZKEqM7YwI62+GCZOVWJTiuK5IU/U9jyS2B4t72/uOAmMCD+v LpGE+ZncnpedXoHqrCAobHzR7Dp5IC00L118njh0ZSf5Lx5ln0uAhv6L0PVxc3FoPzrF PutBZpERA1e5H5uXRPMf9nt/XMSa5EOJ9lKRAXhhX0FZlTE+7pPrWOfryek6UyZ0qYuP x0cRq3ZjBEuATXmM5qCMDxCbjlwCL2IKWYRGZVaJcFr/iXD283+oNKvw5R+QTwhbtE2U c4Yg== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr2331724qct.123.1335508609512; Thu, 26 Apr 2012 23:36:49 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Thu, 26 Apr 2012 23:36:49 -0700 (PDT) In-Reply-To: <4F99A520.5070102@joelhalpern.com> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <4F999098.3040402@nic.br> <4F99A520.5070102@joelhalpern.com> Date: Fri, 27 Apr 2012 08:36:49 +0200 Message-ID: From: Wojciech Dec To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=00235453035043b43d04bea3544c Cc: softwires@ietf.org Subject: Re: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 06:36:51 -0000 --00235453035043b43d04bea3544c Content-Type: text/plain; charset=ISO-8859-1 Joel, allow me to ask you as an observer some questions: 1. If this WG is not for the WG members, of all cuts & sizes, to work in then what is it for? 2. If the chairs of this WG are unable to steer, form and then actually measure consensus, and in due course also end up "disenfranchising" WG members, then isn't this a point that needs to be addressed (sadly a recurring theme in this particular WG)? 3. Is a regular way forward is to adopt every draft with "some interest", even if nearly entirely overlapping in scope with other draft also adopted, and is there a precedent? Thanks, Woj. On 26 April 2012 21:42, Joel M. Halpern wrote: > If I may, it seems to me that several of these replies miss some important > points in the message from the chairs. > > 1) It became clear during the WG poll that the documents were not > complete. This is not a bad thing. We need to finish them. > 2) The poll did indicate that there is interest in the documents. > 3) Given that the documents are not complete, they can not be sent to the > IESG at this time. Until they are complete, a final decision on what > status they will be labelled with can not be made. > > Hence, what can be done is either to adopt the documents as WG documents, > or not. Even if the chairs were to state an intended status for the > documents upon completion, that would have to be verified when the final > content was available. > > The most important thing actually is the call for reviewers. If you want > to see any of the documents adopted by the working group, and worked on, we > need folks to step forward as reviewers. Folks who are not the authors. > > Yours, > Joel M. Halpern > An observer without a preference on outcomes. > > PS: I think there is also some confusion about IETF processes. However, I > will not belabor the list with a rant on that. I will happily answer > off-list questions if it i helpful to individuals. > > > On 4/26/2012 2:14 PM, Antonio M. Moreiras wrote: > >> On 25-04-2012 22:41, Alain Durand wrote: >> >>> b) the number of MAP responses seem to be inflated, we see a >>> disproportionate number of response from some particular organizations. We >>> also see a large number of responses coming from people who have not >>> participated before in the working group. Also, it is apparent that a >>> number of people have joined the mailing list for the sole purpose of >>> expressing support for MAP. >>> >>> None of the above behaviors do any favors for the working group. We do >>> need participation in the official call for consensus from all the active >>> participants of the working group. As we mentioned before, in such calls, >>> silence is consent. Also, the inflated participation in the consensus call >>> from 'new' members that have never participate in the discussion before, >>> creates noise that makes the results harder to read. >>> >> >> I regret so much this decision. >> >> I, personaly, and also my team, have been following the work of this >> IETF WG, and others regarding IPv6, for quite a long time. We are >> involved with IPv6 dissemination. We do not participate actively here, >> because we choose to prioritize other tasks. Sadly, the time and other >> resources are always limited, and we can't contribute in all ways we >> would like to. >> >> I did choose to sign the list with this email address recently solely in >> order to vote in this matter, because it is important and urgent, and I >> wanted to express my support to MAP (but, more important than that, to >> express my support on advancing only one of the options, MAP or 4rd-U), >> and help the group to make the decision in a timely way. If I had the >> slightest idea that this kind of behavior could prejudice the vote and >> decision in any way, as it seems to have done, I wouldn't have voted. I >> honestly thought the IETF was more open, and that newcomers were more >> welcome. I am really, really sorry because I didn't know that it was not >> expected that newcomers in a WG expressed their opnions, and that it >> would be considered "noise", "inflating" the numbers. >> >> Maybe it could be a bit more clear, when the vote was called, that >> newcomers were not expected to express their opinions, and that only >> those already discussing the question in the list for some time should >> participate. I am not criticizing the process in anyway, just stating >> that I could not understand it correctly before now. >> >> Said that, I must add that I've not voted lightly. It was a choose based >> on a careful reading and analysis of the proposals, of a technical point >> of view, and on a good understanding of the current state of the IPv6 >> implementation, and current planning, in the local Internet market of >> the country I live on, including local ISPs and local equipment >> manufacturers. >> >> I apologize for trying to contribute, helping the group to make what I >> considered a very needed choose, based on my limited experience, and >> ending up being just a noise generator, inflating the numbers. I am >> feeling really bad about that. >> >> Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a >> decision that lead us to more indefinition regarding a usable stateless >> transition technique based on A+P is very, very, disappointing. >> >> It seems to me that with this new way forward we will loose the timing. >> We will end up with an optimal and very elegant solution that will not >> be used by anyone. Sadly, it seems to be better to forget the whole >> idea, and put our efforts elsewhere. >> >> Antonio M. Moreiras. >> ______________________________**_________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/**listinfo/softwires >> >> ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --00235453035043b43d04bea3544c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

allow me to ask you as an observer= some questions:

1. If this WG is not for the WG me= mbers, of all cuts & sizes, to work in then what is it for?
2. If t= he chairs of this WG are unable to steer, form and then actually measure co= nsensus, and in due course also end up "disenfranchising" WG memb= ers, then isn't this a point that needs to be addressed (sadly a recurr= ing theme in this particular WG)?
3. Is a regular way forward is to adopt every draft with "some interes= t", even if nearly entirely overlapping in scope with other draft also= adopted, and is there a precedent?

Thanks,
Woj.


On 26 April 2012 21:42, Joel M. Halpern <jmh@joelhalpern.com> wrote:
If I may, it seems to me that several of these replies miss some important = points in the message from the chairs.

1) It became clear during the WG poll that the documents were not complete.= =A0This is not a bad thing. =A0We need to finish them.
2) The poll did indicate that there is interest in the documents.
3) Given that the documents are not complete, they can not be sent to the I= ESG at this time. =A0Until they are complete, a final decision on what stat= us they will be labelled with can not be made.

Hence, what can be done is either to adopt the documents as WG documents, o= r not. =A0Even if the chairs were to state an intended status for the docum= ents upon completion, that would have to be verified when the final content= was available.

The most important thing actually is the call for reviewers. =A0If you want= to see any of the documents adopted by the working group, and worked on, w= e need folks to step forward as reviewers. =A0Folks who are not the authors= .

Yours,
Joel M. Halpern
An observer without a preference on outcomes.

PS: I think there is also some confusion about IETF processes. =A0However, = I will not belabor the list with a rant on that. =A0I will happily answer o= ff-list questions if it i helpful to individuals.


On 4/26/2012 2:14 PM, Antonio M. Moreiras wrote:
On 25-04-2012 22:41, Alain Durand wrote:
b) the number of MAP responses seem to be inflated, we see a disproportiona= te number of response from some particular organizations. We also see a lar= ge number of responses coming from people who have not participated before = in the working group. Also, it is apparent that a number of people have joi= ned the mailing list for the sole purpose of expressing support for MAP.
None of the above behaviors do any favors for the working group. We do need= participation in the official call for consensus from all the active parti= cipants of the working group. As we mentioned before, in such calls, silenc= e is consent. Also, the inflated participation in the consensus call from &= #39;new' members that have never participate in the discussion before, = creates noise that makes the results harder to read.

I regret so much this decision.

I, personaly, and also my team, have been following the work of this
IETF WG, and others regarding IPv6, for quite a long time. We are
involved with IPv6 dissemination. We do not participate actively here,
because we choose to prioritize other tasks. Sadly, the time and other
resources are always limited, and we can't contribute in all ways we would like to.

I did choose to sign the list with this email address recently solely in order to vote in this matter, because it is important and urgent, and I
wanted to express my support to MAP (but, more important than that, to
express my support on advancing only one of the options, MAP or 4rd-U),
and help the group to make the decision in a timely way. If I had the
slightest idea that this kind of behavior could prejudice the vote and
decision in any way, as it seems to have done, I wouldn't have voted. I=
honestly thought the IETF was more open, and that newcomers were more
welcome. I am really, really sorry because I didn't know that it was no= t
expected that newcomers in a WG expressed their opnions, and that it
would be considered "noise", "inflating" the numbers.
Maybe it could be a bit more clear, when the vote was called, that
newcomers were not expected to express their opinions, and that only
those already discussing the question in the list for some time should
participate. I am not criticizing the process in anyway, just stating
that I could not understand it correctly before now.

Said that, I must add that I've not voted lightly. It was a choose base= d
on a careful reading and analysis of the proposals, of a technical point of view, and on a good understanding of the current state of the IPv6
implementation, and current planning, in the local Internet market of
the country I live on, including local ISPs and local equipment
manufacturers.

I apologize for trying to contribute, helping the group to make what I
considered a very needed choose, based on my limited experience, and
ending up being just a noise generator, inflating the numbers. =A0I am
feeling really bad about that.

Anyway, seeing the 75 x 0 votes to the 1st question being ignored, and a decision that lead us to more indefinition regarding a usable stateless
transition technique based on A+P is very, very, disappointing.

It seems to me that with this new way forward we will loose the timing.
We will end up with an optimal and very elegant solution that will not
be used by anyone. Sadly, it seems to be better to forget the whole
idea, and put our efforts elsewhere.

Antonio M. Moreiras.
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--00235453035043b43d04bea3544c-- From leaf.y.yeh@huawei.com Thu Apr 26 23:37:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3694321F86FA for ; Thu, 26 Apr 2012 23:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5EqvFEi-iEd for ; Thu, 26 Apr 2012 23:36:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3810A21F86D4 for ; Thu, 26 Apr 2012 23:36:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFQ14891; Fri, 27 Apr 2012 02:36:54 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 23:34:07 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 23:34:13 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.29]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 27 Apr 2012 14:34:08 +0800 From: Leaf yeh To: "softwires@ietf.org" Thread-Topic: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: AQHNI9iN6n7iMVzqQ0KLpjjIb+nD5Jas+5oAgAEE/1A= Date: Fri, 27 Apr 2012 06:34:07 +0000 Message-ID: References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> <4F999098.3040402@nic.br> <4F99A520.5070102@joelhalpern.com> In-Reply-To: <4F99A520.5070102@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Sorry for being a noise generator, inflating the results. Re: Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 06:37:00 -0000 SSBhbHNvIGJlbGlldmUgdGhlIGFkZGl0aW9uYWwgcHJvZ3Jlc3MgYW5kIHRoZSBleHBlcnQgcmV2 aWV3IG9uIHRoZSBkcmFmdCB3aWxsIG1ha2UgdGhpbmcgYmV0dGVyIHRoYW4gdG9kYXkuIEV2ZXJ5 b25lIGdvdCB0aGUgY2hhbmNlIHRvIGRldmVsb3AgaGltc2VsZi4gU28gcGxzLiBrZWVwIHRvIHdv cmsgb24gd2hhdCB5b3UgbG92ZS4gSSBtZWFudCB0aGUgcmVzdWx0IG9mIHRoZSBsYXN0IHBvbGwg KDczPTIpIGhhdmUgeW91IGNvbnRpbnVlIHlvdXIgb3duIHN0b3J5LiBSaWdodD8NCg0KDQpCZXN0 IFJlZ2FyZHMsDQpMZWFmIFllaA0KDQpBZHZhbmNlZCBSZXNlYXJjaCwgTmV0d29yayBQcm9kdWN0 IExpbmUsIEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpQaG9uZTogKzg2LTc1NS0yODk3 ODg1MSwgIE1vYmlsZTogKzg2LTEzNjAwNDUxMDc1LCAgDQpQb3N0YWwgQWRkcmVzczogRjQtM0Es IEh1YXdlaSwgQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIu Q2hpbmENCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc29mdHdpcmVzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogRnJpZGF5LCBBcHJpbCAyNywgMjAxMiAzOjQy IEFNDQpUbzogQW50b25pbyBNLiBNb3JlaXJhcw0KQ2M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtTb2Z0d2lyZXNdIFNvcnJ5IGZvciBiZWluZyBhIG5vaXNlIGdlbmVyYXRvciwg aW5mbGF0aW5nIHRoZSByZXN1bHRzLiBSZTogUmVzdWx0IGZyb20gdGhlIGNvbnNlbnN1cyBjYWxs IG9uIE1hcCB2cyA0cmQtVSBhbmQgb2ZmaWNpYWwgd2F5IGZvcndhcmQNCg0KSWYgSSBtYXksIGl0 IHNlZW1zIHRvIG1lIHRoYXQgc2V2ZXJhbCBvZiB0aGVzZSByZXBsaWVzIG1pc3Mgc29tZSANCmlt cG9ydGFudCBwb2ludHMgaW4gdGhlIG1lc3NhZ2UgZnJvbSB0aGUgY2hhaXJzLg0KDQoxKSBJdCBi ZWNhbWUgY2xlYXIgZHVyaW5nIHRoZSBXRyBwb2xsIHRoYXQgdGhlIGRvY3VtZW50cyB3ZXJlIG5v dCANCmNvbXBsZXRlLiAgVGhpcyBpcyBub3QgYSBiYWQgdGhpbmcuICBXZSBuZWVkIHRvIGZpbmlz aCB0aGVtLg0KMikgVGhlIHBvbGwgZGlkIGluZGljYXRlIHRoYXQgdGhlcmUgaXMgaW50ZXJlc3Qg aW4gdGhlIGRvY3VtZW50cy4NCjMpIEdpdmVuIHRoYXQgdGhlIGRvY3VtZW50cyBhcmUgbm90IGNv bXBsZXRlLCB0aGV5IGNhbiBub3QgYmUgc2VudCB0byANCnRoZSBJRVNHIGF0IHRoaXMgdGltZS4g IFVudGlsIHRoZXkgYXJlIGNvbXBsZXRlLCBhIGZpbmFsIGRlY2lzaW9uIG9uIA0Kd2hhdCBzdGF0 dXMgdGhleSB3aWxsIGJlIGxhYmVsbGVkIHdpdGggY2FuIG5vdCBiZSBtYWRlLg0KDQpIZW5jZSwg d2hhdCBjYW4gYmUgZG9uZSBpcyBlaXRoZXIgdG8gYWRvcHQgdGhlIGRvY3VtZW50cyBhcyBXRyAN CmRvY3VtZW50cywgb3Igbm90LiAgRXZlbiBpZiB0aGUgY2hhaXJzIHdlcmUgdG8gc3RhdGUgYW4g aW50ZW5kZWQgc3RhdHVzIA0KZm9yIHRoZSBkb2N1bWVudHMgdXBvbiBjb21wbGV0aW9uLCB0aGF0 IHdvdWxkIGhhdmUgdG8gYmUgdmVyaWZpZWQgd2hlbiANCnRoZSBmaW5hbCBjb250ZW50IHdhcyBh dmFpbGFibGUuDQoNClRoZSBtb3N0IGltcG9ydGFudCB0aGluZyBhY3R1YWxseSBpcyB0aGUgY2Fs bCBmb3IgcmV2aWV3ZXJzLiAgSWYgeW91IA0Kd2FudCB0byBzZWUgYW55IG9mIHRoZSBkb2N1bWVu dHMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgYW5kIA0Kd29ya2VkIG9uLCB3ZSBuZWVk IGZvbGtzIHRvIHN0ZXAgZm9yd2FyZCBhcyByZXZpZXdlcnMuICBGb2xrcyB3aG8gYXJlIA0Kbm90 IHRoZSBhdXRob3JzLg0KDQpZb3VycywNCkpvZWwgTS4gSGFscGVybg0KQW4gb2JzZXJ2ZXIgd2l0 aG91dCBhIHByZWZlcmVuY2Ugb24gb3V0Y29tZXMuDQoNClBTOiBJIHRoaW5rIHRoZXJlIGlzIGFs c28gc29tZSBjb25mdXNpb24gYWJvdXQgSUVURiBwcm9jZXNzZXMuICBIb3dldmVyLCANCkkgd2ls bCBub3QgYmVsYWJvciB0aGUgbGlzdCB3aXRoIGEgcmFudCBvbiB0aGF0LiAgSSB3aWxsIGhhcHBp bHkgYW5zd2VyIA0Kb2ZmLWxpc3QgcXVlc3Rpb25zIGlmIGl0IGkgaGVscGZ1bCB0byBpbmRpdmlk dWFscy4NCg== From internet-drafts@ietf.org Sat Apr 28 14:31:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5631E21F854E; Sat, 28 Apr 2012 14:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h52wge-3ggT; Sat, 28 Apr 2012 14:30:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC99421F84DF; Sat, 28 Apr 2012 14:30:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120428213059.9792.53848.idtracker@ietfa.amsl.com> Date: Sat, 28 Apr 2012 14:30:59 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-gateway-init-ds-lite-08.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 21:31:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Gateway Initiated Dual-Stack Lite Deployment Author(s) : Frank Brockners Sri Gundavelli Sebastian Speicher David Ward Filename : draft-ietf-softwire-gateway-init-ds-lite-08.txt Pages : 14 Date : 2012-04-28 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lit= e-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lite= -08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/ From yiu_lee@cable.comcast.com Sun Apr 29 13:04:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0085621F8569 for ; Sun, 29 Apr 2012 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.51 X-Spam-Level: X-Spam-Status: No, score=-100.51 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OhhMn35E9dK for ; Sun, 29 Apr 2012 13:04:06 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57321F84C3 for ; Sun, 29 Apr 2012 13:04:06 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.10844092; Sun, 29 Apr 2012 15:56:35 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Sun, 29 Apr 2012 16:04:00 -0400 From: "Lee, Yiu" To: "Jan Zorz @ go6.si" , "softwires@ietf.org" Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: AQHNJkM3COYqTazcrEOKJl0d1UibEQ== Date: Sun, 29 Apr 2012 20:03:59 +0000 Message-ID: In-Reply-To: <4F9960D2.8060208@go6.si> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3418560239_10037733" MIME-Version: 1.0 Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 20:04:08 -0000 --B_3418560239_10037733 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Well, even the WG decided to go with MAP, we would still need to coin toss between MAP-T and MAP-E, wouldn't we? On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" wrote: >On 4/26/12 11:50 AM, Mark Townsley wrote: >> Perhaps we would have been better off with the coin toss. > >+1 > >bingo. > >Cheers, Jan > >P.S: I'll not waste more bits on this topic as it's apparently a waste >of bandwidth :) > >P.P.S: Should we deprecate RFC6346? >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3418560239_10037733 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSE4aZF h1Ox5BQp9BTEhsgFgG/hATAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MjkyMDAzNThaMA0GCSqGSIb3DQEBAQUABIIBAKfI9zaUd/M1l4/goEwpojSL IZrWNRSF9Zd6PNJJnXtZp388k4E5T2Dh7OKAA65roaxpBBPc0Q8dSatE1Qflblc3qRc5jFaW 3fDo4iGg71ihcS+IpH/MaO6kfnmkB1pv0dS6GK7iK2PHDyAQkvnE1KRsTPEwxFh0U+ErjpCG M199k8LzN0lG28ROtp0gFUYmS+U957pXkC2Z7nyUbrbd+DQdmaEobnBK6GSdWneR3mqpzhxe wpPiYd4lyqRTJi1n0vqe7rK4IYbUqzvY4eDACqjGNvicpNtRt3nI4iJ4DKQfav724674fxj0 ECeI8qHfmQzJIeKUMK454SBFdSvDUV4= --B_3418560239_10037733--
Hi Shishio,
 
It seems the definition of=20 6rd MIB is more acceptable than the extension of IP tunnel MIB=20 according to the  Softwire meeting in Paris.
 
Since the 6rd MIB draft itself= is=20 quite clear, a clarification of using one specific way would be helpf= ul :=20 )
 
Regards!
Jiang Dong
2012-04-18