From nobody Sun Feb 1 05:38:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062671A88AC for ; Sun, 1 Feb 2015 05:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrzCbfBSdvTm for ; Sun, 1 Feb 2015 05:38:35 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CBC1A88A8 for ; Sun, 1 Feb 2015 05:38:34 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so12799526igk.1 for ; Sun, 01 Feb 2015 05:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EyZcqnAhMLU9DvIBqXPB/C7Zh1i3YbjY8Ag75h4E+EY=; b=XXqm+prd8VsE+t3c4gyTq0LCXTqWXpRBst3LfJQB3qgHps+qJ9Lq74bCSDfg4NMJ2a 1R0ZOjSHRx0v+n8qh9rdf21tNX5MlrkGtY1v6myaNh/G44fnndNSys5FX+FRsrRd74q1 jPEUvo2vcLI1aDp9vHbHQ9rQ3o2Gja/EzpaW4ypf+9GuF3x06w7delEE4pNxPxkiDzDm bncWFK1inVtqCi65Wf4a8haZRmKYEafrfY+nEEXYSWYCS9SUH2RfJu7p94SnXig8zeQ/ B8Y6qmKyB+jbnb7PUnwIRk6HQrUxS/ml46B66JkyVCV5JJz7gDOb70ruZkY64kkbMzrN G60A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EyZcqnAhMLU9DvIBqXPB/C7Zh1i3YbjY8Ag75h4E+EY=; b=lkCabvfP3QgVznM0AVG4H9c6chDiWauY45NC6td3AUziAN11LXVyOLL7RtAsyayrh/ vX1mnlXcpf6Ea5/lS6IdTeFr7Hul1SrVY5rq8GbOCnnvSABnGGEmA0VS/5hDhN6LmCm5 PGhLUngbJozU8yHjiXOLBD9PNOq1y3Ga6ILJOPNdkAbgbMn3Hytb6/ZlgRikr+UCS2is c6RZiqA0ytDFsq7xorQsNFce6xPIcdhzKXgM9UhGUMTc6lUN62k+E67IHdin46PZzrGE GCtM3j+rHn5eSbNtRM7GQVuqnweYkwILmKSp53qlY5tDbN6oY/rtQdGBHPcWAOv1y4Px 8suA== X-Gm-Message-State: ALoCoQnZHFkdNjNNy6m/sNfqA/vDZj3L3/Yadh96ECeCpF7kdhe045+GTdqHWYHwt935quJ+8I3j X-Received: by 10.107.36.70 with SMTP id k67mr14808330iok.30.1422797914027; Sun, 01 Feb 2015 05:38:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Sun, 1 Feb 2015 05:38:13 -0800 (PST) In-Reply-To: <7D4F2458-B559-4F9E-A142-D1C0880C9A79@eircom.net> References: <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> <20150130164126.GO34798@Space.Net> <8909_1422637053_54CBB7FD_8909_6553_1_5adce3e7-c0d1-4493-b88f-a20a0d4e3c9b@OPEXCLILH03.corporate.adroot.infra.ftgroup> <20150130180456.GP34798@Space.Net> <7D4F2458-B559-4F9E-A142-D1C0880C9A79@eircom.net> From: Lorenzo Colitti Date: Sun, 1 Feb 2015 22:38:13 +0900 Message-ID: To: Ross Chandler Content-Type: multipart/alternative; boundary=001a1140f7c84106d2050e06f483 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 13:38:36 -0000 --001a1140f7c84106d2050e06f483 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 31, 2015 at 4:50 AM, Ross Chandler wrote: > I just tested bug fixes from another vendor to make 464xlat work with IPv= 4 > tethering when a shared handset data & tethering APN is used. > The software developed I assume to meet the requirements of T-Mobile US > didn=E2=80=99t work for the above case although that case works in stock= android. > There is no text in the document that would have prevented this. > Another vendor hasn=E2=80=99t said that they=E2=80=99ll support 464xlat a= nd it doesn=E2=80=99t > look like they=E2=80=99ve any plans to. > If you mean Apple, then I doubt that an IETF document will make them change their mind. --001a1140f7c84106d2050e06f483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 31, 2015 at 4:50 AM, Ross Chandler <ross@eircom.net> w= rote:
I just tested bug fixes from anothe= r vendor to make 464xlat work with IPv4 tethering when a shared handset dat= a & tethering APN is used.
The software developed I assume to meet the requirements of T-Mobile US did= n=E2=80=99t work=C2=A0 for the above case although that case works in stock= android.

There is no text in the docum= ent that would have prevented this.
=C2=A0
Another vendor hasn=E2=80=99t said that they=E2=80=99ll suppo= rt 464xlat and it doesn=E2=80=99t look like they=E2=80=99ve any plans to.

If you mean Apple, then I doubt that an = IETF document will make them change their mind.
--001a1140f7c84106d2050e06f483-- From nobody Sun Feb 1 22:32:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215061A9241 for ; Sun, 1 Feb 2015 22:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k3Rns-lbNAu for ; Sun, 1 Feb 2015 22:32:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E579A1A1B94 for ; Sun, 1 Feb 2015 22:32:49 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id A14761B8167; Mon, 2 Feb 2015 07:32:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 73947180067; Mon, 2 Feb 2015 07:32:47 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 07:32:47 +0100 From: To: "STARK, BARBARA H" , James Woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJ94KoZb5URc+rHGKXMO3E0JzXWAcAgACD64CAAMlUAIAAF8PwgAANrZCAACKoAIAD/q6w Date: Mon, 2 Feb 2015 06:32:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D53E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F0D53E@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.22719 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 06:32:52 -0000 SGkgQmFyYmFyYSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IFNUQVJLLCBCQVJCQVJBIEggW21haWx0bzpi czc2NTJAYXR0LmNvbV0gDQpFbnZvecOpwqA6IHZlbmRyZWRpIDMwIGphbnZpZXIgMjAxNSAxODo0 NQ0Kw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSmFtZXMgV29vZHlhdHQNCkNjwqA6 IElQdjYgT3BzIFdHDQpPYmpldMKgOiBSRTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KPiBBcyBwZXIgUkZDNzA4NCwgd2UgZGlkbid0 IGluY2x1ZGVkIGl0IGJlY2F1c2UgaXQgaW5jbHVkZWQgc29tZSBJUHY0DQo+IGNvbnRpbnVpdHkg c2VydmljZSBmZWF0dXJlcyB0aGF0IGFyZSBub3QgdmFsaWQgZm9yIHRoZSBtb2JpbGUgY29udGV4 dC4gVGhlDQo+IGRvY3VtZW50IGFscmVhZHkgbWVudGlvbnMgdGhlIGZvbGxvd2luZzoNCj4gDQo+ ICAgICAgICAgICAgICAgICAiTm90ZSwgZXZlbiBpZiBSRkM3MDg0IG9ic29sZXRlcyBbUkZDNjIw NF0sIHRoaXMgcHJvZmlsZQ0KPiAgICAgICAgICAgICAgICAgZG9lcyBub3QgcmVxdWlyZSBSRkM3 MDg0IGJlY2F1c2UgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkNCj4gICAgICAgICAgICAgICAgIHRl Y2huaXF1ZXMgdXNlZCBpbiBtb2JpbGUgbmV0d29ya3MgYXJlIG5vdCB0aGUgc2FtZSBhcw0KPiAg ICAgICAgICAgICAgICAgaW4gZml4ZWQgbmV0d29ya3MuIg0KDQpSZXF1aXJpbmcgY29tcGxpYW5j ZSB0byBhbiBvYnNvbGV0ZWQgUkZDICg2MjA0KSBpcy4uLnVtLi4udW51c3VhbC4gRXNwZWNpYWxs eSBzaW5jZSBSRkMgNzA4NCBmaXhlZCBzZXZlcmFsIGl0ZW1zIGluIDYyMDQgdGhhdCBuZWVkZWQg Zml4aW5nLiBJLCBwZXJzb25hbGx5LCB3b3VsZCBub3QgcmVjb21tZW5kIGFueXRoaW5nIGJlIGNv bXBsaWFudCB3aXRoIFJGQyA2MjA0Lg0KDQpBbHNvIG5vdGUgdGhhdCBEUy1MaXRlIGFuZCA2cmQg YXJlICJTSE9VTEQiIHJlcXVpcmVtZW50cyBpbiBSRkMgNzA4NC4gSXQgaXMgdG90YWxseSBwb3Nz aWJsZSBmb3IgYSBkZXZpY2UgdG8gYmUgMTAwJSBjb21wbGlhbnQgd2l0aCBSRkMgNzA4NCBhbmQg bm90IGRvIGVpdGhlciBEUy1MaXRlIG9yIDZyZC4gDQoNCltNZWRdIEkgZnVsbHkgYWdyZWUgLi4u IGJ1dCwgdW5mb3J0dW5hdGVseSwgIHRoaXMgaW50ZXJwcmV0YXRpb24gaXMgbm90IHNoYXJlZC4g SXQgc2VlbXMgdGhhdCBzb21lIHRoaW5rIHRoYXQgQUxMIGl0ZW1zIG1lbnRpb25lZCBpbiBhIGRv Y3VtZW50ICh3aGF0ZXZlciB0aGUgbGFuZ3VhZ2UgdXNlZCBmb3IgaW5kaXZpZHVhbCBpdGVtcykg bXVzdCBiZSBzdXBwb3J0ZWQgd2hpY2ggaXMgbm90IHRydWUuIA0KDQpTdXJlbHkgbW9iaWxlIGRl dmljZSBtYW51ZmFjdHVyZXJzIGFyZSBpbnRlbGxpZ2VudCBlbm91Z2ggdG8gcmVjb2duaXplIHRo YXQgdGhlcmUgaXMgYSB2ZXJ5IGdvb2QgcmVhc29uIGZvciB0aGVtIG5vdCB0byBkbyBEUy1MaXRl IG9yIDZyZCAoYmVjYXVzZSB0aGVzZSBhcmVuJ3QgdXNlZCBpbiAzR1BQIG5ldHdvcmtzKT8gSXQg d291bGQgYWxzbyBiZSBwb3NzaWJsZSB0byBleHBsaWNpdGx5IG5vdGUgdGhhdCB0aGVzZSB0ZWNo bm9sb2dpZXMgYXJlIG5vdCB1c2VkIG9yIG5lZWRlZCBmb3IgY29ubmVjdGluZyB0byAzR1BQIG5l dHdvcmtzLg0KDQpJdCdzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB3aGVuIGFuIFJGQyBpcyBvYnNv bGV0ZWQgYnkgYW5vdGhlciBSRkMsIHJlYWRlcnMgYXJlIHN1cHBvc2VkIHRvIGNvbnNpZGVyIHRo ZSBuZXcgUkZDIGFzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBvYnNvbGV0ZWQgUkZDLCBldmVyeSB0 aW1lIHRoZXkgc2VlIGEgcmVmZXJlbmNlIHRvIHRoZSBvYnNvbGV0ZWQgUkZDLiBTbyBhIGJyYW5k IG5ldyByZWZlcmVuY2UgdG8gYW4gb2Jzb2xldGVkIFJGQywgZm9yIG1lLCBpcyByYXRoZXIgYml6 YXJyZS4gSXQncyBib2dnbGluZyBteSBtaW5kLg0KDQpbTWVkXSBJIGhlYXIgeW91LiBJIHdpbGwg cmVtb3ZlIHRoZSBvYnNvbGV0ZSByZWZlcmVuY2UgKyBhZGQgYSBzZW50ZW5jZSB0byBleGNsdWRl IElQdjQgc2VydmljZSBjb250aW51aXR5IGZlYXR1cmVzIG1lbnRpb25lZCBpbiBSRkM3MDg0LiAN Cg0KIEknbSBub3QgY29udmluY2VkIHRoYXQgdGhpcyByZWZlcmVuY2UgdG8gYW4gb2Jzb2xldGVk IFJGQyB3aWxsIGJlIHVuZGVyc3Rvb2QgaW4gdGhlIG1hbm5lciB5b3UgaW50ZW5kLg0KDQpbTWVk XSBJIHdpbGwgZm9sbG93IHlvdXIgc3VnZ2VzdGlvbi4gDQoNCkJhcmJhcmENCg== From nobody Sun Feb 1 22:40:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD21A9239 for ; Sun, 1 Feb 2015 22:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6250iE27nh5H for ; Sun, 1 Feb 2015 22:40:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC601A9237 for ; Sun, 1 Feb 2015 22:40:53 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 478902AC305; Mon, 2 Feb 2015 07:40:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1B7C3158078; Mon, 2 Feb 2015 07:40:51 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 07:40:51 +0100 From: To: joel jaeggli , Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQPZdT94KoZb5URc+rHGKXMO3E0Jzc6ddw Date: Mon, 2 Feb 2015 06:40:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049034FD@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CD3FB7.3020402@bogus.com> In-Reply-To: <54CD3FB7.3020402@bogus.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.22719 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 06:40:55 -0000 Hi Joel, Which consensus are your talking about?: The one for adopting the document = as a WG item?, the first one declared by the WG before sending it to the IE= SG? the second one declared by the WG to send the document to the IESG?, or= the IETF consensus that was declared before the IESG starts its review? Cheers, Med -----Message d'origine----- De=A0: joel jaeggli [mailto:joelja@bogus.com]=20 Envoy=E9=A0: samedi 31 janvier 2015 21:49 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Gert Doering Cc=A0: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops Li= st Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call On 1/30/15 4:21 AM, mohamed.boucadair@orange.com wrote: > Re-, >=20 > With all due respect, I'm afraid we are not discussing whether the > document is needed or not but (as I see it) whether the new version > does not break the WG consensus that was declared for the version > sent to the IESG. I recall that both the WG and IETF consensus were > declared for the version sent to the IESG. One point on that. Part of the reason we are engaged canvasing, is that Brian's discussed questioned my interpretation of the consensus call. Given that I conceded from the outset that the call is somewhat narrow, one of the questions before us as a w.g. and the ietf community is, is that consensus more unequivocal? Brian I believe is willing to extended the benefit of the doubt. So am I, but it's the working groups document... thanks joel > Thank you. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Gert Doering [mailto:gert@space.net] > Envoy=E9 : vendredi 30 janvier 2015 11:39 =C0 : BOUCADAIR Mohamed > IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred); > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops > List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > call >=20 > Hi, >=20 > On Fri, Jan 30, 2015 at 09:12:16AM +0000, > mohamed.boucadair@orange.com wrote: >> Can you please help us identifying technical flaws that you think >> need to be fixed in the document? >=20 > I don't think there is a need for this document, and I can't truly > see it reflecting WG consensus. So it's more fundamental than just > individual technical issues. >=20 > For the specifics, everything that Lorenzo said. >=20 > Gert Doering -- NetMaster >=20 From nobody Sun Feb 1 23:01:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB551A9245 for ; Sun, 1 Feb 2015 23:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvUZLJ0lhrKC for ; Sun, 1 Feb 2015 23:01:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5061A923C for ; Sun, 1 Feb 2015 23:01:39 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A52362AC21F; Mon, 2 Feb 2015 08:01:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7E0AA384069; Mon, 2 Feb 2015 08:01:37 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 08:01:37 +0100 From: To: Gert Doering , Nick Hilliard Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQPKq094KoZb5URc+rHGKXMO3E0JzYzRQAgAQiipA= Date: Mon, 2 Feb 2015 07:01:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004903527@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CBB2BB.9010608@foobar.org> <20150130164126.GO34798@Space.Net> In-Reply-To: <20150130164126.GO34798@Space.Net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.63025 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:01:41 -0000 Gert, The point about successful deployment is not a valid argument. It is about = rhetoric, not technical. If we adopt that position, every RFC is useless !! Please let me clarify the following points: * This profile is a superset of RFC6434 and RFC7066. For example, the profi= le lists items to fix some problem for IPv6 deployments (e.g., roaming) * This profile also covers IPv4 service continuity features over an IPv6 co= nnectivity * This profile also lists items related to devices with LAN capabilities (t= here are deployments relying on mobile CPEs) * The profile includes items related to the delivery of advanced services o= ver IPv6 (e.g., VoLTE profile). * THE PROFILE DOES NOT REQUIRE IMPLEMENTING ALL THE FEATURES IT LISTS!=20 * All these items were present in the draft when both the WG and IETF conse= nsus were declared. I really recommend you read Section 1.2. Cheers, Med -----Message d'origine----- De=A0: Gert Doering [mailto:gert@space.net]=20 Envoy=E9=A0: vendredi 30 janvier 2015 17:41 =C0=A0: Nick Hilliard Cc=A0: Olaf.Bonness@telekom.de; lorenzo@google.com; BOUCADAIR Mohamed IMT/O= LN; draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; v6ops@ietf.o= rg Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Hi, On Fri, Jan 30, 2015 at 04:35:07PM +0000, Nick Hilliard wrote: > the WG position hasn't materially changed; the document has. To some extent, reality has changed. There are a number of large scale production wireless 3G/4G deployments out there, so the claim "it cannot=20 be done because handsets sucks" is most definitely no longer true. And, as Lorenzo stated, none of these handsets (that work well in=20 practice!) fulfills the shopping list in this draft... which gives that=20 the requirements are not needed for successful deployment, and *that* makes the whole document slightly... superfluous. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sun Feb 1 23:04:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E181A923C; Sun, 1 Feb 2015 23:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVNvSF6ch_lS; Sun, 1 Feb 2015 23:04:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FC31A9245; Sun, 1 Feb 2015 23:04:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202070414.15263.35482.idtracker@ietfa.amsl.com> Date: Sun, 01 Feb 2015 23:04:14 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-16.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:04:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-16.txt Pages : 18 Date : 2015-02-01 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 1 23:08:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86521A923C for ; Sun, 1 Feb 2015 23:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXYEdCjyrtQj for ; Sun, 1 Feb 2015 23:08:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFC81A9239 for ; Sun, 1 Feb 2015 23:08:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BBD7132409E for ; Mon, 2 Feb 2015 08:08:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A20AA27C059 for ; Mon, 2 Feb 2015 08:08:02 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 08:08:02 +0100 From: To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-16.txt Thread-Index: AQHQPrZ/Kb/rAkDDvk6sCHxTwg3GP5zc8AFQ Date: Mon, 2 Feb 2015 07:08:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004903560@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150202070414.15263.35482.idtracker@ietfa.amsl.com> In-Reply-To: <20150202070414.15263.35482.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-16.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:08:07 -0000 Dear all, This version integrates the comments received from James, Lorenzo, and Barb= ara.=20 Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de internet-drafts@= ietf.org Envoy=E9=A0: lundi 2 f=E9vrier 2015 08:04 =C0=A0: i-d-announce@ietf.org Cc=A0: v6ops@ietf.org Objet=A0: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-16.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF= . Title : An Internet Protocol Version 6 (IPv6) Profile for= 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-16.txt Pages : 18 Date : 2015-02-01 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-1= 6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Feb 1 23:12:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09231A923E for ; Sun, 1 Feb 2015 23:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EAagrF3nk_T for ; Sun, 1 Feb 2015 23:11:59 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3181A9239 for ; Sun, 1 Feb 2015 23:11:58 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so14993296igb.5 for ; Sun, 01 Feb 2015 23:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=acK/MxyAXH5OCmad4stzaXSHeWqt17YUsvDLJRTKBe4=; b=INefH36J0kBboK/Y2akILqVSBibarYzV1VKYmxOQ7hlFAlreNLjoX82X28vgt+R1Qg We+In9CGHyLHviJJIPTdrAJR2o80hd+fa/LHMwXvV3ydruGWWt61erYj1jSHdXBbazA4 X9TcJpyN2qRV4Wg2a4U1aktTLeEOnBJGyfHWAwUaGzT/kBTkGjAZCRW6wdSlycsXgnoD SW9yUZxsfrlJWvdQSJI9wp0FJwJcnKl0+JAgu57VtvYd9FB4ADllYHIRVKFLNpiDucW+ kyvP2fucvPPtLS/xLTKEa16C8t5nH4CQj/IVYUgY0v3TjjZ3JP3itrCQ2PR/1Ynyynth 9LzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=acK/MxyAXH5OCmad4stzaXSHeWqt17YUsvDLJRTKBe4=; b=kU7r3wOxGnCrfY/BH7TxMl30yQ3hg/uCewudANSutdIgeGZxV426BRhfVLuHcrq/ym shv/iOEMVxumHE+niiXM0oxgVYjrKViCg1+ABoAqx2e/eV2fwl1Yl4E6WFGwIAhf0zQf nFCJBQcD2yQ+8/nuz6QoEdQcTc+OQa+jaYClVVVtIMjk7Yq80MOz6IA0QODk8GFdBt/Y hLnzILAqcSWoTBAsQQqfQ+WFLxr7Ykbvv136iD3S3sqGpLgvb4f/Qlv/JX9MUSGtbtP8 k+9xrofnCGhMh3akqYlesZftiTQaPFupb7XYKD+8XHQvvm3Ur9WqwQJQUgzyxzJg9vir cBWg== X-Gm-Message-State: ALoCoQlaUborhPwPNKqHdH087KL9EG9qiPfnb7iRtoy9aCV4Hnpn5VWOStaKFthnDumMv4814+d5 X-Received: by 10.43.100.67 with SMTP id cv3mr17750939icc.92.1422861117966; Sun, 01 Feb 2015 23:11:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Sun, 1 Feb 2015 23:11:37 -0800 (PST) From: Lorenzo Colitti Date: Mon, 2 Feb 2015 16:11:37 +0900 Message-ID: To: joel jaeggli , "v6ops-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=bcaec5171e81807e06050e15ab3b Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:12:01 -0000 --bcaec5171e81807e06050e15ab3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Editing subject for for visibility; +v6ops-chairs since this is their bailiwick] Forgive me for being ignorant on these procedural points, but... it seems to me that if there is no longer consensus in the WG that this document should be published, then it should not be published - regardless of what procedural steps the document has been through already. Am I mistaken? If I am correct, then we should make sure that we still have consensus to proceed before we do anything else. The response to this thread suggests that there may not be consensus, but hopefully it deciding the question should be as simple as issuing another consensus call. Regards, Lorenzo On Mon, Feb 2, 2015 at 3:40 PM, wrote: > Hi Joel, > > Which consensus are your talking about?: The one for adopting the documen= t > as a WG item?, the first one declared by the WG before sending it to the > IESG? the second one declared by the WG to send the document to the IESG?= , > or the IETF consensus that was declared before the IESG starts its review= ? > > Cheers, > Med > > -----Message d'origine----- > De : joel jaeggli [mailto:joelja@bogus.com] > Envoy=C3=A9 : samedi 31 janvier 2015 21:49 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Gert Doering > Cc : draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops > List > Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call > > On 1/30/15 4:21 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > With all due respect, I'm afraid we are not discussing whether the > > document is needed or not but (as I see it) whether the new version > > does not break the WG consensus that was declared for the version > > sent to the IESG. I recall that both the WG and IETF consensus were > > declared for the version sent to the IESG. > > One point on that. Part of the reason we are engaged canvasing, is that > Brian's discussed questioned my interpretation of the consensus call. > Given that I conceded from the outset that the call is somewhat narrow, > one of the questions before us as a w.g. and the ietf community is, is > that consensus more unequivocal? Brian I believe is willing to extended > the benefit of the doubt. So am I, but it's the working groups document..= . > > thanks > > joel > > > Thank you. > > > > Cheers, Med > > > > -----Message d'origine----- De : Gert Doering [mailto:gert@space.net] > > Envoy=C3=A9 : vendredi 30 janvier 2015 11:39 =C3=80 : BOUCADAIR Mohame= d > > IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred); > > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops > > List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > > call > > > > Hi, > > > > On Fri, Jan 30, 2015 at 09:12:16AM +0000, > > mohamed.boucadair@orange.com wrote: > >> Can you please help us identifying technical flaws that you think > >> need to be fixed in the document? > > > > I don't think there is a need for this document, and I can't truly > > see it reflecting WG consensus. So it's more fundamental than just > > individual technical issues. > > > > For the specifics, everything that Lorenzo said. > > > > Gert Doering -- NetMaster > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec5171e81807e06050e15ab3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Editing subject for for visibility; +v6ops-chairs since t= his is their bailiwick]

Forgive me for being ignorant on these= procedural points, but... it seems to me that if there is no longer consen= sus in the WG that this document should be published, then it should not be= published - regardless of what procedural steps the document has been thro= ugh already. Am I mistaken?

If I am correct, then = we should make sure that we still have consensus to proceed before we do an= ything else.=C2=A0The response to this thread suggests that there may not b= e consensus, but hopefully it deciding the question should be as simple as = issuing another consensus call.

<= div class=3D"gmail_extra">Regards,
Lorenzo<= /div>

On Mon, Feb = 2, 2015 at 3:40 PM, <mohamed.boucadair@orange.com> wrote:
Hi Joel,

Which consensus are your talking about?: The one for adopting the document = as a WG item?, the first one declared by the WG before sending it to the IE= SG? the second one declared by the WG to send the document to the IESG?, or= the IETF consensus that was declared before the IESG starts its review?
Cheers,
Med

-----Message d'origine-----
De=C2=A0: joel jaeggli [mailto:j= oelja@bogus.com]
Envoy=C3=A9=C2=A0: samedi 31 janvier 2015 21:49
=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN; Gert Doering
Cc=C2=A0: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; = V6 Ops List
Objet=C2=A0: Re: [v6ops] draft-ietf= -v6ops-mobile-device-profile last call

On 1/30/15 4:21 AM, mohamed= .boucadair@orange.com wrote:
> Re-,
>
> With all due respect, I'm afraid we are not discussing whether the=
> document is needed or not but (as I see it) whether the new version > does not break the WG consensus that was declared for the version
> sent to the IESG. I recall that both the WG and IETF consensus were > declared for the version sent to the IESG.

One point on that. Part of the reason we are engaged canvasing, is that
Brian's discussed questioned my interpretation of the consensus call. Given that I conceded from the outset that the call is somewhat narrow,
one of the questions before us as a w.g. and the ietf community is, is
that consensus more unequivocal?=C2=A0 Brian I believe is willing to extend= ed
the benefit of the doubt. So am I, but it's the working groups document= ...

thanks

joel

> Thank you.
>
> Cheers, Med
>
> -----Message d'origine----- De : Gert Doering [mailto:gert@space.net]
>=C2=A0 Envoy=C3=A9 : vendredi 30 janvier 2015 11:39 =C3=80 : BOUCADAIR = Mohamed
> IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred);
> draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Op= s
> List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > call
>
> Hi,
>
> On Fri, Jan 30, 2015 at 09:12:16AM +0000,
> mohamed.boucadair@oran= ge.com wrote:
>> Can you please help us identifying technical flaws that you think<= br> >> need to be fixed in the document?
>
> I don't think there is a need for this document, and I can't t= ruly
> see it reflecting WG consensus.=C2=A0 So it's more fundamental tha= n just
> individual technical issues.
>
> For the specifics, everything that Lorenzo said.
>
> Gert Doering -- NetMaster
>


_______________________= ________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec5171e81807e06050e15ab3b-- From nobody Mon Feb 2 00:08:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C6C1A002A for ; Mon, 2 Feb 2015 00:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3zwN2IJ7VAO for ; Mon, 2 Feb 2015 00:08:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA641A000B for ; Mon, 2 Feb 2015 00:08:02 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id C0B211B8182; Mon, 2 Feb 2015 09:08:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 88203180072; Mon, 2 Feb 2015 09:08:00 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 09:08:00 +0100 From: To: Lorenzo Colitti , joel jaeggli , "v6ops-chairs@tools.ietf.org" Thread-Topic: Consensus call on draft-ietf-v6ops-mobile-device-profile ? Thread-Index: AQHQPreKtyiJoat2D0O2zimQJMaGP5zc/YRA Date: Mon, 2 Feb 2015 08:07:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490366FOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.63025 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:08:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490366FOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJ4oCZbSBub3QgYSBjaGFpciBub3IgYW4gQUQgYnV0LCBidXQgYXMgYW4gZWRpdG9y IG9mIHRoZSBkb2N1bWVudCwgSSBkb27igJl0IHNlZSB3aGF0IGNoYW5nZWQgc2luY2UgdGhlIGNv bnNlbnN1cyB3YXMgZGVjbGFyZWQgZm9yIHRoaXMgZG9jdW1lbnQgU0VWRVJBTCB0aW1lcy4NCg0K V2hhdOKAmXMgbmV3IGluIHRoZSBkb2N1bWVudCB0aGF0IGJyZWFrcyB0aGUgY29uc2Vuc3VzPw0K DQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdv b2dsZS5jb21dDQpFbnZvecOpIDogbHVuZGkgMiBmw6l2cmllciAyMDE1IDA4OjEyDQrDgCA6IGpv ZWwgamFlZ2dsaTsgdjZvcHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQpDYyA6IEdlcnQgRG9lcmlu ZzsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYu b3JnOyBWNiBPcHMgTGlzdDsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KT2JqZXQgOiBDb25z ZW5zdXMgY2FsbCBvbiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSA/DQoN CltFZGl0aW5nIHN1YmplY3QgZm9yIGZvciB2aXNpYmlsaXR5OyArdjZvcHMtY2hhaXJzIHNpbmNl IHRoaXMgaXMgdGhlaXIgYmFpbGl3aWNrXQ0KDQpGb3JnaXZlIG1lIGZvciBiZWluZyBpZ25vcmFu dCBvbiB0aGVzZSBwcm9jZWR1cmFsIHBvaW50cywgYnV0Li4uIGl0IHNlZW1zIHRvIG1lIHRoYXQg aWYgdGhlcmUgaXMgbm8gbG9uZ2VyIGNvbnNlbnN1cyBpbiB0aGUgV0cgdGhhdCB0aGlzIGRvY3Vt ZW50IHNob3VsZCBiZSBwdWJsaXNoZWQsIHRoZW4gaXQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQg LSByZWdhcmRsZXNzIG9mIHdoYXQgcHJvY2VkdXJhbCBzdGVwcyB0aGUgZG9jdW1lbnQgaGFzIGJl ZW4gdGhyb3VnaCBhbHJlYWR5LiBBbSBJIG1pc3Rha2VuPw0KDQpJZiBJIGFtIGNvcnJlY3QsIHRo ZW4gd2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IHdlIHN0aWxsIGhhdmUgY29uc2Vuc3VzIHRvIHBy b2NlZWQgYmVmb3JlIHdlIGRvIGFueXRoaW5nIGVsc2UuIFRoZSByZXNwb25zZSB0byB0aGlzIHRo cmVhZCBzdWdnZXN0cyB0aGF0IHRoZXJlIG1heSBub3QgYmUgY29uc2Vuc3VzLCBidXQgaG9wZWZ1 bGx5IGl0IGRlY2lkaW5nIHRoZSBxdWVzdGlvbiBzaG91bGQgYmUgYXMgc2ltcGxlIGFzIGlzc3Vp bmcgYW5vdGhlciBjb25zZW5zdXMgY2FsbC4NCg0KUmVnYXJkcywNCkxvcmVuem8NCg0KT24gTW9u LCBGZWIgMiwgMjAxNSBhdCAzOjQwIFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgSm9lbCwNCg0K V2hpY2ggY29uc2Vuc3VzIGFyZSB5b3VyIHRhbGtpbmcgYWJvdXQ/OiBUaGUgb25lIGZvciBhZG9w dGluZyB0aGUgZG9jdW1lbnQgYXMgYSBXRyBpdGVtPywgdGhlIGZpcnN0IG9uZSBkZWNsYXJlZCBi eSB0aGUgV0cgYmVmb3JlIHNlbmRpbmcgaXQgdG8gdGhlIElFU0c/IHRoZSBzZWNvbmQgb25lIGRl Y2xhcmVkIGJ5IHRoZSBXRyB0byBzZW5kIHRoZSBkb2N1bWVudCB0byB0aGUgSUVTRz8sIG9yIHRo ZSBJRVRGIGNvbnNlbnN1cyB0aGF0IHdhcyBkZWNsYXJlZCBiZWZvcmUgdGhlIElFU0cgc3RhcnRz IGl0cyByZXZpZXc/DQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCkRlIDogam9lbCBqYWVnZ2xpIFttYWlsdG86am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9l bGphQGJvZ3VzLmNvbT5dDQpFbnZvecOpIDogc2FtZWRpIDMxIGphbnZpZXIgMjAxNSAyMTo0OQ0K w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBHZXJ0IERvZXJpbmcNCkNjIDogZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5v cmc+OyBWNiBPcHMgTGlzdA0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1v YmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KT24gMS8zMC8xNSA0OjIxIEFNLCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPiB3cm90ZToNCj4gUmUtLA0KPg0KPiBXaXRoIGFsbCBkdWUgcmVzcGVjdCwgSSdtIGFmcmFp ZCB3ZSBhcmUgbm90IGRpc2N1c3Npbmcgd2hldGhlciB0aGUNCj4gZG9jdW1lbnQgaXMgbmVlZGVk IG9yIG5vdCBidXQgKGFzIEkgc2VlIGl0KSB3aGV0aGVyIHRoZSBuZXcgdmVyc2lvbg0KPiBkb2Vz IG5vdCBicmVhayB0aGUgV0cgY29uc2Vuc3VzIHRoYXQgd2FzIGRlY2xhcmVkIGZvciB0aGUgdmVy c2lvbg0KPiBzZW50IHRvIHRoZSBJRVNHLiBJIHJlY2FsbCB0aGF0IGJvdGggdGhlIFdHIGFuZCBJ RVRGIGNvbnNlbnN1cyB3ZXJlDQo+IGRlY2xhcmVkIGZvciB0aGUgdmVyc2lvbiBzZW50IHRvIHRo ZSBJRVNHLg0KDQpPbmUgcG9pbnQgb24gdGhhdC4gUGFydCBvZiB0aGUgcmVhc29uIHdlIGFyZSBl bmdhZ2VkIGNhbnZhc2luZywgaXMgdGhhdA0KQnJpYW4ncyBkaXNjdXNzZWQgcXVlc3Rpb25lZCBt eSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgY29uc2Vuc3VzIGNhbGwuDQpHaXZlbiB0aGF0IEkgY29u Y2VkZWQgZnJvbSB0aGUgb3V0c2V0IHRoYXQgdGhlIGNhbGwgaXMgc29tZXdoYXQgbmFycm93LA0K b25lIG9mIHRoZSBxdWVzdGlvbnMgYmVmb3JlIHVzIGFzIGEgdy5nLiBhbmQgdGhlIGlldGYgY29t bXVuaXR5IGlzLCBpcw0KdGhhdCBjb25zZW5zdXMgbW9yZSB1bmVxdWl2b2NhbD8gIEJyaWFuIEkg YmVsaWV2ZSBpcyB3aWxsaW5nIHRvIGV4dGVuZGVkDQp0aGUgYmVuZWZpdCBvZiB0aGUgZG91YnQu IFNvIGFtIEksIGJ1dCBpdCdzIHRoZSB3b3JraW5nIGdyb3VwcyBkb2N1bWVudC4uLg0KDQp0aGFu a3MNCg0Kam9lbA0KDQo+IFRoYW5rIHlvdS4NCj4NCj4gQ2hlZXJzLCBNZWQNCj4NCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tIERlIDogR2VydCBEb2VyaW5nIFttYWlsdG86Z2VydEBzcGFj ZS5uZXQ8bWFpbHRvOmdlcnRAc3BhY2UubmV0Pl0NCj4gIEVudm95w6kgOiB2ZW5kcmVkaSAzMCBq YW52aWVyIDIwMTUgMTE6Mzkgw4AgOiBCT1VDQURBSVIgTW9oYW1lZA0KPiBJTVQvT0xOIENjIDog R2VydCBEb2VyaW5nOyBPbGUgVHJvYW47IEZyZWQgQmFrZXIgKGZyZWQpOw0KPiBkcmFmdC1pZXRm LXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLmFsbEB0b29scy5pZXRmLm9yZz47 IFY2IE9wcw0KPiBMaXN0IE9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUgbGFzdA0KPiBjYWxsDQo+DQo+IEhpLA0KPg0KPiBPbiBGcmksIEph biAzMCwgMjAxNSBhdCAwOToxMjoxNkFNICswMDAwLA0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+IENh biB5b3UgcGxlYXNlIGhlbHAgdXMgaWRlbnRpZnlpbmcgdGVjaG5pY2FsIGZsYXdzIHRoYXQgeW91 IHRoaW5rDQo+PiBuZWVkIHRvIGJlIGZpeGVkIGluIHRoZSBkb2N1bWVudD8NCj4NCj4gSSBkb24n dCB0aGluayB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoaXMgZG9jdW1lbnQsIGFuZCBJIGNhbid0IHRy dWx5DQo+IHNlZSBpdCByZWZsZWN0aW5nIFdHIGNvbnNlbnN1cy4gIFNvIGl0J3MgbW9yZSBmdW5k YW1lbnRhbCB0aGFuIGp1c3QNCj4gaW5kaXZpZHVhbCB0ZWNobmljYWwgaXNzdWVzLg0KPg0KPiBG b3IgdGhlIHNwZWNpZmljcywgZXZlcnl0aGluZyB0aGF0IExvcmVuem8gc2FpZC4NCj4NCj4gR2Vy dCBEb2VyaW5nIC0tIE5ldE1hc3Rlcg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQoNCg== --_000_787AE7BB302AE849A7480A190F8B93300490366FOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUtLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZbSBub3QgYSBj aGFpciBub3IgYW4gQUQgYnV0LCBidXQgYXMgYW4gZWRpdG9yIG9mIHRoZSBkb2N1bWVudCwgSSBk b27igJl0IHNlZSB3aGF0IGNoYW5nZWQgc2luY2UgdGhlIGNvbnNlbnN1cyB3YXMgZGVjbGFyZWQg Zm9yIHRoaXMgZG9jdW1lbnQgU0VWRVJBTCB0aW1lcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGF04oCZcyBuZXcgaW4gdGhlIGRvY3VtZW50 IHRoYXQgYnJlYWtzIHRoZSBjb25zZW5zdXM/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDIgZsOpdnJpZXIgMjAxNSAwODoxMjxicj4N CjxiPsOAJm5ic3A7OjwvYj4gam9lbCBqYWVnZ2xpOyB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEdlcnQgRG9lcmluZzsgZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdDsgQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gQ29uc2Vuc3Vz IGNhbGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W0VkaXRpbmcgc3ViamVjdCBmb3IgZm9yIHZpc2liaWxpdHk7ICYjNDM7djZvcHMtY2hhaXJzIHNp bmNlIHRoaXMgaXMgdGhlaXIgYmFpbGl3aWNrXTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZvcmdpdmUgbWUgZm9yIGJlaW5nIGlnbm9yYW50IG9uIHRoZXNlIHByb2NlZHVy YWwgcG9pbnRzLCBidXQuLi4gaXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB0aGVyZSBpcyBubyBsb25n ZXIgY29uc2Vuc3VzIGluIHRoZSBXRyB0aGF0IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIHB1Ymxp c2hlZCwgdGhlbiBpdCBzaG91bGQgbm90IGJlIHB1Ymxpc2hlZCAtIHJlZ2FyZGxlc3Mgb2Ygd2hh dCBwcm9jZWR1cmFsIHN0ZXBzDQogdGhlIGRvY3VtZW50IGhhcyBiZWVuIHRocm91Z2ggYWxyZWFk eS4gQW0gSSBtaXN0YWtlbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgSSBhbSBjb3JyZWN0LCB0aGVuIHdlIHNob3VsZCBtYWtlIHN1cmUg dGhhdCB3ZSBzdGlsbCBoYXZlIGNvbnNlbnN1cyB0byBwcm9jZWVkIGJlZm9yZSB3ZSBkbyBhbnl0 aGluZyBlbHNlLiZuYnNwO1RoZSByZXNwb25zZSB0byB0aGlzIHRocmVhZCBzdWdnZXN0cyB0aGF0 IHRoZXJlIG1heSBub3QgYmUgY29uc2Vuc3VzLCBidXQgaG9wZWZ1bGx5IGl0IGRlY2lkaW5nIHRo ZSBxdWVzdGlvbiBzaG91bGQgYmUgYXMgc2ltcGxlDQogYXMgaXNzdWluZyBhbm90aGVyIGNvbnNl bnN1cyBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TG9yZW56bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBGZWIgMiwgMjAxNSBhdCAzOjQwIFBNLCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBKb2VsLDxicj4NCjxicj4NCldoaWNoIGNvbnNlbnN1cyBhcmUg eW91ciB0YWxraW5nIGFib3V0PzogVGhlIG9uZSBmb3IgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGFz IGEgV0cgaXRlbT8sIHRoZSBmaXJzdCBvbmUgZGVjbGFyZWQgYnkgdGhlIFdHIGJlZm9yZSBzZW5k aW5nIGl0IHRvIHRoZSBJRVNHPyB0aGUgc2Vjb25kIG9uZSBkZWNsYXJlZCBieSB0aGUgV0cgdG8g c2VuZCB0aGUgZG9jdW1lbnQgdG8gdGhlIElFU0c/LCBvciB0aGUgSUVURiBjb25zZW5zdXMgdGhh dCB3YXMgZGVjbGFyZWQNCiBiZWZvcmUgdGhlIElFU0cgc3RhcnRzIGl0cyByZXZpZXc/PGJyPg0K PGJyPg0KQ2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLTxicj4NCkRlJm5ic3A7OiBqb2VsIGphZWdnbGkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT5dPGJyPg0KRW52b3nDqSZuYnNw Ozogc2FtZWRpIDMxIGphbnZpZXIgMjAxNSAyMTo0OTxicj4NCsOAJm5ic3A7OiBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBHZXJ0IERvZXJpbmc8YnI+DQpDYyZuYnNwOzogPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLmFsbEB0b29scy5pZXRm Lm9yZyI+ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmll dGYub3JnPC9hPjsgVjYgT3BzIExpc3Q8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PYmpldCZuYnNw OzogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFz dCBjYWxsPGJyPg0KPGJyPg0KT24gMS8zMC8xNSA0OjIxIEFNLCA8YSBocmVmPSJtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT4gd3JvdGU6PGJyPg0KJmd0OyBSZS0sPGJyPg0KJmd0Ozxicj4NCiZndDsgV2l0aCBhbGwgZHVl IHJlc3BlY3QsIEknbSBhZnJhaWQgd2UgYXJlIG5vdCBkaXNjdXNzaW5nIHdoZXRoZXIgdGhlPGJy Pg0KJmd0OyBkb2N1bWVudCBpcyBuZWVkZWQgb3Igbm90IGJ1dCAoYXMgSSBzZWUgaXQpIHdoZXRo ZXIgdGhlIG5ldyB2ZXJzaW9uPGJyPg0KJmd0OyBkb2VzIG5vdCBicmVhayB0aGUgV0cgY29uc2Vu c3VzIHRoYXQgd2FzIGRlY2xhcmVkIGZvciB0aGUgdmVyc2lvbjxicj4NCiZndDsgc2VudCB0byB0 aGUgSUVTRy4gSSByZWNhbGwgdGhhdCBib3RoIHRoZSBXRyBhbmQgSUVURiBjb25zZW5zdXMgd2Vy ZTxicj4NCiZndDsgZGVjbGFyZWQgZm9yIHRoZSB2ZXJzaW9uIHNlbnQgdG8gdGhlIElFU0cuPGJy Pg0KPGJyPg0KT25lIHBvaW50IG9uIHRoYXQuIFBhcnQgb2YgdGhlIHJlYXNvbiB3ZSBhcmUgZW5n YWdlZCBjYW52YXNpbmcsIGlzIHRoYXQ8YnI+DQpCcmlhbidzIGRpc2N1c3NlZCBxdWVzdGlvbmVk IG15IGludGVycHJldGF0aW9uIG9mIHRoZSBjb25zZW5zdXMgY2FsbC48YnI+DQpHaXZlbiB0aGF0 IEkgY29uY2VkZWQgZnJvbSB0aGUgb3V0c2V0IHRoYXQgdGhlIGNhbGwgaXMgc29tZXdoYXQgbmFy cm93LDxicj4NCm9uZSBvZiB0aGUgcXVlc3Rpb25zIGJlZm9yZSB1cyBhcyBhIHcuZy4gYW5kIHRo ZSBpZXRmIGNvbW11bml0eSBpcywgaXM8YnI+DQp0aGF0IGNvbnNlbnN1cyBtb3JlIHVuZXF1aXZv Y2FsPyZuYnNwOyBCcmlhbiBJIGJlbGlldmUgaXMgd2lsbGluZyB0byBleHRlbmRlZDxicj4NCnRo ZSBiZW5lZml0IG9mIHRoZSBkb3VidC4gU28gYW0gSSwgYnV0IGl0J3MgdGhlIHdvcmtpbmcgZ3Jv dXBzIGRvY3VtZW50Li4uPGJyPg0KPGJyPg0KdGhhbmtzPGJyPg0KPGJyPg0Kam9lbDxicj4NCjxi cj4NCiZndDsgVGhhbmsgeW91Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycywgTWVkPGJyPg0K Jmd0Ozxicj4NCiZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tIERlIDogR2VydCBEb2Vy aW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmdlcnRAc3BhY2UubmV0Ij5nZXJ0QHNwYWNlLm5l dDwvYT5dPGJyPg0KJmd0OyZuYnNwOyBFbnZvecOpIDogdmVuZHJlZGkgMzAgamFudmllciAyMDE1 IDExOjM5IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQ8YnI+DQomZ3Q7IElNVC9PTE4gQ2MgOiBHZXJ0 IERvZXJpbmc7IE9sZSBUcm9hbjsgRnJlZCBCYWtlciAoZnJlZCk7PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xz LmlldGYub3JnIj5kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9v bHMuaWV0Zi5vcmc8L2E+OyBWNiBPcHM8YnI+DQomZ3Q7IExpc3QgT2JqZXQgOiBSZTogW3Y2b3Bz XSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0PGJyPg0KJmd0OyBj YWxsPGJyPg0KJmd0Ozxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBK YW4gMzAsIDIwMTUgYXQgMDk6MTI6MTZBTSAmIzQzOzAwMDAsPGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT4gd3JvdGU6PGJyPg0KJmd0OyZndDsgQ2FuIHlvdSBwbGVhc2UgaGVscCB1cyBp ZGVudGlmeWluZyB0ZWNobmljYWwgZmxhd3MgdGhhdCB5b3UgdGhpbms8YnI+DQomZ3Q7Jmd0OyBu ZWVkIHRvIGJlIGZpeGVkIGluIHRoZSBkb2N1bWVudD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRv bid0IHRoaW5rIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhpcyBkb2N1bWVudCwgYW5kIEkgY2FuJ3Qg dHJ1bHk8YnI+DQomZ3Q7IHNlZSBpdCByZWZsZWN0aW5nIFdHIGNvbnNlbnN1cy4mbmJzcDsgU28g aXQncyBtb3JlIGZ1bmRhbWVudGFsIHRoYW4ganVzdDxicj4NCiZndDsgaW5kaXZpZHVhbCB0ZWNo bmljYWwgaXNzdWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZvciB0aGUgc3BlY2lmaWNzLCBldmVy eXRoaW5nIHRoYXQgTG9yZW56byBzYWlkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEdlcnQgRG9lcmlu ZyAtLSBOZXRNYXN0ZXI8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300490366FOPEXCLILM23corp_-- From nobody Mon Feb 2 03:18:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ACC1A00CF for ; Mon, 2 Feb 2015 03:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DarXmExJUf3Y for ; Mon, 2 Feb 2015 03:18:20 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3041A0078 for ; Mon, 2 Feb 2015 03:18:20 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hn18so17315916igb.2 for ; Mon, 02 Feb 2015 03:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ab2IgSHy0fUmzjfvYnyl8nCPL6MnFQI6zYiLfujG+HA=; b=KjRkbCstZ/qooyZvb4xZXYeCIZ2D5VE+PCiu8j4llR4gHQ7uCEXIsY1dAvu7sT2Rmu r3EQkJY458aEAg/OZXDN7CYo/Im7KMr62+KFeCKwgLuD0OGoCNvwYgOxAa5WTkuWetV+ egiOa5wjzYC4G88nWgiob5OSkBBHdPXEDHGdhCtbqbl8HGxHqGuKOqUZMxjATEHB0YNS UAqiIFB8qGlls4ac7Ixl8t/bjWsrRZKjUoSOc/x5XsObDqSi4EP2DbX/ghg89WYjJsSa ME7Zau7gPihdEKhFcd8UB8jCG17xVLVUu/2KczskB2VsMK0ky/PAT+h93oEApoZ7L2MA E7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ab2IgSHy0fUmzjfvYnyl8nCPL6MnFQI6zYiLfujG+HA=; b=SiK5EuBw3gi70+nrKqCuB4F63NJswz8gl4P87y6ufC5oFgXgQA1G1K/N4c5jYUpjB8 x2CVPkhRhFYZWcJvyWCAeqgwkNAQo+aRYt1M+oqSmFQN5sfBuSInmzePSu+iWraKbm/f eaOQ5BFmfW47KA0GXYevJA0/2k8nOb8Zd4WTTd19diVZxKwNuP+hVPjtaMiJn7BdNJwp dFM30VkqY6ryLJp/IOLJCaHRlp+FhGmpaXnlejNRaTG2QbgNrXov9Z6e6d0zq1bwLsxm tAPpbFP52LrOUv06Jx38wZcrIJyRH++nxXcZ+G3Zta3DBJW0Mc6H343ZJMy29X/G1FjJ In4w== X-Gm-Message-State: ALoCoQmoySslpy5Lx9tN8v8izKSH4XoSHmim9khNmppegqu/gLztOvmKQluSa8KoDRq8LIwtgdV2 X-Received: by 10.50.1.48 with SMTP id 16mr11043864igj.45.1422875898771; Mon, 02 Feb 2015 03:18:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Mon, 2 Feb 2015 03:17:58 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 2 Feb 2015 20:17:58 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdc12b081a435050e191ce2 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 11:18:21 -0000 --047d7bdc12b081a435050e191ce2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 2, 2015 at 5:07 PM, wrote: > I=E2=80=99m not a chair nor an AD but, but as an editor of the document,= I don=E2=80=99t > see what changed since the consensus was declared for this document SEVER= AL > times. > Well... for one, the WG can always change its mind, can it not? Or are you saying that because consensus was declared in the past, we are now irrevocably committed to publishing this document? --047d7bdc12b081a435050e191ce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 2, 2015 at 5:07 PM, <mohamed.boucadair@orange.com&= gt; wrote:

I=E2=80=99m not a chair nor an AD but, but as an e= ditor of the document, I don=E2=80=99t see what changed since the consensus= was declared for this document SEVERAL times.


Well... for one, the WG can always change its mi= nd, can it not? Or are you saying that because consensus was declared in th= e past, we are now irrevocably committed to publishing this document?
=
--047d7bdc12b081a435050e191ce2-- From nobody Mon Feb 2 04:01:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9ECC1A0195 for ; Mon, 2 Feb 2015 04:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXDZdL2somI2 for ; Mon, 2 Feb 2015 04:01:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FB11A0191 for ; Mon, 2 Feb 2015 04:01:51 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 7C6593B4096; Mon, 2 Feb 2015 13:01:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 50123180067; Mon, 2 Feb 2015 13:01:49 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 13:01:49 +0100 From: To: Lorenzo Colitti Thread-Topic: Consensus call on draft-ietf-v6ops-mobile-device-profile ? Thread-Index: AQHQPtnzKGaB97TLQpOXcL51MclsIpzdQWTA Date: Mon, 2 Feb 2015 12:01:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004903904@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004903904OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.110619 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 12:01:54 -0000 --_000_787AE7BB302AE849A7480A190F8B933004903904OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpXaGF0IEnigJltIHNheWluZyBpcyBjbGVhcjogQXMgYW4gZWRpdG9yIG9mIHRoaXMg V0cgYWRvcHRlZCBkb2N1bWVudCwgSSBkb27igJl0IHNlZSBuZXcgZWxlbWVudHMgdGhhdCB3b3Vs ZCBtb3RpdmF0ZSB0aGUgd2cgdG8gY29uc2lkZXIgdGhlIGNvbnNlbnN1cyBmb3IgaXQgZ2l2ZW4g dGhlIHJlY2VudCBjaGFuZ2VzIGRvIG5vdCBjb25mbGljdCB3aXRoIHRoZSBzcGlyaXQgb2YgdGhl IHZlcnNpb24gdGhhdCByZWFjaGVkIGJvdGggdGhlIFdHIGFuZCBJRVRGIGNvbnNlbnN1cyArIHRo ZXNlIGNoYW5nZXMgYXJlIHByb3Bvc2VkIGJ5IHRoZSBJRVNHLg0KDQpXaGF0IEnigJltIGFsc28g b2JzZXJ2aW5nIGlzIHRoYXQgeW91IHdlcmUgYWdhaW5zdCB0aGlzIGRyYWZ0IHNpbmNlIGl0cyBh ZG9wdGlvbiwgeW91IHJlcGVhdGVkIHlvdXIgb2JqZWN0aW9uIGR1cmluZyB0aGUgSUVURiBMQyBi dXQgd2UgYWdyZWVkIHRvIGludGVncmF0ZSB0aGUgdGV4dCBjaGFuZ2VzIHlvdSBhc2tlZCBmb3Iu DQoNCklzIGl0IGZhaXIgdG8gcmVwZWF0ZWRseSByZWl0ZXJhdGUgdGhlIHNhbWUgYXJndW1lbnRz IHdoaWxlIHRoZSB3ZyBkZWNpZGVkIG90aGVyd2lzZT8NCg0KV291bGQgeW91IGFjY2VwdCB0aGF0 IHRoZSBJRVRGIGNvbnNlbnN1cyBkb2VzIG5vdCByZWZsZWN0IHlvdXIgb3duIG9waW5pb24/DQoN CkNoZWVycywNCk1lZA0KDQoNCkRlIDogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bn b29nbGUuY29tXQ0KRW52b3nDqSA6IGx1bmRpIDIgZsOpdnJpZXIgMjAxNSAxMjoxOA0Kw4AgOiBC T1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IGpvZWwgamFlZ2dsaTsgdjZvcHMtY2hhaXJz QHRvb2xzLmlldGYub3JnOyBHZXJ0IERvZXJpbmc7IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlLmFsbEB0b29scy5pZXRmLm9yZzsgVjYgT3BzIExpc3QNCk9iamV0IDogUmU6 IENvbnNlbnN1cyBjYWxsIG9uIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxl ID8NCg0KT24gTW9uLCBGZWIgMiwgMjAxNSBhdCA1OjA3IFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0K SeKAmW0gbm90IGEgY2hhaXIgbm9yIGFuIEFEIGJ1dCwgYnV0IGFzIGFuIGVkaXRvciBvZiB0aGUg ZG9jdW1lbnQsIEkgZG9u4oCZdCBzZWUgd2hhdCBjaGFuZ2VkIHNpbmNlIHRoZSBjb25zZW5zdXMg d2FzIGRlY2xhcmVkIGZvciB0aGlzIGRvY3VtZW50IFNFVkVSQUwgdGltZXMuDQoNCldlbGwuLi4g Zm9yIG9uZSwgdGhlIFdHIGNhbiBhbHdheXMgY2hhbmdlIGl0cyBtaW5kLCBjYW4gaXQgbm90PyBP ciBhcmUgeW91IHNheWluZyB0aGF0IGJlY2F1c2UgY29uc2Vuc3VzIHdhcyBkZWNsYXJlZCBpbiB0 aGUgcGFzdCwgd2UgYXJlIG5vdyBpcnJldm9jYWJseSBjb21taXR0ZWQgdG8gcHVibGlzaGluZyB0 aGlzIGRvY3VtZW50Pw0K --_000_787AE7BB302AE849A7480A190F8B933004903904OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgSeKAmW0g c2F5aW5nIGlzIGNsZWFyOiBBcyBhbiBlZGl0b3Igb2YgdGhpcyBXRyBhZG9wdGVkIGRvY3VtZW50 LCBJIGRvbuKAmXQgc2VlIG5ldyBlbGVtZW50cyB0aGF0IHdvdWxkIG1vdGl2YXRlIHRoZSB3ZyB0 byBjb25zaWRlciB0aGUgY29uc2Vuc3VzIGZvciBpdCBnaXZlbg0KIHRoZSByZWNlbnQgY2hhbmdl cyBkbyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgc3Bpcml0IG9mIHRoZSB2ZXJzaW9uIHRoYXQgcmVh Y2hlZCBib3RoIHRoZSBXRyBhbmQgSUVURiBjb25zZW5zdXMgJiM0MzsgdGhlc2UgY2hhbmdlcyBh cmUgcHJvcG9zZWQgYnkgdGhlIElFU0cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+V2hhdCBJ4oCZbSBhbHNvIG9ic2VydmluZyBpcyB0aGF0IHlv dSB3ZXJlIGFnYWluc3QgdGhpcyBkcmFmdCBzaW5jZSBpdHMgYWRvcHRpb24sIHlvdSByZXBlYXRl ZCB5b3VyIG9iamVjdGlvbiBkdXJpbmcgdGhlIElFVEYgTEMgYnV0IHdlIGFncmVlZCB0byBpbnRl Z3JhdGUNCiB0aGUgdGV4dCBjaGFuZ2VzIHlvdSBhc2tlZCBmb3IuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JcyBpdCBmYWlyIHRvIHJlcGVhdGVk bHkgcmVpdGVyYXRlIHRoZSBzYW1lIGFyZ3VtZW50cyB3aGlsZSB0aGUgd2cgZGVjaWRlZCBvdGhl cndpc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PldvdWxkIHlvdSBhY2NlcHQgdGhhdCB0aGUgSUVURiBjb25zZW5zdXMgZG9lcyBub3QgcmVmbGVj dCB5b3VyIG93biBvcGluaW9uPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkgW21haWx0 bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkg MiBmw6l2cmllciAyMDE1IDEyOjE4PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9o YW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBqb2VsIGphZWdnbGk7IHY2b3BzLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgR2VydCBEb2VyaW5nOyBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IFY2IE9wcyBMaXN0PGJyPg0KPGI+ T2JqZXQmbmJzcDs6PC9iPiBSZTogQ29uc2Vuc3VzIGNhbGwgb24gZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMiwgMjAxNSBhdCA1OjA3IFBNLCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPknigJltIG5vdCBhIGNoYWlyIG5vciBhbiBBRCBidXQsIGJ1dCBhcyBhbiBlZGl0b3Ig b2YgdGhlIGRvY3VtZW50LCBJIGRvbuKAmXQgc2VlIHdoYXQgY2hhbmdlZCBzaW5jZSB0aGUgY29u c2Vuc3VzDQogd2FzIGRlY2xhcmVkIGZvciB0aGlzIGRvY3VtZW50IFNFVkVSQUwgdGltZXMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlbGwuLi4gZm9yIG9uZSwgdGhlIFdHIGNhbiBhbHdheXMgY2hhbmdlIGl0cyBt aW5kLCBjYW4gaXQgbm90PyBPciBhcmUgeW91IHNheWluZyB0aGF0IGJlY2F1c2UgY29uc2Vuc3Vz IHdhcyBkZWNsYXJlZCBpbiB0aGUgcGFzdCwgd2UgYXJlIG5vdyBpcnJldm9jYWJseSBjb21taXR0 ZWQgdG8gcHVibGlzaGluZyB0aGlzIGRvY3VtZW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933004903904OPEXCLILM23corp_-- From nobody Mon Feb 2 04:32:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D521A0277 for ; Mon, 2 Feb 2015 04:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8VKkP0lU7O6 for ; Mon, 2 Feb 2015 04:32:11 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D091A0276 for ; Mon, 2 Feb 2015 04:32:10 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so16382962igk.1 for ; Mon, 02 Feb 2015 04:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0//xhV/za0ztxRlM34LxD4zVGDuNp1AsY3V7GzXdtY4=; b=hWG27VTavAJgp0J+ryq/df/9SXwMQB/dM+/wHyalAbqI3jC0aSMbNjSst/cYj5i2Im P8/SLFNf7XwKHeUqQJzaGYCVU0bDtLQHy1JRatBYvXSDzXDQAn6oEs4T2qXifKpo262b /ArGk2wtjj8cWo1HptQF2BJBzVvjYWIuYGDuDAc2lagAMeZNglexNeOkWguyWTsH+zYH Ww3q628eH1A9YEa9VPZtD3BLPiur+o7aLR20BDGlNvdUutO+c9gaDAi4xW/sp4ENFV3y gho0w49Ofhh9mxbCDz0ZCZ2rML+hMbECSA/MwbKKzO4eB5a+CcWUp3OlaikEXnhwFs/e pshA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0//xhV/za0ztxRlM34LxD4zVGDuNp1AsY3V7GzXdtY4=; b=g+q/AxZGP33ERkl35jlfPHAYI7cFbrnVsDqACAst5mJgy4+B4OETvxDZRe0WN1ZJz/ rAUv9V+yoUK3FcIUIT3K/aEFuTTKEsLW2RG20SQjp4Be7mA1DGiwA03rlvNQfZbW3Wyh dOe1XLI2fJLl+I6Mlqb4DNDyoIPt2ijkE2Gm0JE80bBMpl62lwYwFe+czPmBEyoR0MsP VvnalF5Y+iU9wZ6s19Op20Y+LWiSzJVVlwwHYyXHIVsr5R1TRsEJVrCu7ih/vgzBe/7q phbThX9Gg7X4eyySgi3hWaKM6fAESUKGAE6UnJZCDAlYwSJ+w53yzebTAuMgliSfINAY j8EQ== X-Gm-Message-State: ALoCoQlk3G/3Hpser7QvDCWqNxHuSeagjt+yYcHCLR0hcRo9+IZRK3SvfHonb6mUURWWCtDnBwxL X-Received: by 10.43.67.3 with SMTP id xs3mr15946523icb.39.1422880330134; Mon, 02 Feb 2015 04:32:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.138.136 with HTTP; Mon, 2 Feb 2015 04:31:50 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004903904@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004903904@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 2 Feb 2015 21:31:50 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11c2162ea2e05b050e1a24c0 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 12:32:12 -0000 --001a11c2162ea2e05b050e1a24c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 2, 2015 at 9:01 PM, wrote: > What I=E2=80=99m saying is clear: As an editor of this WG adopted docume= nt, I > don=E2=80=99t see new elements that would motivate the wg to consider the= consensus > for it given the recent changes do not conflict with the spirit of the > version that reached both the WG and IETF consensus + these changes are > proposed by the IESG. > Are you saying that the WG cannot change its mind, or that you see no reason for it to change its mind? Whether the WG can or cannot change its mind on this document is, I think, a procedural point that the chairs and the AD can clarify or decide. Whether you see any reason for it to do so is a matter of opinion that may or may not be shared by the rest of the WG. All I'm saying is that in the latest WGLC thread, there were a lot of negative responses and not a whole lot of support except from the authors. To me that suggests that people are unhappy with this document. > Is it fair to repeatedly reiterate the same arguments while the wg decide= d > otherwise? > I didn't reiterate the same arguments. I started my response to this new WGLC by saying that I was found to be in the rough, and only picked three points to comment on, none of which had been made before. > Would you accept that the IETF consensus does not reflect your own > opinion? > Of course consensus might not reflect my opinion. The question I'm asking is: is there still consensus in the WG to publish this document? --001a11c2162ea2e05b050e1a24c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 2, 2015 at 9:01 PM, <mohamed.boucadair@orange.com&= gt; wrote:

What I=E2=80=99m saying is clear: As an editor of = this WG adopted document, I don=E2=80=99t see new elements that would motiv= ate the wg to consider the consensus for it given the recent changes do not conflict with the spirit of the version that rea= ched both the WG and IETF consensus + these changes are proposed by the IES= G.


Are you saying th= at the WG cannot change its mind, or that you see no reason for it to chang= e its mind?

Whether the WG can or cannot change it= s mind on this document is, I think, a procedural point that the chairs and= the AD can clarify or decide. Whether you see any reason for it to do so i= s a matter of opinion that may or may not be shared by the rest of the WG. = All I'm saying is that in the latest WGLC thread, there were a lot of n= egative responses and not a whole lot of support except from the authors. T= o me that suggests that people are unhappy with this document.
= =C2=A0

Is it fair to repeatedly reiterate= the same arguments while the wg decided otherwise?


I didn't reiterate the same arguments. I = started my response to this new WGLC by saying that I was found to be in th= e rough, and only picked three points to comment on, none of which had been= made before.
=C2=A0

Would you accept that the IETF consensus does not = reflect your own opinion?


Of course consensus might not reflect my opinion. The question I'= m asking is: is there still consensus in the WG to publish this document?
--001a11c2162ea2e05b050e1a24c0-- From nobody Mon Feb 2 04:38:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E541A032D for ; Mon, 2 Feb 2015 04:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ-9LSP_Qpcy for ; Mon, 2 Feb 2015 04:38:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9981A0277 for ; Mon, 2 Feb 2015 04:38:05 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id A342A3B426F; Mon, 2 Feb 2015 13:38:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 83FEFC8080; Mon, 2 Feb 2015 13:38:01 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Mon, 2 Feb 2015 13:38:01 +0100 From: To: "STARK, BARBARA H" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJ94KoZb5URc+rHGKXMO3E0JzXWAcAgACD64CAAMlUAIAAF8PwgAANrZCAACKoAIAD/q6wgABnNwA= Date: Mon, 2 Feb 2015 12:38:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004903953@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902567@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D3B0@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933004902B03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61130F0D53E@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049034C8@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.2.110619 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 12:38:08 -0000 QmFyYmFyYSwgDQoNCllvdXIgcHJvcG9zZWQgY2hhbmdlIGhhcyBiZWVuIGludGVncmF0ZWQgaW4g dGhlIG5ldyB2ZXJzaW9uOiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNiANCg0KUGxlYXNlIGxldCBtZSBrbm93 IGlmIHRoaXMgc29sdmVzIHlvdXIgY29uY2Vybi4gVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQN Cg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KRW52b3nDqcKgOiBsdW5kaSAyIGbDqXZyaWVyIDIwMTUgMDc6MzMNCsOAwqA6IFNUQVJL LCBCQVJCQVJBIEg7IEphbWVzIFdvb2R5YXR0DQpDY8KgOiBJUHY2IE9wcyBXRw0KT2JqZXTCoDog UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBj YWxsDQoNCkhpIEJhcmJhcmEsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQN Cg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBTVEFSSywgQkFSQkFSQSBIIFtt YWlsdG86YnM3NjUyQGF0dC5jb21dIA0KRW52b3nDqcKgOiB2ZW5kcmVkaSAzMCBqYW52aWVyIDIw MTUgMTg6NDUNCsOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEphbWVzIFdvb2R5YXR0 DQpDY8KgOiBJUHY2IE9wcyBXRw0KT2JqZXTCoDogUkU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9w cy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsDQoNCj4gQXMgcGVyIFJGQzcwODQsIHdl IGRpZG4ndCBpbmNsdWRlZCBpdCBiZWNhdXNlIGl0IGluY2x1ZGVkIHNvbWUgSVB2NA0KPiBjb250 aW51aXR5IHNlcnZpY2UgZmVhdHVyZXMgdGhhdCBhcmUgbm90IHZhbGlkIGZvciB0aGUgbW9iaWxl IGNvbnRleHQuIFRoZQ0KPiBkb2N1bWVudCBhbHJlYWR5IG1lbnRpb25zIHRoZSBmb2xsb3dpbmc6 DQo+IA0KPiAgICAgICAgICAgICAgICAgIk5vdGUsIGV2ZW4gaWYgUkZDNzA4NCBvYnNvbGV0ZXMg W1JGQzYyMDRdLCB0aGlzIHByb2ZpbGUNCj4gICAgICAgICAgICAgICAgIGRvZXMgbm90IHJlcXVp cmUgUkZDNzA4NCBiZWNhdXNlIElQdjQgc2VydmljZSBjb250aW51aXR5DQo+ICAgICAgICAgICAg ICAgICB0ZWNobmlxdWVzIHVzZWQgaW4gbW9iaWxlIG5ldHdvcmtzIGFyZSBub3QgdGhlIHNhbWUg YXMNCj4gICAgICAgICAgICAgICAgIGluIGZpeGVkIG5ldHdvcmtzLiINCg0KUmVxdWlyaW5nIGNv bXBsaWFuY2UgdG8gYW4gb2Jzb2xldGVkIFJGQyAoNjIwNCkgaXMuLi51bS4uLnVudXN1YWwuIEVz cGVjaWFsbHkgc2luY2UgUkZDIDcwODQgZml4ZWQgc2V2ZXJhbCBpdGVtcyBpbiA2MjA0IHRoYXQg bmVlZGVkIGZpeGluZy4gSSwgcGVyc29uYWxseSwgd291bGQgbm90IHJlY29tbWVuZCBhbnl0aGlu ZyBiZSBjb21wbGlhbnQgd2l0aCBSRkMgNjIwNC4NCg0KQWxzbyBub3RlIHRoYXQgRFMtTGl0ZSBh bmQgNnJkIGFyZSAiU0hPVUxEIiByZXF1aXJlbWVudHMgaW4gUkZDIDcwODQuIEl0IGlzIHRvdGFs bHkgcG9zc2libGUgZm9yIGEgZGV2aWNlIHRvIGJlIDEwMCUgY29tcGxpYW50IHdpdGggUkZDIDcw ODQgYW5kIG5vdCBkbyBlaXRoZXIgRFMtTGl0ZSBvciA2cmQuIA0KDQpbTWVkXSBJIGZ1bGx5IGFn cmVlIC4uLiBidXQsIHVuZm9ydHVuYXRlbHksICB0aGlzIGludGVycHJldGF0aW9uIGlzIG5vdCBz aGFyZWQuIEl0IHNlZW1zIHRoYXQgc29tZSB0aGluayB0aGF0IEFMTCBpdGVtcyBtZW50aW9uZWQg aW4gYSBkb2N1bWVudCAod2hhdGV2ZXIgdGhlIGxhbmd1YWdlIHVzZWQgZm9yIGluZGl2aWR1YWwg aXRlbXMpIG11c3QgYmUgc3VwcG9ydGVkIHdoaWNoIGlzIG5vdCB0cnVlLiANCg0KU3VyZWx5IG1v YmlsZSBkZXZpY2UgbWFudWZhY3R1cmVycyBhcmUgaW50ZWxsaWdlbnQgZW5vdWdoIHRvIHJlY29n bml6ZSB0aGF0IHRoZXJlIGlzIGEgdmVyeSBnb29kIHJlYXNvbiBmb3IgdGhlbSBub3QgdG8gZG8g RFMtTGl0ZSBvciA2cmQgKGJlY2F1c2UgdGhlc2UgYXJlbid0IHVzZWQgaW4gM0dQUCBuZXR3b3Jr cyk/IEl0IHdvdWxkIGFsc28gYmUgcG9zc2libGUgdG8gZXhwbGljaXRseSBub3RlIHRoYXQgdGhl c2UgdGVjaG5vbG9naWVzIGFyZSBub3QgdXNlZCBvciBuZWVkZWQgZm9yIGNvbm5lY3RpbmcgdG8g M0dQUCBuZXR3b3Jrcy4NCg0KSXQncyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgd2hlbiBhbiBSRkMg aXMgb2Jzb2xldGVkIGJ5IGFub3RoZXIgUkZDLCByZWFkZXJzIGFyZSBzdXBwb3NlZCB0byBjb25z aWRlciB0aGUgbmV3IFJGQyBhcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgb2Jzb2xldGVkIFJGQywg ZXZlcnkgdGltZSB0aGV5IHNlZSBhIHJlZmVyZW5jZSB0byB0aGUgb2Jzb2xldGVkIFJGQy4gU28g YSBicmFuZCBuZXcgcmVmZXJlbmNlIHRvIGFuIG9ic29sZXRlZCBSRkMsIGZvciBtZSwgaXMgcmF0 aGVyIGJpemFycmUuIEl0J3MgYm9nZ2xpbmcgbXkgbWluZC4NCg0KW01lZF0gSSBoZWFyIHlvdS4g SSB3aWxsIHJlbW92ZSB0aGUgb2Jzb2xldGUgcmVmZXJlbmNlICsgYWRkIGEgc2VudGVuY2UgdG8g ZXhjbHVkZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSBmZWF0dXJlcyBtZW50aW9uZWQgaW4gUkZD NzA4NC4gDQoNCiBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgcmVmZXJlbmNlIHRvIGFuIG9i c29sZXRlZCBSRkMgd2lsbCBiZSB1bmRlcnN0b29kIGluIHRoZSBtYW5uZXIgeW91IGludGVuZC4N Cg0KW01lZF0gSSB3aWxsIGZvbGxvdyB5b3VyIHN1Z2dlc3Rpb24uIA0KDQpCYXJiYXJhDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGlu ZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0K From nobody Mon Feb 2 08:41:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35BE1A03B3 for ; Mon, 2 Feb 2015 08:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjs_EQYtsvqr for ; Mon, 2 Feb 2015 08:41:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE6F1A03A5 for ; Mon, 2 Feb 2015 08:41:27 -0800 (PST) Received: from mb-aye.local ([192.252.253.126]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t12GfM34069956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2015 16:41:23 GMT (envelope-from joelja@bogus.com) Message-ID: <54CFA8B2.2030707@bogus.com> Date: Mon, 02 Feb 2015 10:41:22 -0600 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Lorenzo Colitti , "v6ops-chairs@tools.ietf.org" References: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490366F@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r8sJ4IXcA4hAeLD6kXVwKViLaUkgAOd1p" Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] Consensus call on draft-ietf-v6ops-mobile-device-profile ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:41:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r8sJ4IXcA4hAeLD6kXVwKViLaUkgAOd1p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/2/15 2:07 AM, mohamed.boucadair@orange.com wrote: > Re-, >=20 > =20 >=20 > I=E2=80=99m not a chair nor an AD but, but as an editor of the document= , I don=E2=80=99t > see what changed since the consensus was declared for this document > SEVERAL times. It's not your role to declare consensus. as I noted previously: =2E.. One point on that. Part of the reason we are engaged canvasing, is that Brian's discuss questioned my interpretation of the consensus call. Given that I conceded from the outset that the call is somewhat narrow, one of the questions before us as a w.g. and the ietf community is, is that consensus more unequivocal? Brian I believe is willing to extended the benefit of the doubt. So am I, but it's the working group's document.= =2E. =2E.. >=20 > What=E2=80=99s new in the document that breaks the consensus? >=20 >=20 > Cheers, >=20 > Med >=20 > =20 >=20 > *De :*Lorenzo Colitti [mailto:lorenzo@google.com] > *Envoy=C3=A9 :* lundi 2 f=C3=A9vrier 2015 08:12 > *=C3=80 :* joel jaeggli; v6ops-chairs@tools.ietf.org > *Cc :* Gert Doering; > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops List;= > BOUCADAIR Mohamed IMT/OLN > *Objet :* Consensus call on draft-ietf-v6ops-mobile-device-profile ? >=20 > =20 >=20 > [Editing subject for for visibility; +v6ops-chairs since this is their > bailiwick] >=20 > =20 >=20 > Forgive me for being ignorant on these procedural points, but... it > seems to me that if there is no longer consensus in the WG that this > document should be published, then it should not be published - > regardless of what procedural steps the document has been through > already. Am I mistaken? >=20 > =20 >=20 > If I am correct, then we should make sure that we still have consensus > to proceed before we do anything else. The response to this thread > suggests that there may not be consensus, but hopefully it deciding the= > question should be as simple as issuing another consensus call. >=20 > =20 >=20 > Regards, >=20 > Lorenzo >=20 > =20 >=20 > On Mon, Feb 2, 2015 at 3:40 PM, > wrote: >=20 > Hi Joel, >=20 > Which consensus are your talking about?: The one for adopting the > document as a WG item?, the first one declared by the WG before sending= > it to the IESG? the second one declared by the WG to send the document > to the IESG?, or the IETF consensus that was declared before the IESG > starts its review? >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : joel jaeggli [mailto:joelja@bogus.com ] > Envoy=C3=A9 : samedi 31 janvier 2015 21:49 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Gert Doering > Cc : draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org > ; V6 > Ops List >=20 > Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call >=20 > On 1/30/15 4:21 AM, mohamed.boucadair@orange.com > wrote: >> Re-, >> >> With all due respect, I'm afraid we are not discussing whether the >> document is needed or not but (as I see it) whether the new version >> does not break the WG consensus that was declared for the version >> sent to the IESG. I recall that both the WG and IETF consensus were >> declared for the version sent to the IESG. >=20 > One point on that. Part of the reason we are engaged canvasing, is that= > Brian's discussed questioned my interpretation of the consensus call. > Given that I conceded from the outset that the call is somewhat narrow,= > one of the questions before us as a w.g. and the ietf community is, is > that consensus more unequivocal? Brian I believe is willing to extende= d > the benefit of the doubt. So am I, but it's the working groups document= =2E.. >=20 > thanks >=20 > joel >=20 >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : Gert Doering [mailto:gert@space.net > ] >> Envoy=C3=A9 : vendredi 30 janvier 2015 11:39 =C3=80 : BOUCADAIR Moham= ed >> IMT/OLN Cc : Gert Doering; Ole Troan; Fred Baker (fred); >> draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org > ; V6 = Ops >> List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last >> call >> >> Hi, >> >> On Fri, Jan 30, 2015 at 09:12:16AM +0000, >> mohamed.boucadair@orange.com wro= te: >>> Can you please help us identifying technical flaws that you think >>> need to be fixed in the document? >> >> I don't think there is a need for this document, and I can't truly >> see it reflecting WG consensus. So it's more fundamental than just >> individual technical issues. >> >> For the specifics, everything that Lorenzo said. >> >> Gert Doering -- NetMaster >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > =20 >=20 --r8sJ4IXcA4hAeLD6kXVwKViLaUkgAOd1p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTPqLIACgkQ8AA1q7Z/VrJohACfQwnUtn0X4zC7aqNglxmTVMx/ pRgAniwQOs9e4XvkFAJ3e8mPYK6a+UMd =Souy -----END PGP SIGNATURE----- --r8sJ4IXcA4hAeLD6kXVwKViLaUkgAOd1p-- From nobody Tue Feb 3 11:18:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF91A8796 for ; Tue, 3 Feb 2015 11:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id holDJKx_vXpG for ; Tue, 3 Feb 2015 11:18:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726881A8745 for ; Tue, 3 Feb 2015 11:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2291; q=dns/txt; s=iport; t=1422991081; x=1424200681; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ekC97dH0AkFb4iF76tFCIR2aVI/Kz7cDdg7J70ziKPk=; b=diOUjHyJF24kJvoFmorc7uLK63dytfqqvDjMHxlB8mWgR68i6u/mGIa3 BkibBIYAroO7co8Eag0s6c+npPUm3KJBPDhTech9wHHIKUI7la5EBmYks sWyvbnGUFU6LQFYTsTALELL6GqeqgubgBI3qlOLZK0jPVSIa4sXbmQrzp o=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQCHHtFU/40NJK1agwZSWQTFCIVvAoEeQwEBAQEBfYQMAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFwgN1nsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI94B4MWgRMFjwyBVIErT4VYkl8ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="asc'?scan'208";a="393025555" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 03 Feb 2015 19:18:00 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t13JI0Cb006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 19:18:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 13:18:00 -0600 From: "Fred Baker (fred)" To: "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQP+YfPEziQPdp1EyC0nGHN6ynig== Date: Tue, 3 Feb 2015 19:17:59 +0000 Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_CCCD477A-BDFC-493C-9275-FBB8391A1EBF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:18:03 -0000 --Apple-Mail=_CCCD477A-BDFC-493C-9275-FBB8391A1EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jan 30, 2015, at 4:21 AM, mohamed.boucadair@orange.com wrote: >=20 > With all due respect, I'm afraid we are not discussing whether the = document is needed or not but (as I see it) whether the new version does = not break the WG consensus that was declared for the version sent to the = IESG. I recall that both the WG and IETF consensus were declared for the = version sent to the IESG. = https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/hi= story/ That=92s not quite the way I recall it. In the WG, consensus has always = been rough. I sent it out when the number of people stating a dissenting = position dwindled. In the IETF LC in September 2013, James, Lorenzo, and = Owen made comments that caused Joel to withdraw it from the IESG. In the = IETF LC in September 2014 and subsequent IESG discussion, comments were = raised by several in the IESG and summarized by Brian Haberman to the = effect that the document has serious issues. = https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ba= llot/. In this round, you have tried to address the issues raised. Before I bother the IESG with it a third time, I=92d really like to hear = a clear consensus, not a rough one. Where it stands right now, that=92s = not at all obvious. --Apple-Mail=_CCCD477A-BDFC-493C-9275-FBB8391A1EBF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVNEe5Z9ieig10VPpAQL9DAf9EU6HNTj5eJ9x6nhARU+gatUHsDc3E0hc WV8n5JuaNEUXTgO5PTBKAdBSWp+hlYyYIZT+3oPlLlSLy3BlUSr1hsumXRZQyxnD 4zqyZNXseOH+6oT38FpFZs0tHDtOu+SXmxsMCUhd5MXkKNUrYKLkBR3V/qFHCZCl EXTcc3XHvYp7qDTCulrVKACm3q/b4CReUeg11wUH9XWD2z5MEEen++OVWdjdbVgT +YbXzQSh3GAyYD28d6N9fZPJdlVURWmUa+Pbl8Lr+bCy9aTb5o3QfQIZ4Po9FgUj ouMcuqfsGmHqdxvHuNqIXA91yrvmonrWfmh2Z1JrJELxfV2lo/5VQg== =cxa9 -----END PGP SIGNATURE----- --Apple-Mail=_CCCD477A-BDFC-493C-9275-FBB8391A1EBF-- From nobody Tue Feb 3 15:16:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBBE1A01AE for ; Tue, 3 Feb 2015 15:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.401 X-Spam-Level: **** X-Spam-Status: No, score=4.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI-DhlJlOrz8 for ; Tue, 3 Feb 2015 15:16:01 -0800 (PST) Received: from nm40-vm8.bullet.mail.bf1.yahoo.com (nm40-vm8.bullet.mail.bf1.yahoo.com [72.30.239.216]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A601A00F6 for ; Tue, 3 Feb 2015 15:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423005360; bh=AWjYx+kSiJYPXWd6I7p+YYCwqPc7eLUktvRFTgMKnzw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RwjpYWPPmoWKLPE4VtbBLuAHuumf+ZLvpq7vmNgbamMkJpjBThlDChPlw1BaOMaww9WrHwUMU2tzqcA4GarcR1d9rXNocoSKDGw+t+rRMXy1ic149v71BMxpnCpjF6hykEpsNBNDACEJN0+ZKVqPXP3fvCysj3QKuDYHBb5fZ/HDG24NT3dXyoXWd766YVcRB34VhxYAABExonm8HfjmNNaeuUiSlif+AZUz8VN1rcCqOhDK7r5t69WMySVJbDCtvnluHu6v223eXdB2gr1iMQx7fT57C9uJddnVN1tNmdfWxsF9Z5YEXQJtJbZFBISyNfN0Te7AJMsCBKy1dz/FlA== Received: from [66.196.81.174] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2015 23:16:00 -0000 Received: from [98.139.212.202] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2015 23:16:00 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 03 Feb 2015 23:16:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 575930.5019.bm@omp1011.mail.bf1.yahoo.com X-YMail-OSG: EAMDBvAVM1kFC8MfSIfgSG4GaOXXr7CMXV4gT5evZd2ZyZ1PAls1Tk0JVZ1UQcG H_yL4wtnGQtSbl7ED8exN0ZWbPUpInvQPO086pdc3szAZpkeOTy0iGGb17egTGx4SwHIvJJQFe99 Uup5ls4ULvlyoVmSH8tQzcf6AJ5jxBP.v1uQo8DLWCL.kVL.p4BenaeitHoGDilRBgIkRVxl7E2p PmogYLUTKOyvws2WgZY2bg.iYwZeMKktASwqLK25hofQyV2LIGYPvIbj02R8SFYvuuOkZwMHwxfV sLuwKqN37Y2iSHGDmDPzwTu9WJ7IVjYgZHSBBPzFDotEg4priQOXxMKjxetNYWF_WHs7BHadHIDr BZLyEc5BSIuD9OLxvU_jQFDTLIGd.sfcW7MkV3SlDjWa.QiPfxD568c3WpirTzq0ZXWXeKKhByxj q4AcTL18_ekcw5lGWtnIsSBt2B69EO1phNz4Dn4G2vbt8DmMR0G8RM5zy32._EKiMYyPfm_RzYHr pywfxEyZhojyvOJL8Rj1MbwNNgQ_yWnkVuTN0U3a3ABU- Received: by 66.196.80.115; Tue, 03 Feb 2015 23:16:00 +0000 Date: Tue, 3 Feb 2015 23:15:33 +0000 (UTC) From: Mark ZZZ Smith To: George Michaelson , Lorenzo Colitti Message-ID: <1954701383.1811136.1423005333378.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 23:16:04 -0000 So this was interesting data, however I've realised that I don't think it i= s quite measuring what I thought it was measuring if the test destination w= as IPv6 only. If that is the case, then the choice was 6to4 or nothing to u= se to access the IPv6 only destination.=20 I think the more interesting case is when the destination is dual stack, an= d the end host has a choice of native IPv4 or 6to4 tunnelled IPv6. A host o= r application that chooses 6to4 over native IPv4 isn't following RFC3484/RF= C6724 precedence. They would be the ones impacted by actively blocking 6to4= traffic somewhere between the host and destination, and that impact would = be visible to the end-user if Happy Eyeball techniques weren't being used. Would it be possible to conduct the same test with a dual stack site? Thanks, Mark. ________________________________ From: George Michaelson To: Lorenzo Colitti =20 Cc: Brian E Carpenter ; Mark ZZZ Smith ; "v6ops@ietf.org" ; Tore Anderson =20 Sent: Tuesday, 27 January 2015, 14:39 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti wrote= : Are these probes made to an IPv6-only hostname? If so, then of course we'd = expect OSes to attempt 6to4. Yes and yes. I thought about pruning, and decided to make it complete. Its = certainly not a strong reflection of the real world dynamic, but it shows h= ow many people are still sitting on vestigial 6to4 technology which can be = woken. Since we know some ISPs had deployment models which included this, I= ts not surprising. Functionally its dead technology. But its zombie dead. not stone-cold. -G =20 > >On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter wrote: > >Measurable, indeed. >> >>Windows 8? Really? >> >>Regards >> Brian >> >> >>On 27/01/2015 15:07, George Michaelson wrote: >>> Ask and ye shall receive >>> >>> Here is a days summary of os, browser, os+browser as determined by the >>> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Pyth= on >>> httpagentparser module to detect OS and Version info. >>> >>> -George >>> >>> os,Windows+7,22287 >>> os,Windows+8.1,1743 >>> os,Windows+Vista,939 >>> os,Windows+8,894 >>> os,Windows+XP,431 >>> os,Macintosh+[na],124 >>> os,iOS+[na],44 >>> os,Linux+[na],29 >>> os,Windows+NT 6.4,6 >>> os,Windows Phone+8.1,2 >>> os,ChromeOS+6310.68.0,2 >>> >>> browser,Chrome,18297 >>> browser,Firefox,3774 >>> browser,Microsoft Internet Explorer,2872 >>> browser,Opera,1439 >>> browser,Safari,110 >>> browser,AndroidBrowser,5 >>> browser,[na],2 >>> browser,SeaMonkey,2 >>> >>> os+browser,Windows+7.Chrome,15539 >>> os+browser,Windows+7.Firefox,3033 >>> os+browser,Windows+7.Microsoft Internet Explorer,2432 >>> os+browser,Windows+8.1.Chrome,1305 >>> os+browser,Windows+7.Opera,1277 >>> os+browser,Windows+8.Chrome,644 >>> os+browser,Windows+Vista.Chrome,537 >>> os+browser,Windows+8.1.Firefox,311 >>> os+browser,Windows+Vista.Microsoft Internet Explorer,230 >>> os+browser,Windows+XP.Chrome,216 >>> os+browser,Windows+Vista.Firefox,148 >>> os+browser,Windows+XP.Firefox,134 >>> os+browser,Windows+8.Firefox,116 >>> os+browser,Windows+8.Microsoft Internet Explorer,87 >>> os+browser,Windows+8.1.Opera,64 >>> os+browser,Windows+8.1.Microsoft Internet Explorer,63 >>> os+browser,Macintosh+[na].Safari,60 >>> os+browser,Windows+XP.Microsoft Internet Explorer,54 >>> os+browser,Windows+8.Opera,45 >>> os+browser,iOS+[na].Safari,44 >>> os+browser,Macintosh+[na].Chrome,36 >>> os+browser,Windows+XP.Opera,25 >>> os+browser,Windows+Vista.Opera,24 >>> os+browser,Macintosh+[na].Firefox,24 >>> os+browser,Linux+[na].Chrome,16 >>> os+browser,Linux+[na].Firefox,8 >>> os+browser,Windows+7.Safari,6 >>> os+browser,Linux+[na].AndroidBrowser,5 >>> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 >>> os+browser,Macintosh+[na].Opera,4 >>> os+browser,Windows+XP.SeaMonkey,2 >>> os+browser,Windows+NT 6.4.Chrome,2 >>> os+browser,Windows+8.[na],2 >>> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 >>> os+browser,ChromeOS+6310.68.0.Chrome,2 >>> >>> >>> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith >>> wrote: >>> >>>> I'm fine with that. >>>> >>>> If it is easy enough, I think it would be interesting to get a bit mor= e of >>>> an insight into who/what is still using 6to4 either in preference to o= r in >>>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 u= sers. >>>> >>>> ------------------------------ >>>> *From:* Lorenzo Colitti >>>> *To:* Mark ZZZ Smith >>>> *Cc:* Brian E Carpenter ; Tore Anderson < >>>> tore@fud.no>; "v6ops@ietf.org" >>>> *Sent:* Wednesday, 21 January 2015, 23:16 >>>> >>>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >>>> >>>> Yes, those users will definitely be impacted. Which is why the documen= t >>>> does not suggest dropping the packets or turning off the relays, excep= t by >>>> saying things like "operators SHOULD [...] consider carefully whether = the >>>> [...] relay can be discontinued as traffic diminishes". That's quite >>>> reasonable guidance, I think. >>>> >>>> Remember: 0.01% is really a very small number. Multiplying it by 1 bil= lion >>>> (like Brian did) makes it seem large, but that's just a trick of the l= ight. >>>> Look at it this way: if all the relays in the world were turned off >>>> overnight and all the 6to4 users were unable to reach a given website,= that >>>> website's reliability would still be 99.99% of what it was before. >>>> >>>> I support this document in its current form. I only have three comment= s >>>> beyond seconding Tore's objection to the draft calling 6to4 "substanti= al": >>>> >>>> 1. Is it necessary to formally deprecate RFC 6732? It's an individu= al >>>> submission. (Not that I support RFC 6732 in any way, to be sure.) >>>> 2. I don't think the sentence "some content providers have been >>>> reluctant to make content available over IPv6" is true, or at least= any >>>> true for any non-trivial value of "some". 6to4 was a problem for co= ntent >>>> providers a few years ago, but we've moved past it. >>>> 3. It might be useful to cite that another reason 6to4 is being >> >>>> deprecated is that IPv6 is actually being deployed these days (fina= lly). >>>> >>>> >>>> >>>> >>>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Brian E Carpenter >>>> To: Tore Anderson ; v6ops@ietf.org >>>> Cc: >>>> Sent: Wednesday, 21 January 2015, 7:14 >>>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >>>> >>>> On 21/01/2015 02:16, Tore Anderson wrote: >>>>> * fred@cisco.com >>>>> >>>>>> This is to initiate a one week working group last call of >>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. >>>>> >>>>> I have read this document, and I think it is ready to move forward. >>>>> >>>>> Its operational need for this document is less pressing now than when >>>>> the -00 version was published back in 2011. Nevertheless, I find it >>>>> valuable and correct to put the final nail in 6to4's coffin at this >>>>> point in time. While the operational community for the most part has >>>>> already realised that 6to4 has no future, there might be some who hav= e >>>>> not been paying attention and formal deprecation of the protocol may >>>>> help prevent them from making the mistake of attempting to base >>>>> production systems on it. >>>>> >>>>> I have one minor comment though: In section 1, it says =C2=ABa substa= ntial >>>>> amount of 6to4 traffic is still observed by IPv6 content providers=C2= =BB. >>>>> While I do see 6to4 traffic, it is quite far from being of "substanti= al" >>>>> levels. I would therefore recommend replacing "substantial" with >>>>> something milder like "noticeable", "measurable", or something along >>>>> those lines. >>>>> >>>>> For what it's worth, today the Google public IPv6 graph shows just a >>>>> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's n= ot >>>>> just me. >>>> >>>> "Tore, >>>> >>>> However, that fraction of Google traffic multipled by Google users >>>> represents something like 100000 users. I don't think we can dismiss >>>> that number of people too easily. It's a matter of taste whether >>>> that's "substantial" or "noticeable". >>>> >>>> Brian" >>>> >>>> Actually, to those end users, the impact might be both quite significa= nt >>>> and noticeable. >>>> >>>> I think one explanation for the use of 6to4 tunnelled IPv6 is that the= ir >>>> hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Goog= le >>>> make their services equally available over both, which I think they do= ), as >>>> per RFC3484 address selection rules. >>>> >>>> The other explanation for it could be that these users have Happy Eyeb= alls >>>> enabled browsers and the browser is choosing to try to use both IPv4 a= nd >>>> IPv6, despite the IPv6 being tunnelled rather than native. From a Happ= y >>>> Eyeballs robustness perspective, that would be quite a reasonable thin= g to >>>> do I think. >>>> >>>> If the end-hosts aren't following RFC3484's default preferences, then >>>> breaking 6to4 might cause the sorts of timeouts that HE is designed to >>>> overcome. RFC3484 is quite old now (2003), and as a minor data point I >>>> first encountered the implementation of them in around 2008/2009 if I >>>> recall correctly on my Linux system (as I was using 6to4 at the time a= nd >>>> wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3= ) is >>>> the way you change that). So if some hosts are still preferring tunnel= led >>>> 6to4 IPv6 over native IPv4 then perhaps they're also not going to be >>>> running a HE enabled browser either. >>>> >>>> Perhaps it might be possible for somebody at Google to produce a list = of >>>> the browser User-Agent strings for people still using 6to4 to see if t= he >>>> browsers being used are HE enabled, which might also give some insight= into >>>> RFC3484 support in the underlying OSes. >>>> >>>> Regards, >>>> Mark. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Tue Feb 3 16:18:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A41A1B15 for ; Tue, 3 Feb 2015 16:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vD-hcGFCjUg for ; Tue, 3 Feb 2015 16:18:37 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39C21A1B12 for ; Tue, 3 Feb 2015 16:18:36 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so382890igb.2 for ; Tue, 03 Feb 2015 16:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KikyuAEna+0zi3zpVfZa5DKnm6hi0BYoH0Rwzz2gZrg=; b=j2UV48IJ9IktGsXACrC+tv97y5KlbkDd6dbGvBKuAGv2nHsCJc1+V57Vyn5PZAJXPP Y8e1CwrJhPr1eq5/FRf7h8YrLYM4TeNn3CfMoIqB/5FrbsAe20XE7IKBPiXVWjU6oBrP omOi2lONE5SyLGG8etZWh8n64uqfesM6+18/OtGD0wps8H45wOh0JDhctZ9Z9dQJjLCG arhaonUabSZAE/DCkcdSsewi870zk5poL47G7NtdkrGVLvJ+9uIBxXxIhYHHQOelo8si XAg2n97VbmOu0B3dBL7/IKGTrQiUZ9wQSOKv+cXh+W3dxDOXG99+7mX7sc4Knt1s+22R VdmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KikyuAEna+0zi3zpVfZa5DKnm6hi0BYoH0Rwzz2gZrg=; b=ZIsghiWn/ZAkwuSyi6R9OTCA/2Gb7i9flcRZ5LHj7HOrCD0IAuXp99H/ZR9v3MySNV KHRiiPERX+q8QCHbZdz3eNG03/f1vrjYPsavBYDFcyL6gUAhU0IIKOBTpBqrQsbKom4B 3aGUMG2hunzQKpccQm2mvQ3OXGfdEsVYM3MxJvYAkYAbge8EphmZ7RVA1XtnzC7DPAEz NapebrSasokD9hmWtVyicmJfSOXrTo/ZepJU9fl0hNnuWTVeQL02m5s/ny/iG7PeaA2G H2b04uU63PLa13uZyFiF2g7oC8W8DFwd/K8gebSqGBrC/Zn3snazjEvs2YTVLdhl/Ypi ul2A== X-Gm-Message-State: ALoCoQlsCvPKJqdgsqxZcyUstXviHEK3wpVJL05duHbtFmOohoqrCgcZEjtvWbSCXDWEsJkGqO9C X-Received: by 10.50.66.131 with SMTP id f3mr21382134igt.7.1423009115932; Tue, 03 Feb 2015 16:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 3 Feb 2015 16:18:15 -0800 (PST) In-Reply-To: <1954701383.1811136.1423005333378.JavaMail.yahoo@mail.yahoo.com> References: <1954701383.1811136.1423005333378.JavaMail.yahoo@mail.yahoo.com> From: Lorenzo Colitti Date: Wed, 4 Feb 2015 09:18:15 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7bdc07a2de2d9a050e38201d Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 00:18:38 -0000 --047d7bdc07a2de2d9a050e38201d Content-Type: text/plain; charset=UTF-8 On Wed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith wrote: > Would it be possible to conduct the same test with a dual stack site? > What would we learn from such an exercise? The OS / user-agent breakdown of the 0.01% of hosts that use 6to4 when talking to dual-stack destinations? Even if we knew that, what would we do with it? --047d7bdc07a2de2d9a050e38201d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com= .au> wrote:
Would it be pos= sible to conduct the same test with a dual stack site?

What would we learn from such an exercise? The OS / user-ag= ent breakdown of the 0.01% of hosts that use 6to4 when talking to dual-stac= k destinations? Even if we knew that, what would we do with it?
=
--047d7bdc07a2de2d9a050e38201d-- From nobody Tue Feb 3 16:26:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4181A1B21 for ; Tue, 3 Feb 2015 16:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emUQ7CbtUhDF for ; Tue, 3 Feb 2015 16:26:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC741A1B1F for ; Tue, 3 Feb 2015 16:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2733; q=dns/txt; s=iport; t=1423009580; x=1424219180; h=from:to:subject:date:message-id:mime-version; bh=TjWVaiNYvgPwJJ99EJ4TfWrwlQu7QEvYGFyvVflvi2s=; b=e283jGpSCNDVSEx6sE7d9xCQGCaTUMEvoOyZRZIIHwIEBTPbUV+hMItj Ki4ezT67/RyuNF8zaGE0RDUvo+uelmwA4daA9QB1qhu6fa4RFEpEOmHCQ 98Oy+jK0eX4VTpbhPukBSQ42MG+Q1ZINSSEtXx19t0p6sUaUZlsPqBXLo 4=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAOdm0VStJA2I/2dsb2JhbABagwZSWgPFCYcJQwEBAQEBfYQTgQsBgQAnBCGIHw2wN6YVAQEBBwEBAQEBHZMVgRMFjwyBVIErT4VYgU2REiKDboIzfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,516,1418083200"; d="asc'?scan'208";a="393155028" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 04 Feb 2015 00:26:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t140QJ9V023226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Feb 2015 00:26:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 18:26:19 -0600 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: IETF 92 heads Up Thread-Index: AQHQQBEyx7zCVfLjf0+my3ib4AWmZw== Date: Wed, 4 Feb 2015 00:26:19 +0000 Message-ID: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_DADE1559-A0BA-498E-98A2-63B4774506A4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 00:26:22 -0000 --Apple-Mail=_DADE1559-A0BA-498E-98A2-63B4774506A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If I had to schedule the meeting today, this is what I would have to = work with: IESG: Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis Jan 28 draft-ietf-v6ops-6to4-to-historic WGLC; on its way to IESG: Feb 1 draft-ietf-v6ops-mobile-device-profile Jan 20 draft-ietf-v6ops-cidr-prefix Working Group Document updated since IETF: Dec 18 draft-ietf-v6ops-siit-dc Jan 27 draft-ietf-v6ops-siit-dc-2xlat Individual Submission updated since IETF: Dec 31 draft-sun-v6ops-xlat-multi Jan 8 draft-anderson-v6ops-siit-eam Working Group Document NOT updated since IETF: Sep 18 draft-ietf-v6ops-design-choices Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem Oct 27 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Aug 24 draft-v6ops-pmtud-ecmp-problem Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world Sep 18 draft-elkins-v6ops-multicast-virtual-nodes Sep 18 draft-wang-v6ops-xlat-prefix-discovery Sep 25 draft-ybai-v6ops-ipv6-for-openstack Oct 11 draft-liu-v6ops-running-multiple-prefixes Oct 27 draft-chen-v6ops-nfv-ipv6 Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance Oct 27 draft-osamu-v6ops-ipv4-literal-in-url Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie more data at = http://datatracker.ietf.org/doc/search/?sort=3Dstatus&activedrafts=3Don&na= me=3Dv6ops Draft cutoff is 2015-03-09, and our preliminary agenda is due the same = day. As usual, we are looking for discussion of posted drafts as an = argument for face time, and under deadline pressure that can be = difficult. If people want to file updates or new drafts, now would be an = excellent time to do so. --Apple-Mail=_DADE1559-A0BA-498E-98A2-63B4774506A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVNFnKZ9ieig10VPpAQJ/zQf9FBqeLgcJlTHF51Jh5llbEcV3E7NmCiWK 7fKCQzlWigDJkHcjFCcG15xAPD6VBoDOOPqmtM4ks/451vY/xCwdOsw2I5mZgVUv bq7gzwN/OZX6BP0r0qGUcZ7nlVhB/o/iJDXOQntctXRthwpW/wo2v0tPPSHkyGiO Ya9bvqjqa/pbJ868q4MI6MvyWw/8l05SjsrjaEWRnkbPjdp9j3JVRYCz6E8u6xWJ 5CwcvT8B+kFaRUxFGV9evmHRlWZbbCyNdfAqjFsbPl3TaxP4o8OcTeQyEw95yDLS IYdT01+5NuEOrQ5qgBU/RXjeVrN+DJ3goTEi3g7dOS8fjz1KI8WWyw== =m65v -----END PGP SIGNATURE----- --Apple-Mail=_DADE1559-A0BA-498E-98A2-63B4774506A4-- From nobody Tue Feb 3 19:12:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5851A1ACA for ; Tue, 3 Feb 2015 19:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKgLUxZqV8GW for ; Tue, 3 Feb 2015 19:12:24 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987721A1BA9 for ; Tue, 3 Feb 2015 19:12:24 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id j7so36889154qaq.5 for ; Tue, 03 Feb 2015 19:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=282AUBfGwOhOIKguRyHtiNcl8TQ3KYgG9KT3olq0Kgs=; b=dA4GbGtvgYLsLaiKGo43MbjZ/u+K6feN8BVCkFd2IzR7rTsBI34Q4KV9PB3i+KUq5Q WvWIGsT6HJWx1KUN/tW/Mm3d/SmzPXKX2SCH7UgzA4i1D5vmYHDD5b11MkEdlai0xfAI ovgOeyOX8xZT9BZK8zWGduXtR1MLoitMBYr2+7i6Q8cM2FX5ypQFCQ3JR+/ZqWXawdWK FLGopRxLJU41wqJwgQ5i2UD8zBYqDQ8SqsuEZ0Hvpk+uiKo5JwYQnFCRgGMJZFPpxD35 iudDlqpOO679XbWfqx6oKHX9V9QL7a1D1ra9syKSBpm2g2+QczVqeLLehh7pu5M0v+FR 7D+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=282AUBfGwOhOIKguRyHtiNcl8TQ3KYgG9KT3olq0Kgs=; b=CzlVNiUYtHdC4EsYasQLOPghdJlppBbvltIKmsqRyXtRhAK2ic52W7RrS28gjeXPjr DIiawmtk7F2zgxcBawwnxjVg7YaAESVXl786Bmxw+BtrjdARV0Pja8oKs65GMvL8oXZ/ 8ZgdxmWX5o3BnoUCeGdVoXTC14FuTifeK1YVfAfkf0CXCcwx4OE5wP1hYF+6JKfdSCnQ ya4+/VTXHY9YVRKfgIzNaw/AQQBqeMI+5I6i6Q+aih8ACVvSHkmCfIOUhU79rOzuAIOP yYeJhYWawduw4MRqGOYhAPY8biuxNiD5tCre4LBYtaONBn2U72Uk0LPBsV6Ue6zRWsWz 7dfQ== X-Gm-Message-State: ALoCoQlmHHeAN8sL7IimZC0FaQR3qAd/EncPjSBgEE3qgbBQ8BNkPG6HQFU8mHxuHVEYn14MbBsR X-Received: by 10.224.136.130 with SMTP id r2mr60808220qat.18.1423019543736; Tue, 03 Feb 2015 19:12:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.230.10 with HTTP; Tue, 3 Feb 2015 19:12:02 -0800 (PST) In-Reply-To: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> References: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> From: Erik Kline Date: Wed, 4 Feb 2015 12:12:02 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:12:25 -0000 > WGLC; on its way to IESG: > Feb 1 draft-ietf-v6ops-mobile-device-profile Are you implying that this would be on the agenda for discussion in Dallas, or is it past that point now and its being past discussion is what would appear on a slide? :) > Individual Submission NOT updated since IETF: > > Aug 24 draft-v6ops-pmtud-ecmp-problem I've seen this draft be usefully referred to a couple of times in the last few months. +1 to keeping it afloat, if not moving forward for some reason (cc'ing Joel explicitly). From nobody Tue Feb 3 19:48:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4F01A1BE6 for ; Tue, 3 Feb 2015 19:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI59lX_dp1YZ for ; Tue, 3 Feb 2015 19:48:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854F61A1BDD for ; Tue, 3 Feb 2015 19:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1936; q=dns/txt; s=iport; t=1423021685; x=1424231285; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZfI0SnSnE8vxMMDcxT+gkEaaZ2lsVxKYriqjiVPpRJk=; b=jnzTzloFyWb88Ka4haVLlQ93oMbllNkQXxNYtkl8Ecm3a4NdehIt+NNZ mx+amOBotgOSP0bCvCfHT2+vkcLuB3YZ4ClWlspajDAtBAYpUR77xFxKc Uph8OWOCmlFvoVOox2534KI6wJLpn/Ee/7RUqxwFXaYCMzYNDtkGOqnnK g=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAI2V0VStJV2R/2dsb2JhbABagwaBKwSCfbR6kwQCgRdDAQEBAQF9hAwBAQEDASNWBQsCAQgOCioCAjIlAgQOBQ6IFwi/ZJZYAQEBAQEBAQEBAQEBAQEBAQEBAQEBF494B4JoLoETBYRKBoo8gVSBK4Ynkl8ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,516,1418083200"; d="asc'?scan'208";a="393239390" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 04 Feb 2015 03:48:04 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t143m3hI010663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 03:48:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 21:48:03 -0600 From: "Fred Baker (fred)" To: Erik Kline Thread-Topic: [v6ops] IETF 92 heads Up Thread-Index: AQHQQC1g63JX6izw00mQIN8RMgIU3g== Date: Wed, 4 Feb 2015 03:48:03 +0000 Message-ID: <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> References: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_70B15157-F8F6-4E4A-AD60-95F4C612E6B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:48:07 -0000 --Apple-Mail=_70B15157-F8F6-4E4A-AD60-95F4C612E6B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2015, at 7:12 PM, Erik Kline wrote: >=20 >> WGLC; on its way to IESG: >> Feb 1 draft-ietf-v6ops-mobile-device-profile >=20 > Are you implying that this would be on the agenda for discussion in > Dallas, or is it past that point now and its being past discussion is > what would appear on a slide? :) If we=E2=80=99re still talking about it, we should finalize it there. We = do need to decide what its status is. >> Individual Submission NOT updated since IETF: >>=20 >> Aug 24 draft-v6ops-pmtud-ecmp-problem >=20 > I've seen this draft be usefully referred to a couple of times in the > last few months. +1 to keeping it afloat, if not moving forward for > some reason (cc'ing Joel explicitly). Up to Joel. If folks tell us it should be a working group draft, it can = be resubmitted as draft-ietf-v6ops-pmtud-ecmp-problem, following the = naming guideline that IETF tools depend on. Or whatever. --Apple-Mail=_70B15157-F8F6-4E4A-AD60-95F4C612E6B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVNGWcp9ieig10VPpAQLO0gf/UYqn69VS3VDJeG9srUq/fSX21XaNG8a/ yghdVG0a9uZFPDhZlf1DRAzZSKY1TgMPFi0QKIz2Dk3M75ydn4YlnUo80sPgaVpX QtYpftTH6KaSrZr51LNrxh3D9ZPagwKRO6eXzBsBxUmv/MhMRgcZz65JwK/iVdLG 7TmLzBorL//zoJxWRXZD/oAjTs11EYRVE/Z1Wudg1bLOmsHgq6/F9vOAk1C3Em23 Ntw3PLckpB2AXT+pQ8/Alm+ee/RD+u2Be0xeZ8ba+x30+g+x0mzDcoGrxtCzqWJv F06Sf4lq2+W0yGMr0yuGR9iFx/OjxxsSGt6NynCTsBU2PyDX+086LA== =Pkyf -----END PGP SIGNATURE----- --Apple-Mail=_70B15157-F8F6-4E4A-AD60-95F4C612E6B9-- From nobody Tue Feb 3 20:05:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0B1A1BA4 for ; Tue, 3 Feb 2015 20:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAIizkIf1rz0 for ; Tue, 3 Feb 2015 20:04:58 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDC1A1B77 for ; Tue, 3 Feb 2015 20:04:58 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id rl12so30398179iec.0 for ; Tue, 03 Feb 2015 20:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D/xpsNE3a2UVpA3DW6adc0C1I8EhFkR825879AuCR5s=; b=jn35Q2flba8fpQK4xF2dsVM3C2yz5/MR8oOkev/1tDVeNHkXysnNEIAuME7MkpIvnj T3CIWHLhfOcOIySi9Sm/mJ4meD9Tq9xvbU/33JUeH5WgG2/Q28zWVNhgvD/rbfhv9R8s IggtXasWPyAAIdzggiqflplg/Ydso5rrja8caw9i7pu/Kq56JCgevQecTgGuf0yQc7gQ 30yyOF8FSfbf12VptlxZtvCvBST/YmWlGvE15ESGwmCrgyb4azLvX7nmzD2tHidZYcLT avjnrhS1qmv6mJ0oergMiMwLKYPgC2VEdr4pCSIp0apvVTJeUAz1b71mqRMwT+p+ObXd 1YXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=D/xpsNE3a2UVpA3DW6adc0C1I8EhFkR825879AuCR5s=; b=h3Yom5dkJoIOzZU6JMdo2VJUvn+m8kbgoGmcLy+zvr7BXRvs/grW1qYPYEBqH2V49c HUUudsTjGEpBM9uMR9IK6WM2eS5VJSLUna1vu6K6saGpHT3Xte/M53a4x617pEe91dk7 ZPNByYska/FgEaNED33ot9C0v2JF99T4MIyOaBvUBnnmAsxo01B6NH/rIixGP967jhgx Z57AW4lNOZ4PKFK2gD/4CrRILPPwoqtQWdzqSIXGmoTeCSsG1kF5hxRtZkdTJtwlFx4O EnXzk1zEwsPM67FFEilN7vScx73VCMsVn4Fk12aer75dHL7B7AYTeSvRe6rIpUjDh7Hj MxlQ== X-Gm-Message-State: ALoCoQmWyIzeGgAKfAeo5awI9Qp5LBIhOVk2h0LOmg2KMN8+oc/s9FhdZ9zoa9c8/VTEABviDflR X-Received: by 10.107.154.17 with SMTP id c17mr32575344ioe.74.1423022697636; Tue, 03 Feb 2015 20:04:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 3 Feb 2015 20:04:37 -0800 (PST) In-Reply-To: <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> References: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> From: Lorenzo Colitti Date: Wed, 4 Feb 2015 13:04:37 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a1140fae8668b74050e3b4a74 Archived-At: Cc: Erik Kline , V6 Ops List Subject: Re: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 04:05:00 -0000 --001a1140fae8668b74050e3b4a74 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 4, 2015 at 12:48 PM, Fred Baker (fred) wrote: > Up to Joel. If folks tell us it should be a working group draft, it can be > resubmitted as draft-ietf-v6ops-pmtud-ecmp-problem, following the naming > guideline that IETF tools depend on. Or whatever. > I though we had an adoption call and there was consensus to adopt. In which case I suppose we just need Joel to post an update. Do I remember wrong? --001a1140fae8668b74050e3b4a74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 4, 2015 at 12:48 PM, Fred Baker (fred) <fred@cisco.com>= wrote:
Up to Joel. If folks tell us it s= hould be a working group draft, it can be resubmitted as draft-ietf-v6ops-p= mtud-ecmp-problem, following the naming guideline that IETF tools depend on= . Or whatever.

I though we had an adopt= ion call and there was consensus to adopt. In which case I suppose we just = need Joel to post an update. Do I remember wrong?
--001a1140fae8668b74050e3b4a74-- From nobody Wed Feb 4 00:11:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD9F1A6FF7 for ; Wed, 4 Feb 2015 00:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKzNkqJnD33C for ; Wed, 4 Feb 2015 00:10:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2601A6FEA for ; Wed, 4 Feb 2015 00:10:57 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C31522AC465; Wed, 4 Feb 2015 09:10:55 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 9B83015805A; Wed, 4 Feb 2015 09:10:55 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 4 Feb 2015 09:10:54 +0100 From: To: "Fred Baker (fred)" , BOUCADAIR Mohamed IMT/OLN Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACFfYCAAOoGUIAACBcAgAAccoCABr3FgIAA44SA Date: Wed, 4 Feb 2015 08:10:54 +0000 Message-ID: <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.4.31819 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:11:09 -0000 Hi, >=20 >=20 > > On Jan 30, 2015, at 4:21 AM, mohamed.boucadair@orange.com wrote: > > > > With all due respect, I'm afraid we are not discussing whether the docu= ment is > needed or not but (as I see it) whether the new version does not break th= e WG > consensus that was declared for the version sent to the IESG. I recall th= at both the > WG and IETF consensus were declared for the version sent to the IESG. >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/h= istory/ >=20 > That's not quite the way I recall it. In the WG, consensus has always bee= n rough. I > sent it out when the number of people stating a dissenting position dwind= led. In > the IETF LC in September 2013, James, Lorenzo, and Owen made comments that > caused Joel to withdraw it from the IESG. In the IETF LC in September 201= 4 and > subsequent IESG discussion, comments were raised by several in the IESG a= nd > summarized by Brian Haberman to the effect that the document has serious > issues. https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device- > profile/ballot/. In this round, you have tried to address the issues rais= ed. [DB] Based on discussions we had regarding Brian's comments, we did not onl= y try to address these comments. We published a new version taking into con= sideration these comments and the main comment about 3GPP liaison has been = closed because 3GPP has no interest and does not edit such kind of document= .=20 >=20 > Before I bother the IESG with it a third time, I'd really like to hear a = clear > consensus, not a rough one. Where it stands right now, that's not at all = obvious. [DB] Do not you think we are in a loop regarding the process ? There were s= ome WG and IETF consensus, then some final comments we have taken into cons= ideration, and now a new WG last call where no technical comments are raise= d but only the same arguments we had during the first last call process. An= d I do not speak about the fact that we may not have, as operators, some le= gitimacy to edit such document or that some people think that IPv6 deployme= nt is done if 3% of the world population can benefit of some IPv6 connectiv= ity.=20 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 4 00:32:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2C1A0163 for ; Wed, 4 Feb 2015 00:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 878Y9WBbq5zP for ; Wed, 4 Feb 2015 00:31:42 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681241A6F3D for ; Wed, 4 Feb 2015 00:31:41 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4495A62F82 for ; Wed, 4 Feb 2015 09:31:39 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 88E1862F7B for ; Wed, 4 Feb 2015 09:31:38 +0100 (CET) Received: (qmail 17056 invoked by uid 1007); 4 Feb 2015 09:31:38 +0100 Date: Wed, 4 Feb 2015 09:31:38 +0100 From: Gert Doering To: david.binet@orange.com Message-ID: <20150204083138.GB34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:31:47 -0000 Hi, On Wed, Feb 04, 2015 at 08:10:54AM +0000, david.binet@orange.com wrote: > some people think that IPv6 deployment is done if 3% of the world population can benefit of some IPv6 connectivity. I notice that those that actually do deploy IPv6 are not those that complain about non-deployment. So, how's Orange's IPv6 deployment coming on? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Feb 4 00:45:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059B71A7016 for ; Wed, 4 Feb 2015 00:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj5CDyzn9nDO for ; Wed, 4 Feb 2015 00:45:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6941A6FF3 for ; Wed, 4 Feb 2015 00:45:36 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 9379F3B4372; Wed, 4 Feb 2015 09:45:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5FF6815805B; Wed, 4 Feb 2015 09:45:31 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Wed, 4 Feb 2015 09:45:27 +0100 From: To: Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACFfYCAAOoGUIAACBcAgAAccoCAB6xKNoAAAuMA Date: Wed, 4 Feb 2015 08:45:27 +0000 Message-ID: <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> In-Reply-To: <20150204083138.GB34798@Space.Net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.4.31819 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:45:38 -0000 > -----Message d'origine----- > De=A0: Gert Doering [mailto:gert@space.net] > Envoy=E9=A0: mercredi 4 f=E9vrier 2015 09:32 > =C0=A0: BINET David IMT/OLN > Cc=A0: Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN; draft-ietf-v6ops-mob= ile- > device-profile.all@tools.ietf.org; V6 Ops List > Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call >=20 > Hi, >=20 > On Wed, Feb 04, 2015 at 08:10:54AM +0000, david.binet@orange.com wrote: > > some people think that IPv6 deployment is done if 3% of the world popul= ation > can benefit of some IPv6 connectivity. >=20 > I notice that those that actually do deploy IPv6 are not those that compl= ain about > non-deployment. [DB] It is a "litote" in French language, doesn't it ? >=20 > So, how's Orange's IPv6 deployment coming on? [DB] Why do you think we are editing with other operators the document we a= re talking about.? >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 4 00:52:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1E1A86EC for ; Wed, 4 Feb 2015 00:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7mbJ4NGUT9K for ; Wed, 4 Feb 2015 00:52:24 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAF11A86E9 for ; Wed, 4 Feb 2015 00:52:24 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so33240049igb.3 for ; Wed, 04 Feb 2015 00:52:23 -0800 (PST) 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; bh=pqua/OhaL3gJVIVRlczGLn5poZ7zL1tlhK+OlGrx1FQ=; b=SWXBugrkZ7nVPYefWilLx9C4dUqIo4vzVykHpJYmB/CUZd8Uq09UnVYyooqEw3wNmT 1HFhnyZHqgfA1jjHUvoN9FBEyf+HyGAK7AqmPewumqwY1f37+A00aCT5bpELNITDzx8v zI6sa/aqQ4QatQU3ydrdwagHBaUAa0T4rdxa2suuFMAFIoRZHsnPX8DJjzCWaN5qL3nl dRpwZOWkDndyzIzBB3P12nIV4rCBPMsNKw3dX7FwVQWAynogeLaHebdejurWm1p+xA3E HmV5oaxvpTz/zFkZGnOfx5pZ32Ax0fVenT2D6WsLnYDM/0tTDtZW/HVKYq/gKqaCevYT R+VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pqua/OhaL3gJVIVRlczGLn5poZ7zL1tlhK+OlGrx1FQ=; b=GGVGy/zZRI1opa2tc3Mlu9EkgI3b3aNiOgBrNiUHUKLBv1gaf23GEGtbuBp2i8hmnn PxTVmEnQPDqMq2DCopATUzawABDAs7KIWKjeEYMja3/iej8lRIp33Aw9t1ZNKmT8Cl2I iO+MOHPQIIZ2OBXbjcgvN9A90ZVeIpO6JTx2+EbFLjyxbogsiMUkU62C4PBQBae5mbra BxNuvfUlmjhV8aqY7q90VQ4ZjvJis+l0OzoWE8ad0m1+fGuYXtlhWITDekoBxa8KKDT8 iRbG67d5T8HIKi+MEBKOS9hQPHuQMu5dC0JPsk99THQN0JZiLLJtST535zfiLL/H3zi/ 3vEA== X-Gm-Message-State: ALoCoQln1dYw8wKybqmqAb6YpKxov4FDKvaxfZXcjuv9q5f2v7JYDeXa4/bbyiYMwWBBVNwV3ahG MIME-Version: 1.0 X-Received: by 10.42.88.9 with SMTP id a9mr826940icm.34.1423039943334; Wed, 04 Feb 2015 00:52:23 -0800 (PST) Received: by 10.64.33.104 with HTTP; Wed, 4 Feb 2015 00:52:23 -0800 (PST) Received: by 10.64.33.104 with HTTP; Wed, 4 Feb 2015 00:52:23 -0800 (PST) In-Reply-To: <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> Date: Wed, 4 Feb 2015 17:52:23 +0900 Message-ID: From: Lorenzo Colitti To: "BINET David IMT/OLN" Content-Type: multipart/alternative; boundary=90e6ba61486e530045050e3f4e42 Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:52:25 -0000 --90e6ba61486e530045050e3f4e42 Content-Type: text/plain; charset=UTF-8 On 4 Feb 2015 5:45 pm, wrote: > [DB] It is a "litote" in French language, doesn't it ? > > > > So, how's Orange's IPv6 deployment coming on? > [DB] Why do you think we are editing with other operators the document we are talking about.? Well, but on the other hand, there's an expression in English my mother always used to use. "Those who can, do. Those who can't, teach". :-) --90e6ba61486e530045050e3f4e42 Content-Type: text/html; charset=UTF-8


On 4 Feb 2015 5:45 pm, <david.binet@orange.com> wrote:
> [DB] It is a "litote" in French language, doesn't it ?
> >
> > So, how's Orange's IPv6 deployment coming on?
> [DB] Why do you think we are editing with other operators the document we are talking about.?

Well, but on the other hand, there's an expression in English my mother always used to use. "Those who can, do. Those who can't, teach". :-)

--90e6ba61486e530045050e3f4e42-- From nobody Wed Feb 4 01:03:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B537D1A8702 for ; Wed, 4 Feb 2015 01:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_8zlSZBe9n6 for ; Wed, 4 Feb 2015 01:03:34 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4D31A8701 for ; Wed, 4 Feb 2015 01:03:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4A0A662F8E for ; Wed, 4 Feb 2015 10:03:32 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 154DF62DF8 for ; Wed, 4 Feb 2015 10:03:32 +0100 (CET) Received: (qmail 22435 invoked by uid 1007); 4 Feb 2015 10:03:31 +0100 Date: Wed, 4 Feb 2015 10:03:31 +0100 From: Gert Doering To: david.binet@orange.com Message-ID: <20150204090331.GD34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FH3lonGIRP4/ScEM" Content-Disposition: inline In-Reply-To: <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:03:37 -0000 --FH3lonGIRP4/ScEM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 04, 2015 at 08:45:27AM +0000, david.binet@orange.com wrote: > > So, how's Orange's IPv6 deployment coming on? > [DB] Why do you think we are editing with other operators the document we= are talking about.? No idea, TBH. I look at other operators that have successfully deployed IPv6 in mobile networks, and fail to see the correspondence to your document. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --FH3lonGIRP4/ScEM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVNHgY99WwGXkzn/FAQIXFxAArrdJOakRtnzzb68SG3vD6/ZfNoTTj2ML lazxEihGamYiMiFQKSfM/fC0qMJkUkdd9V7ant4N9yp4YGwHm637mq5kxP4GLZDX RqUmJbNn9uPI9raJQ02QO5NzN4NqtDti8GxiAN4IZDReEpsbthBU8vZACctzZmIk XBOlVTShhtz8K9VG+OuY4fUqPDRYO9eLHs6UqsUeBBWg+77+qtD8VEmMbhnZorWV 4r0Wv2xIJqHJiMvmVgqH6oQ8gZ0JNWmlxynxSJqOq7fzOSjhwZeApXH1yVxxq0i4 xUqlB/vRVBZS1NiJUQ8aONF3BfyfSEIZDVuJm0Ugc+ZktjMuAJ72L451CRP/vWW/ rq3Bk5+OekDg5eGxOI+Q9zPvRqofxNtXFKv+dWiOS0IC8BRN9NbwL9w2TSeymcSF KjZCmeHpgS27xqxcE2r0mI27zjvia4xFlDhIix/UFQsJveaHJViWO6fyzRCpQImd gyln0sTV1jj5Rmm90CHDqqo8A+dRcMG7N/1m773SzpsdTGytMo07zmLwRI/Virvi 75QAWQ8Gsjvu2KIm+GPju7tEKOS7YSInaUUkGqHZazjtQIfIce9Pp0JzuteNF/mW 3kgx3BaPoZ6dseefoXj4/7s4XuLO/iWidPHZuWrQmyLTZJ6dNfzY/4KKiIPuwHB9 cKplNibuQ+8= =SWLN -----END PGP SIGNATURE----- --FH3lonGIRP4/ScEM-- From nobody Wed Feb 4 02:58:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C191A8722 for ; Wed, 4 Feb 2015 02:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMB9JdsS_FtJ for ; Wed, 4 Feb 2015 02:58:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06D41A86FE for ; Wed, 4 Feb 2015 02:58:43 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id DAD193B4508; Wed, 4 Feb 2015 11:58:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id AD02115808C; Wed, 4 Feb 2015 11:58:41 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 4 Feb 2015 11:58:41 +0100 From: To: Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW83IAgACFfYCAAOoGUIAACBcAgAAccoCAB7UzCIAAHNKA Date: Wed, 4 Feb 2015 10:58:40 +0000 Message-ID: <31656_1423047521_54D1FB61_31656_714_1_bc5e4a4b-0e38-46d8-9c7c-359507e33289@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> <20150204090331.GD34798@Space.Net> In-Reply-To: <20150204090331.GD34798@Space.Net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:58:46 -0000 >=20 > Hi, >=20 > On Wed, Feb 04, 2015 at 08:45:27AM +0000, david.binet@orange.com wrote: > > > So, how's Orange's IPv6 deployment coming on? > > [DB] Why do you think we are editing with other operators the document = we are > talking about.? >=20 > No idea, TBH. I look at other operators that have successfully deployed > IPv6 in mobile networks, and fail to see the correspondence to your docum= ent. [DB] Operators you are talking about have done a great job regarding IPv6 d= eployment but you also have to understand that other operators may not have= the same strength and the same workforce to get IPv6 support from devices = vendors. As Ross said in a previous mail, we still have some specificities = regarding devices capabilities and we should try to reach a state where IPv= 6 support in devices is not a specific feature anymore, whatever the region= s or the way consumers purchase their devices.=20 Such document can certainly help to progress on such issue but I agree it w= ill not solve everything and operators have to think about their IPv6 intro= duction strategy and to deploy it effectively.=20 >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 4 04:11:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381F21A00C6 for ; Wed, 4 Feb 2015 04:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_Gf7iV6_2vu for ; Wed, 4 Feb 2015 04:11:46 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B651A00C0 for ; Wed, 4 Feb 2015 04:11:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t14CBhix013988 for ; Wed, 4 Feb 2015 13:11:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0AA7520249A for ; Wed, 4 Feb 2015 13:12:26 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EC58B202491 for ; Wed, 4 Feb 2015 13:12:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t14CBfpT016953 for ; Wed, 4 Feb 2015 13:11:43 +0100 Message-ID: <54D20C7D.3060406@gmail.com> Date: Wed, 04 Feb 2015 13:11:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 12:11:48 -0000 I support this draft. I support it for a particular reason: its stance with respect to DHCPv6-PD. It mandates the DHCPv6-PD feature (where other documents like RFC7066 IPv6/cell are very diffuse about this requirement). This is needed, because ongoing IPv6-over-foo documents, and RFC 7278 "tethering", tell the best way is DHCPv6-PD, despite deployments missing it. But I am aware of a risk: it is possible to put up an RFC and its technique to never get deployed, however strong the language is. Alex Le 28/01/2015 17:57, Fred Baker (fred) a écrit : > draft-ietf-v6ops-mobile-device-profile has been through Quite a bit > of change in the IESG. The ADs would like to see the working group > read it again and comment - working group last call - before they > proceed. To summarize, it provides requirements for handsets that > would work in a specific business model. As such, it builds on RFC > 6434 and 7066, strengthening some of those requirements, and going > on to add requirements related to 464xlat and other technologies. > > Please read it now, and comment. This WGLC will run until 15 > February. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Feb 4 04:37:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5B1A007B for ; Wed, 4 Feb 2015 04:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygaBgQ0jOZkz for ; Wed, 4 Feb 2015 04:37:00 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667781A0091 for ; Wed, 4 Feb 2015 04:37:00 -0800 (PST) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB586.namprd04.prod.outlook.com (10.141.196.145) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 4 Feb 2015 12:36:59 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0065.013; Wed, 4 Feb 2015 12:36:59 +0000 From: "Metzler, Dan J" To: Mark ZZZ Smith , George Michaelson , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHQQAd7SSN0x98hRUKJ5KFP4IYHJZzgasWA Date: Wed, 4 Feb 2015 12:36:58 +0000 Message-ID: References: <1954701383.1811136.1423005333378.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1954701383.1811136.1423005333378.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.55.230.66] authentication-results: yahoo.com.au; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB586; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB586; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(164054003)(51704005)(377454003)(2521001)(2656002)(87936001)(66066001)(90282001)(88552001)(76176999)(230783001)(54356999)(50986999)(76576001)(15975445007)(77096005)(92566002)(102836002)(33656002)(122556002)(40100003)(75432002)(99286002)(46102003)(106116001)(19580395003)(86362001)(89122001)(2950100001)(74316001)(2900100001)(19580405001)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB586; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2015 12:36:58.5677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB586 Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 12:37:03 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyayBaWlogU21pdGgNCj4gU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMywgMjAxNSA1OjE2IFBNDQo+IFRvOiBHZW9yZ2UgTWljaGFl bHNvbjsgTG9yZW56byBDb2xpdHRpDQo+IENjOiB2Nm9wc0BpZXRmLm9yZzsgVG9yZSBBbmRlcnNv bg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9y aWMgV0dMQw0KPiANCj4gDQo+IA0KPiANCj4gU28gdGhpcyB3YXMgaW50ZXJlc3RpbmcgZGF0YSwg aG93ZXZlciBJJ3ZlIHJlYWxpc2VkIHRoYXQgSSBkb24ndCB0aGluayBpdCBpcyBxdWl0ZQ0KPiBt ZWFzdXJpbmcgd2hhdCBJIHRob3VnaHQgaXQgd2FzIG1lYXN1cmluZyBpZiB0aGUgdGVzdCBkZXN0 aW5hdGlvbiB3YXMgSVB2Ng0KPiBvbmx5LiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGVuIHRoZSBj aG9pY2Ugd2FzIDZ0bzQgb3Igbm90aGluZyB0byB1c2UgdG8gYWNjZXNzDQo+IHRoZSBJUHY2IG9u bHkgZGVzdGluYXRpb24uDQo+IA0KPiBJIHRoaW5rIHRoZSBtb3JlIGludGVyZXN0aW5nIGNhc2Ug aXMgd2hlbiB0aGUgZGVzdGluYXRpb24gaXMgZHVhbCBzdGFjaywgYW5kIHRoZQ0KPiBlbmQgaG9z dCBoYXMgYSBjaG9pY2Ugb2YgbmF0aXZlIElQdjQgb3IgNnRvNCB0dW5uZWxsZWQgSVB2Ni4gQSBo b3N0IG9yDQo+IGFwcGxpY2F0aW9uIHRoYXQgY2hvb3NlcyA2dG80IG92ZXIgbmF0aXZlIElQdjQg aXNuJ3QgZm9sbG93aW5nDQo+IFJGQzM0ODQvUkZDNjcyNCBwcmVjZWRlbmNlLiBUaGV5IHdvdWxk IGJlIHRoZSBvbmVzIGltcGFjdGVkIGJ5IGFjdGl2ZWx5DQo+IGJsb2NraW5nIDZ0bzQgdHJhZmZp YyBzb21ld2hlcmUgYmV0d2VlbiB0aGUgaG9zdCBhbmQgZGVzdGluYXRpb24sIGFuZCB0aGF0DQo+ IGltcGFjdCB3b3VsZCBiZSB2aXNpYmxlIHRvIHRoZSBlbmQtdXNlciBpZiBIYXBweSBFeWViYWxs IHRlY2huaXF1ZXMgd2VyZW4ndA0KPiBiZWluZyB1c2VkLgkNCg0KQW0gSSBtaXNzaW5nIHNvbWV0 aGluZz8gIElzbid0IHRoYXQgcmVhbGx5IGZsYXdlZCBsb2dpYz8gIDZ0bzQgdXNlcnMgdGhhdCB0 YXJnZXQgbmF0aXZlIElQdjYgKG5vbi1kdWFsIHN0YWNrKSB3b3VsZCBkZWZpbml0ZWx5IGJlIGlt cGFjdGVkIGJ5IGJsb2NraW5nIDZ0bzQgdHJhZmZpYy4NClRoZSBudW1iZXIgb2YgdGFyZ2V0cyB0 aGF0IGFyZSBkdWFsIHN0YWNrIGFuZCBzdGlsbCB1c2luZyA2dG80IGlzIGxpa2VseSB0byBiZSBz bWFsbCwgYW5kIGVhc2lseSBmaXhhYmxlLiAgVGhpcyBzZWVtcyBsaWtlbHkgeW91J3JlIHRyeWlu ZyB0byBpZ25vcmUgdGhlIHJlbGV2YW50IHBvcHVsYXRpb24/DQoNCk9yIGFyZSB5b3UgcmVhbGx5 IGZvY3VzZWQgb24gc29tZXRoaW5nIHVucmVsYXRlZD8NCgkNCj4gDQo+IFdvdWxkIGl0IGJlIHBv c3NpYmxlIHRvIGNvbmR1Y3QgdGhlIHNhbWUgdGVzdCB3aXRoIGEgZHVhbCBzdGFjayBzaXRlPw0K PiANCj4gVGhhbmtzLA0KPiBNYXJrLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBGcm9tOiBHZW9yZ2UgTWljaGFlbHNvbiA8Z2dtQGFsZ2VicmFzLm9yZz4NCj4gVG86IExv cmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KPiBDYzogQnJpYW4gRSBDYXJwZW50 ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT47IE1hcmsgWlpaIFNtaXRoDQo+IDxtYXJr enp6c21pdGhAeWFob28uY29tLmF1PjsgInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+ OyBUb3JlDQo+IEFuZGVyc29uIDx0b3JlQGZ1ZC5ubz4NCj4gU2VudDogVHVlc2RheSwgMjcgSmFu dWFyeSAyMDE1LCAxNDozOQ0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3Bz LTZ0bzQtdG8taGlzdG9yaWMgV0dMQw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24g VHVlLCBKYW4gMjcsIDIwMTUgYXQgMTozNiBQTSwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdv b2dsZS5jb20+DQo+IHdyb3RlOg0KPiANCj4gQXJlIHRoZXNlIHByb2JlcyBtYWRlIHRvIGFuIElQ djYtb25seSBob3N0bmFtZT8gSWYgc28sIHRoZW4gb2YgY291cnNlIHdlJ2QNCj4gZXhwZWN0IE9T ZXMgdG8gYXR0ZW1wdCA2dG80Lg0KPiANCj4gWWVzIGFuZCB5ZXMuIEkgdGhvdWdodCBhYm91dCBw cnVuaW5nLCBhbmQgZGVjaWRlZCB0byBtYWtlIGl0IGNvbXBsZXRlLiBJdHMNCj4gY2VydGFpbmx5 IG5vdCBhIHN0cm9uZyByZWZsZWN0aW9uIG9mIHRoZSByZWFsIHdvcmxkIGR5bmFtaWMsIGJ1dCBp dCBzaG93cyBob3cNCj4gbWFueSBwZW9wbGUgYXJlIHN0aWxsIHNpdHRpbmcgb24gdmVzdGlnaWFs IDZ0bzQgdGVjaG5vbG9neSB3aGljaCBjYW4gYmUgd29rZW4uDQo+IFNpbmNlIHdlIGtub3cgc29t ZSBJU1BzIGhhZCBkZXBsb3ltZW50IG1vZGVscyB3aGljaCBpbmNsdWRlZCB0aGlzLCBJdHMgbm90 DQo+IHN1cnByaXNpbmcuDQo+IA0KPiBGdW5jdGlvbmFsbHkgaXRzIGRlYWQgdGVjaG5vbG9neS4g QnV0IGl0cyB6b21iaWUgZGVhZC4gbm90IHN0b25lLWNvbGQuDQo+IA0KPiAtRw0KPiANCj4gDQo+ IA0KPiANCj4gPg0KPiA+T24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTI6MzUgUE0sIEJyaWFuIEUg Q2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ ID5NZWFzdXJhYmxlLCBpbmRlZWQuDQo+ID4+DQo+ID4+V2luZG93cyA4PyBSZWFsbHk/DQo+ID4+ DQo+ID4+UmVnYXJkcw0KPiA+PiAgIEJyaWFuDQo+ID4+DQo+ID4+DQo+ID4+T24gMjcvMDEvMjAx NSAxNTowNywgR2VvcmdlIE1pY2hhZWxzb24gd3JvdGU6DQo+ID4+PiBBc2sgYW5kIHllIHNoYWxs IHJlY2VpdmUNCj4gPj4+DQo+ID4+PiBIZXJlIGlzIGEgZGF5cyBzdW1tYXJ5IG9mIG9zLCBicm93 c2VyLCBvcyticm93c2VyIGFzIGRldGVybWluZWQgYnkNCj4gPj4+IHRoZSBBUE5JQyAxeDEgY2Fw dHVyZSwgdXNpbmcgMjAwMjogYXMgdGhlIHNvdXJjZSBJUHY2IGFkZHJlc3MsIGFuZA0KPiA+Pj4g dGhlIFB5dGhvbiBodHRwYWdlbnRwYXJzZXIgbW9kdWxlIHRvIGRldGVjdCBPUyBhbmQgVmVyc2lv biBpbmZvLg0KPiA+Pj4NCj4gPj4+IC1HZW9yZ2UNCj4gPj4+DQo+ID4+PiBvcyxXaW5kb3dzKzcs MjIyODcNCj4gPj4+IG9zLFdpbmRvd3MrOC4xLDE3NDMNCj4gPj4+IG9zLFdpbmRvd3MrVmlzdGEs OTM5DQo+ID4+PiBvcyxXaW5kb3dzKzgsODk0DQo+ID4+PiBvcyxXaW5kb3dzK1hQLDQzMQ0KPiA+ Pj4gb3MsTWFjaW50b3NoK1tuYV0sMTI0DQo+ID4+PiBvcyxpT1MrW25hXSw0NA0KPiA+Pj4gb3Ms TGludXgrW25hXSwyOQ0KPiA+Pj4gb3MsV2luZG93cytOVCA2LjQsNg0KPiA+Pj4gb3MsV2luZG93 cyBQaG9uZSs4LjEsMg0KPiA+Pj4gb3MsQ2hyb21lT1MrNjMxMC42OC4wLDINCj4gPj4+DQo+ID4+ PiBicm93c2VyLENocm9tZSwxODI5Nw0KPiA+Pj4gYnJvd3NlcixGaXJlZm94LDM3NzQNCj4gPj4+ IGJyb3dzZXIsTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVyLDI4NzINCj4gPj4+IGJyb3dzZXIs T3BlcmEsMTQzOQ0KPiA+Pj4gYnJvd3NlcixTYWZhcmksMTEwDQo+ID4+PiBicm93c2VyLEFuZHJv aWRCcm93c2VyLDUNCj4gPj4+IGJyb3dzZXIsW25hXSwyDQo+ID4+PiBicm93c2VyLFNlYU1vbmtl eSwyDQo+ID4+Pg0KPiA+Pj4gb3MrYnJvd3NlcixXaW5kb3dzKzcuQ2hyb21lLDE1NTM5DQo+ID4+ PiBvcyticm93c2VyLFdpbmRvd3MrNy5GaXJlZm94LDMwMzMNCj4gPj4+IG9zK2Jyb3dzZXIsV2lu ZG93cys3Lk1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3JlciwyNDMyDQo+ID4+PiBvcyticm93c2Vy LFdpbmRvd3MrOC4xLkNocm9tZSwxMzA1DQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrNy5PcGVy YSwxMjc3DQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrOC5DaHJvbWUsNjQ0DQo+ID4+PiBvcyti cm93c2VyLFdpbmRvd3MrVmlzdGEuQ2hyb21lLDUzNw0KPiA+Pj4gb3MrYnJvd3NlcixXaW5kb3dz KzguMS5GaXJlZm94LDMxMQ0KPiA+Pj4gb3MrYnJvd3NlcixXaW5kb3dzK1Zpc3RhLk1pY3Jvc29m dCBJbnRlcm5ldCBFeHBsb3JlciwyMzANCj4gPj4+IG9zK2Jyb3dzZXIsV2luZG93cytYUC5DaHJv bWUsMjE2DQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrVmlzdGEuRmlyZWZveCwxNDgNCj4gPj4+ IG9zK2Jyb3dzZXIsV2luZG93cytYUC5GaXJlZm94LDEzNA0KPiA+Pj4gb3MrYnJvd3NlcixXaW5k b3dzKzguRmlyZWZveCwxMTYNCj4gPj4+IG9zK2Jyb3dzZXIsV2luZG93cys4Lk1pY3Jvc29mdCBJ bnRlcm5ldCBFeHBsb3Jlciw4Nw0KPiA+Pj4gb3MrYnJvd3NlcixXaW5kb3dzKzguMS5PcGVyYSw2 NA0KPiA+Pj4gb3MrYnJvd3NlcixXaW5kb3dzKzguMS5NaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9y ZXIsNjMNCj4gPj4+IG9zK2Jyb3dzZXIsTWFjaW50b3NoK1tuYV0uU2FmYXJpLDYwDQo+ID4+PiBv cyticm93c2VyLFdpbmRvd3MrWFAuTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVyLDU0DQo+ID4+ PiBvcyticm93c2VyLFdpbmRvd3MrOC5PcGVyYSw0NQ0KPiA+Pj4gb3MrYnJvd3NlcixpT1MrW25h XS5TYWZhcmksNDQNCj4gPj4+IG9zK2Jyb3dzZXIsTWFjaW50b3NoK1tuYV0uQ2hyb21lLDM2DQo+ ID4+PiBvcyticm93c2VyLFdpbmRvd3MrWFAuT3BlcmEsMjUNCj4gPj4+IG9zK2Jyb3dzZXIsV2lu ZG93cytWaXN0YS5PcGVyYSwyNA0KPiA+Pj4gb3MrYnJvd3NlcixNYWNpbnRvc2grW25hXS5GaXJl Zm94LDI0DQo+ID4+PiBvcyticm93c2VyLExpbnV4K1tuYV0uQ2hyb21lLDE2DQo+ID4+PiBvcyti cm93c2VyLExpbnV4K1tuYV0uRmlyZWZveCw4DQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrNy5T YWZhcmksNg0KPiA+Pj4gb3MrYnJvd3NlcixMaW51eCtbbmFdLkFuZHJvaWRCcm93c2VyLDUNCj4g Pj4+IG9zK2Jyb3dzZXIsV2luZG93cytOVCA2LjQuTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVy LDQNCj4gPj4+IG9zK2Jyb3dzZXIsTWFjaW50b3NoK1tuYV0uT3BlcmEsNA0KPiA+Pj4gb3MrYnJv d3NlcixXaW5kb3dzK1hQLlNlYU1vbmtleSwyDQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrTlQg Ni40LkNocm9tZSwyDQo+ID4+PiBvcyticm93c2VyLFdpbmRvd3MrOC5bbmFdLDINCj4gPj4+IG9z K2Jyb3dzZXIsV2luZG93cyBQaG9uZSs4LjEuTWljcm9zb2Z0IEludGVybmV0IEV4cGxvcmVyLDIN Cj4gPj4+IG9zK2Jyb3dzZXIsQ2hyb21lT1MrNjMxMC42OC4wLkNocm9tZSwyDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IE9uIFR1ZSwgSmFuIDI3LCAyMDE1IGF0IDk6MzEgQU0sIE1hcmsgWlpaIFNtaXRo DQo+ID4+PiA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4NCj4gPj4+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+PiBJJ20gZmluZSB3aXRoIHRoYXQuDQo+ID4+Pj4NCj4gPj4+PiBJZiBpdCBpcyBlYXN5 IGVub3VnaCwgSSB0aGluayBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBnZXQgYSBiaXQNCj4g Pj4+PiBtb3JlIG9mIGFuIGluc2lnaHQgaW50byB3aG8vd2hhdCBpcyBzdGlsbCB1c2luZyA2dG80 IGVpdGhlciBpbg0KPiA+Pj4+IHByZWZlcmVuY2UgdG8gb3IgaW4NCj4gPj4+PiAoSEUpIHBhcmFs bGVsIHRvIG5hdGl2ZSBJUHY0IGJ5IGUuZy4sIGNvbGxlY3RpbmcgVXNlci1BZ2VudCBmb3IgNnRv NCB1c2Vycy4NCj4gPj4+Pg0KPiA+Pj4+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+Pj4gICpGcm9tOiogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+DQo+ ID4+Pj4gKlRvOiogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+DQo+ ID4+Pj4gKkNjOiogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bT47IFRvcmUNCj4gPj4+PiBBbmRlcnNvbiA8IHRvcmVAZnVkLm5vPjsgInY2b3BzQGlldGYub3Jn IiA8djZvcHNAaWV0Zi5vcmc+DQo+ID4+Pj4gKlNlbnQ6KiBXZWRuZXNkYXksIDIxIEphbnVhcnkg MjAxNSwgMjM6MTYNCj4gPj4+Pg0KPiA+Pj4+ICpTdWJqZWN0OiogUmU6IFt2Nm9wc10gZHJhZnQt aWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljIFdHTEMNCj4gPj4+Pg0KPiA+Pj4+IFllcywgdGhv c2UgdXNlcnMgd2lsbCBkZWZpbml0ZWx5IGJlIGltcGFjdGVkLiBXaGljaCBpcyB3aHkgdGhlDQo+ ID4+Pj4gZG9jdW1lbnQgZG9lcyBub3Qgc3VnZ2VzdCBkcm9wcGluZyB0aGUgcGFja2V0cyBvciB0 dXJuaW5nIG9mZiB0aGUNCj4gPj4+PiByZWxheXMsIGV4Y2VwdCBieSBzYXlpbmcgdGhpbmdzIGxp a2UgIm9wZXJhdG9ycyBTSE9VTEQgWy4uLl0NCj4gPj4+PiBjb25zaWRlciBjYXJlZnVsbHkgd2hl dGhlciB0aGUgWy4uLl0gcmVsYXkgY2FuIGJlIGRpc2NvbnRpbnVlZCBhcw0KPiA+Pj4+IHRyYWZm aWMgZGltaW5pc2hlcyIuIFRoYXQncyBxdWl0ZSByZWFzb25hYmxlIGd1aWRhbmNlLCBJIHRoaW5r Lg0KPiA+Pj4+DQo+ID4+Pj4gUmVtZW1iZXI6IDAuMDElIGlzIHJlYWxseSBhIHZlcnkgc21hbGwg bnVtYmVyLiBNdWx0aXBseWluZyBpdCBieSAxDQo+ID4+Pj4gYmlsbGlvbiAobGlrZSBCcmlhbiBk aWQpIG1ha2VzIGl0IHNlZW0gbGFyZ2UsIGJ1dCB0aGF0J3MganVzdCBhIHRyaWNrIG9mIHRoZQ0K PiBsaWdodC4NCj4gPj4+PiBMb29rIGF0IGl0IHRoaXMgd2F5OiBpZiBhbGwgdGhlIHJlbGF5cyBp biB0aGUgd29ybGQgd2VyZSB0dXJuZWQgb2ZmDQo+ID4+Pj4gb3Zlcm5pZ2h0IGFuZCBhbGwgdGhl IDZ0bzQgdXNlcnMgd2VyZSB1bmFibGUgdG8gcmVhY2ggYSBnaXZlbg0KPiA+Pj4+IHdlYnNpdGUs IHRoYXQgd2Vic2l0ZSdzIHJlbGlhYmlsaXR5IHdvdWxkIHN0aWxsIGJlIDk5Ljk5JSBvZiB3aGF0 IGl0IHdhcw0KPiBiZWZvcmUuDQo+ID4+Pj4NCj4gPj4+PiBJIHN1cHBvcnQgdGhpcyBkb2N1bWVu dCBpbiBpdHMgY3VycmVudCBmb3JtLiBJIG9ubHkgaGF2ZSB0aHJlZQ0KPiA+Pj4+IGNvbW1lbnRz IGJleW9uZCBzZWNvbmRpbmcgVG9yZSdzIG9iamVjdGlvbiB0byB0aGUgZHJhZnQgY2FsbGluZyA2 dG80DQo+ICJzdWJzdGFudGlhbCI6DQo+ID4+Pj4NCj4gPj4+PiAgICAxLiBJcyBpdCBuZWNlc3Nh cnkgdG8gZm9ybWFsbHkgZGVwcmVjYXRlIFJGQyA2NzMyPyBJdCdzIGFuIGluZGl2aWR1YWwNCj4g Pj4+PiAgICBzdWJtaXNzaW9uLiAoTm90IHRoYXQgSSBzdXBwb3J0IFJGQyA2NzMyIGluIGFueSB3 YXksIHRvIGJlIHN1cmUuKQ0KPiA+Pj4+ICAgIDIuIEkgZG9uJ3QgdGhpbmsgdGhlIHNlbnRlbmNl ICJzb21lIGNvbnRlbnQgcHJvdmlkZXJzIGhhdmUgYmVlbg0KPiA+Pj4+ICAgIHJlbHVjdGFudCB0 byBtYWtlIGNvbnRlbnQgYXZhaWxhYmxlIG92ZXIgSVB2NiIgaXMgdHJ1ZSwgb3IgYXQgbGVhc3Qg YW55DQo+ID4+Pj4gICAgdHJ1ZSBmb3IgYW55IG5vbi10cml2aWFsIHZhbHVlIG9mICJzb21lIi4g NnRvNCB3YXMgYSBwcm9ibGVtIGZvciBjb250ZW50DQo+ID4+Pj4gICAgcHJvdmlkZXJzIGEgZmV3 IHllYXJzIGFnbywgYnV0IHdlJ3ZlIG1vdmVkIHBhc3QgaXQuDQo+ID4+Pj4gICAgMy4gSXQgbWln aHQgYmUgdXNlZnVsIHRvIGNpdGUgdGhhdCBhbm90aGVyIHJlYXNvbiA2dG80IGlzIGJlaW5nDQo+ ID4+DQo+ID4+Pj4gICAgZGVwcmVjYXRlZCBpcyB0aGF0IElQdjYgaXMgYWN0dWFsbHkgYmVpbmcg ZGVwbG95ZWQgdGhlc2UgZGF5cyAoZmluYWxseSkuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+PiBPbiBXZWQsIEphbiAyMSwgMjAxNSBhdCA5OjMwIEFNLCBNYXJrIFpaWiBT bWl0aA0KPiA+Pj4+IDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1DQo+ID4+Pj4+IHdyb3RlOg0K PiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4+Pj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4NCj4gPj4+PiBUbzogVG9yZSBBbmRlcnNvbiA8dG9yZUBm dWQubm8+OyB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4+IENjOg0KPiA+Pj4+IFNlbnQ6IFdlZG5lc2Rh eSwgMjEgSmFudWFyeSAyMDE1LCA3OjE0DQo+ID4+Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljIFdHTEMNCj4gPj4+Pg0KPiA+Pj4+IE9uIDIx LzAxLzIwMTUgMDI6MTYsIFRvcmUgQW5kZXJzb24gd3JvdGU6DQo+ID4+Pj4+ICogZnJlZEBjaXNj by5jb20NCj4gPj4+Pj4NCj4gPj4+Pj4+IFRoaXMgaXMgdG8gaW5pdGlhdGUgYSBvbmUgd2VlayB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvZg0KPiA+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljLg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBJIGhhdmUgcmVhZCB0aGlzIGRvY3VtZW50LCBhbmQgSSB0aGluayBpdCBpcyByZWFkeSB0byBt b3ZlIGZvcndhcmQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0cyBvcGVyYXRpb25hbCBuZWVkIGZvciB0 aGlzIGRvY3VtZW50IGlzIGxlc3MgcHJlc3Npbmcgbm93IHRoYW4NCj4gPj4+Pj4gd2hlbiB0aGUg LTAwIHZlcnNpb24gd2FzIHB1Ymxpc2hlZCBiYWNrIGluIDIwMTEuIE5ldmVydGhlbGVzcywgSQ0K PiA+Pj4+PiBmaW5kIGl0IHZhbHVhYmxlIGFuZCBjb3JyZWN0IHRvIHB1dCB0aGUgZmluYWwgbmFp bCBpbiA2dG80J3MNCj4gPj4+Pj4gY29mZmluIGF0IHRoaXMgcG9pbnQgaW4gdGltZS4gV2hpbGUg dGhlIG9wZXJhdGlvbmFsIGNvbW11bml0eSBmb3INCj4gPj4+Pj4gdGhlIG1vc3QgcGFydCBoYXMg YWxyZWFkeSByZWFsaXNlZCB0aGF0IDZ0bzQgaGFzIG5vIGZ1dHVyZSwgdGhlcmUNCj4gPj4+Pj4g bWlnaHQgYmUgc29tZSB3aG8gaGF2ZSBub3QgYmVlbiBwYXlpbmcgYXR0ZW50aW9uIGFuZCBmb3Jt YWwNCj4gPj4+Pj4gZGVwcmVjYXRpb24gb2YgdGhlIHByb3RvY29sIG1heSBoZWxwIHByZXZlbnQg dGhlbSBmcm9tIG1ha2luZyB0aGUNCj4gPj4+Pj4gbWlzdGFrZSBvZiBhdHRlbXB0aW5nIHRvIGJh c2UgcHJvZHVjdGlvbiBzeXN0ZW1zIG9uIGl0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGhhdmUgb25l IG1pbm9yIGNvbW1lbnQgdGhvdWdoOiBJbiBzZWN0aW9uIDEsIGl0IHNheXMgwqthDQo+ID4+Pj4+ IHN1YnN0YW50aWFsIGFtb3VudCBvZiA2dG80IHRyYWZmaWMgaXMgc3RpbGwgb2JzZXJ2ZWQgYnkg SVB2NiBjb250ZW50DQo+IHByb3ZpZGVyc8K7Lg0KPiA+Pj4+PiBXaGlsZSBJIGRvIHNlZSA2dG80 IHRyYWZmaWMsIGl0IGlzIHF1aXRlIGZhciBmcm9tIGJlaW5nIG9mICJzdWJzdGFudGlhbCINCj4g Pj4+Pj4gbGV2ZWxzLiBJIHdvdWxkIHRoZXJlZm9yZSByZWNvbW1lbmQgcmVwbGFjaW5nICJzdWJz dGFudGlhbCIgd2l0aA0KPiA+Pj4+PiBzb21ldGhpbmcgbWlsZGVyIGxpa2UgIm5vdGljZWFibGUi LCAibWVhc3VyYWJsZSIsIG9yIHNvbWV0aGluZw0KPiA+Pj4+PiBhbG9uZyB0aG9zZSBsaW5lcy4N Cj4gPj4+Pj4NCj4gPj4+Pj4gRm9yIHdoYXQgaXQncyB3b3J0aCwgdG9kYXkgdGhlIEdvb2dsZSBw dWJsaWMgSVB2NiBncmFwaCBzaG93cyBqdXN0DQo+ID4+Pj4+IGEgbWVhc2x5IDAuMDElIG9mIHRo ZWlyIHRvdGFsIElQdjYgdHJhZmZpYyBiZWluZyBUZXJlZG8vNnRvNCwgc28NCj4gPj4+Pj4gaXQn cyBub3QganVzdCBtZS4NCj4gPj4+Pg0KPiA+Pj4+ICJUb3JlLA0KPiA+Pj4+DQo+ID4+Pj4gSG93 ZXZlciwgdGhhdCBmcmFjdGlvbiBvZiBHb29nbGUgdHJhZmZpYyBtdWx0aXBsZWQgYnkgR29vZ2xl IHVzZXJzDQo+ID4+Pj4gcmVwcmVzZW50cyBzb21ldGhpbmcgbGlrZSAxMDAwMDAgdXNlcnMuIEkg ZG9uJ3QgdGhpbmsgd2UgY2FuDQo+ID4+Pj4gZGlzbWlzcyB0aGF0IG51bWJlciBvZiBwZW9wbGUg dG9vIGVhc2lseS4gSXQncyBhIG1hdHRlciBvZiB0YXN0ZQ0KPiA+Pj4+IHdoZXRoZXIgdGhhdCdz ICJzdWJzdGFudGlhbCIgb3IgIm5vdGljZWFibGUiLg0KPiA+Pj4+DQo+ID4+Pj4gICAgIEJyaWFu Ig0KPiA+Pj4+DQo+ID4+Pj4gQWN0dWFsbHksIHRvIHRob3NlIGVuZCB1c2VycywgdGhlIGltcGFj dCBtaWdodCBiZSBib3RoIHF1aXRlDQo+ID4+Pj4gc2lnbmlmaWNhbnQgYW5kIG5vdGljZWFibGUu DQo+ID4+Pj4NCj4gPj4+PiBJIHRoaW5rIG9uZSBleHBsYW5hdGlvbiBmb3IgdGhlIHVzZSBvZiA2 dG80IHR1bm5lbGxlZCBJUHY2IGlzIHRoYXQNCj4gPj4+PiB0aGVpciBob3N0cyBhcmVuJ3QgcHJl ZmVycmluZyBuYXRpdmUgSVB2NCBvdmVyIHR1bm5lbGxlZCBJUHY2DQo+ID4+Pj4gKGFzc3VtaW5n IEdvb2dsZSBtYWtlIHRoZWlyIHNlcnZpY2VzIGVxdWFsbHkgYXZhaWxhYmxlIG92ZXIgYm90aCwN Cj4gPj4+PiB3aGljaCBJIHRoaW5rIHRoZXkgZG8pLCBhcyBwZXIgUkZDMzQ4NCBhZGRyZXNzIHNl bGVjdGlvbiBydWxlcy4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBvdGhlciBleHBsYW5hdGlvbiBmb3Ig aXQgY291bGQgYmUgdGhhdCB0aGVzZSB1c2VycyBoYXZlIEhhcHB5DQo+ID4+Pj4gRXllYmFsbHMg ZW5hYmxlZCBicm93c2VycyBhbmQgdGhlIGJyb3dzZXIgaXMgY2hvb3NpbmcgdG8gdHJ5IHRvIHVz ZQ0KPiA+Pj4+IGJvdGggSVB2NCBhbmQgSVB2NiwgZGVzcGl0ZSB0aGUgSVB2NiBiZWluZyB0dW5u ZWxsZWQgcmF0aGVyIHRoYW4NCj4gPj4+PiBuYXRpdmUuIEZyb20gYSBIYXBweSBFeWViYWxscyBy b2J1c3RuZXNzIHBlcnNwZWN0aXZlLCB0aGF0IHdvdWxkIGJlDQo+ID4+Pj4gcXVpdGUgYSByZWFz b25hYmxlIHRoaW5nIHRvIGRvIEkgdGhpbmsuDQo+ID4+Pj4NCj4gPj4+PiBJZiB0aGUgZW5kLWhv c3RzIGFyZW4ndCBmb2xsb3dpbmcgUkZDMzQ4NCdzIGRlZmF1bHQgcHJlZmVyZW5jZXMsDQo+ID4+ Pj4gdGhlbiBicmVha2luZyA2dG80IG1pZ2h0IGNhdXNlIHRoZSBzb3J0cyBvZiB0aW1lb3V0cyB0 aGF0IEhFIGlzDQo+ID4+Pj4gZGVzaWduZWQgdG8gb3ZlcmNvbWUuIFJGQzM0ODQgaXMgcXVpdGUg b2xkIG5vdyAoMjAwMyksIGFuZCBhcyBhDQo+ID4+Pj4gbWlub3IgZGF0YSBwb2ludCBJIGZpcnN0 IGVuY291bnRlcmVkIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGVtIGluDQo+ID4+Pj4gYXJvdW5k IDIwMDgvMjAwOSBpZiBJIHJlY2FsbCBjb3JyZWN0bHkgb24gbXkgTGludXggc3lzdGVtIChhcyBJ IHdhcw0KPiA+Pj4+IHVzaW5nIDZ0bzQgYXQgdGhlIHRpbWUgYW5kIHdhbnRlZCB0byB1c2UgdHVu bmVsbGVkIElQdjYgaW4NCj4gPj4+PiBwcmVmZXJlbmNlIHRvIG5hdGl2ZSBJUHY0IC0gZ2FpLmNv bmYoMykgaXMgdGhlIHdheSB5b3UgY2hhbmdlDQo+ID4+Pj4gdGhhdCkuIFNvIGlmIHNvbWUgaG9z dHMgYXJlIHN0aWxsIHByZWZlcnJpbmcgdHVubmVsbGVkDQo+ID4+Pj4gNnRvNCBJUHY2IG92ZXIg bmF0aXZlIElQdjQgdGhlbiBwZXJoYXBzIHRoZXkncmUgYWxzbyBub3QgZ29pbmcgdG8NCj4gPj4+ PiBiZSBydW5uaW5nIGEgSEUgZW5hYmxlZCBicm93c2VyIGVpdGhlci4NCj4gPj4+Pg0KPiA+Pj4+ IFBlcmhhcHMgaXQgbWlnaHQgYmUgcG9zc2libGUgZm9yIHNvbWVib2R5IGF0IEdvb2dsZSB0byBw cm9kdWNlIGENCj4gPj4+PiBsaXN0IG9mIHRoZSBicm93c2VyIFVzZXItQWdlbnQgc3RyaW5ncyBm b3IgcGVvcGxlIHN0aWxsIHVzaW5nIDZ0bzQNCj4gPj4+PiB0byBzZWUgaWYgdGhlIGJyb3dzZXJz IGJlaW5nIHVzZWQgYXJlIEhFIGVuYWJsZWQsIHdoaWNoIG1pZ2h0IGFsc28NCj4gPj4+PiBnaXZl IHNvbWUgaW5zaWdodCBpbnRvDQo+ID4+Pj4gUkZDMzQ4NCBzdXBwb3J0IGluIHRoZSB1bmRlcmx5 aW5nIE9TZXMuDQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzLA0KPiA+Pj4+IE1hcmsuDQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gdjZv cHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pj4NCj4gPj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IHY2b3BzIG1h aWxpbmcgbGlzdA0KPiA+Pj4+IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+Pj4+IHY2b3BzQGlldGYu b3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K PiA+Pj4+DQo+ID4+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gPj4+IHY2b3BzQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pg0KPiA+Pg0KPiA+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+djZvcHMgbWFpbGluZyBsaXN0DQo+ID4+ djZvcHNAaWV0Zi5vcmcNCj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQo+ID4+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Wed Feb 4 05:20:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF981A87CC for ; Wed, 4 Feb 2015 05:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7GsA58d0old for ; Wed, 4 Feb 2015 05:20:27 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED6C1A00E4 for ; Wed, 4 Feb 2015 05:20:27 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id B8642DA0181 for ; Wed, 4 Feb 2015 13:20:27 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8EE8653E086; Wed, 4 Feb 2015 05:20:27 -0800 (PST) Received: from [172.21.196.201] (64.110.2.19) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 4 Feb 2015 05:20:27 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 4 Feb 2015 06:20:24 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <337FCBBB-9C1A-498D-A816-94ED8DA911C2@nominum.com> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> <3309_1423039531_54D1DC2B_3309_7566_1_cc902962-a4e4-4dc6-899a-b9ba3cfab534@OPEXCLILH05.corporate.adroot.infra.ftgroup> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.110.2.19] Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:20:30 -0000 On Feb 4, 2015, at 1:52 AM, Lorenzo Colitti wrote: > Well, but on the other hand, there's an expression in English my = mother always used to use. "Those who can, do. Those who can't, teach". = :-) It would not be unwelcome if we were to avoid casting aspersions on the = practitioners of various important, difficult and often thankless = professions as we continue the discussion about this document. From nobody Wed Feb 4 08:12:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08431A6F12 for ; Wed, 4 Feb 2015 08:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBi9E9ArqnX7 for ; Wed, 4 Feb 2015 08:12:14 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCA81A0404 for ; Wed, 4 Feb 2015 08:12:14 -0800 (PST) Received: from mb-aye.local ([192.252.247.9]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t14GC9kL094963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Feb 2015 16:12:10 GMT (envelope-from joelja@bogus.com) Message-ID: <54D244D8.9050709@bogus.com> Date: Wed, 04 Feb 2015 10:12:08 -0600 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Erik Kline References: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> In-Reply-To: <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AfGVuSi3Tcx2BC8mwViMLABGrbthtQktL" Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:12:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AfGVuSi3Tcx2BC8mwViMLABGrbthtQktL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/3/15 9:48 PM, Fred Baker (fred) wrote: >=20 >> On Feb 3, 2015, at 7:12 PM, Erik Kline wrote: >>=20 >>> WGLC; on its way to IESG: Feb 1 >>> draft-ietf-v6ops-mobile-device-profile >>=20 >> Are you implying that this would be on the agenda for discussion >> in Dallas, or is it past that point now and its being past >> discussion is what would appear on a slide? :) >=20 > If we=E2=80=99re still talking about it, we should finalize it there. W= e do > need to decide what its status is. >=20 >>> Individual Submission NOT updated since IETF: >>>=20 >>> Aug 24 draft-v6ops-pmtud-ecmp-problem >>=20 >> I've seen this draft be usefully referred to a couple of times in >> the last few months. +1 to keeping it afloat, if not moving >> forward for some reason (cc'ing Joel explicitly). >=20 > Up to Joel. If folks tell us it should be a working group draft, it > can be resubmitted as draft-ietf-v6ops-pmtud-ecmp-problem, following > the naming guideline that IETF tools depend on. Or whatever. I am happy to undertake a revision, or encourage my co-authors to do so. I throw myself at the mercy of the chairs with respect to the title. joel --AfGVuSi3Tcx2BC8mwViMLABGrbthtQktL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTSRNkACgkQ8AA1q7Z/VrJP8ACfaOBZmECY29LAYBDTtGcv9iOD 0J8AnR+HfmKYkPoc8OegjEqaLvc07HOn =YYL0 -----END PGP SIGNATURE----- --AfGVuSi3Tcx2BC8mwViMLABGrbthtQktL-- From nobody Wed Feb 4 13:55:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2181A8997; Wed, 4 Feb 2015 13:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF6pXcxleD_s; Wed, 4 Feb 2015 13:55:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0821D1A888B; Wed, 4 Feb 2015 13:55:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150204215521.20810.26259.idtracker@ietfa.amsl.com> Date: Wed, 04 Feb 2015 13:55:21 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Deprecating Anycast Prefix for 6to4 Relay Routers) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 21:55:22 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Deprecating Anycast Prefix for 6to4 Relay Routers' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that when used in its anycast mode, the mechanism is unsuitable for widespread deployment and use in the Internet. This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 4 15:26:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E661A0024 for ; Wed, 4 Feb 2015 15:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.202 X-Spam-Level: *** X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSsTFY43r0o4 for ; Wed, 4 Feb 2015 15:26:54 -0800 (PST) Received: from nm42-vm7.bullet.mail.ne1.yahoo.com (nm42-vm7.bullet.mail.ne1.yahoo.com [98.138.121.63]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB381A0011 for ; Wed, 4 Feb 2015 15:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423092413; bh=SLWmShtgZVMuINz85We7cl1FumQdeBHbnwlECRxJ3O8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=FXh6YxJv5QPIhcAHu0N1/ZFuw3BD07IRKve8TptQilku2MGzmxJHn2WHKtOgjdVK7Acf1i+cIT1P04NdBqZroxZQ7RmE5MazvQ5DTAwlKqsasuT2MGfe6gxvRvx4re47wKY2ywYQc/pVYQ6ZHedARPdwU2W1UNiRVyk7I1YEXPZQ9wifqFXFQnQuzHwso3/NM0uHRFqM7/smATFYQ9cYOpsj4MuPy5tOfaHT+u/ORPD7ni2s5tO8FfgvoVa0HFbdEotVR9y9+YZxbSORRxkLY4hRSdaIN2+3THq6nLE7XKcQ0M2iOaT+eZCbe0Lm5UIe9bVd3gyF7WlDur/SCNRnHA== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:26:53 -0000 Received: from [98.138.100.112] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:24:01 -0000 Received: from [98.139.215.142] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:24:01 -0000 Received: from [98.139.212.246] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 23:24:01 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 23:24:01 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 187703.94335.bm@omp1055.mail.bf1.yahoo.com X-YMail-OSG: t0R8HwAVM1l.3cT9.9ZsW0AZlxggJrCduiuX5gKdtxhxOxkCGxO8VAt7RktJdoV tlOkDxOhbJEIF.gtoc011AiU1AW6xl6yeOKHjVKJ4IFKzpiZSUM_tvESLD7l5Q4Op7O4xdaG7aAJ RK0F8O0W9Zhe0wP.A6bn3WtUsCTW.eLRcEI92qelslP1bPilxoNb2C75vc3rpAjuj9V2Mo6Ogim9 eRPwferpdMVKmM.qvsfterMFZHF9TF6K7H1LHjLbzy15Uwf6VqgR_UYkXZhQPvRq2Gz4cWHioHs_ bs3yahLfy403D8fHjOR.40cNIXPKk34pozJYZZLv3vQtC.YlVb4I5S0fdznLRDNT6YB_jcr2YauU _84.u4qsX4WnboQFBYuJRKloDf87rqDfe.49JAnPMRY_PfUytin7cFS1eVM1LHFkn6MdrzehguFD iVz1nqHItfn5._hBanVJsPM7gdJcBaYu0H_6Ma5SSlm.ztGRyJrIkGUtaKBfiYya1vLwGyY1r6Bc aPjV8VvsaJ88LJklpzoIuPKVBwy1H717Z1Zma2GmyOAkJjDPShEN6GdzL Received: by 76.13.27.55; Wed, 04 Feb 2015 23:24:00 +0000 Date: Wed, 4 Feb 2015 23:23:59 +0000 (UTC) From: Mark ZZZ Smith To: Lorenzo Colitti Message-ID: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2415572_1962542060.1423092240084" Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:26:55 -0000 ------=_Part_2415572_1962542060.1423092240084 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable While I appreciate that the draft isn't advising to block 6to4, I think it = would be useful to gain some more detailed insight into the consequences of= blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending on = the results, it may also mean that making a strong statement not to block 6= to4 traffic in the draft would be beneficial, reinforcing what is in RFC634= 3. Indirectly I think it would also be a measure of the deployment of the RFC3= 484/RFC6724 rules on various OSes.=C2=A0 From: Lorenzo Colitti To: Mark ZZZ Smith =20 Cc: George Michaelson ; Brian E Carpenter ; "v6ops@ietf.org" ; Tore Anderson =20 Sent: Wednesday, 4 February 2015, 11:18 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC =20 On Wed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith = wrote: Would it be possible to conduct the same test with a dual stack site? What would we learn from such an exercise? The OS / user-agent breakdown of= the 0.01% of hosts that use 6to4 when talking to dual-stack destinations? = Even if we knew that, what would we do with it? ------=_Part_2415572_1962542060.1423092240084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While I appreciate that the draft isn't advising to= block 6to4, I think it would be useful to gain some more detailed insight = into the consequences of blocking 6to4 (i.e., which OSes/browsers might be = impacted). Depending on the results, it may also mean that making a strong = statement not to block 6to4 traffic in the draft would be beneficial, reinf= orcing what is in RFC6343.

Indirectly I think it would also be a measure of the deployment of the = RFC3484/RFC6724 rules on various OSes. 

From: Lorenzo Colitti <lorenzo@g= oogle.com>
To: Mark= ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: George Michaelson <ggm@algebras.org>; Bria= n E Carpenter <brian.e.carpenter@gmail.com>; "v6ops@ietf.org" <v6o= ps@ietf.org>; Tore Anderson <tore@fud.no>
Sent: Wednesday, 4 February 2015, 11:18
<= b>Subject: Re: [v6ops] draft-= ietf-v6ops-6to4-to-historic WGLC



<= div class=3D"yiv5646391431yqt6353621006" id=3D"yiv5646391431yqtfd97181">On Wed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith <markzzzsmith@ya= hoo.com.au> wrote:
Would it be possible to conduct the same test with a d= ual stack site?

What would we learn from such an exercise? The OS / user-agent br= eakdown of the 0.01% of hosts that use 6to4 when talking to dual-stack dest= inations? Even if we knew that, what would we do with it?
=


------=_Part_2415572_1962542060.1423092240084-- From nobody Wed Feb 4 15:41:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0211A0081 for ; Wed, 4 Feb 2015 15:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.402 X-Spam-Level: **** X-Spam-Status: No, score=4.402 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhKe_elXXkxZ for ; Wed, 4 Feb 2015 15:40:57 -0800 (PST) Received: from nm34-vm6.bullet.mail.ne1.yahoo.com (nm34-vm6.bullet.mail.ne1.yahoo.com [98.138.229.86]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C64B1A0076 for ; Wed, 4 Feb 2015 15:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423093256; bh=sHP/g7FrLqmWMKwMfCk4Q1tPOM5AfRa2nxtrbLI1q7o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=sGuCjD0E3zDUNAdpRam3vuV2VL8KFFYR0U/gU8nTEvwxpPwjcB2e/SwdKs7Q9DuN0tb6h8QNT9EGAWL0Ktg5VLlU81FxKAtKaioJmkHcxJIwhfNjTCAKoWMhvQn8qEYHMyk7nrn6QNm0jnCjUWRwkk2yksGcHaX6WA1/OlcJu+Q+ewY7iR6CYHIWnn3nU0RBYYz8SzezlYXySXR+bYL/OAnRgj08L6ybXC/3RhPDQ4L0k1fM+nh7J3cuAhRZcB39Air+dT0YBXMnFSWBsKIr2LpZksExCiTE3BsYUjM3iYyaNAohh3mCehEgnhPHOR/YwnuvGiew0pFfKV9uvMG4wA== Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:40:56 -0000 Received: from [98.138.101.131] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:38:13 -0000 Received: from [66.196.81.171] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2015 23:38:12 -0000 Received: from [98.139.212.199] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 23:38:12 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 23:38:12 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 796878.81537.bm@omp1008.mail.bf1.yahoo.com X-YMail-OSG: J0ADHjUVM1nIhaBm4pZmLLU90N6B8k3hvnDzTeX30xfyewaKnTQS9fI_uJOyLz5 biDTV9aojqFU1MW7Ege0_FYkAhKT02yxKgr07NL6vQQ1HBuSaEhVw8F.zetEqSTfEL4J_3YuhAdT j3NOiDFM1SB57AgowUc2jLHxEs9dC1zZfLDH5uD0i_XUW84Ie_zFzEVQL0joMgGI49r9HJh5oX_u h7.TGyHFF6OLt2YVbPkwdrZ13SwoamJGGyxmPirfnSEGggSokMVgpQbkGzqaZzmA4xHs_yzk_F0e Gs_vPqIc6TOzPqNQBXrVBH1cL7AzNdrDegP0NxMrc.CQ36L8G8WZ09epiNCJZKiu9xZX_0LNPq4Q tLd9EpxWk0vbMCUF1hZYq_eXTsH5LcGQgnUJGzBAIJY8UAPxVQ.HImZvC5f2NhafazL7JM4_j0cH 14UyI0.Bm50rZ_V7CMorJmW5PMK7bOmmYsh71Mv9Ky_E7xdH59XXpXZJm8sh6uHkntvJGrh_mY3k qCKadj9YfykO8Iof_0v1YPrfqwBCIRB4FUlZqnk3c3ONMX76J7Dl7Bkow1A-- Received: by 76.13.27.134; Wed, 04 Feb 2015 23:38:12 +0000 Date: Wed, 4 Feb 2015 23:38:11 +0000 (UTC) From: Mark ZZZ Smith To: "Metzler, Dan J" , George Michaelson , Lorenzo Colitti Message-ID: <332356709.2414725.1423093091734.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2414724_2012949938.1423093091720" Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:41:02 -0000 ------=_Part_2414724_2012949938.1423093091720 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: "Metzler, Dan J" To: Mark ZZZ Smith ; George Michaelson ; Lorenzo Colitti =20 Cc: "v6ops@ietf.org" ; Tore Anderson =20 Sent: Wednesday, 4 February 2015, 23:36 Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC =20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith > Sent: Tuesday, February 3, 2015 5:16 PM > To: George Michaelson; Lorenzo Colitti > Cc: v6ops@ietf.org; Tore Anderson > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >=20 >=20 >=20 >=20 > So this was interesting data, however I've realised that I don't think it= is quite > measuring what I thought it was measuring if the test destination was IPv= 6 > only. If that is the case, then the choice was 6to4 or nothing to use to = access > the IPv6 only destination. >=20 > I think the more interesting case is when the destination is dual stack, = and the > end host has a choice of native IPv4 or 6to4 tunnelled IPv6. A host or > application that chooses 6to4 over native IPv4 isn't following > RFC3484/RFC6724 precedence. They would be the ones impacted by actively > blocking 6to4 traffic somewhere between the host and destination, and tha= t > impact would be visible to the end-user if Happy Eyeball techniques weren= 't > being used.=C2=A0=C2=A0=C2=A0=20 Am I missing something?=C2=A0 Isn't that really flawed logic?=C2=A0 6to4 us= ers that target native IPv6 (non-dual stack) would definitely be impacted b= y blocking 6to4 traffic. The number of targets that are dual stack and still using 6to4 is likely to= be small, and easily fixable.=C2=A0 This seems likely you're trying to ign= ore the relevant population? * Actually, my fear would be that a number of people still using 6to4 might= not know they're using it, because it has been enabled by default on IPv6 = residential CPE when there isn't a native IPv6 service available. In market= s such as Australia, where the customer usually chooses the model of and ow= ns/"operates" the CPE, disabling 6to4 would be beyond most of their capabil= ities. IOW, actions that may break 6to4 may have the greatest impact on the= "technically incompetent", and therefore strong advice not to block 6to4 i= n this draft may be worth providing. * That may be a bit of an unrealistic fear on my behalf, however it seems t= he level of detail the current observations about 6to4 provide are that it = isn't being used much and it isn't reliable. I'm curious to know the next l= evel of detail down - who/what is (still) trying to use it, in particular w= hen native IPv4 should now have been preferred for quite a long time. Or are you really focused on something unrelated? =C2=A0=C2=A0=C2=A0=20 >=20 > Would it be possible to conduct the same test with a dual stack site? >=20 > Thanks, > Mark. > ________________________________ > From: George Michaelson > To: Lorenzo Colitti > Cc: Brian E Carpenter ; Mark ZZZ Smith > ; "v6ops@ietf.org" ; Tore > Anderson > Sent: Tuesday, 27 January 2015, 14:39 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti > wrote: >=20 > Are these probes made to an IPv6-only hostname? If so, then of course we'= d > expect OSes to attempt 6to4. >=20 > Yes and yes. I thought about pruning, and decided to make it complete. It= s > certainly not a strong reflection of the real world dynamic, but it shows= how > many people are still sitting on vestigial 6to4 technology which can be w= oken. > Since we know some ISPs had deployment models which included this, Its no= t > surprising. >=20 > Functionally its dead technology. But its zombie dead. not stone-cold. >=20 > -G >=20 >=20 >=20 >=20 > > > >On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter > wrote: > > > >Measurable, indeed. > >> > >>Windows 8? Really? > >> > >>Regards > >>=C2=A0 Brian > >> > >> > >>On 27/01/2015 15:07, George Michaelson wrote: > >>> Ask and ye shall receive > >>> > >>> Here is a days summary of os, browser, os+browser as determined by > >>> the APNIC 1x1 capture, using 2002: as the source IPv6 address, and > >>> the Python httpagentparser module to detect OS and Version info. > >>> > >>> -George > >>> > >>> os,Windows+7,22287 > >>> os,Windows+8.1,1743 > >>> os,Windows+Vista,939 > >>> os,Windows+8,894 > >>> os,Windows+XP,431 > >>> os,Macintosh+[na],124 > >>> os,iOS+[na],44 > >>> os,Linux+[na],29 > >>> os,Windows+NT 6.4,6 > >>> os,Windows Phone+8.1,2 > >>> os,ChromeOS+6310.68.0,2 > >>> > >>> browser,Chrome,18297 > >>> browser,Firefox,3774 > >>> browser,Microsoft Internet Explorer,2872 > >>> browser,Opera,1439 > >>> browser,Safari,110 > >>> browser,AndroidBrowser,5 > >>> browser,[na],2 > >>> browser,SeaMonkey,2 > >>> > >>> os+browser,Windows+7.Chrome,15539 > >>> os+browser,Windows+7.Firefox,3033 > >>> os+browser,Windows+7.Microsoft Internet Explorer,2432 > >>> os+browser,Windows+8.1.Chrome,1305 > >>> os+browser,Windows+7.Opera,1277 > >>> os+browser,Windows+8.Chrome,644 > >>> os+browser,Windows+Vista.Chrome,537 > >>> os+browser,Windows+8.1.Firefox,311 > >>> os+browser,Windows+Vista.Microsoft Internet Explorer,230 > >>> os+browser,Windows+XP.Chrome,216 > >>> os+browser,Windows+Vista.Firefox,148 > >>> os+browser,Windows+XP.Firefox,134 > >>> os+browser,Windows+8.Firefox,116 > >>> os+browser,Windows+8.Microsoft Internet Explorer,87 > >>> os+browser,Windows+8.1.Opera,64 > >>> os+browser,Windows+8.1.Microsoft Internet Explorer,63 > >>> os+browser,Macintosh+[na].Safari,60 > >>> os+browser,Windows+XP.Microsoft Internet Explorer,54 > >>> os+browser,Windows+8.Opera,45 > >>> os+browser,iOS+[na].Safari,44 > >>> os+browser,Macintosh+[na].Chrome,36 > >>> os+browser,Windows+XP.Opera,25 > >>> os+browser,Windows+Vista.Opera,24 > >>> os+browser,Macintosh+[na].Firefox,24 > >>> os+browser,Linux+[na].Chrome,16 > >>> os+browser,Linux+[na].Firefox,8 > >>> os+browser,Windows+7.Safari,6 > >>> os+browser,Linux+[na].AndroidBrowser,5 > >>> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4 > >>> os+browser,Macintosh+[na].Opera,4 > >>> os+browser,Windows+XP.SeaMonkey,2 > >>> os+browser,Windows+NT 6.4.Chrome,2 > >>> os+browser,Windows+8.[na],2 > >>> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2 > >>> os+browser,ChromeOS+6310.68.0.Chrome,2 > >>> > >>> > >>> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith > >>> > >>> wrote: > >>> > >>>> I'm fine with that. > >>>> > >>>> If it is easy enough, I think it would be interesting to get a bit > >>>> more of an insight into who/what is still using 6to4 either in > >>>> preference to or in > >>>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4= users. > >>>> > >>>>=C2=A0 ------------------------------ > >>>>=C2=A0 *From:* Lorenzo Colitti > >>>> *To:* Mark ZZZ Smith > >>>> *Cc:* Brian E Carpenter ; Tore > >>>> Anderson < tore@fud.no>; "v6ops@ietf.org" > >>>> *Sent:* Wednesday, 21 January 2015, 23:16 > >>>> > >>>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >>>> > >>>> Yes, those users will definitely be impacted. Which is why the > >>>> document does not suggest dropping the packets or turning off the > >>>> relays, except by saying things like "operators SHOULD [...] > >>>> consider carefully whether the [...] relay can be discontinued as > >>>> traffic diminishes". That's quite reasonable guidance, I think. > >>>> > >>>> Remember: 0.01% is really a very small number. Multiplying it by 1 > >>>> billion (like Brian did) makes it seem large, but that's just a tric= k of the > light. > >>>> Look at it this way: if all the relays in the world were turned off > >>>> overnight and all the 6to4 users were unable to reach a given > >>>> website, that website's reliability would still be 99.99% of what it= was > before. > >>>> > >>>> I support this document in its current form. I only have three > >>>> comments beyond seconding Tore's objection to the draft calling 6to4 > "substantial": > >>>> > >>>>=C2=A0 =C2=A0 1. Is it necessary to formally deprecate RFC 6732? It's= an individual > >>>>=C2=A0 =C2=A0 submission. (Not that I support RFC 6732 in any way, to= be sure.) > >>>>=C2=A0 =C2=A0 2. I don't think the sentence "some content providers h= ave been > >>>>=C2=A0 =C2=A0 reluctant to make content available over IPv6" is true,= or at least any > >>>>=C2=A0 =C2=A0 true for any non-trivial value of "some". 6to4 was a pr= oblem for content > >>>>=C2=A0 =C2=A0 providers a few years ago, but we've moved past it. > >>>>=C2=A0 =C2=A0 3. It might be useful to cite that another reason 6to4 = is being > >> > >>>>=C2=A0 =C2=A0 deprecated is that IPv6 is actually being deployed thes= e days (finally). > >>>> > >>>> > >>>> > >>>> > >>>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith > >>>> >>>>> wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: Brian E Carpenter > >>>> To: Tore Anderson ; v6ops@ietf.org > >>>> Cc: > >>>> Sent: Wednesday, 21 January 2015, 7:14 > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >>>> > >>>> On 21/01/2015 02:16, Tore Anderson wrote: > >>>>> * fred@cisco.com > >>>>> > >>>>>> This is to initiate a one week working group last call of > >>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. > >>>>> > >>>>> I have read this document, and I think it is ready to move forward. > >>>>> > >>>>> Its operational need for this document is less pressing now than > >>>>> when the -00 version was published back in 2011. Nevertheless, I > >>>>> find it valuable and correct to put the final nail in 6to4's > >>>>> coffin at this point in time. While the operational community for > >>>>> the most part has already realised that 6to4 has no future, there > >>>>> might be some who have not been paying attention and formal > >>>>> deprecation of the protocol may help prevent them from making the > >>>>> mistake of attempting to base production systems on it. > >>>>> > >>>>> I have one minor comment though: In section 1, it says =C2=ABa > >>>>> substantial amount of 6to4 traffic is still observed by IPv6 conten= t > providers=C2=BB. > >>>>> While I do see 6to4 traffic, it is quite far from being of "substan= tial" > >>>>> levels. I would therefore recommend replacing "substantial" with > >>>>> something milder like "noticeable", "measurable", or something > >>>>> along those lines. > >>>>> > >>>>> For what it's worth, today the Google public IPv6 graph shows just > >>>>> a measly 0.01% of their total IPv6 traffic being Teredo/6to4, so > >>>>> it's not just me. > >>>> > >>>> "Tore, > >>>> > >>>> However, that fraction of Google traffic multipled by Google users > >>>> represents something like 100000 users. I don't think we can > >>>> dismiss that number of people too easily. It's a matter of taste > >>>> whether that's "substantial" or "noticeable". > >>>> > >>>>=C2=A0 =C2=A0 Brian" > >>>> > >>>> Actually, to those end users, the impact might be both quite > >>>> significant and noticeable. > >>>> > >>>> I think one explanation for the use of 6to4 tunnelled IPv6 is that > >>>> their hosts aren't preferring native IPv4 over tunnelled IPv6 > >>>> (assuming Google make their services equally available over both, > >>>> which I think they do), as per RFC3484 address selection rules. > >>>> > >>>> The other explanation for it could be that these users have Happy > >>>> Eyeballs enabled browsers and the browser is choosing to try to use > >>>> both IPv4 and IPv6, despite the IPv6 being tunnelled rather than > >>>> native. From a Happy Eyeballs robustness perspective, that would be > >>>> quite a reasonable thing to do I think. > >>>> > >>>> If the end-hosts aren't following RFC3484's default preferences, > >>>> then breaking 6to4 might cause the sorts of timeouts that HE is > >>>> designed to overcome. RFC3484 is quite old now (2003), and as a > >>>> minor data point I first encountered the implementation of them in > >>>> around 2008/2009 if I recall correctly on my Linux system (as I was > >>>> using 6to4 at the time and wanted to use tunnelled IPv6 in > >>>> preference to native IPv4 - gai.conf(3) is the way you change > >>>> that). So if some hosts are still preferring tunnelled > >>>> 6to4 IPv6 over native IPv4 then perhaps they're also not going to > >>>> be running a HE enabled browser either. > >>>> > >>>> Perhaps it might be possible for somebody at Google to produce a > >>>> list of the browser User-Agent strings for people still using 6to4 > >>>> to see if the browsers being used are HE enabled, which might also > >>>> give some insight into > >>>> RFC3484 support in the underlying OSes. > >>>> > >>>> Regards, > >>>> Mark. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >>_______________________________________________ > >>v6ops mailing list > >>v6ops@ietf.org > >>https://www.ietf.org/mailman/listinfo/v6ops > >> > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_2414724_2012949938.1423093091720 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: "Metzler, Dan J" <dan-metzler@uiowa.edu>
<= b>To: Mark ZZZ Smith <mark= zzzsmith@yahoo.com.au>; George Michaelson <ggm@algebras.org>; Lore= nzo Colitti <lorenzo@google.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>; Tore Anderson= <tore@fud.no>
Sent: Wednesday, 4 February 2015, 23:36
Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WG= LC



>= ; -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smit= h
> Sent: Tuesday, February 3, 2015 5:16 PM
> To: George Michaelson; Lorenzo Colitti
>= ; Cc: v6ops@ietf.org; Tore Anderson
> Subj= ect: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
&= gt;
>
>
>=
> So this was interesting data, however I've realise= d that I don't think it is quite
> measuring what I th= ought it was measuring if the test destination was IPv6
&= gt; only. If that is the case, then the choice was 6to4 or nothing to use t= o access
> the IPv6 only destination.
>
> I think the more interesting case is when th= e destination is dual stack, and the
> end host has a = choice of native IPv4 or 6to4 tunnelled IPv6. A host or
&= gt; application that chooses 6to4 over native IPv4 isn't following
> RFC3484/RFC6724 precedence. They would be the ones impacted = by actively
> blocking 6to4 traffic somewhere between = the host and destination, and that
> impact would be v= isible to the end-user if Happy Eyeball techniques weren't
> being used.   

= Am I missing something?  Isn't that really flawed logic?  6to4 us= ers that target native IPv6 (non-dual stack) would definitely be impacted b= y blocking 6to4 traffic.
The number of targets that are d= ual stack and still using 6to4 is likely to be small, and easily fixable.&n= bsp; This seems likely you're trying to ignore the relevant population?

* Actually, my fear would be that a number of people sti= ll using 6to4 might not know they're using it, because it has been enabled = by default on IPv6 residential CPE when there isn't a native IPv6 service a= vailable. In markets such as Australia, where the customer usually chooses = the model of and owns/"operates" the CPE, disabling 6to4 would be beyond mo= st of their capabilities. IOW, actions that may break 6to4 may have the gre= atest impact on the "technically incompetent", and therefore strong advice = not to block 6to4 in this draft may be worth providing.

* That may be a bit of an unrealistic fear on my behalf, howeve= r it seems the level of detail the current observations about 6to4 provide = are that it isn't being used much and it isn't reliable. I'm curious to kno= w the next level of detail down - who/what is (still) trying to use it, in = particular when native IPv4 should now have been preferred for quite a long= time.


Or are you really focused on something unr= elated?
   
>
> Would it be possible to conduct the same test with a dual= stack site?
>
> Thanks,
> Mark.
> ______________________________= __
> From: George Michaelson <ggm@algeb= ras.org>
> To: Lorenzo Colitti <lorenzo@google.com>
> Cc: Brian E Carpenter= <brian.e.carpenter@gmail.com>= ; Mark ZZZ Smith
> <m= arkzzzsmith@yahoo.com.au>; "v6ops@ietf.org" <= v6ops@ietf.org>; Tore
> Anderson <tore@f= ud.no>
> Sent: Tuesday, 27 January 2015, 14:39<= br clear=3D"none">> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-histor= ic WGLC
>
>
&= gt;
>
>
>=
>
> On Tue, Jan 27, 2015 at 1:= 36 PM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
> Are= these probes made to an IPv6-only hostname? If so, then of course we'd
> expect OSes to attempt 6to4.
> > Yes and yes. I thought about pruning, and decided to m= ake it complete. Its
> certainly not a strong reflecti= on of the real world dynamic, but it shows how
> many = people are still sitting on vestigial 6to4 technology which can be woken.> Since we know some ISPs had deployment models which i= ncluded this, Its not
> surprising.
= >
> Functionally its dead technology. But its zomb= ie dead. not stone-cold.
>
> -G<= br clear=3D"none">>
>
>
>
> >
> >= ;On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter
>= <brian.e.carpenter@gmail.com>= wrote:
> >
> >Measurable, = indeed.
> >>
> >>Wind= ows 8? Really?
> >>
> >&= gt;Regards
> >>  Brian
&= gt; >>
> >>
> >>= ;On 27/01/2015 15:07, George Michaelson wrote:
> >&= gt;> Ask and ye shall receive
> >>>
> >>> Here is a days summary of os, browser, os+bro= wser as determined by
> >>> the APNIC 1x1 cap= ture, using 2002: as the source IPv6 address, and
> &g= t;>> the Python httpagentparser module to detect OS and Version info.=
> >>>
> >>> -G= eorge
> >>>
> >>&g= t; os,Windows+7,22287
> >>> os,Windows+8.1,17= 43
> >>> os,Windows+Vista,939
> >>> os,Windows+8,894
> >>> o= s,Windows+XP,431
> >>> os,Macintosh+[na],124<= br clear=3D"none">> >>> os,iOS+[na],44
> &= gt;>> os,Linux+[na],29
> >>> os,Windows= +NT 6.4,6
> >>> os,Windows Phone+8.1,2
> >>> os,ChromeOS+6310.68.0,2
>= ; >>>
> >>> browser,Chrome,18297
> >>> browser,Firefox,3774
>= ; >>> browser,Microsoft Internet Explorer,2872
&= gt; >>> browser,Opera,1439
> >>> bro= wser,Safari,110
> >>> browser,AndroidBrowser,= 5
> >>> browser,[na],2
>= >>> browser,SeaMonkey,2
> >>>
> >>> os+browser,Windows+7.Chrome,15539
> >>> os+browser,Windows+7.Firefox,3033
> >>> os+browser,Windows+7.Microsoft Internet Explorer,243= 2
> >>> os+browser,Windows+8.1.Chrome,1305> >>> os+browser,Windows+7.Opera,1277
> >>> os+browser,Windows+8.Chrome,644
> >>> os+browser,Windows+Vista.Chrome,537
= > >>> os+browser,Windows+8.1.Firefox,311
>= >>> os+browser,Windows+Vista.Microsoft Internet Explorer,230
> >>> os+browser,Windows+XP.Chrome,216
> >>> os+browser,Windows+Vista.Firefox,148
> >>> os+browser,Windows+XP.Firefox,134
> >>> os+browser,Windows+8.Firefox,116
&= gt; >>> os+browser,Windows+8.Microsoft Internet Explorer,87
> >>> os+browser,Windows+8.1.Opera,64
> >>> os+browser,Windows+8.1.Microsoft Internet Explorer,6= 3
> >>> os+browser,Macintosh+[na].Safari,60> >>> os+browser,Windows+XP.Microsoft Internet= Explorer,54
> >>> os+browser,Windows+8.Opera= ,45
> >>> os+browser,iOS+[na].Safari,44
> >>> os+browser,Macintosh+[na].Chrome,36
> >>> os+browser,Windows+XP.Opera,25
> >>> os+browser,Windows+Vista.Opera,24
>= ; >>> os+browser,Macintosh+[na].Firefox,24
> = >>> os+browser,Linux+[na].Chrome,16
> >>= ;> os+browser,Linux+[na].Firefox,8
> >>> o= s+browser,Windows+7.Safari,6
> >>> os+browser= ,Linux+[na].AndroidBrowser,5
> >>> os+browser= ,Windows+NT 6.4.Microsoft Internet Explorer,4
> >&g= t;> os+browser,Macintosh+[na].Opera,4
> >>>= ; os+browser,Windows+XP.SeaMonkey,2
> >>> os+= browser,Windows+NT 6.4.Chrome,2
> >>> os+brow= ser,Windows+8.[na],2
> >>> os+browser,Windows= Phone+8.1.Microsoft Internet Explorer,2
> >>>= ; os+browser,ChromeOS+6310.68.0.Chrome,2
> >>>= ;
> >>>
> >>> O= n Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith
> >&= gt;> <markzzzsmith@yahoo.com.au>=
> >>> wrote:
> >>= >
> >>>> I'm fine with that.
> >>>>
> >>>> If = it is easy enough, I think it would be interesting to get a bit
> >>>> more of an insight into who/what is still usin= g 6to4 either in
> >>>> preference to or i= n
> >>>> (HE) parallel to native IPv4 by e= .g., collecting User-Agent for 6to4 users.
> >>&= gt;>
> >>>>  --------------------= ----------
> >>>>  *From:* Lorenzo Co= litti <lorenzo@google.com>
>= >>>> *To:* Mark ZZZ Smith <ma= rkzzzsmith@yahoo.com.au>
> >>>> *Cc= :* Brian E Carpenter <brian.e.carpente= r@gmail.com>; Tore
> >>>> Anderson = < tore@fud.no>; "v6ops@ietf.org" <v6ops@= ietf.org>
> >>>> *Sent:* Wednesday,= 21 January 2015, 23:16
> >>>>
> >>>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-t= o-historic WGLC
> >>>>
&= gt; >>>> Yes, those users will definitely be impacted. Which is= why the
> >>>> document does not suggest = dropping the packets or turning off the
> >>>= > relays, except by saying things like "operators SHOULD [...]
> >>>> consider carefully whether the [...] relay = can be discontinued as
> >>>> traffic dimi= nishes". That's quite reasonable guidance, I think.
> = >>>>
> >>>> Remember: 0.01% is= really a very small number. Multiplying it by 1
> >= ;>>> billion (like Brian did) makes it seem large, but that's just= a trick of the
> light.
> >&g= t;>> Look at it this way: if all the relays in the world were turned = off
> >>>> overnight and all the 6to4 user= s were unable to reach a given
> >>>> webs= ite, that website's reliability would still be 99.99% of what it was
> before.
> >>>>
> >>>> I support this document in its current form= . I only have three
> >>>> comments beyond= seconding Tore's objection to the draft calling 6to4
>= ; "substantial":
> >>>>
= > >>>>    1. Is it necessary to formally deprecate= RFC 6732? It's an individual
> >>>> =   submission. (Not that I support RFC 6732 in any way, to be sure.)> >>>>    2. I don't think the se= ntence "some content providers have been
> >>>= ;>    reluctant to make content available over IPv6" is true, = or at least any
> >>>>    true f= or any non-trivial value of "some". 6to4 was a problem for content
> >>>>    providers a few years ago, but= we've moved past it.
> >>>>    = 3. It might be useful to cite that another reason 6to4 is being
> >>
> >>>>    d= eprecated is that IPv6 is actually being deployed these days (finally).
> >>>>
> >>>>= ;
> >>>>
> >>&g= t;>
> >>>> On Wed, Jan 21, 2015 at 9:30= AM, Mark ZZZ Smith
> >>>> <markzzzsmith@yahoo.com.au
> >= ;>>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>= ;
> >>>> ----- Original Message -----
> >>>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> >>>> To: Tore Anderson <tore@fud.no>; v6ops@ietf.org
> >>>> Cc:
> >>>> Sent: Wednesday, 21 January 2015, 7:14
> >>>> Subject: Re: [v6ops] draft-ietf-v6ops-6= to4-to-historic WGLC
> >>>>
> >>>> On 21/01/2015 02:16, Tore Anderson wrote:
> >>>>> * fred@cisco.com
> >>>>>
> >>>>= >> This is to initiate a one week working group last call of
> >>>>>> http://tools.ietf.org/html/draft-ie= tf-v6ops-6to4-to-historic.
> >>>>>
> >>>>> I have read this document, and I th= ink it is ready to move forward.
> >>>>>= ;
> >>>>> Its operational need for this= document is less pressing now than
> >>>>= > when the -00 version was published back in 2011. Nevertheless, I
> >>>>> find it valuable and correct to put = the final nail in 6to4's
> >>>>> coffin= at this point in time. While the operational community for
> >>>>> the most part has already realised that 6to4 h= as no future, there
> >>>>> might be so= me who have not been paying attention and formal
> >= ;>>>> deprecation of the protocol may help prevent them from ma= king the
> >>>>> mistake of attempting = to base production systems on it.
> >>>>&g= t;
> >>>>> I have one minor comment tho= ugh: In section 1, it says =C2=ABa
> >>>>&= gt; substantial amount of 6to4 traffic is still observed by IPv6 content> providers=C2=BB.
> >>>&g= t;> While I do see 6to4 traffic, it is quite far from being of "substant= ial"
> >>>>> levels. I would therefore = recommend replacing "substantial" with
> >>>&= gt;> something milder like "noticeable", "measurable", or something
> >>>>> along those lines.
> >>>>>
> >>>>> For= what it's worth, today the Google public IPv6 graph shows just
> >>>>> a measly 0.01% of their total IPv6 traffic= being Teredo/6to4, so
> >>>>> it's not= just me.
> >>>>
> &g= t;>>> "Tore,
> >>>>
> >>>> However, that fraction of Google traffic multipl= ed by Google users
> >>>> represents somet= hing like 100000 users. I don't think we can
> >>= ;>> dismiss that number of people too easily. It's a matter of taste<= br clear=3D"none">> >>>> whether that's "substantial" or "no= ticeable".
> >>>>
> &= gt;>>>    Brian"
> >>>>= ;
> >>>> Actually, to those end users, the= impact might be both quite
> >>>> signifi= cant and noticeable.
> >>>>
> >>>> I think one explanation for the use of 6to4 tunne= lled IPv6 is that
> >>>> their hosts aren'= t preferring native IPv4 over tunnelled IPv6
> >>= ;>> (assuming Google make their services equally available over both,=
> >>>> which I think they do), as per RFC= 3484 address selection rules.
> >>>>
> >>>> The other explanation for it could be th= at these users have Happy
> >>>> Eyeballs = enabled browsers and the browser is choosing to try to use
> >>>> both IPv4 and IPv6, despite the IPv6 being tunnelle= d rather than
> >>>> native. From a Happy = Eyeballs robustness perspective, that would be
> >&= gt;>> quite a reasonable thing to do I think.
> = >>>>
> >>>> If the end-hosts a= ren't following RFC3484's default preferences,
> >&= gt;>> then breaking 6to4 might cause the sorts of timeouts that HE is=
> >>>> designed to overcome. RFC3484 is q= uite old now (2003), and as a
> >>>> minor= data point I first encountered the implementation of them in
> >>>> around 2008/2009 if I recall correctly on my Lin= ux system (as I was
> >>>> using 6to4 at t= he time and wanted to use tunnelled IPv6 in
> >>= >> preference to native IPv4 - gai.conf(3) is the way you change
> >>>> that). So if some hosts are still prefe= rring tunnelled
> >>>> 6to4 IPv6 over nati= ve IPv4 then perhaps they're also not going to
> >&= gt;>> be running a HE enabled browser either.
> = >>>>
> >>>> Perhaps it might b= e possible for somebody at Google to produce a
> >&= gt;>> list of the browser User-Agent strings for people still using 6= to4
> >>>> to see if the browsers being us= ed are HE enabled, which might also
> >>>>= give some insight into
> >>>> RFC3484 sup= port in the underlying OSes.
> >>>>
> >>>> Regards,
> >>&= gt;> Mark.
> >>>>
>= ; >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> >>>>
> >>>&= gt;
> >>>>
> >>= >>
> >>>>
> >= ;>>> _______________________________________________
> >>>> v6ops mailing list
> >&g= t;>> v6ops@ietf.org
> >>>&g= t; https://www.ietf.org/mailman/listinfo/v6ops



> >>>>
> >&g= t;>> _______________________________________________
> >>>> v6ops mailing list
> >>&= gt;> v6ops@ietf.org
> >>>> = https://www.ietf.org/mailman/listinfo/v6ops
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>= ; _______________________________________________
> &g= t;>>> v6ops mailing list
> >>>> <= a shape=3D"rect" ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@iet= f.org">v6ops@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
>= ; >>>>
> >>>>
> >>>
> >>>
&= gt; >>>
> >>> ______________________= _________________________
> >>> v6ops mailing= list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/li= stinfo/v6ops
> >>>
>= >>
> >>__________________________________= _____________
> >>v6ops mailing list
> >>v6ops@ietf.org
> >&= gt;https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> =
> _______________________________________________
> v6ops mailing list
> v6ops= @ietf.org
> https://www.ietf.org/mai= lman/listinfo/v6ops


------=_Part_2414724_2012949938.1423093091720-- From nobody Wed Feb 4 15:41:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA11A008F for ; Wed, 4 Feb 2015 15:41:18 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4ebBkNHPzcc for ; Wed, 4 Feb 2015 15:41:16 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6B61A007A for ; Wed, 4 Feb 2015 15:41:13 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so5759486pab.12 for ; Wed, 04 Feb 2015 15:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ie9Gjbnf4n0HsSJxhVD2K1enY6lq1C1EWoURm5stA30=; b=YcRtSgbY+LxfT4Da2jhx5lFhnBqnPVJQe8D5ggXyoEvXnJ+BHqq4iBgz1B0Zb2q1k7 n448ZDNPfqwImYrAftCj6VHD0OobfNvPeHy1WIKtaMOiYRPHfq91+xgrOY/KXh9TW7JB QFtAa04+37Q1B0liU79pvGdt1iE3XY2OvNLsW+D8xjQPBD0ehn4PVca+fDRCTLADIFoj yAoHlMOtTcZasL0PDzI/OOFQWn666DtcReO33gizkLK/EbEq8/kOHdg481Q2V/Mj+YQ3 NtKseDdIY6uSlCiU3JNk8emWSY+2Dq/5gEiFO/BQ7b19pPiVIDK1Yhx9yDzSq4d1KiXu sxQQ== X-Received: by 10.66.120.236 with SMTP id lf12mr153740pab.67.1423093272389; Wed, 04 Feb 2015 15:41:12 -0800 (PST) Received: from ?IPv6:2406:e007:63b2:1:28cc:dc4c:9703:6781? ([2406:e007:63b2:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id k5sm3113941pdn.45.2015.02.04.15.41.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 15:41:11 -0800 (PST) Message-ID: <54D2AE1A.4070603@gmail.com> Date: Thu, 05 Feb 2015 12:41:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Lorenzo Colitti References: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:41:18 -0000 On 05/02/2015 12:23, Mark ZZZ Smith wrote: > While I appreciate that the draft isn't advising to block 6to4, I think it would be useful to gain some more detailed insight into the consequences of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending on the results, it may also mean that making a strong statement not to block 6to4 traffic in the draft would be beneficial, reinforcing what is in RFC6343. otoh, if we leave the text as it is now we have a fair chance of getting through the IETF Last Call and the IESG, and finally getting this done. Brian > Indirectly I think it would also be a measure of the deployment of the RFC3484/RFC6724 rules on various OSes. > From: Lorenzo Colitti > To: Mark ZZZ Smith > Cc: George Michaelson ; Brian E Carpenter ; "v6ops@ietf.org" ; Tore Anderson > Sent: Wednesday, 4 February 2015, 11:18 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > > > On Wed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith wrote: > > Would it be possible to conduct the same test with a dual stack site? > > > What would we learn from such an exercise? The OS / user-agent breakdown of the 0.01% of hosts that use 6to4 when talking to dual-stack destinations? Even if we knew that, what would we do with it? > > > From nobody Wed Feb 4 15:52:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382F21A0024 for ; Wed, 4 Feb 2015 15:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3YEP9WF_ZPB for ; Wed, 4 Feb 2015 15:52:44 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6431A000F for ; Wed, 4 Feb 2015 15:52:43 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id rl12so6283635iec.0 for ; Wed, 04 Feb 2015 15:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dkb3aoj+zHs8aumt9rrYlvKTvcvNxe+uB3aiUTvJaAA=; b=QMftyxJvv4AvF+2CFrgwA1izHrU4vwcereMJHYQ1PytBes2qPyuHnzMJQ5F8dSMb/e duk3DyY5Hlj7ENJPRmZwy80t0yPGKj0pfhsCm9Hcl62t/vnzp5pGW9/P05OvP2FonKek cd7jaEZ9PLltOtIBzjctkj9lmKstN2Ntk10p6f6c1HziD+Ead/ij9ORADrskIhxhIMZd oumh/eODcqtQhAUrykp9bCz6W3k297D53P/ltKX/vARu7pVvlo5xE6LSJS/sC6HUviLB oXBdMiRQZnoh4qZzpFQI79qsrm/cSdSYh7bh9dbnmvXmHFW1sy+45sJPn/toxh9SE1kV 53hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dkb3aoj+zHs8aumt9rrYlvKTvcvNxe+uB3aiUTvJaAA=; b=Yx+KkcLOZE/jgZJxr+OI8uVsDJ8tdgru9n22vCc0Fn5DGSfuq5XvuDAVsWrSIKGmek /jyy3AXl8IZRwUDWXpd5s6csQ39aiP2TSWb9yURU2CNfqpromBiPvzX7RUGQi5wBX9n4 nnZb7ziPwNFpJuTgQNTCHc1dGMKH+NkColVE7J3pYzluYuTNNBFZkpwvWcFd16Sx9DPA bAzoKplqFDGQxUrYs8RJJTIhN0TrWBXhO/InihGqV/t1gSTr9qp+4OnuVYmZq4xZXNGr hl5JKLFTBFUs9yX7p1enToy1muEg00l2SoDPzK0yVEgc4Y2++YAymukHKXEEQEfTGyYs KG3g== X-Gm-Message-State: ALoCoQnEgOYUo3GuE349Q8Im5l8u/ISUYdAgFUvAFiPD3OFQ1Njju0YAsVsIIQxlPBclJcRnTqF1 X-Received: by 10.50.142.106 with SMTP id rv10mr5496888igb.18.1423093963182; Wed, 04 Feb 2015 15:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Wed, 4 Feb 2015 15:52:22 -0800 (PST) In-Reply-To: <54D2AE1A.4070603@gmail.com> References: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> <54D2AE1A.4070603@gmail.com> From: Lorenzo Colitti Date: Thu, 5 Feb 2015 08:52:22 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c3d13a2873ad050e4be27e Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:52:45 -0000 --001a11c3d13a2873ad050e4be27e Content-Type: text/plain; charset=UTF-8 On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05/02/2015 12:23, Mark ZZZ Smith wrote: > > While I appreciate that the draft isn't advising to block 6to4, I think > it would be useful to gain some more detailed insight into the consequences > of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending > on the results, it may also mean that making a strong statement not to > block 6to4 traffic in the draft would be beneficial, reinforcing what is in > RFC6343. > > otoh, if we leave the text as it is now we have a fair chance of getting > through > the IETF Last Call and the IESG, and finally getting this done. > +1. We can always explore that question in a separate document once this one is published. If it turns out that blocking provides no benefit and/or is harmful, then nothing changes. If it turns out that it can be done safely, then we can issue an operational guidance document advising it. --001a11c3d13a2873ad050e4be27e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
On 05/02/2015 12:23, Mark ZZZ Smith wrote:
> While I appreciate that the draft isn't advising to block 6to4, I = think it would be useful to gain some more detailed insight into the conseq= uences of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depe= nding on the results, it may also mean that making a strong statement not t= o block 6to4 traffic in the draft would be beneficial, reinforcing what is = in RFC6343.

otoh, if we leave the text as it is now we have a fair chance of get= ting through
the IETF Last Call and the IESG, and finally getting this done.

+1. We can always explore that question in a separ= ate document once this one is published. If it turns out that blocking prov= ides no benefit and/or is harmful, then nothing changes. If it turns out th= at it can be done safely, then we can issue an operational guidance documen= t advising it.=C2=A0
--001a11c3d13a2873ad050e4be27e-- From nobody Wed Feb 4 19:48:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46B21A047A for ; Wed, 4 Feb 2015 19:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekYFvq7aub_F for ; Wed, 4 Feb 2015 19:48:03 -0800 (PST) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBD91A049C for ; Wed, 4 Feb 2015 19:48:03 -0800 (PST) Received: by pdbfp1 with SMTP id fp1so4999115pdb.4 for ; Wed, 04 Feb 2015 19:48:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=krcACy6GHjVqcnQ/U+y+oYLe2OqFHbFcxlItAMTNdt8=; b=Kld+jelcnK/jrtIzYOo9rL8ELTO9hdb4xFlJJKHcLKGuYjHOX9YswRDZOJmkyBAvX4 oQtt/hDIdW5K2jTz21yFfEZ7ICmYPuTR7BaFYyhcRGQbTRfS0lpAOI3UwkaN694hs/jF xsKR20EEJJTSaVPlcTeRcF7hq0jdGHfN6heJm6bsRV53SBgQauUHOgV01/ZdHnJmwuCt pgygBflazT07ooncmka30HFQDWqG79wpCiq015TnWNeg0+sotooQnNAKvQy8t/gSWRrf dLZcMm856RN2sWNALjKUJWDq+AuVuN020Kha1zrR9kdf62/RMiWjqBzQmpBTkqnFLB21 esww== X-Gm-Message-State: ALoCoQmdkVT/5EA08lvxyaKffOE+p1AA7F/vF3Tn/mJ/gMDVAARlLfXrfnU4Fis0/+tuei4iBdNn MIME-Version: 1.0 X-Received: by 10.70.90.226 with SMTP id bz2mr2176504pdb.157.1423108083102; Wed, 04 Feb 2015 19:48:03 -0800 (PST) Received: by 10.70.67.226 with HTTP; Wed, 4 Feb 2015 19:48:02 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:69f7:ae6a:b34f:c90a] In-Reply-To: References: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> <54D2AE1A.4070603@gmail.com> Date: Thu, 5 Feb 2015 13:48:02 +1000 Message-ID: From: George Michaelson To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11c20dacc54d12050e4f2be9 Archived-At: Cc: Tore Anderson , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 03:48:06 -0000 --001a11c20dacc54d12050e4f2be9 Content-Type: text/plain; charset=UTF-8 I think I agree with Lorenzo. I did run the numbers over 40 days of data, considering *ONLY* the fetches made to a dualstack URL. stf 2766 v4 23002469 v6 474779 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of the total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In this measure, IPv6 is around 2% of total request traffic, which is lower than even our pessimistic world-rate, but I did no complex analysis of this by economy or anything, its an un-weighted simple sum. The point being, that over a 40 day period 2,700 odd people insisted on using 6to4, given a dual-stack URL out of 23,000,000 connections. I believe would be going too far to consider this right now as a damage risk. A Top-10 OS/Browser list: Windows 7.Chrome 1574 Windows 7.Firefox 328 Macintosh [na].Safari 250 Windows 8.1.Chrome 162 Windows 7.Microsoft IE 95 Windows 8.Chrome 81 Windows Vista.Chrome 74 Windows 7.Opera 52 Windows XP.Chrome 34 Windows 8.1.Firefox 23 On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti wrote: > On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 05/02/2015 12:23, Mark ZZZ Smith wrote: >> > While I appreciate that the draft isn't advising to block 6to4, I think >> it would be useful to gain some more detailed insight into the consequences >> of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending >> on the results, it may also mean that making a strong statement not to >> block 6to4 traffic in the draft would be beneficial, reinforcing what is in >> RFC6343. >> >> otoh, if we leave the text as it is now we have a fair chance of getting >> through >> the IETF Last Call and the IESG, and finally getting this done. >> > > +1. We can always explore that question in a separate document once this > one is published. If it turns out that blocking provides no benefit and/or > is harmful, then nothing changes. If it turns out that it can be done > safely, then we can issue an operational guidance document advising it. > --001a11c20dacc54d12050e4f2be9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I agree with Lorenzo.=C2=A0

I d= id run the numbers over 40 days of data, considering *ONLY* the fetches mad= e to a dualstack URL.

stf =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2766
v4 23002469
v6 =C2=A0 =C2=A0 474779

6 to 4 (stf) in this measure is (as Lorenzo say= s) of the order 0.01% of the total load seen on a dual-stack URL, and its o= nly 0.57% of total IPv6. In this measure, IPv6 is around 2% of total reques= t traffic, which is lower than even our pessimistic world-rate, but I did n= o complex analysis of this by economy or anything, its an un-weighted simpl= e sum.

The point being, that over a 40 day period = 2,700 odd people insisted on using 6to4, given a dual-stack URL out of 23,0= 00,000 connections.=C2=A0 I believe would be going too far to consider this= right now as a damage risk.=C2=A0

A Top-10 OS/Bro= wser list:

Windows 7.Chrome =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A01574
Windows 7.Firefox =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0328
Macintosh [na].Safari =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0250
Windows 8.1.Chrome =C2=A0 =C2=A0 =C2=A0 = =C2=A0 162
Windows 7.Microsoft IE =C2=A0 =C2=A0 =C2=A0 =C2=A095
Windows 8.Chrome =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08= 1
Windows Vista.Chrome =C2=A0 =C2=A0 =C2=A0 =C2=A074
Wi= ndows 7.Opera =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 52
Windows XP.Chrome =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 34
W= indows 8.1.Firefox =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
=



On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti <loren= zo@google.com> wrote:
On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <brian= .e.carpenter@gmail.com> wrote:
On 05/02/2015 12:23, Mark ZZZ Smith wrote:
> While I appreciate that the draft isn't advising to block 6to4, I = think it would be useful to gain some more detailed insight into the conseq= uences of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depe= nding on the results, it may also mean that making a strong statement not t= o block 6to4 traffic in the draft would be beneficial, reinforcing what is = in RFC6343.

otoh, if we leave the text as it is now we have a fair chance of get= ting through
the IETF Last Call and the IESG, and finally getting this done.

+1. We can always explore that question in = a separate document once this one is published. If it turns out that blocki= ng provides no benefit and/or is harmful, then nothing changes. If it turns= out that it can be done safely, then we can issue an operational guidance = document advising it.=C2=A0

--001a11c20dacc54d12050e4f2be9-- From nobody Wed Feb 4 20:01:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6F1A020D for ; Wed, 4 Feb 2015 20:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM6dDpy0vCMG for ; Wed, 4 Feb 2015 20:01:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823331A013B for ; Wed, 4 Feb 2015 20:01:08 -0800 (PST) Received: from mb-aye.local ([172.56.38.243]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t15415LZ048555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 04:01:06 GMT (envelope-from joelja@bogus.com) Message-ID: <54D2D1D7.8090502@bogus.com> Date: Wed, 04 Feb 2015 18:13:43 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Gert Doering , david.binet@orange.com References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> In-Reply-To: <20150204083138.GB34798@Space.Net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="feWhcUK9tCi99IDVbEjoA3XivpLXpKQVr" Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 04:01:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --feWhcUK9tCi99IDVbEjoA3XivpLXpKQVr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/4/15 12:31 AM, Gert Doering wrote: > Hi, >=20 > On Wed, Feb 04, 2015 at 08:10:54AM +0000, david.binet@orange.com wrote:= >> some people think that IPv6 deployment is done if 3% of the world popu= lation can benefit of some IPv6 connectivity.=20 >=20 > I notice that those that actually do deploy IPv6 are not those that com= plain > about non-deployment. >=20 > So, how's Orange's IPv6 deployment coming on? I think this out of line. disagreement on implementation one thing, individual business decissions may be influenced by things outside this document. >=20 > Gert Doering > -- NetMaster >=20 --feWhcUK9tCi99IDVbEjoA3XivpLXpKQVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTS0dgACgkQ8AA1q7Z/VrJ1VACcCwc+QsewUaKGB08muOVyaV8j 8fMAnj9whakY0EGZJDMl4DaXwCkf0cCB =N/wd -----END PGP SIGNATURE----- --feWhcUK9tCi99IDVbEjoA3XivpLXpKQVr-- From nobody Thu Feb 5 07:00:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9321A893E for ; Thu, 5 Feb 2015 07:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rptL6ObC18mr for ; Thu, 5 Feb 2015 07:00:25 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EADA1A895B for ; Thu, 5 Feb 2015 06:59:05 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 83583d45.0.1674139.00-2139.4695043.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Feb 2015 14:59:05 +0000 (UTC) X-MXL-Hash: 54d3853966108ee2-5db3e7f837907b7e6593cc94fa08c44a7e9a4b46 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t15Ex3dA003709 for ; Thu, 5 Feb 2015 09:59:03 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t15Ewx9M003653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Feb 2015 09:58:59 -0500 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 5 Feb 2015 14:58:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.10]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 09:58:41 -0500 From: "STARK, BARBARA H" To: IPv6 Ops WG Thread-Topic: OECD report on the economics of the transition to IPv6 Thread-Index: AdBBUu5tbgSRe7A7SVys6lHBYT/52w== Date: Thu, 5 Feb 2015 14:58:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F11F49@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.247.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=WYS7nTdX c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=nkTqSvrMtFgA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=C9Y7xvUbA] X-AnalysisOut: [AAA:8 a=K1BCCrfol5i5xJCtPv0A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [v6ops] OECD report on the economics of the transition to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 15:00:27 -0000 Given some of the recent discussion regarding the mobile-device-profile dra= ft, I thought some people might be interested in this report on the economi= cs of transition to IPv6 that was commissioned by OECD and published in Nov= ember 2014. A number of people who participate in v6ops were interviewed fo= r this report. Barbara [If the link gets broken across lines, just paste it together again.] http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=3DDSTI= /ICCP/CISP%282014%293/FINAL&docLanguage=3DEn=20 From nobody Thu Feb 5 11:29:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FA31A8A8F for ; Thu, 5 Feb 2015 11:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TAW57lNskK6 for ; Thu, 5 Feb 2015 11:29:16 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230A81A8A97 for ; Thu, 5 Feb 2015 11:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1423164552; x=1424374152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wiYv55DFHwgfmhvRni79/qU80newG/1FF/jjzIiA464=; b=WtFtdZJ1cdGge/A6j3QMvueW3leh8kKCOYweGt5pRmP0+QBqMYl4dsxL Rn3i9QF6w8H43BI4JeSMyBeNKXZu6dZNx8B2M0XfFP2S1c0Dex7SRaBxp RlMHJqO6ffZJIYvor/XjtFtmMV4hjgCJLIMeCv04Y9P+lWzNB2Uw0HhfA Q=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4BQBMxNNU/4YNJK1agwZSWQSCfb9QhW8CgShDAQEBAQF9hAwBAQEDASNEEgULAgEIGCoCAjIlAgQOBQkFiBcIDcBDli0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXj3gHgmgugRMFjTWBY4FVgSxPhVySayKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,525,1418083200"; d="asc'?scan'208";a="120877835" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 05 Feb 2015 19:28:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t15JStnv014618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 19:28:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 13:28:55 -0600 From: "Fred Baker (fred)" To: joel jaeggli Thread-Topic: [v6ops] IETF 92 heads Up Thread-Index: AQHQQXn6aHb8e1Yj8kiQKUIm/2TKKA== Date: Thu, 5 Feb 2015 19:28:54 +0000 Message-ID: References: <39A489D3-C0EB-49DC-90E6-3279A23EC60E@cisco.com> <441D3CE6-16C4-4CD2-9EB8-B63B2AA040A7@cisco.com> <54D244D8.9050709@bogus.com> In-Reply-To: <54D244D8.9050709@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_AFB8403C-A647-45C7-B2D0-49B65F900C82"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Erik Kline , V6 Ops List Subject: Re: [v6ops] IETF 92 heads Up X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:29:18 -0000 --Apple-Mail=_AFB8403C-A647-45C7-B2D0-49B65F900C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 4, 2015, at 8:12 AM, joel jaeggli wrote: >>>> Individual Submission NOT updated since IETF: >>>>=20 >>>> Aug 24 draft-v6ops-pmtud-ecmp-problem >>>=20 >>> I've seen this draft be usefully referred to a couple of times in >>> the last few months. +1 to keeping it afloat, if not moving >>> forward for some reason (cc'ing Joel explicitly). >>=20 >> Up to Joel. If folks tell us it should be a working group draft, it >> can be resubmitted as draft-ietf-v6ops-pmtud-ecmp-problem, following >> the naming guideline that IETF tools depend on. Or whatever. >=20 > I am happy to undertake a revision, or encourage my co-authors to do = so. That would be fine. > I throw myself at the mercy of the chairs with respect to the title. I=E2=80=99m working from = http://www.ietf.org/id-info/guidelines.html#naming and the fact that = IETF tools depend on this. Drafts can be named one of three ways: draft-ietf--*-nn.txt A working group draft draft---*-nn.txt An individual submission to a working = group draft--*-nn.txt An individual submission not targeted = to a specific working group The guidelines have a number of special "authors", such as -iab-, = -iaoc-, and so on. When you file a draft as draft-ietf-v6ops-*-00.txt, the working group = chairs get a question from the secretariat: "is this an authorized = working group draft?" If we say "yes", it's allowed to be posted, and if = we say "no" or don't say anything, it doesn't. Once the -00 is posted, = it can be updated at will. The status also show up in the data tracker: = if you look up = https://datatracker.ietf.org/doc/search/?name=3Dv6ops&activedrafts=3Don&so= rt=3D, drafts named draft-ietf-v6ops-* are listed as "WG Documents", and = other documents aren't. IETF tools depend on that naming - WG status is = not a separate attribute (although I would prefer that it was), it is = carried in the name of the draft. My personal tools are a little more forgiving; if I find the character = string "v6ops" anywhere in the name, I consider it related to v6ops = somehow. In part, that is because we sometimes get documents with names = like draft-tom-dick-harry-v6ops-*, that completely screw the naming = guidelines. We also sometimes get documents that are individual = submissions without respect to a working group that are shopped to = several working groups. I'm perfectly willing to see people drop a note = to the list saying "I filed draft-myname-stuff-i-am-worried-about, and = wonder what the operational folks think", or for that matter drafts from = other working groups, and if folks ask, we may fit those into an agenda = somewhere. But if it has the word "v6ops" in the name, I electronic = ear-equivalents perk up, my bot sends a note to the working group and a = separate note to the authors, and it automatically shows up in my agenda = analysis. But really. We decided to accept this as a working group draft. I'm = looking for a document with a name like = draft-ietf-v6ops-pmtud-ecmp-problem. --Apple-Mail=_AFB8403C-A647-45C7-B2D0-49B65F900C82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVNPEdZ9ieig10VPpAQKi8gf/TGp6cFkm/RUqRPbhnJvNQDptWiD1Gb+V quoOYx7ac25+J8T1JGaHlcubjUevlv4ouYd8ia0Hbif5aRDei17JLIrVhcLD1VLG tIsUAZwVxEHoCOvJNfFYr7nOcR59hNhh/q0J+SsfBVWnSJtzOM0xvd9OOyeg65IG A98yuA+0Um6PrBXgPnAkGSxGKGxQ0AZMd+fmo0RR36FQ4mBBEkEpV1JHpvR6LpkS L3bMZQtsR9h+ihAUcCB6v0ieiTA1xZWAzLL6UhHTwSdmjSjzfXIg/JfGFdy/jugm z3LgOI1ESfpod/pC+PwFYsJY/9A8qjV01mCeihkx87cD7LPSxbtILQ== =h/fh -----END PGP SIGNATURE----- --Apple-Mail=_AFB8403C-A647-45C7-B2D0-49B65F900C82-- From nobody Thu Feb 5 18:53:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172F51A03AA for ; Thu, 5 Feb 2015 18:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYVV9lY1shH3 for ; Thu, 5 Feb 2015 18:52:52 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5E1A0193 for ; Thu, 5 Feb 2015 18:52:52 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 5 Feb 2015 20:52:51 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f169.google.com with SMTP id hl2so10533056igb.0 for ; Thu, 05 Feb 2015 18:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=qjigvud5IDPP1uBfhs63SZNz8GvBw1NuRJO/Z2dyGIQ=; b=iIPHz44k7goTF4C1wSvBq2M01cpB6RC5ozvz+djnGmi0fHZlM1gr2H6/21IMh6dLxv eOtS4EfCoYXKJTkfDzXiOUBsiUs/hFq+Ute4nLTd+GQZ4ila3hs2vFi2NrN5BW/PYkLT KSYRH91oz9GCh0MI36QKvNmonixErYlR0jsKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=qjigvud5IDPP1uBfhs63SZNz8GvBw1NuRJO/Z2dyGIQ=; b=fO2Ei4Zg6uHBCwZfZoD+9WSc/fNf9CFvLwTsmeAzkFlz8kph6OEBAniEbaoBnngc+U sM8qljLm9pCFSeKFSOUEvxoAEUb84eD0I73eUJn0gYibHt6/vqkuBjpok77fZjNMkGAr R/aGyEX2Eya/lJzvfHm3wKmoPyJim/IG0E3wUaTn9y8nowI/pJKvOHJ7237RwxvydyFu opAfUO2WaDTudoPobMIRUZYBEQ4xftZTTIPdWPvr/YSFrTyZ3cNblkgxTX1Oo2rbcJmL xR/lg7Ka9IAup+5U9bIcVLb10xa2tXfEqnEuOIxL+BmVYnoYqeCmBC4DwzjGO4dPDnVN LZww== X-Gm-Message-State: ALoCoQm0NsU0gxyTNJJLYa4PO12TRe3XK4mfKr1RwYpeBsVQxaeoLRrKNBoo/YsuLHFnJiAg4y9xnvKFZmleH5NzpQwhcIODRUkPINiQXyqxZq0jymEcdbTNpHeUaulOxc5fYrUoduB/ X-Received: by 10.50.254.4 with SMTP id ae4mr104596igd.10.1423191170851; Thu, 05 Feb 2015 18:52:50 -0800 (PST) X-Received: by 10.50.254.4 with SMTP id ae4mr104576igd.10.1423191170622; Thu, 05 Feb 2015 18:52:50 -0800 (PST) Received: from ?IPv6:2601:2:5b00:a9f:58c9:6ab9:ca45:9b03? ([2601:2:5b00:a9f:58c9:6ab9:ca45:9b03]) by mx.google.com with ESMTPSA id qr1sm544399igb.18.2015.02.05.18.52.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 18:52:49 -0800 (PST) References: <1328555025.2415573.1423092240089.JavaMail.yahoo@mail.yahoo.com> <54D2AE1A.4070603@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <41B3E5F6-3208-426F-BD1C-76322C46FC1E@umn.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (12B466) From: David Farmer Date: Thu, 5 Feb 2015 20:52:47 -0600 To: George Michaelson Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 02:53:02 -0000 > On Feb 4, 2015, at 21:48, George Michaelson wrote: >=20 > I think I agree with Lorenzo.=20 +1, but more below. > I did run the numbers over 40 days of data, considering *ONLY* the fetches= made to a dualstack URL. >=20 > stf 2766 > v4 23002469 > v6 474779 >=20 > 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of th= e total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In t= his measure, IPv6 is around 2% of total request traffic, which is lower than= even our pessimistic world-rate, but I did no complex analysis of this by e= conomy or anything, its an un-weighted simple sum. >=20 > The point being, that over a 40 day period 2,700 odd people insisted on us= ing 6to4, given a dual-stack URL out of 23,000,000 connections. I believe w= ould be going too far to consider this right now as a damage risk.=20 >=20 > A Top-10 OS/Browser list: >=20 > Windows 7.Chrome 1574 > Windows 7.Firefox 328 > Macintosh [na].Safari 250 > Windows 8.1.Chrome 162 > Windows 7.Microsoft IE 95 > Windows 8.Chrome 81 > Windows Vista.Chrome 74 > Windows 7.Opera 52 > Windows XP.Chrome 34 > Windows 8.1.Firefox 23 I appreciate the data, but your previous data for the IPv6 only URL was one d= ay and this is 40 days for the Dual Stack URL. It would be better to have t= he same time basis for the two data sets to determine a ratio estimating the= 6to4 (2002::) hosts preferring IPv4 over 6to4. This data seems to only include successful connections, as you have browser s= trings which implies they got though a TCP handshake to get to an HTTP excha= nge. Would you also have failed(partial) connect attempts with only a SYN a= nd nothing after, for 6to4, v6, and v4 source addresses to the Dual Stack UR= L and the IPv6 only URL? This would give us a rough idea of a ratio for 6to= 4 return relay failures presumably. =20 Obviously, 6to4 forward relay failures are impossible to measure with this t= echnique, as you shouldn't even see any packets get to you with a failed 6to= 4 forward relay. Anyone have any ideas how to measure 6to4 forward relay fa= ilure rate? The draft hypothesizes that; The advice to disable 6to4 by default has been widely adopted in recent=20= operating systems, and the failure modes have been widely hidden from=20= users by many browsers adopting the "Happy Eyeballs" approach. So, would you have any historic data, from maybe 2011 or 2012, to help suppo= rt this first part and then anyway to look for Happy Eyeballs activity to su= pport the second part? Something tells me that measuring Happy Eyeballs from= the server end is going to be really hard, but I figure It can't hurt to as= k. Finally, nothing so far contradicts the drafts hypotheses or conclusions, es= pecially to not recommend filtering 6to4 anycast relay traffic or routes. S= o, please keep the draft moving forward. I appreciate any additional data you might be able to produce. And, thanks again for the data so far. --=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 David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 nobody Fri Feb 6 00:15:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D698E1A0210 for ; Fri, 6 Feb 2015 00:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.802 X-Spam-Level: *** X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl247b-0aPg9 for ; Fri, 6 Feb 2015 00:15:27 -0800 (PST) Received: from nm40-vm3.bullet.mail.gq1.yahoo.com (nm40-vm3.bullet.mail.gq1.yahoo.com [98.136.217.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283CB1A19F8 for ; Fri, 6 Feb 2015 00:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423210526; bh=011rpXMQYEW4aug+BTAZ2tNLfw+jnkFmf4KwGxd382I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lB7tz8GfKarjWkrbEdn//WWmBEV6vsdhCF8h67Q6T+AV6c+rREJ30MxmcNPyV1qdCfIJBCi26vXseABv+sd23XN9jj50+DQoj/ZeoNCJq/1OTQ30Ae9MmrMpF1KKUC0YwHE9W7aOBZNhTXaW9ERyzJSwYH5/UXispeoUo+3zQGzDpoa0kNNiTSBqkVSKY0myvekMsDB5021ZxSw5235NINyoiHD/QBQUdmCwEL/PkrvG/ZPQyJ6G9lPClF3CWeQznIsOw0esG5AqMG+9Ti16Anck3lgSEHQ1RngjWg4Hx/EjHVyk79EO985gOAlNzs/NxGANwhwIZMIztKrRyI+6rg== Received: from [127.0.0.1] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 06 Feb 2015 08:15:26 -0000 Received: from [216.39.60.184] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 06 Feb 2015 08:12:40 -0000 Received: from [66.196.81.174] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 06 Feb 2015 08:12:39 -0000 Received: from [98.139.212.246] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2015 08:12:39 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 06 Feb 2015 08:12:39 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 475764.89090.bm@omp1055.mail.bf1.yahoo.com X-YMail-OSG: 2eoJjGwVM1kRWJJg9SqbyAq_pIpTQ_sxKWIroeHIK52jyOlNXHrpHEnX1OFyW5P x1sFMbu96jG_30V3WnnvuHrttB38DDxQHOsPdzVYUKm0fN5Y9f4PpM5QfXE3FOYBN84d90Y85q6U Z9dy784recoNtTpG21rzMV22PNlf06Ku1KEJ.eapr19SOdef4lHioTiEtykqE1eTNmsL45MmfYRC bmOKuGkW8e.TGmqHbtlh.c44x.Xh9RFVWNuQPpaAMKLfB451ffwamORxsgab_10X5Nw7WnLrxKdD PD22YIuN6NgLb6F174xdDr4y0cDM9WKfM2KKKM9eFv2YZGCpubDcSCZKnEnKVKgykRmzXNe_q05Y pEkhP8j26NbzcGcqY0HPJAzUubgHJu1Vz8IolkWSJSheUqogSz.swDdD71C3Tlxy8OUyAo3dmM1p _Bev8r.ebZSORj_fAN.Z3trrbJf0Y3V71U4C8n8GU158LX2vEKzzzVGWU8ofXUKVAK.goMRAJlPT 7z8g10bQbnXbF4JMLLnt_TNK3nQ-- Received: by 76.13.26.138; Fri, 06 Feb 2015 08:12:39 +0000 Date: Fri, 6 Feb 2015 08:12:38 +0000 (UTC) From: Mark ZZZ Smith To: George Michaelson , Lorenzo Colitti Message-ID: <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_659398_463277315.1423210358445" Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 08:15:29 -0000 ------=_Part_659398_463277315.1423210358445 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi George, Thanks very much for the new data. (Off topic for the draft) I do find the entries in the list of OS/Browsers = a bit surprising - it either implies that they didn't have native IPv4 conn= ectivity and only had 6to4, or weren't following RFC3484/6724 rules, which = is surprising given how modern they all look. Some searches have shown up some articles from Microsoft saying that they'v= e been following RFC3484 rules since at least Windows Vista, and there are = some registry hacks that can disable that, so perhaps that might explain th= e Windows entries Vista and later. I found an article that said that since Mac OS X 10.6.5, native IPv4 is pre= ferred over 6to4 IPv6, perhaps the Macintosh's in your list are pre-10.6.5. Thanks,Mark. From: George Michaelson To: Lorenzo Colitti =20 Cc: Brian E Carpenter ; Mark ZZZ Smith ; "v6ops@ietf.org" ; Tore Anderson =20 Sent: Thursday, 5 February 2015, 14:48 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC =20 I think I agree with Lorenzo.=C2=A0 I did run the numbers over 40 days of data, considering *ONLY* the fetches = made to a dualstack URL. stf =C2=A0 =C2=A0 =C2=A0 =C2=A0 2766v4 23002469v6 =C2=A0 =C2=A0 474779 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of the= total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In = this measure, IPv6 is around 2% of total request traffic, which is lower th= an even our pessimistic world-rate, but I did no complex analysis of this b= y economy or anything, its an un-weighted simple sum. The point being, that over a 40 day period 2,700 odd people insisted on usi= ng 6to4, given a dual-stack URL out of 23,000,000 connections.=C2=A0 I beli= eve would be going too far to consider this right now as a damage risk.=C2= =A0 A Top-10 OS/Browser list: Windows 7.Chrome =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01574Windows 7.Firefox = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0328Macintosh [na].Safari = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0250Windows 8.1.Chrome =C2=A0 =C2=A0 =C2= =A0 =C2=A0 162Windows 7.Microsoft IE =C2=A0 =C2=A0 =C2=A0 =C2=A095Windows 8= .Chrome =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A081Windows Vista.Chr= ome =C2=A0 =C2=A0 =C2=A0 =C2=A074Windows 7.Opera =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 52Windows XP.Chrome =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 34Windows 8.1.Firefox =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 23 On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti wrote: On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter wrote: On 05/02/2015 12:23, Mark ZZZ Smith wrote: > While I appreciate that the draft isn't advising to block 6to4, I think i= t would be useful to gain some more detailed insight into the consequences = of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending o= n the results, it may also mean that making a strong statement not to block= 6to4 traffic in the draft would be beneficial, reinforcing what is in RFC6= 343. otoh, if we leave the text as it is now we have a fair chance of getting th= rough the IETF Last Call and the IESG, and finally getting this done. +1. We can always explore that question in a separate document once this on= e is published. If it turns out that blocking provides no benefit and/or is= harmful, then nothing changes. If it turns out that it can be done safely,= then we can issue an operational guidance document advising it.=C2=A0 ------=_Part_659398_463277315.1423210358445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Geo= rge,

Thanks very much for the new= data.

(Off topic for the dr= aft) I do find the entries in the list of OS/Browsers a bit surprising - it= either implies that they didn't have native IPv4 connectivity and only had= 6to4, or weren't following RFC3484/6724 rules, which is surprising given h= ow modern they all look.

Some searches have shown up some articles from Microsoft saying that they= 've been following RFC3484 rules since at least Windows Vista, and there ar= e some registry hacks that can disable that, so perhaps that might explain = the Windows entries Vista and later.

I found an article that said that since Mac OS X 10.6.5, native IPv4 is p= referred over 6to4 IPv6, perhaps the Macintosh's in your list are pre-10.6.= 5.

<= div id=3D"yui_3_16_0_1_1423205443739_8243" dir=3D"ltr">Thanks,
Mark.

<= hr size=3D"1" id=3D"yui_3_16_0_1_1423205443739_8251"> From: George Michaelson <ggm@algebras.org> To: Lorenzo Colitti <= ;lorenzo@google.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; Mark ZZZ Smith= <markzzzsmith@yahoo.com.au>; "v6ops@ietf.org" <v6ops@ietf.org>= ; Tore Anderson <tore@fud.no>
Sent: Thursday, 5 February 2015, 14:48
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-= to-historic WGLC

I think I agree with Lorenzo.&nbs= p;

<= div dir=3D"ltr" id=3D"yui_3_16_0_1_1423205443739_8335">


I did run the numbers over 40 days of data, considering *ONL= Y* the fetches made to a dualstack URL.

=
stf         2766
v4 23002469
v6     474779

6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01= % of the total load seen on a dual-stack URL, and its only 0.57% of total I= Pv6. In this measure, IPv6 is around 2% of total request traffic, which is = lower than even our pessimistic world-rate, but I did no complex analysis o= f this by economy or anything, its an un-weighted simple sum.

The point being, that over a 40 day period 2= ,700 odd people insisted on using 6to4, given a dual-stack URL out of 23,00= 0,000 connections.  I believe would be going too far to consider this = right now as a damage risk. 

A Top-10 OS/Browser list:

Windows 7.Chrome     &nbs= p;    1574
Windo= ws 7.Firefox              328
Macintosh [na].Safari     =      250
Wi= ndows 8.1.Chrome         162
Windows 7.Micros= oft IE        95
Windows 8.Chrome   &nbs= p;          81
Windows Vista.Chrome &nbs= p;      74
Windows 7.Opera       &n= bsp;         52
Windows XP.Chrome   &nbs= p;       34
Windows 8.1.Firefox     &nbs= p;       23




On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti <lorenzo@goo= gle.com> wrote:
=
On Th= u, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 05/02/2015 12:23, Mark ZZZ Smith = wrote:
> While I appreciate that the draft isn't advising to block 6to4, I thin= k it would be useful to gain some more detailed insight into the consequenc= es of blocking 6to4 (i.e., which OSes/browsers might be impacted). Dependin= g on the results, it may also mean that making a strong statement not to bl= ock 6to4 traffic in the draft would be beneficial, reinforcing what is in R= FC6343.

otoh, if we leave the text as it is now we have a fair chance of get= ting through
the IETF Last Call and the IESG, and finally getting this done.

+1. We can always ex= plore that question in a separate document once this one is published. If i= t turns out that blocking provides no benefit and/or is harmful, then nothi= ng changes. If it turns out that it can be done safely, then we can issue a= n operational guidance document advising it. 
=



------=_Part_659398_463277315.1423210358445-- From nobody Fri Feb 6 05:22:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81D1A1AB5 for ; Fri, 6 Feb 2015 05:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5CMMhgqXycJ for ; Fri, 6 Feb 2015 05:22:29 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B091A1AB0 for ; Fri, 6 Feb 2015 05:22:29 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 5AAA71FCC6F; Fri, 6 Feb 2015 13:22:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 237CA160066; Fri, 6 Feb 2015 13:29:10 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 660E3160055; Fri, 6 Feb 2015 13:29:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6C4FA28E3B7B; Sat, 7 Feb 2015 00:22:18 +1100 (EST) To: Mark ZZZ Smith From: Mark Andrews References: <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com> In-reply-to: Your message of "Fri, 06 Feb 2015 08:12:38 -0000." <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 07 Feb 2015 00:22:17 +1100 Message-Id: <20150206132218.6C4FA28E3B7B@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 13:22:30 -0000 In message <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com>, Mark ZZZ Smith writes: > > Hi George, > Thanks very much for the new data. > (Off topic for the draft) I do find the entries in the list of > OS/Browsers a bit surprising - it either implies that they didn't have > native IPv4 connectivity and only had 6to4, or weren't following > RFC3484/6724 rules, which is surprising given how modern they all look. If you have a IPv4 and a IPv6 address and the v4 connection attempt fails then the v6 address will be tried and if the only viable source address is 6to4 then that will be used. > Some searches have shown up some articles from Microsoft saying that > they've been following RFC3484 rules since at least Windows Vista, and > there are some registry hacks that can disable that, so perhaps that > might explain the Windows entries Vista and later. > I found an article that said that since Mac OS X 10.6.5, native IPv4 is > preferred over 6to4 IPv6, perhaps the Macintosh's in your list are > pre-10.6.5. > Thanks,Mark. > From: George Michaelson > To: Lorenzo Colitti > Cc: Brian E Carpenter ; Mark ZZZ Smith > ; "v6ops@ietf.org" ; Tore > Anderson > Sent: Thursday, 5 February 2015, 14:48 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > I think I agree with Lorenzo.  > > > > I did run the numbers over 40 days of data, considering *ONLY* the > fetches made to a dualstack URL. > stf         2766 > v4 23002469 > v6     474779 > 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of > the total load seen on a dual-stack URL, and its only 0.57% of total > IPv6. In this measure, IPv6 is around 2% of total request traffic, which > is lower than even our pessimistic world-rate, but I did no complex > analysis of this by economy or anything, its an un-weighted simple sum. > The point being, that over a 40 day period 2,700 odd people insisted on > using 6to4, given a dual-stack URL out of 23,000,000 connections.  I > believe would be going too far to consider this right now as a damage > risk.  > A Top-10 OS/Browser list: > Windows 7.Chrome          1574 > Windows 7.Firefox              328 > Macintosh [na].Safari          250 > Windows 8.1.Chrome         162 > Windows 7.Microsoft IE        95 > Windows 8.Chrome              81 > Windows Vista.Chrome         74 > Windows 7.Opera                 52 > Windows XP.Chrome           34 > Windows 8.1.Firefox             23 > > > > > On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti > wrote: > > On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter > wrote: > > On 05/02/2015 12:23, Mark ZZZ Smith wrote: > > While I appreciate that the draft isn't advising to block 6to4, I think > it would be useful to gain some more detailed insight into the > consequences of blocking 6to4 (i.e., which OSes/browsers might be > impacted). Depending on the results, it may also mean that making a > strong statement not to block 6to4 traffic in the draft would be > beneficial, reinforcing what is in RFC6343. > > otoh, if we leave the text as it is now we have a fair chance of getting > through > the IETF Last Call and the IESG, and finally getting this done. > > > +1. We can always explore that question in a separate document once this > one is published. If it turns out that blocking provides no benefit > and/or is harmful, then nothing changes. If it turns out that it can be > done safely, then we can issue an operational guidance document advising > it.  -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Feb 6 06:56:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0A01A1AFE for ; Fri, 6 Feb 2015 06:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1as9jHQo7dB for ; Fri, 6 Feb 2015 06:55:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AF01A1AE2 for ; Fri, 6 Feb 2015 06:55:56 -0800 (PST) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB730.namprd04.prod.outlook.com (10.141.229.17) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 14:55:34 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 14:55:31 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0081.018; Fri, 6 Feb 2015 14:55:31 +0000 From: "Metzler, Dan J" To: Mark ZZZ Smith , George Michaelson , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHQQAd7SSN0x98hRUKJ5KFP4IYHJZzfoBOAgAGDLICAAATSAIAAAxwAgABB2ACAAdxDAIAAYuXw Date: Fri, 6 Feb 2015 14:55:31 +0000 Message-ID: References: <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <647306733.659399.1423210358451.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:d8c2:8652:93b5:e29a] authentication-results: yahoo.com.au; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(479174004)(164054003)(377454003)(87936001)(122556002)(2656002)(106116001)(75432002)(89122001)(40100003)(74316001)(2950100001)(2900100001)(561924002)(77156002)(46102003)(33656002)(92566002)(62966003)(88552001)(76176999)(99286002)(54356999)(76576001)(19609705001)(50986999)(19625215002)(15975445007)(19580395003)(19580405001)(230783001)(2521001)(19300405004)(68736005)(86362001)(77096005)(16236675004)(102836002)(90282001)(97736003)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR04MB585BE5436BABCB9D2B913E3FE380CO2PR04MB585namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2015 14:55:31.5410 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB730; X-OriginatorOrg: uiowa.edu Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:56:01 -0000 --_000_CO2PR04MB585BE5436BABCB9D2B913E3FE380CO2PR04MB585namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcKE9mZiB0b3BpYyBmb3IgdGhlIGRyYWZ0KSBJIGRvIGZpbmQgdGhlIGVudHJpZXMgaW4gdGhl IGxpc3Qgb2YgT1MvQnJvd3NlcnMgYSBiaXQgc3VycHJpc2luZyAtIGl0IGVpdGhlciBpbXBsaWVz IHRoYXQgdGhleSBkaWRuJ3QgaGF2ZSBuYXRpdmUgSVB2NCBjb25uZWN0aXZpdHkgYW5kIG9ubHkg aGFkIDZ0bzQsIG9yIHdlcmVuJ3QgZm9sbG93aW5nIFJGQzM0ODQvNjcyNCBydWxlcywgd2hpY2gg aXMgc3VycHJpc2luZyBnaXZlbiBob3cgbW9kZXJuIHRoZXkgYWxsIGxvb2su4oCdDQoNClZpc3Rh L1dpbmRvd3MgU2VydmVyIDIwMDgg4oCTIEZvbGxvdyBSRkMgMzQ4NCAgKEhhdmUgdG8gbWFudWFs bHkgY2hhbmdlIHRoZSBwcmVmaXggc2VsZWN0aW9uIHRhYmxlIHRvIGdldCBtb3JlIG1vZGVybiBi ZWhhdmlvcikNCldpbmRvd3MgNy9XaW5kb3dzIFNlcnZlciAyMDA4IFIyIHdpdGhvdXQgSVB2NiBy ZWFkaW5lc3MgdXBkYXRlIChLQjI3NTA4NDEpIOKAkyBGb2xsb3cgUkZDIDM0ODQNCldpbmRvd3Mg Ny9XaW5kb3dzIFNlcnZlciAyMDA4IFIyIHdpdGggSVB2NiByZWFkaW5lc3MgdXBkYXRlIChLQjI3 NTA4NDEpIOKAkyBGb2xsb3cgUkZDIDY3MjQNCldpbmRvd3MgOC84LjEvV2luZG93cyBTZXJ2ZXIg MjAxMiDigJMgRm9sbG93IFJGQyA2NzI0DQoNCk9mIGNvdXJzZSBzb21lIGNoYW5nZSB0aGUgZGVm YXVsdCBwcmVmaXggdGFibGVzLiAgVGhlIGFib3ZlIG9ubHkgcmVmbGVjdCBkZWZhdWx0cywgYW5k IHRoYXQgaXNu4oCZdCBqdXN0IGZvciBXaW5kb3dzLg0KTkNTSSAoTWljcm9zb2Z0IEhhcHB5IEV5 ZWJhbGxzIGxpa2UgaW1wbGVtZW50YXRpb24/KSBhZmZlY3RzIHJlc3VsdHMgaGVyZSwgYnV0IG5v dCBzdXJlIHdoYXQgaGFwcGVucyB3aXRoIENocm9tZSBhbmQgRmlyZWZveCBydW5uaW5nIG9uIFdp bmRvd3MuDQoNCg0KLSAgICAgICAgICBEYW4NCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyayBaWlogU21pdGgNClNlbnQ6IEZyaWRh eSwgRmVicnVhcnkgNiwgMjAxNSAyOjEzIEFNDQpUbzogR2VvcmdlIE1pY2hhZWxzb247IExvcmVu em8gQ29saXR0aQ0KQ2M6IHY2b3BzQGlldGYub3JnOyBUb3JlIEFuZGVyc29uDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMgV0dMQw0KDQpIaSBH ZW9yZ2UsDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSBuZXcgZGF0YS4NCg0KKE9mZiB0b3Bp YyBmb3IgdGhlIGRyYWZ0KSBJIGRvIGZpbmQgdGhlIGVudHJpZXMgaW4gdGhlIGxpc3Qgb2YgT1Mv QnJvd3NlcnMgYSBiaXQgc3VycHJpc2luZyAtIGl0IGVpdGhlciBpbXBsaWVzIHRoYXQgdGhleSBk aWRuJ3QgaGF2ZSBuYXRpdmUgSVB2NCBjb25uZWN0aXZpdHkgYW5kIG9ubHkgaGFkIDZ0bzQsIG9y IHdlcmVuJ3QgZm9sbG93aW5nIFJGQzM0ODQvNjcyNCBydWxlcywgd2hpY2ggaXMgc3VycHJpc2lu ZyBnaXZlbiBob3cgbW9kZXJuIHRoZXkgYWxsIGxvb2suDQoNClNvbWUgc2VhcmNoZXMgaGF2ZSBz aG93biB1cCBzb21lIGFydGljbGVzIGZyb20gTWljcm9zb2Z0IHNheWluZyB0aGF0IHRoZXkndmUg YmVlbiBmb2xsb3dpbmcgUkZDMzQ4NCBydWxlcyBzaW5jZSBhdCBsZWFzdCBXaW5kb3dzIFZpc3Rh LCBhbmQgdGhlcmUgYXJlIHNvbWUgcmVnaXN0cnkgaGFja3MgdGhhdCBjYW4gZGlzYWJsZSB0aGF0 LCBzbyBwZXJoYXBzIHRoYXQgbWlnaHQgZXhwbGFpbiB0aGUgV2luZG93cyBlbnRyaWVzIFZpc3Rh IGFuZCBsYXRlci4NCg0KSSBmb3VuZCBhbiBhcnRpY2xlIHRoYXQgc2FpZCB0aGF0IHNpbmNlIE1h YyBPUyBYIDEwLjYuNSwgbmF0aXZlIElQdjQgaXMgcHJlZmVycmVkIG92ZXIgNnRvNCBJUHY2LCBw ZXJoYXBzIHRoZSBNYWNpbnRvc2gncyBpbiB5b3VyIGxpc3QgYXJlIHByZS0xMC42LjUuDQoNClRo YW5rcywNCk1hcmsuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBH ZW9yZ2UgTWljaGFlbHNvbiA8Z2dtQGFsZ2VicmFzLm9yZzxtYWlsdG86Z2dtQGFsZ2VicmFzLm9y Zz4+DQpUbzogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbT4+DQpDYzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj47IE1hcmsgWlpa IFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PG1haWx0bzptYXJrenp6c21pdGhAeWFo b28uY29tLmF1Pj47ICJ2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IiA8djZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj47IFRvcmUgQW5kZXJzb24gPHRvcmVA ZnVkLm5vPG1haWx0bzp0b3JlQGZ1ZC5ubz4+DQpTZW50OiBUaHVyc2RheSwgNSBGZWJydWFyeSAy MDE1LCAxNDo0OA0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRv LWhpc3RvcmljIFdHTEMNCg0KSSB0aGluayBJIGFncmVlIHdpdGggTG9yZW56by4NCg0KDQoNCg0K SSBkaWQgcnVuIHRoZSBudW1iZXJzIG92ZXIgNDAgZGF5cyBvZiBkYXRhLCBjb25zaWRlcmluZyAq T05MWSogdGhlIGZldGNoZXMgbWFkZSB0byBhIGR1YWxzdGFjayBVUkwuDQoNCnN0ZiAgICAgICAg IDI3NjYNCnY0IDIzMDAyNDY5DQp2NiAgICAgNDc0Nzc5DQoNCjYgdG8gNCAoc3RmKSBpbiB0aGlz IG1lYXN1cmUgaXMgKGFzIExvcmVuem8gc2F5cykgb2YgdGhlIG9yZGVyIDAuMDElIG9mIHRoZSB0 b3RhbCBsb2FkIHNlZW4gb24gYSBkdWFsLXN0YWNrIFVSTCwgYW5kIGl0cyBvbmx5IDAuNTclIG9m IHRvdGFsIElQdjYuIEluIHRoaXMgbWVhc3VyZSwgSVB2NiBpcyBhcm91bmQgMiUgb2YgdG90YWwg cmVxdWVzdCB0cmFmZmljLCB3aGljaCBpcyBsb3dlciB0aGFuIGV2ZW4gb3VyIHBlc3NpbWlzdGlj IHdvcmxkLXJhdGUsIGJ1dCBJIGRpZCBubyBjb21wbGV4IGFuYWx5c2lzIG9mIHRoaXMgYnkgZWNv bm9teSBvciBhbnl0aGluZywgaXRzIGFuIHVuLXdlaWdodGVkIHNpbXBsZSBzdW0uDQoNClRoZSBw b2ludCBiZWluZywgdGhhdCBvdmVyIGEgNDAgZGF5IHBlcmlvZCAyLDcwMCBvZGQgcGVvcGxlIGlu c2lzdGVkIG9uIHVzaW5nIDZ0bzQsIGdpdmVuIGEgZHVhbC1zdGFjayBVUkwgb3V0IG9mIDIzLDAw MCwwMDAgY29ubmVjdGlvbnMuICBJIGJlbGlldmUgd291bGQgYmUgZ29pbmcgdG9vIGZhciB0byBj b25zaWRlciB0aGlzIHJpZ2h0IG5vdyBhcyBhIGRhbWFnZSByaXNrLg0KDQpBIFRvcC0xMCBPUy9C cm93c2VyIGxpc3Q6DQoNCldpbmRvd3MgNy5DaHJvbWUgICAgICAgICAgMTU3NA0KV2luZG93cyA3 LkZpcmVmb3ggICAgICAgICAgICAgIDMyOA0KTWFjaW50b3NoIFtuYV0uU2FmYXJpICAgICAgICAg IDI1MA0KV2luZG93cyA4LjEuQ2hyb21lICAgICAgICAgMTYyDQpXaW5kb3dzIDcuTWljcm9zb2Z0 IElFICAgICAgICA5NQ0KV2luZG93cyA4LkNocm9tZSAgICAgICAgICAgICAgODENCldpbmRvd3Mg VmlzdGEuQ2hyb21lICAgICAgICA3NA0KV2luZG93cyA3Lk9wZXJhICAgICAgICAgICAgICAgICA1 Mg0KV2luZG93cyBYUC5DaHJvbWUgICAgICAgICAgIDM0DQpXaW5kb3dzIDguMS5GaXJlZm94ICAg ICAgICAgICAgIDIzDQoNCg0KDQoNCk9uIFRodSwgRmViIDUsIDIwMTUgYXQgOTo1MiBBTSwgTG9y ZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bT4+IHdyb3RlOg0KT24gVGh1LCBGZWIgNSwgMjAxNSBhdCA4OjQxIEFNLCBCcmlhbiBFIENhcnBl bnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDA1LzAyLzIwMTUgMTI6MjMsIE1hcmsgWlpaIFNtaXRo IHdyb3RlOg0KPiBXaGlsZSBJIGFwcHJlY2lhdGUgdGhhdCB0aGUgZHJhZnQgaXNuJ3QgYWR2aXNp bmcgdG8gYmxvY2sgNnRvNCwgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZ2FpbiBzb21l IG1vcmUgZGV0YWlsZWQgaW5zaWdodCBpbnRvIHRoZSBjb25zZXF1ZW5jZXMgb2YgYmxvY2tpbmcg NnRvNCAoaS5lLiwgd2hpY2ggT1Nlcy9icm93c2VycyBtaWdodCBiZSBpbXBhY3RlZCkuIERlcGVu ZGluZyBvbiB0aGUgcmVzdWx0cywgaXQgbWF5IGFsc28gbWVhbiB0aGF0IG1ha2luZyBhIHN0cm9u ZyBzdGF0ZW1lbnQgbm90IHRvIGJsb2NrIDZ0bzQgdHJhZmZpYyBpbiB0aGUgZHJhZnQgd291bGQg YmUgYmVuZWZpY2lhbCwgcmVpbmZvcmNpbmcgd2hhdCBpcyBpbiBSRkM2MzQzLg0KDQpvdG9oLCBp ZiB3ZSBsZWF2ZSB0aGUgdGV4dCBhcyBpdCBpcyBub3cgd2UgaGF2ZSBhIGZhaXIgY2hhbmNlIG9m IGdldHRpbmcgdGhyb3VnaA0KdGhlIElFVEYgTGFzdCBDYWxsIGFuZCB0aGUgSUVTRywgYW5kIGZp bmFsbHkgZ2V0dGluZyB0aGlzIGRvbmUuDQoNCisxLiBXZSBjYW4gYWx3YXlzIGV4cGxvcmUgdGhh dCBxdWVzdGlvbiBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uY2UgdGhpcyBvbmUgaXMgcHVibGlz aGVkLiBJZiBpdCB0dXJucyBvdXQgdGhhdCBibG9ja2luZyBwcm92aWRlcyBubyBiZW5lZml0IGFu ZC9vciBpcyBoYXJtZnVsLCB0aGVuIG5vdGhpbmcgY2hhbmdlcy4gSWYgaXQgdHVybnMgb3V0IHRo YXQgaXQgY2FuIGJlIGRvbmUgc2FmZWx5LCB0aGVuIHdlIGNhbiBpc3N1ZSBhbiBvcGVyYXRpb25h bCBndWlkYW5jZSBkb2N1bWVudCBhZHZpc2luZyBpdC4NCg0KDQo= --_000_CO2PR04MB585BE5436BABCB9D2B913E3FE380CO2PR04MB585namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi55 aXY3MjkwNzA4NTYxDQoJe21zby1zdHlsZS1uYW1lOnlpdjcyOTA3MDg1NjE7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDc4OTQxNDg1 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc0OTQw MzY1OCAtNDMwODA5MzI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4oT2ZmIHRvcGlj IGZvciB0aGUgZHJhZnQpIEkgZG8gZmluZCB0aGUgZW50cmllcyBpbiB0aGUgbGlzdCBvZiBPUy9C cm93c2VycyBhIGJpdCBzdXJwcmlzaW5nDQogLSBpdCBlaXRoZXIgaW1wbGllcyB0aGF0IHRoZXkg ZGlkbid0IGhhdmUgbmF0aXZlIElQdjQgY29ubmVjdGl2aXR5IGFuZCBvbmx5IGhhZCA2dG80LCBv ciB3ZXJlbid0IGZvbGxvd2luZyBSRkMzNDg0LzY3MjQgcnVsZXMsIHdoaWNoIGlzIHN1cnByaXNp bmcgZ2l2ZW4gaG93IG1vZGVybiB0aGV5IGFsbCBsb29rLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5WaXN0YS9XaW5kb3dzIFNlcnZlciAyMDA4IOKAkyBGb2xsb3cgUkZDIDM0ODQmbmJzcDsg KEhhdmUgdG8gbWFudWFsbHkgY2hhbmdlIHRoZSBwcmVmaXggc2VsZWN0aW9uIHRhYmxlIHRvIGdl dCBtb3JlIG1vZGVybiBiZWhhdmlvcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2luZG93cyA3L1dpbmRv d3MgU2VydmVyIDIwMDggUjIgd2l0aG91dCBJUHY2IHJlYWRpbmVzcyB1cGRhdGUgKEtCMjc1MDg0 MSkg4oCTIEZvbGxvdyBSRkMgMzQ4NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaW5kb3dzIDcvV2luZG93 cyBTZXJ2ZXIgMjAwOCBSMiB3aXRoIElQdjYgcmVhZGluZXNzIHVwZGF0ZSAoS0IyNzUwODQxKSDi gJMgRm9sbG93IFJGQyA2NzI0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpbmRvd3MgOC84LjEvV2luZG93 cyBTZXJ2ZXIgMjAxMiDigJMgRm9sbG93IFJGQyA2NzI0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5PZiBjb3Vyc2Ugc29tZSBjaGFuZ2UgdGhlIGRlZmF1bHQgcHJl Zml4IHRhYmxlcy4mbmJzcDsgVGhlIGFib3ZlIG9ubHkgcmVmbGVjdCBkZWZhdWx0cywgYW5kIHRo YXQgaXNu4oCZdCBqdXN0IGZvciBXaW5kb3dzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5OQ1NJIChNaWNy b3NvZnQgSGFwcHkgRXllYmFsbHMgbGlrZSBpbXBsZW1lbnRhdGlvbj8pIGFmZmVjdHMgcmVzdWx0 cyBoZXJlLCBidXQgbm90IHN1cmUgd2hhdCBoYXBwZW5zIHdpdGggQ2hyb21lIGFuZCBGaXJlZm94 IHJ1bm5pbmcgb24gV2luZG93cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+RGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJrIFpa WiBTbWl0aDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDYsIDIwMTUgMjoxMyBB TTxicj4NCjxiPlRvOjwvYj4gR2VvcmdlIE1pY2hhZWxzb247IExvcmVuem8gQ29saXR0aTxicj4N CjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc7IFRvcmUgQW5kZXJzb248YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljIFdHTEM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0 MjMyMDU0NDM3MzlfODE2MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSBHZW9yZ2UsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MTYxIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8x XzE0MjMyMDU0NDM3MzlfODE2MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgbmV3IGRh dGEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFf MTQyMzIwNTQ0MzczOV84MjA0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI0NCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4oT2Zm IHRvcGljIGZvciB0aGUgZHJhZnQpIEkgZG8gZmluZCB0aGUgZW50cmllcyBpbiB0aGUgbGlzdCBv ZiBPUy9Ccm93c2VycyBhIGJpdCBzdXJwcmlzaW5nIC0gaXQgZWl0aGVyIGltcGxpZXMgdGhhdCB0 aGV5IGRpZG4ndCBoYXZlIG5hdGl2ZSBJUHY0IGNvbm5lY3Rpdml0eQ0KIGFuZCBvbmx5IGhhZCA2 dG80LCBvciB3ZXJlbid0IGZvbGxvd2luZyBSRkMzNDg0LzY3MjQgcnVsZXMsIHdoaWNoIGlzIHN1 cnByaXNpbmcgZ2l2ZW4gaG93IG1vZGVybiB0aGV5IGFsbCBsb29rLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI0NCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyNDQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U29tZSBzZWFyY2hlcyBoYXZlIHNob3du IHVwIHNvbWUgYXJ0aWNsZXMgZnJvbSBNaWNyb3NvZnQgc2F5aW5nIHRoYXQgdGhleSd2ZSBiZWVu IGZvbGxvd2luZyBSRkMzNDg0IHJ1bGVzIHNpbmNlIGF0IGxlYXN0IFdpbmRvd3MgVmlzdGEsIGFu ZCB0aGVyZSBhcmUNCiBzb21lIHJlZ2lzdHJ5IGhhY2tzIHRoYXQgY2FuIGRpc2FibGUgdGhhdCwg c28gcGVyaGFwcyB0aGF0IG1pZ2h0IGV4cGxhaW4gdGhlIFdpbmRvd3MgZW50cmllcyBWaXN0YSBh bmQgbGF0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQyMzIwNTQ0MzczOV84MjQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI0MyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5JIGZvdW5kIGFuIGFydGljbGUgdGhhdCBzYWlkIHRoYXQgc2luY2UgTWFjIE9TIFggMTAuNi41 LCBuYXRpdmUgSVB2NCBpcyBwcmVmZXJyZWQgb3ZlciA2dG80IElQdjYsIHBlcmhhcHMgdGhlIE1h Y2ludG9zaCdzIGluIHlvdXIgbGlzdCBhcmUgcHJlLTEwLjYuNS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyNDMiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQyMzIwNTQ0MzczOV84MjQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyNDMiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+TWFyay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2 XzBfMV8xNDIzMjA1NDQzNzM5XzgyNDIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MTY1Ij4NCjxk aXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgxNjQiPg0KPGRpdiBpZD0ieXVpXzNf MTZfMF8xXzE0MjMyMDU0NDM3MzlfODE2MyI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IEdlb3JnZSBNaWNoYWVsc29uICZs dDs8YSBocmVmPSJtYWlsdG86Z2dtQGFsZ2VicmFzLm9yZyI+Z2dtQGFsZ2VicmFzLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+VG86PC9iPiBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzps b3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5D Yzo8L2I+IEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+Jmd0OzsgTWFy ayBaWlogU21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1 Ij5tYXJrenp6c21pdGhAeWFob28uY29tLmF1PC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDs7DQogVG9yZSBBbmRl cnNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcmVAZnVkLm5vIj50b3JlQGZ1ZC5ubzwvYT4mZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgNSBGZWJydWFyeSAyMDE1LCAxNDo0ODxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlz dG9yaWMgV0dMQzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5 XzgyNTUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgaWQ9InlpdjcyOTA3MDg1NjEiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0 NDM3MzlfODI1NCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB0aGluayBJIGFncmVlIHdpdGggTG9y ZW56by4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyODQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMy MDU0NDM3MzlfODMzNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MjU3 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MjU2Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2 XzBfMV8xNDIzMjA1NDQzNzM5XzgyODMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgZGlkIHJ1biB0 aGUgbnVtYmVycyBvdmVyIDQwIGRheXMgb2YgZGF0YSwgY29uc2lkZXJpbmcgKk9OTFkqIHRoZSBm ZXRjaGVzIG1hZGUgdG8gYSBkdWFsc3RhY2sgVVJMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyNTkiPg0K PGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI4NSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+c3RmICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyNzY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MjU4 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj52NCAyMzAwMjQ2OTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI4MiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+djYgJm5ic3A7ICZuYnNwOyA0NzQ3Nzk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3Mzlf ODI4MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MjYwIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj42IHRvIDQgKHN0ZikgaW4gdGhpcyBtZWFzdXJlIGlzIChhcyBMb3Jlbnpv IHNheXMpIG9mIHRoZSBvcmRlciAwLjAxJSBvZiB0aGUgdG90YWwgbG9hZCBzZWVuIG9uIGEgZHVh bC1zdGFjayBVUkwsIGFuZCBpdHMgb25seSAwLjU3JSBvZg0KIHRvdGFsIElQdjYuIEluIHRoaXMg bWVhc3VyZSwgSVB2NiBpcyBhcm91bmQgMiUgb2YgdG90YWwgcmVxdWVzdCB0cmFmZmljLCB3aGlj aCBpcyBsb3dlciB0aGFuIGV2ZW4gb3VyIHBlc3NpbWlzdGljIHdvcmxkLXJhdGUsIGJ1dCBJIGRp ZCBubyBjb21wbGV4IGFuYWx5c2lzIG9mIHRoaXMgYnkgZWNvbm9teSBvciBhbnl0aGluZywgaXRz IGFuIHVuLXdlaWdodGVkIHNpbXBsZSBzdW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84MjgwIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1 aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyNjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBw b2ludCBiZWluZywgdGhhdCBvdmVyIGEgNDAgZGF5IHBlcmlvZCAyLDcwMCBvZGQgcGVvcGxlIGlu c2lzdGVkIG9uIHVzaW5nIDZ0bzQsIGdpdmVuIGEgZHVhbC1zdGFjayBVUkwgb3V0IG9mIDIzLDAw MCwwMDAgY29ubmVjdGlvbnMuJm5ic3A7DQogSSBiZWxpZXZlIHdvdWxkIGJlIGdvaW5nIHRvbyBm YXIgdG8gY29uc2lkZXIgdGhpcyByaWdodCBub3cgYXMgYSBkYW1hZ2Ugcmlzay4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1 NDQzNzM5XzgyOTMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3MzlfODI5MiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+QSBUb3AtMTAgT1MvQnJvd3NlciBsaXN0OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3Mzlf ODI4NiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzIwNTQ0MzczOV84Mjg4Ij4NCjxkaXYg aWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyOTEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PldpbmRvd3MgNy5DaHJvbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzE1NzQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIz MjA1NDQzNzM5XzgyOTAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldpbmRvd3MgNy5GaXJlZm94ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMyODxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjMyMDU0NDM3 MzlfODI4OSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TWFjaW50b3NoIFtuYV0uU2FmYXJpICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyNTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzMjA1NDQzNzM5XzgyODciPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPldpbmRvd3MgOC4xLkNocm9tZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgMTYyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPldpbmRvd3MgNy5NaWNyb3NvZnQgSUUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+V2luZG93cyA4LkNocm9tZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs4MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5XaW5kb3dzIFZpc3RhLkNocm9tZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs3NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5XaW5kb3dzIDcuT3BlcmEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA1MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XaW5kb3dzIFhQLkNocm9tZSAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDM0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldpbmRvd3MgOC4xLkZpcmVmb3ggJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5aXY3MjkwNzA4NTYxeXF0OTAxODEiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPk9uIFRodSwgRmViIDUsIDIwMTUgYXQgOTo1MiBBTSwgTG9yZW56byBDb2xpdHRp ICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBjbGFzcz0ieWl2NzI5MDcwODU2MSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gVGh1LCBGZWIgNSwgMjAxNSBhdCA4OjQxIEFNLCBC cmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4m Z3Q7DQogd3JvdGU6PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9u IDA1LzAyLzIwMTUgMTI6MjMsIE1hcmsgWlpaIFNtaXRoIHdyb3RlOjxicj4NCiZndDsgV2hpbGUg SSBhcHByZWNpYXRlIHRoYXQgdGhlIGRyYWZ0IGlzbid0IGFkdmlzaW5nIHRvIGJsb2NrIDZ0bzQs IEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGdhaW4gc29tZSBtb3JlIGRldGFpbGVkIGlu c2lnaHQgaW50byB0aGUgY29uc2VxdWVuY2VzIG9mIGJsb2NraW5nIDZ0bzQgKGkuZS4sIHdoaWNo IE9TZXMvYnJvd3NlcnMgbWlnaHQgYmUgaW1wYWN0ZWQpLiBEZXBlbmRpbmcgb24gdGhlIHJlc3Vs dHMsIGl0IG1heSBhbHNvIG1lYW4NCiB0aGF0IG1ha2luZyBhIHN0cm9uZyBzdGF0ZW1lbnQgbm90 IHRvIGJsb2NrIDZ0bzQgdHJhZmZpYyBpbiB0aGUgZHJhZnQgd291bGQgYmUgYmVuZWZpY2lhbCwg cmVpbmZvcmNpbmcgd2hhdCBpcyBpbiBSRkM2MzQzLjxicj4NCjxicj4NCm90b2gsIGlmIHdlIGxl YXZlIHRoZSB0ZXh0IGFzIGl0IGlzIG5vdyB3ZSBoYXZlIGEgZmFpciBjaGFuY2Ugb2YgZ2V0dGlu ZyB0aHJvdWdoPGJyPg0KdGhlIElFVEYgTGFzdCBDYWxsIGFuZCB0aGUgSUVTRywgYW5kIGZpbmFs bHkgZ2V0dGluZyB0aGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JiM0MzsxLiBXZSBjYW4gYWx3YXlz IGV4cGxvcmUgdGhhdCBxdWVzdGlvbiBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uY2UgdGhpcyBv bmUgaXMgcHVibGlzaGVkLiBJZiBpdCB0dXJucyBvdXQgdGhhdCBibG9ja2luZyBwcm92aWRlcyBu byBiZW5lZml0DQogYW5kL29yIGlzIGhhcm1mdWwsIHRoZW4gbm90aGluZyBjaGFuZ2VzLiBJZiBp dCB0dXJucyBvdXQgdGhhdCBpdCBjYW4gYmUgZG9uZSBzYWZlbHksIHRoZW4gd2UgY2FuIGlzc3Vl IGFuIG9wZXJhdGlvbmFsIGd1aWRhbmNlIGRvY3VtZW50IGFkdmlzaW5nIGl0LiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR04MB585BE5436BABCB9D2B913E3FE380CO2PR04MB585namprd_-- From nobody Mon Feb 9 01:14:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BBD1A0102 for ; Mon, 9 Feb 2015 01:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oyFH2MkOmg1 for ; Mon, 9 Feb 2015 01:14:54 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D003B1A00E5 for ; Mon, 9 Feb 2015 01:14:53 -0800 (PST) Received: from [85.158.136.3] by server-6.bemta-5.messagelabs.com id 9D/44-03165-B8A78D45; Mon, 09 Feb 2015 09:14:51 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-13.tower-123.messagelabs.com!1423473291!36952984!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4991 invoked from network); 9 Feb 2015 09:14:51 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-13.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2015 09:14:51 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Mon, 09 Feb 2015 09:14:49 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 09 Feb 2015 09:14:50 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 09:14:50 +0000 From: "Heatley, Nick" To: "Fred Baker (fred)" , "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzXBDUAgACFfoCAANnEAIAAGFgAgAAcc4CABr3FgIAA+7oA Date: Mon, 9 Feb 2015 09:14:50 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 09:14:57 -0000 SnVzdCBhIHJlbWluZGVyIG9uIHdoeSBJLCBhcyBhbiBvcGVyYXRvciwgaGF2ZSBhIG5lZWQgb2Yg YSBkb2N1bWVudCBmcm9tIHRoZSBJRVRGLiANCkkgZGVzaXJlOg0KLSBhbiBJUCBwcm9maWxlIGZy b20gSUVURiAtIElFVEYgaXMgdGhlIGhvbWUgb2YgSVAgYW5kIEludGVybmV0IEVuZ2luZWVyaW5n IChidXQgaGFwcHkgdG8gdGllIHVwIHdpdGggM0dQUCBldGMuKQ0KLSBhIHByb2ZpbGUgZm9yIG1v YmlsZSBkZXZpY2VzIHdoZW4gdGhlIG5ldHdvcmsgb2ZmZXJzIHRoZW0gSVB2Ni1vbmx5IChkdWFs c3RhY2sgd2lsbCBub3QgZ2V0IHVzIGJleW9uZCBJUHY0IGV4aGF1c3Rpb24pDQotIGEgc2luZ2xl IHJlY29tbWVuZGVkIHByb2ZpbGUgY292ZXJpbmcgYWxsIG1vYmlsZSB1c2UgY2FzZXMgIC0gaGFu ZHNldCBjZWxsdWxhciBkYXRhLCBoYW5kc2V0IHRldGhlcmluZywgbW9iaWxlIGJyb2FkYmFuZDsg YW4gaW5mb3JtYXRpb25hbCBzdGFuZGFyZCB3aWxsIHN1ZmZpY2UNCi0gSSB3aWxsIHVzZSB0aGlz IGFzIGEgTk9STSBpbiBmdXJ0aGVyIGRpc2N1c3Npb25zIHdpdGggdGVybWluYWwgdmVuZG9ycy4g WWVzLCBtYW55IG9wZXJhdG9ycyB3aWxsIGhhdmUgZnVydGhlciBkaXNjdXNzaW9ucyB3aXRoIG1h bnkgdGVybWluYWwgdmVuZG9ycywgdGVybWluYWwgc29mdHdhcmUvY29uZmlndXJhdGlvbiBvbiB0 aGUgd2hvbGUgaXMgZnJhZ21lbnRlZC4NCg0KQ29udHJhcnkgdG8gc29tZSBvZiB0aGUgdmlld3Mg ZXhwcmVzc2VkICgidGhhdCBzb21lIElQdjYgaXMgb3V0IHRoZXJlIGluIG1vYmlsZSBsYW5kLCB0 aGVyZWZvcmUgYnkgaW5kdWN0aW9uIGFsbCBtb2JpbGUgaXNzdWVzIGFyZSByZXNvbHZlZCIpIHRo ZXJlIGFyZSBzdGlsbCBzb21lIGlzc3VlcyBhbmQgZ3JleSBhcmVhcy4NCkFzIGZhciBhcyBJIGtu b3cgdGhlcmUgYXJlIG9ubHkgYSBmZXcgb3BlbiBtYXJrZXQgZGV2aWNlIG1vZGVsICJmYW1pbGll cyIsIHRoYXQgbWF5IHdvcmsgSVB2Ni1vbmx5IHdpdGggZnVsbCBiYWNrd2FyZHMgY29tcGF0aWJp bGl0eSB3aXRoIElQdjQsIGFuZCBwcm92aWRlcyBzdGFibGUgdGV0aGVyaW5nLCBhbmQgaW1wbGVt ZW50IEFQTiByb2FtaW5nIGNvbnRyb2xzLg0KRm9yIGFsbCBvdGhlciB2ZW5kb3IgbW9kZWxzIHRo YXQgYXJlIGJhZGdlZCBhcyBJUHY2LCB5b3UgbmVlZCB0byByZXF1ZXN0IGEgcGVyIG9wZXJhdG9y IGJ1aWxkLiBXaWxsIHRoZSByZWxldmFudCBmZWF0dXJlcyBpbiB0aGUgYnVpbGQgYmUgdGhlIHNh bWUgZm9yIGFsbCBvcGVyYXRvcnMsIGluIGFsbCByZWdpb25zPyBIb3cgY2FuIG9uZSBvcGVyYXRv ciByZWFsbHkgc2F5IHdpdGhvdXQgc29tZSBnbG9iYWwgbm9ybSB0byBjb21wYXJlIHRoaXMgdG8/ DQpJZiB0aGUgR29vZ2xlIGd1eSBzYXlzIGl0IGlzIGFsbCBmaW5lLCB0aGF0IGlzIGdyZWF0IG5l d3MuIA0KSSdkIGZlZWwgYmV0dGVyIGlmIHRoZSBMRyBndXksIFNhbXN1bmcgZ3V5LCBBcHBsZSBn dXksIEhUQyBndXkgZXRjLiBldGMuIGFsbCBjYW1lIG9uIHRoZSBWNk9wcyBsaXN0IHdpdGggdGhl IHNhbWUgbWVzc2FnZS4NCk91ciBkZXZpY2VzIHRlYW1zIGRvIG5vdCBub3JtYWxseSBnZXQgaW52 b2x2ZWQgd2l0aCBzdWNoIGxvdyBsZXZlbCByZXF1aXJlbWVudHMgYXMgSVAgcHJvdG9jb2wgdmVy c2lvbnMuIFdlIGhhdmUgdmVuZG9ycyB0aGF0IHdlIGhhdmVu4oCZdCBldmVuIHN0YXJ0ZWQgdGFs a2luZyB0byB5ZXQgYWJvdXQgSVB2Ni4NCg0KU2ltaWxhcmx5LCBmaW5kIG1lIGEgbW9iaWxlIG5l dHdvcmsgd2hlcmUgYWxsIElQdjYtZW5hYmxlZCB0ZXJtaW5hbCBtb2RlbHMgYXJlIGluIElQdjYt b25seSBtb2RlIGZvciBhbGwgdXNlIGNhc2VzIChjLmYuIGNlbGx1bGFyIGRhdGEsIHRldGhlcmlu ZywgbW9iaWxlIGJyb2FkYmFuZCkgdXNpbmcgc3RhbmRhcmRzIGJ1aWxkLg0KVGhvc2UgYXJlIGhh cmQgdG8gZmluZDsgYXMgYW4gaW5kdXN0cnkgd2UgYXJlIG5vdCB0aGVyZSB5ZXQuIChObyBkaXNy ZXNwZWN0LCB0aGlzIGlzIGR1ZSB0byBidXNpbmVzcyByZWFzb25zOiBzb21lIG9wZXJhdG9ycyBo YXZlIGdvbmUgZHVhbHN0YWNrIEFQTiwgc29tZSBoYXZlIGFub3RoZXIgQVBOIGZvciB0ZXRoZXJp bmcsIHNvbWUgaGF2ZSBjaG9zZW4gaGFyZGNvZGluZyBvZiBwcmVmaXg2NCwgc29tZSBuZWVkIGEg Y29tbW9uIEFQTiBmb3IgYWxsICBJUCBjb25uZWN0aXZpdHkgbW9kZXMuLi4uKS4gSXQgaXMgaW1w b3J0YW50IHRvIHJlY29nbmlzZSB0aGUgb3BlcmF0b3IgZGlmZmVyZW5jZXMuDQoNCkFzIG9uZSBv ZiB0aGUgYXV0aG9ycywgd2Ugd2VyZSBhZHZpc2VkIGJ5IHRoZSBXRyB0aGF0IG5vcm1hdGl2ZSBs YW5ndWFnZSB3YXMgbm90IGFwcHJvcHJpYXRlIGZvciB0aGlzIGRvY3VtZW50IGFzIGl0IHdhcyBh IGZlYXR1cmUgbGlzdCAvYnVmZmV0IG9mIG9wdGlvbnMvbGlzdCBkb2N1bWVudCByYXRoZXIgdGhh biBhIHN0YW5kYXJkLg0KRmluZSwgaXQgaXMgbm90IGEgc3RhbmRhcmQsIGl0IGlzIG5vdCBhIHBy b2JsZW0gdG8gYWNjZXB0IHRoYXQgYW5kIG1ha2UgdGhhdCBwZXJmZWN0bHkgY2xlYXIgaW4gdGhl IHBhcGVyLiANCkJ1dCBlcXVhbGx5IEkgd291bGQgc3VzcGVjdCB0aGF0IGFzIGl0IGlzIG5vdCBh IHN0YW5kYXJkIHRoaXMgaXMgd2h5IHRoZSBkb2N1bWVudCBoYXMgZXhwYW5kZWQgd2l0aCBhbGwg dGhlIGJlc3QgYnVmZmV0IG9mIGZlYXR1cmVzIGF2YWlsYWJsZSBtYW5kYXRvcnkvb3B0aW9uYWwv cmVxdWlyZWQgZm9yIGNlcnRhaW4gdXNlIGNhc2VzLiANCk5vdyB0aGUgZG9jdW1lbnQgYXBwZWFy cyB0byBiZSBiZWluZyBibGFzdGVkIGZvciBleGFjdGx5IHRoaXMgZXh0ZW5zaXZlIGxpc3Qgb2Yg bm9uLW1hbmRhdG9yeSBmZWF0dXJlcy4gSXMgdGhhdCBmYWlyPyBIYXMgYSBzdGVlciBiZWVuIGdp dmVuIGhlcmUsIGFuZCBpcyBldmVyeW9uZSBhZ3JlZWQgb24gdGhlIHN0ZWVyPw0KDQpUaGUgcXVl c3Rpb24gaW4gbXkgbWluZCBpcyB0aGlzLCBpZiB3ZSBwcm9kdWNlIGEgZG9jdW1lbnQgdGhhdCBm b2N1c2VzIG9ubHkgb24gZmVhdHVyZXMgZm9yIElQdjYtb25seSBtb2RlIG9mIG9wZXJhdGlvbiAo d2hpY2ggSSBtYXkgc3VwcG9ydCwgbm90IHN1cmUgb2Ygb3RoZXIgYXV0aG9ycycgcG9zaXRpb25z KSwgY2FuIHdlIHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgYW5kIHByb2R1Y2UgYW4gaW5mb3JtYXRp b25hbCBzdGFuZGFyZD8gV2lsbCB0aGF0IGJlIG1vcmUgYWdyZWVhYmxlIHRvIHRoZSBkZXRyYWN0 b3JzPw0KSWYgaXQgY291bGQgYmUgZG9uZSB3aXRob3V0IHJlc2V0dGluZyB0aGUgcHJvY2VzcyB0 b28gZmFyIGJhY2sgYW5kIGl0IHR1cm5lZCBvcHBvc2l0aW9uIGludG8gc3VwcG9ydCwgdGhlbiBJ J2Qgc3VwcG9ydCBpdC4NCkkgdGhpbmsgdGhlIElQdjYtb25seSBwcm9maWxlIGlzIG1vcmUgdXJn ZW50IHRoYW4gdGhlIGVxdWl2YWxlbnQgSVB2NHY2IGR1YWwgc3RhY2sgcHJvZmlsZSwgYmFzZWQg b24gbXkgdmlld3BvaW50LCBhZ2FpbiBJIGNhbm5vdCBzcGVhayBmb3IgYWxsIGF1dGhvcnMuDQoN Ck5vdCBoYXZpbmcgYSBOT1JNIGRvY3VtZW50LCBsZWF2ZXMgdGhlIGluZHVzdHJ5IGluIGEgaG9s ZSBpbiBteSBvcGluaW9uLiANCkkgaG9wZSB3ZSBjYW4gZmluZCBhIHRpbWVseSB3YXkgZm9yd2Fy ZC4NClJlZ2FyZHMsDQpOaWNrDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZyZWQg QmFrZXIgKGZyZWQpDQpTZW50OiAwMyBGZWJydWFyeSAyMDE1IDE5OjE4DQpUbzogbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KQ2M6IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1w cm9maWxlLmFsbEB0b29scy5pZXRmLm9yZzsgVjYgT3BzIExpc3QNClN1YmplY3Q6IFJlOiBbdjZv cHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbA0KDQoN Cj4gT24gSmFuIDMwLCAyMDE1LCBhdCA0OjIxIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIHdyb3RlOg0KPiANCj4gV2l0aCBhbGwgZHVlIHJlc3BlY3QsIEknbSBhZnJhaWQgd2UgYXJl IG5vdCBkaXNjdXNzaW5nIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIG5lZWRlZCBvciBub3QgYnV0 IChhcyBJIHNlZSBpdCkgd2hldGhlciB0aGUgbmV3IHZlcnNpb24gZG9lcyBub3QgYnJlYWsgdGhl IFdHIGNvbnNlbnN1cyB0aGF0IHdhcyBkZWNsYXJlZCBmb3IgdGhlIHZlcnNpb24gc2VudCB0byB0 aGUgSUVTRy4gSSByZWNhbGwgdGhhdCBib3RoIHRoZSBXRyBhbmQgSUVURiBjb25zZW5zdXMgd2Vy ZSBkZWNsYXJlZCBmb3IgdGhlIHZlcnNpb24gc2VudCB0byB0aGUgSUVTRy4NCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUvaGlzdG9yeS8NCg0KVGhhdOKAmXMgbm90IHF1aXRlIHRoZSB3YXkgSSByZWNhbGwgaXQu IEluIHRoZSBXRywgY29uc2Vuc3VzIGhhcyBhbHdheXMgYmVlbiByb3VnaC4gSSBzZW50IGl0IG91 dCB3aGVuIHRoZSBudW1iZXIgb2YgcGVvcGxlIHN0YXRpbmcgYSBkaXNzZW50aW5nIHBvc2l0aW9u IGR3aW5kbGVkLiBJbiB0aGUgSUVURiBMQyBpbiBTZXB0ZW1iZXIgMjAxMywgSmFtZXMsIExvcmVu em8sIGFuZCBPd2VuIG1hZGUgY29tbWVudHMgdGhhdCBjYXVzZWQgSm9lbCB0byB3aXRoZHJhdyBp dCBmcm9tIHRoZSBJRVNHLiBJbiB0aGUgSUVURiBMQyBpbiBTZXB0ZW1iZXIgMjAxNCBhbmQgc3Vi c2VxdWVudCBJRVNHIGRpc2N1c3Npb24sIGNvbW1lbnRzIHdlcmUgcmFpc2VkIGJ5IHNldmVyYWwg aW4gdGhlIElFU0cgYW5kIHN1bW1hcml6ZWQgYnkgQnJpYW4gSGFiZXJtYW4gdG8gdGhlIGVmZmVj dCB0aGF0IHRoZSBkb2N1bWVudCBoYXMgc2VyaW91cyBpc3N1ZXMuIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlL2Jh bGxvdC8uIEluIHRoaXMgcm91bmQsIHlvdSBoYXZlIHRyaWVkIHRvIGFkZHJlc3MgdGhlIGlzc3Vl cyByYWlzZWQuDQoNCkJlZm9yZSBJIGJvdGhlciB0aGUgSUVTRyB3aXRoIGl0IGEgdGhpcmQgdGlt ZSwgSeKAmWQgcmVhbGx5IGxpa2UgdG8gaGVhciBhIGNsZWFyIGNvbnNlbnN1cywgbm90IGEgcm91 Z2ggb25lLiBXaGVyZSBpdCBzdGFuZHMgcmlnaHQgbm93LCB0aGF04oCZcyBub3QgYXQgYWxsIG9i dmlvdXMuDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMp LiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRv IG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRv ciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBs ZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWls IGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMg eW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNl bHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQg V2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9m ZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0 Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== From nobody Mon Feb 9 08:42:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F391A1BCD for ; Mon, 2 Feb 2015 06:13:01 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irzzB4POiWVA for ; Mon, 2 Feb 2015 06:12:59 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C131A1A10 for ; Mon, 2 Feb 2015 06:10:47 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id i138so44204653oig.1 for ; Mon, 02 Feb 2015 06:10:46 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PfYLL2bKtUKMPXVcSmzBrxrqSkHHqA6cKgfXFHIafDc=; b=LeV8uuMSc+F/IBifPeUsn9qbGVWRXg0SMsPc16SuTqsLSSbTkV/Ja/s5KIOfpniBhF nNZvMvv6eQql3ooY2FyNQJPMSnz8lB+oQeoG4FxVwE7OoEiW1+V4SqcfkPxkRGmbVQNO qr48rtIRRZhYyMJ/bro22UXoA+m3i1OTKb0BlFJFg+UO44fQmoBG31k/BpxArR3Sbrrt 9BIgkj50p1WR7XxvwTLgDDEV1y3hXzaLMj0QvTh62RRlqwt2ojH1+DUcmCKst5DbiQrJ 8ZDS+/apohvtqHpjuQ9Cwk5SSgNLJju2/gbK74d1c1k6ODx3BUhXF0BOHgEsG6PSLo7C bgzQ== X-Received: by 10.202.201.194 with SMTP id z185mr11509722oif.32.1422886246598; Mon, 02 Feb 2015 06:10:46 -0800 (PST) Received: from mb-aye.local ([172.56.15.74]) by mx.google.com with ESMTPSA id x15sm8735651oie.26.2015.02.02.06.10.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 06:10:45 -0800 (PST) Message-ID: <54CF8562.30309@gmail.com> Date: Mon, 02 Feb 2015 08:10:42 -0600 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, joel jaeggli , Gert Doering References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54CD3FB7.3020402@bogus.com> <787AE7BB302AE849A7480A190F8B9330049034FD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049034FD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 08:37:19 -0800 Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 14:13:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/2/15 12:40 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > Which consensus are your talking about?: The one for adopting the > document as a WG item?, the first one declared by the WG before > sending it to the IESG? the second one declared by the WG to send > the document to the IESG?, or the IETF consensus that was declared > before the IESG starts its review? IETF last call. > Cheers, Med > > -----Message d'origine----- De : joel jaeggli > [mailto:joelja@bogus.com] Envoyé : samedi 31 janvier 2015 21:49 À : > BOUCADAIR Mohamed IMT/OLN; Gert Doering Cc : > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops > List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile > last call > > On 1/30/15 4:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> With all due respect, I'm afraid we are not discussing whether >> the document is needed or not but (as I see it) whether the new >> version does not break the WG consensus that was declared for the >> version sent to the IESG. I recall that both the WG and IETF >> consensus were declared for the version sent to the IESG. > > One point on that. Part of the reason we are engaged canvasing, is > that Brian's discussed questioned my interpretation of the > consensus call. Given that I conceded from the outset that the call > is somewhat narrow, one of the questions before us as a w.g. and > the ietf community is, is that consensus more unequivocal? Brian I > believe is willing to extended the benefit of the doubt. So am I, > but it's the working groups document... > > thanks > > joel > >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : Gert Doering >> [mailto:gert@space.net] Envoyé : vendredi 30 janvier 2015 11:39 À >> : BOUCADAIR Mohamed IMT/OLN Cc : Gert Doering; Ole Troan; Fred >> Baker (fred); >> draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 >> Ops List Objet : Re: [v6ops] >> draft-ietf-v6ops-mobile-device-profile last call >> >> Hi, >> >> On Fri, Jan 30, 2015 at 09:12:16AM +0000, >> mohamed.boucadair@orange.com wrote: >>> Can you please help us identifying technical flaws that you >>> think need to be fixed in the document? >> >> I don't think there is a need for this document, and I can't >> truly see it reflecting WG consensus. So it's more fundamental >> than just individual technical issues. >> >> For the specifics, everything that Lorenzo said. >> >> Gert Doering -- NetMaster >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTPhWIACgkQ8AA1q7Z/VrJLVgCfRWvwc+ETB6IeRuc0RQQ/laiY 7n4AnjYJxcpLNWt1rd7MRfKjbvaoIw4q =OT3i -----END PGP SIGNATURE----- From nobody Mon Feb 9 08:44:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF611A88AF for ; Fri, 6 Feb 2015 15:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvFPMehm_Rca for ; Fri, 6 Feb 2015 15:29:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A21A88BF for ; Fri, 6 Feb 2015 15:29:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206232942.29561.24725.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 15:29:42 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 08:37:04 -0800 Subject: [v6ops] ID Tracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 23:29:45 -0000 Last call has been made for status-change-rfc-3068-anycast-prefix-for-6to4-to-historic and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/status-change-rfc-3068-anycast-prefix-for-6to4-to-historic/ From nobody Mon Feb 9 09:49:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3C1A1EE8 for ; Mon, 9 Feb 2015 09:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrqS-pH1DDQT for ; Mon, 9 Feb 2015 09:40:32 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BC51A6EED for ; Mon, 9 Feb 2015 09:40:28 -0800 (PST) Received: from mb-aye.local (64.125.197.170.IPYX-102339-ZYO.zip.zayo.com [64.125.197.170] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t19HeLjQ004029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 17:40:21 GMT (envelope-from joelja@bogus.com) Message-ID: <54D8F0FE.6010601@bogus.com> Date: Mon, 09 Feb 2015 09:40:14 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "Heatley, Nick" , "Fred Baker (fred)" , "mohamed.boucadair@orange.com" References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mWRkdoDRHjfPD4wwwN62569WoelsNcqhR" Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 17:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mWRkdoDRHjfPD4wwwN62569WoelsNcqhR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/9/15 1:14 AM, Heatley, Nick wrote: > Just a reminder on why I, as an operator, have a need of a document=20 > from the IETF. I desire: - an IP profile from IETF - IETF is the home > of IP and Internet Engineering (but happy to tie up with 3GPP etc.) - > a profile for mobile devices when the network offers them IPv6-only > (dualstack will not get us beyond IPv4 exhaustion) - a single > recommended profile covering all mobile use cases - handset cellular > data, handset tethering, mobile broadband; an informational standard > will suffice - I will use this as a NORM in further discussions with > terminal vendors. Yes, many operators will have further discussions > with many terminal vendors, terminal software/configuration on the > whole is fragmented. >=20 > Contrary to some of the views expressed ("that some IPv6 is out there > in mobile land, therefore by induction all mobile issues are=20 > resolved") there are still some issues and grey areas. As far as I=20 > know there are only a few open market device model "families", that=20 > may work IPv6-only with full backwards compatibility with IPv4, and=20 > provides stable tethering, and implement APN roaming controls. For=20 > all other vendor models that are badged as IPv6, you need to request > a per operator build. Will the relevant features in the build be the > same for all operators, in all regions? How can one operator really > say without some global norm to compare this to? If the Google guy=20 > says it is all fine, that is great news. I'd feel better if the LG=20 > guy, Samsung guy, Apple guy, HTC guy etc. etc. all came on the V6Ops > list with the same message. Our devices teams do not normally get=20 > involved with such low level requirements as IP protocol versions. We > have vendors that we haven=E2=80=99t even started talking to yet about = IPv6. >=20 > Similarly, find me a mobile network where all IPv6-enabled terminal=20 > models are in IPv6-only mode for all use cases (c.f. cellular data,=20 > tethering, mobile broadband) using standards build. Those are hard to > find; as an industry we are not there yet. (No disrespect, this is > due to business reasons: some operators have gone dualstack APN, some > have another APN for tethering, some have chosen hardcoding of=20 > prefix64, some need a common APN for all IP connectivity modes....). > It is important to recognise the operator differences. >=20 > As one of the authors, we were advised by the WG that normative=20 > language was not appropriate for this document as it was a feature=20 > list /buffet of options/list document rather than a standard. Fine,=20 > it is not a standard, it is not a problem to accept that and make=20 > that perfectly clear in the paper. But equally I would suspect that=20 > as it is not a standard this is why the document has expanded with=20 > all the best buffet of features available mandatory/optional/required > for certain use cases. Well it essentially started with this list of features, so I don't accept that it has ballooned as product of non-normative language. If in total one didn't it like before and the language change didn't mollify, you probably still don't. We have a channel for publishing non-consesus documents but it's not the working group process. I believed, perhaps mistakenly that we could move this to a more durable consensus on the basis of text changes to take it away from requirements. > Now the document appears to be being blasted for exactly this=20 > extensive list of non-mandatory features. Is that fair? Has a steer=20 > been given here, and is everyone agreed on the steer? >=20 > The question in my mind is this, if we produce a document that=20 > focuses only on features for IPv6-only mode of operation (which I may > support, not sure of other authors' positions), can we use normative > language and produce an informational standard? Will that be more > agreeable to the detractors? If it could be done without resetting > the process too far back and it turned opposition into support, then > I'd support it. I think the IPv6-only profile is more urgent than the > equivalent IPv4v6 dual stack profile, based on my viewpoint, again I > cannot speak for all authors. >=20 > Not having a NORM document, leaves the industry in a hole in my=20 > opinion. I hope we can find a timely way forward. Regards, Nick >=20 >=20 > -----Original Message----- From: v6ops=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: > 03 February 2015 19:18 To: mohamed.boucadair@orange.com Cc:=20 > draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops=20 > List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > call >=20 >=20 >> On Jan 30, 2015, at 4:21 AM, mohamed.boucadair@orange.com wrote: >>=20 >> With all due respect, I'm afraid we are not discussing whether the >> document is needed or not but (as I see it) whether the new >> version does not break the WG consensus that was declared for the >> version sent to the IESG. I recall that both the WG and IETF >> consensus were declared for the version sent to the IESG. >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile= /history/ > > > > > > > >=20 That=E2=80=99s not quite the way I recall it. In the WG, consensus has > always been rough. I sent it out when the number of people stating a > dissenting position dwindled. In the IETF LC in September 2013,=20 > James, Lorenzo, and Owen made comments that caused Joel to withdraw=20 > it from the IESG. In the IETF LC in September 2014 and subsequent=20 > IESG discussion, comments were raised by several in the IESG and=20 > summarized by Brian Haberman to the effect that the document has=20 > serious issues.=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile= /ballot/. > > > > > > >=20 In this round, you have tried to address the issues raised. >=20 > Before I bother the IESG with it a third time, I=E2=80=99d really like = to=20 > hear a clear consensus, not a rough one. Where it stands right now,=20 > that=E2=80=99s not at all obvious. >=20 > NOTICE AND DISCLAIMER This e-mail (including any attachments) is=20 > intended for the above-named person(s). If you are not the intended > recipient, notify the sender immediately, delete this email from > your system and do not disclose or use for any purpose. >=20 > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and=20 > attachments are free from any virus, but it remains your=20 > responsibility to ensure that viruses do not adversely affect you. >=20 > EE Limited Registered in England and Wales Company Registered Number: > 02382161 Registered Office Address: Trident Place, Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW.=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --mWRkdoDRHjfPD4wwwN62569WoelsNcqhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTY8P8ACgkQ8AA1q7Z/VrLujACdHrOqF7y8G3GofRg+3EHujY8X 4MAAnRdao7BYTqxKT3bkY6GwHSCnNR+j =MvSw -----END PGP SIGNATURE----- --mWRkdoDRHjfPD4wwwN62569WoelsNcqhR-- From nobody Tue Feb 10 23:00:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184AD1A7D80 for ; Tue, 10 Feb 2015 23:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKfcTf6iSNN5 for ; Tue, 10 Feb 2015 23:00:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9712C1A710D for ; Tue, 10 Feb 2015 23:00:18 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3F71D2AC7B7; Wed, 11 Feb 2015 08:00:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 197CB1800C8; Wed, 11 Feb 2015 08:00:17 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 08:00:16 +0100 From: To: "Heatley, Nick" , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJ94KoZb5URc+rHGKXMO3E0JzXBDUAgACFfoCAANnEAIAAGFgAgAAcc4CABr3FgIAA+7oAgArF1tA= Date: Wed, 11 Feb 2015 07:00:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.30323 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 07:00:22 -0000 SGkgTmljaywNCg0KVGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuIA0KDQpUaGlz IGlzIGV4YWN0bHkgdGhlIG1vdGl2YXRpb25zIGZvciB3aGljaCB3ZSBlZGl0ZWQgdGhlIGZpcnN0 IHZlcnNpb24gb2YgdGhlIGNlbGx1bGFyIHJlcXVpcmVtZW50cyBkcmFmdC4gV2Ugd2FudGVkIGEg ZG9jdW1lbnQgdGhhdCBnYXRoZXJzIGZlYXR1cmVzIHNoYXJlZCBieSBhIGdyb3VwIG9mIG9wZXJh dG9ycy4gVGhpcyBzY29wZSBhbmQgb2JqZWN0aXZlcyBoYXZlIGJlZW4gZXhwbGljaXRseSBjYWxs ZWQgb3V0IHNpbmNlIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBUaGUgZHJhZnQg d2FzIGFkb3B0ZWQgd2l0aCB0aGF0IHNjb3BlIHVuY2hhbmdlZC4gDQoNCkFzIGFuIGVkaXRvciBv ZiB0aGUgZHJhZnQsIEknbSBvcGVuIHRvIGFkZHJlc3MgdGVjaG5pY2FsIGNvbW1lbnRzIHRoYXQg d291bGQgZW5oYW5jZSB0aGUgZG9jdW1lbnQuIFdlIGFscmVhZHkgcmVsZWFzZWQgYW4gdXBkYXRl ZCB2ZXJzaW9uIHRoYXQgaW50ZWdyYXRlZCB0aGUgY2hhbmdlcyByZXF1ZXN0ZWQgZHVyaW5nIHRo aXMgb25nb2luZyBjYWxsLiAoQlRXLCBJIHdvdWxkIGxpa2UgdG8gcHVibGljYWxseSB0aGFuayBG LiBCYWtlciBmb3IgaGlzIGVmZm9ydCBhbmQgZ3VpZGFuY2UgdG8gc29sdmUgb25lIG9mIHRoZSBr ZXkgaXNzdWVzIHJhaXNlZCBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LikNCg0KSWYgdGhlcmUgYXJl IG90aGVyIHRlY2huaWNhbCBjb25jZXJucyBvciBjbGFyaWZpY2F0aW9ucyB0aGF0IG5lZWQgdG8g YmUgYWRkZWQgdG8gdGhlIGRyYWZ0LCB3ZSBhcmUgb3BlbiB0byBkaXNjdXNzIGhvdyB0byBhZGRy ZXNzIHRob3NlLg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQpEZcKgOiBIZWF0bGV5LCBOaWNrIFttYWlsdG86bmljay5oZWF0bGV5QGVlLmNvLnVrXSANCkVu dm95w6nCoDogbHVuZGkgOSBmw6l2cmllciAyMDE1IDEwOjE1DQrDgMKgOiBGcmVkIEJha2VyIChm cmVkKTsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2PCoDogZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdDsgUm9z cyBDaGFuZGxlciAocm9zc0BlaXJjb20ubmV0KQ0KT2JqZXTCoDogUkU6IFt2Nm9wc10gZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsDQoNCkp1c3QgYSByZW1p bmRlciBvbiB3aHkgSSwgYXMgYW4gb3BlcmF0b3IsIGhhdmUgYSBuZWVkIG9mIGEgZG9jdW1lbnQg ZnJvbSB0aGUgSUVURi4gDQpJIGRlc2lyZToNCi0gYW4gSVAgcHJvZmlsZSBmcm9tIElFVEYgLSBJ RVRGIGlzIHRoZSBob21lIG9mIElQIGFuZCBJbnRlcm5ldCBFbmdpbmVlcmluZyAoYnV0IGhhcHB5 IHRvIHRpZSB1cCB3aXRoIDNHUFAgZXRjLikNCi0gYSBwcm9maWxlIGZvciBtb2JpbGUgZGV2aWNl cyB3aGVuIHRoZSBuZXR3b3JrIG9mZmVycyB0aGVtIElQdjYtb25seSAoZHVhbHN0YWNrIHdpbGwg bm90IGdldCB1cyBiZXlvbmQgSVB2NCBleGhhdXN0aW9uKQ0KLSBhIHNpbmdsZSByZWNvbW1lbmRl ZCBwcm9maWxlIGNvdmVyaW5nIGFsbCBtb2JpbGUgdXNlIGNhc2VzICAtIGhhbmRzZXQgY2VsbHVs YXIgZGF0YSwgaGFuZHNldCB0ZXRoZXJpbmcsIG1vYmlsZSBicm9hZGJhbmQ7IGFuIGluZm9ybWF0 aW9uYWwgc3RhbmRhcmQgd2lsbCBzdWZmaWNlDQotIEkgd2lsbCB1c2UgdGhpcyBhcyBhIE5PUk0g aW4gZnVydGhlciBkaXNjdXNzaW9ucyB3aXRoIHRlcm1pbmFsIHZlbmRvcnMuIFllcywgbWFueSBv cGVyYXRvcnMgd2lsbCBoYXZlIGZ1cnRoZXIgZGlzY3Vzc2lvbnMgd2l0aCBtYW55IHRlcm1pbmFs IHZlbmRvcnMsIHRlcm1pbmFsIHNvZnR3YXJlL2NvbmZpZ3VyYXRpb24gb24gdGhlIHdob2xlIGlz IGZyYWdtZW50ZWQuDQoNCkNvbnRyYXJ5IHRvIHNvbWUgb2YgdGhlIHZpZXdzIGV4cHJlc3NlZCAo InRoYXQgc29tZSBJUHY2IGlzIG91dCB0aGVyZSBpbiBtb2JpbGUgbGFuZCwgdGhlcmVmb3JlIGJ5 IGluZHVjdGlvbiBhbGwgbW9iaWxlIGlzc3VlcyBhcmUgcmVzb2x2ZWQiKSB0aGVyZSBhcmUgc3Rp bGwgc29tZSBpc3N1ZXMgYW5kIGdyZXkgYXJlYXMuDQpBcyBmYXIgYXMgSSBrbm93IHRoZXJlIGFy ZSBvbmx5IGEgZmV3IG9wZW4gbWFya2V0IGRldmljZSBtb2RlbCAiZmFtaWxpZXMiLCB0aGF0IG1h eSB3b3JrIElQdjYtb25seSB3aXRoIGZ1bGwgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBJ UHY0LCBhbmQgcHJvdmlkZXMgc3RhYmxlIHRldGhlcmluZywgYW5kIGltcGxlbWVudCBBUE4gcm9h bWluZyBjb250cm9scy4NCkZvciBhbGwgb3RoZXIgdmVuZG9yIG1vZGVscyB0aGF0IGFyZSBiYWRn ZWQgYXMgSVB2NiwgeW91IG5lZWQgdG8gcmVxdWVzdCBhIHBlciBvcGVyYXRvciBidWlsZC4gV2ls bCB0aGUgcmVsZXZhbnQgZmVhdHVyZXMgaW4gdGhlIGJ1aWxkIGJlIHRoZSBzYW1lIGZvciBhbGwg b3BlcmF0b3JzLCBpbiBhbGwgcmVnaW9ucz8gSG93IGNhbiBvbmUgb3BlcmF0b3IgcmVhbGx5IHNh eSB3aXRob3V0IHNvbWUgZ2xvYmFsIG5vcm0gdG8gY29tcGFyZSB0aGlzIHRvPw0KSWYgdGhlIEdv b2dsZSBndXkgc2F5cyBpdCBpcyBhbGwgZmluZSwgdGhhdCBpcyBncmVhdCBuZXdzLiANCkknZCBm ZWVsIGJldHRlciBpZiB0aGUgTEcgZ3V5LCBTYW1zdW5nIGd1eSwgQXBwbGUgZ3V5LCBIVEMgZ3V5 IGV0Yy4gZXRjLiBhbGwgY2FtZSBvbiB0aGUgVjZPcHMgbGlzdCB3aXRoIHRoZSBzYW1lIG1lc3Nh Z2UuDQpPdXIgZGV2aWNlcyB0ZWFtcyBkbyBub3Qgbm9ybWFsbHkgZ2V0IGludm9sdmVkIHdpdGgg c3VjaCBsb3cgbGV2ZWwgcmVxdWlyZW1lbnRzIGFzIElQIHByb3RvY29sIHZlcnNpb25zLiBXZSBo YXZlIHZlbmRvcnMgdGhhdCB3ZSBoYXZlbuKAmXQgZXZlbiBzdGFydGVkIHRhbGtpbmcgdG8geWV0 IGFib3V0IElQdjYuDQoNClNpbWlsYXJseSwgZmluZCBtZSBhIG1vYmlsZSBuZXR3b3JrIHdoZXJl IGFsbCBJUHY2LWVuYWJsZWQgdGVybWluYWwgbW9kZWxzIGFyZSBpbiBJUHY2LW9ubHkgbW9kZSBm b3IgYWxsIHVzZSBjYXNlcyAoYy5mLiBjZWxsdWxhciBkYXRhLCB0ZXRoZXJpbmcsIG1vYmlsZSBi cm9hZGJhbmQpIHVzaW5nIHN0YW5kYXJkcyBidWlsZC4NClRob3NlIGFyZSBoYXJkIHRvIGZpbmQ7 IGFzIGFuIGluZHVzdHJ5IHdlIGFyZSBub3QgdGhlcmUgeWV0LiAoTm8gZGlzcmVzcGVjdCwgdGhp cyBpcyBkdWUgdG8gYnVzaW5lc3MgcmVhc29uczogc29tZSBvcGVyYXRvcnMgaGF2ZSBnb25lIGR1 YWxzdGFjayBBUE4sIHNvbWUgaGF2ZSBhbm90aGVyIEFQTiBmb3IgdGV0aGVyaW5nLCBzb21lIGhh dmUgY2hvc2VuIGhhcmRjb2Rpbmcgb2YgcHJlZml4NjQsIHNvbWUgbmVlZCBhIGNvbW1vbiBBUE4g Zm9yIGFsbCAgSVAgY29ubmVjdGl2aXR5IG1vZGVzLi4uLikuIEl0IGlzIGltcG9ydGFudCB0byBy ZWNvZ25pc2UgdGhlIG9wZXJhdG9yIGRpZmZlcmVuY2VzLg0KDQpBcyBvbmUgb2YgdGhlIGF1dGhv cnMsIHdlIHdlcmUgYWR2aXNlZCBieSB0aGUgV0cgdGhhdCBub3JtYXRpdmUgbGFuZ3VhZ2Ugd2Fz IG5vdCBhcHByb3ByaWF0ZSBmb3IgdGhpcyBkb2N1bWVudCBhcyBpdCB3YXMgYSBmZWF0dXJlIGxp c3QgL2J1ZmZldCBvZiBvcHRpb25zL2xpc3QgZG9jdW1lbnQgcmF0aGVyIHRoYW4gYSBzdGFuZGFy ZC4NCkZpbmUsIGl0IGlzIG5vdCBhIHN0YW5kYXJkLCBpdCBpcyBub3QgYSBwcm9ibGVtIHRvIGFj Y2VwdCB0aGF0IGFuZCBtYWtlIHRoYXQgcGVyZmVjdGx5IGNsZWFyIGluIHRoZSBwYXBlci4gDQpC dXQgZXF1YWxseSBJIHdvdWxkIHN1c3BlY3QgdGhhdCBhcyBpdCBpcyBub3QgYSBzdGFuZGFyZCB0 aGlzIGlzIHdoeSB0aGUgZG9jdW1lbnQgaGFzIGV4cGFuZGVkIHdpdGggYWxsIHRoZSBiZXN0IGJ1 ZmZldCBvZiBmZWF0dXJlcyBhdmFpbGFibGUgbWFuZGF0b3J5L29wdGlvbmFsL3JlcXVpcmVkIGZv ciBjZXJ0YWluIHVzZSBjYXNlcy4gDQpOb3cgdGhlIGRvY3VtZW50IGFwcGVhcnMgdG8gYmUgYmVp bmcgYmxhc3RlZCBmb3IgZXhhY3RseSB0aGlzIGV4dGVuc2l2ZSBsaXN0IG9mIG5vbi1tYW5kYXRv cnkgZmVhdHVyZXMuIElzIHRoYXQgZmFpcj8gSGFzIGEgc3RlZXIgYmVlbiBnaXZlbiBoZXJlLCBh bmQgaXMgZXZlcnlvbmUgYWdyZWVkIG9uIHRoZSBzdGVlcj8NCg0KVGhlIHF1ZXN0aW9uIGluIG15 IG1pbmQgaXMgdGhpcywgaWYgd2UgcHJvZHVjZSBhIGRvY3VtZW50IHRoYXQgZm9jdXNlcyBvbmx5 IG9uIGZlYXR1cmVzIGZvciBJUHY2LW9ubHkgbW9kZSBvZiBvcGVyYXRpb24gKHdoaWNoIEkgbWF5 IHN1cHBvcnQsIG5vdCBzdXJlIG9mIG90aGVyIGF1dGhvcnMnIHBvc2l0aW9ucyksIGNhbiB3ZSB1 c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIGFuZCBwcm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgc3RhbmRh cmQ/IFdpbGwgdGhhdCBiZSBtb3JlIGFncmVlYWJsZSB0byB0aGUgZGV0cmFjdG9ycz8NCklmIGl0 IGNvdWxkIGJlIGRvbmUgd2l0aG91dCByZXNldHRpbmcgdGhlIHByb2Nlc3MgdG9vIGZhciBiYWNr IGFuZCBpdCB0dXJuZWQgb3Bwb3NpdGlvbiBpbnRvIHN1cHBvcnQsIHRoZW4gSSdkIHN1cHBvcnQg aXQuDQpJIHRoaW5rIHRoZSBJUHY2LW9ubHkgcHJvZmlsZSBpcyBtb3JlIHVyZ2VudCB0aGFuIHRo ZSBlcXVpdmFsZW50IElQdjR2NiBkdWFsIHN0YWNrIHByb2ZpbGUsIGJhc2VkIG9uIG15IHZpZXdw b2ludCwgYWdhaW4gSSBjYW5ub3Qgc3BlYWsgZm9yIGFsbCBhdXRob3JzLg0KDQpOb3QgaGF2aW5n IGEgTk9STSBkb2N1bWVudCwgbGVhdmVzIHRoZSBpbmR1c3RyeSBpbiBhIGhvbGUgaW4gbXkgb3Bp bmlvbi4gDQpJIGhvcGUgd2UgY2FuIGZpbmQgYSB0aW1lbHkgd2F5IGZvcndhcmQuDQpSZWdhcmRz LA0KTmljaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkIEJha2VyIChmcmVk KQ0KU2VudDogMDMgRmVicnVhcnkgMjAxNSAxOToxOA0KVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCkNjOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxA dG9vbHMuaWV0Zi5vcmc7IFY2IE9wcyBMaXN0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1p ZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KDQo+IE9uIEphbiAz MCwgMjAxNSwgYXQgNDoyMSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4gDQo+IFdpdGggYWxsIGR1ZSByZXNwZWN0LCBJJ20gYWZyYWlkIHdlIGFyZSBub3QgZGlzY3Vz c2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyBuZWVkZWQgb3Igbm90IGJ1dCAoYXMgSSBzZWUg aXQpIHdoZXRoZXIgdGhlIG5ldyB2ZXJzaW9uIGRvZXMgbm90IGJyZWFrIHRoZSBXRyBjb25zZW5z dXMgdGhhdCB3YXMgZGVjbGFyZWQgZm9yIHRoZSB2ZXJzaW9uIHNlbnQgdG8gdGhlIElFU0cuIEkg cmVjYWxsIHRoYXQgYm90aCB0aGUgV0cgYW5kIElFVEYgY29uc2Vuc3VzIHdlcmUgZGVjbGFyZWQg Zm9yIHRoZSB2ZXJzaW9uIHNlbnQgdG8gdGhlIElFU0cuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlL2hpc3Rv cnkvDQoNClRoYXTigJlzIG5vdCBxdWl0ZSB0aGUgd2F5IEkgcmVjYWxsIGl0LiBJbiB0aGUgV0cs IGNvbnNlbnN1cyBoYXMgYWx3YXlzIGJlZW4gcm91Z2guIEkgc2VudCBpdCBvdXQgd2hlbiB0aGUg bnVtYmVyIG9mIHBlb3BsZSBzdGF0aW5nIGEgZGlzc2VudGluZyBwb3NpdGlvbiBkd2luZGxlZC4g SW4gdGhlIElFVEYgTEMgaW4gU2VwdGVtYmVyIDIwMTMsIEphbWVzLCBMb3JlbnpvLCBhbmQgT3dl biBtYWRlIGNvbW1lbnRzIHRoYXQgY2F1c2VkIEpvZWwgdG8gd2l0aGRyYXcgaXQgZnJvbSB0aGUg SUVTRy4gSW4gdGhlIElFVEYgTEMgaW4gU2VwdGVtYmVyIDIwMTQgYW5kIHN1YnNlcXVlbnQgSUVT RyBkaXNjdXNzaW9uLCBjb21tZW50cyB3ZXJlIHJhaXNlZCBieSBzZXZlcmFsIGluIHRoZSBJRVNH IGFuZCBzdW1tYXJpemVkIGJ5IEJyaWFuIEhhYmVybWFuIHRvIHRoZSBlZmZlY3QgdGhhdCB0aGUg ZG9jdW1lbnQgaGFzIHNlcmlvdXMgaXNzdWVzLiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS9iYWxsb3QvLiBJbiB0 aGlzIHJvdW5kLCB5b3UgaGF2ZSB0cmllZCB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgcmFpc2VkLg0K DQpCZWZvcmUgSSBib3RoZXIgdGhlIElFU0cgd2l0aCBpdCBhIHRoaXJkIHRpbWUsIEnigJlkIHJl YWxseSBsaWtlIHRvIGhlYXIgYSBjbGVhciBjb25zZW5zdXMsIG5vdCBhIHJvdWdoIG9uZS4gV2hl cmUgaXQgc3RhbmRzIHJpZ2h0IG5vdywgdGhhdOKAmXMgbm90IGF0IGFsbCBvYnZpb3VzLg0KDQpO T1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xv c2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29t aW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24u IFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNo bWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9u c2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5 b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21w YW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVz czogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwg QUwxMCA5QlcuDQo= From nobody Tue Feb 10 23:13:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211F1A7008 for ; Tue, 10 Feb 2015 23:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lprE0oBaUQFL for ; Tue, 10 Feb 2015 23:13:30 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13B81A6FEE for ; Tue, 10 Feb 2015 23:13:30 -0800 (PST) Received: by iecat20 with SMTP id at20so1970661iec.12 for ; Tue, 10 Feb 2015 23:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=No+G4gTPtnPIvsfctn9jxap3qr9WytjCHSQoKQd4tAc=; b=HHhTprvrn7k4Z0x4lCUHpatkx7e1b3bixJ7bB+7BcenbmCZjcJToAtbB1lEpeLcsy2 VV+v5L2aImgFwc/dqR5JDizdF+E/RCeqcj13wB+9qsdLlQPAHJKo8wAXuEbfdW5o4IQ4 g0xAnHDgWpddnktUh1bfreB3XoDkFE30XO29oKS4wafum5XLFP97sVaOSi+N5KGi/qkA 2wMoYaDG4hEfYDX5SquFPbJzMJfkR/muZcY2iUA9PTOh+khyzfIp4hFJluNtU+Zw9czH ZwrNVT3xTNvt7PuHTuDX608uC4UqSs6Xz904nEihL2+++Z91aLI6GiaXgtcxtXenutx5 LrXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=No+G4gTPtnPIvsfctn9jxap3qr9WytjCHSQoKQd4tAc=; b=YVtRawkmfPT6Pe8SZiOmetPeoxole+slwPPeIG8lTNsS0BQYtG8mxRfKuxOku7QRIi UzQGw2QT5/wPyUlr2172XFk35q5cjqaRQDeyjhMFOKW1ipK0ccKHZnimszX26oGELA5t 6lWg+XC0JbcCAMIffMXb4O9Ugt9B0Ug9SpOshJJcNiKzm7CD8mawPxuSZEBW/Uo+81Rm DxgYUpCINbuHefZMS8gjkFYsvyvY5/pWaJS5pu5MHhMu/ohmL9oNS72UhSVpTXRsXRVU 6gDA/lCs7H4xP6HGdZY0F5KlEbFNxTtXxIDTkqLrKjMVLf/Ke/sNxxPF3s97FBRboBv8 40aw== X-Gm-Message-State: ALoCoQkE61yATanYIimAc9DsaMWfJKIJxP3M23LBDVU37nhR9yKuGunsRDh3nSGIpHW2VtAmAeN/ X-Received: by 10.107.154.132 with SMTP id c126mr16646439ioe.74.1423638809873; Tue, 10 Feb 2015 23:13:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 10 Feb 2015 23:13:09 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Tue, 10 Feb 2015 23:13:09 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1140fc948d58fb050ecabdea Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 07:13:32 -0000 --001a1140fc948d58fb050ecabdea Content-Type: text/plain; charset=UTF-8 On Tue, Feb 10, 2015 at 11:00 PM, wrote: > Hi Nick, > > Thank you for sharing your thoughts. > > This is exactly the motivations for which we edited the first version of > the cellular requirements draft. Just in case it might have escaped someone's attention, I'd like to point out that David, Mohamed, Nick and Ross are listed as the authors of this draft, and that if you're an author of the document, you're probably likely to agree with the other authors on its content. As Joel says, it's not my role to declare consensus. But I think that on this thread I have seen only one statement in support of this document that was not from an author, and several statements expressing reservations and lack of support. --001a1140fc948d58fb050ecabdea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1140fc948d58fb050ecabdea-- From nobody Tue Feb 10 23:31:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AE81A1A75 for ; Tue, 10 Feb 2015 23:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG8vLT9e3PjM for ; Tue, 10 Feb 2015 23:31:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618981A0055 for ; Tue, 10 Feb 2015 23:31:34 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 787531905F9; Wed, 11 Feb 2015 08:31:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4A86515804E; Wed, 11 Feb 2015 08:31:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 08:31:32 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQRcow94KoZb5URc+rHGKXMO3E0JzrCqvA Date: Wed, 11 Feb 2015 07:31:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004908E6COPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.30323 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 07:31:37 -0000 --_000_787AE7BB302AE849A7480A190F8B933004908E6COPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KSW4gY2FzZSB5b3UgbWlzc2VkIHRoZSBsYXRlc3QgdmVyc2lvbiAoc2VlIHRo ZSBkaWZmOiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXY2b3Bz LW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNSZ1cmwyPWRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlLTE2KSwgd2UgYWRkcmVzc2VkIHRoZSBjaGFuZ2VzIFlPVSBhc2tlZCBmb3Ig YW5kIGFsc28gdGhvc2UgZnJvbSBKYW1lcyBhbmQgQmFyYmFyYSAobWFueSB0aGFua3MgdG8gdGhl bSkuDQoNCldoYXQgYWRkaXRpb25hbCBjaGFuZ2VzIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBhZGRl ZD8NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56 b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUgMDg6MTMN CsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBIZWF0bGV5LCBOaWNrOyBGcmVk IEJha2VyIChmcmVkKTsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxs QHRvb2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdA0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1p ZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KT24gVHVlLCBGZWIg MTAsIDIwMTUgYXQgMTE6MDAgUE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBOaWNrLA0KDQpUaGFu ayB5b3UgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cy4NCg0KVGhpcyBpcyBleGFjdGx5IHRoZSBt b3RpdmF0aW9ucyBmb3Igd2hpY2ggd2UgZWRpdGVkIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBj ZWxsdWxhciByZXF1aXJlbWVudHMgZHJhZnQuDQoNCkp1c3QgaW4gY2FzZSBpdCBtaWdodCBoYXZl IGVzY2FwZWQgc29tZW9uZSdzIGF0dGVudGlvbiwgSSdkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQg RGF2aWQsIE1vaGFtZWQsIE5pY2sgYW5kIFJvc3MgYXJlIGxpc3RlZCBhcyB0aGUgYXV0aG9ycyBv ZiB0aGlzIGRyYWZ0LCBhbmQgdGhhdCBpZiB5b3UncmUgYW4gYXV0aG9yIG9mIHRoZSBkb2N1bWVu dCwgeW91J3JlIHByb2JhYmx5IGxpa2VseSB0byBhZ3JlZSB3aXRoIHRoZSBvdGhlciBhdXRob3Jz IG9uIGl0cyBjb250ZW50Lg0KDQpBcyBKb2VsIHNheXMsIGl0J3Mgbm90IG15IHJvbGUgdG8gZGVj bGFyZSBjb25zZW5zdXMuIEJ1dCBJIHRoaW5rIHRoYXQgb24gdGhpcyB0aHJlYWQgSSBoYXZlIHNl ZW4gb25seSBvbmUgc3RhdGVtZW50IGluIHN1cHBvcnQgb2YgdGhpcyBkb2N1bWVudCB0aGF0IHdh cyBub3QgZnJvbSBhbiBhdXRob3IsIGFuZCBzZXZlcmFsIHN0YXRlbWVudHMgZXhwcmVzc2luZyBy ZXNlcnZhdGlvbnMgYW5kIGxhY2sgb2Ygc3VwcG9ydC4NCg== --_000_787AE7BB302AE849A7480A190F8B933004908E6COPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkxvcmVuem8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SW4gY2FzZSB5b3UgbWlzc2VkIHRoZSBsYXRlc3QgdmVy c2lvbiAoc2VlIHRoZSBkaWZmOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTUmYW1wO3VybDI9 ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTYiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2Zp bGUtMTUmYW1wO3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTY8 L2E+KSwgd2UgYWRkcmVzc2VkIHRoZSBjaGFuZ2VzIFlPVSBhc2tlZCBmb3IgYW5kIGFsc28gdGhv c2UgZnJvbSBKYW1lcyBhbmQgQmFyYmFyYSAobWFueSB0aGFua3MgdG8gdGhlbSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgYWRkaXRpb25h bCBjaGFuZ2VzIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBhZGRlZD8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZu YnNwOzo8L2I+IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUgMDg6MTM8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEhl YXRsZXksIE5pY2s7IEZyZWQgQmFrZXIgKGZyZWQpOyBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IFY2IE9wcyBMaXN0PGJyPg0KPGI+T2Jq ZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2Ut cHJvZmlsZSBsYXN0IGNhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDEwLCAyMDE1IGF0IDExOjAwIFBNLCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOaWNrLDxicj4NCjxicj4NClRoYW5rIHlvdSBmb3Ig c2hhcmluZyB5b3VyIHRob3VnaHRzLjxicj4NCjxicj4NClRoaXMgaXMgZXhhY3RseSB0aGUgbW90 aXZhdGlvbnMgZm9yIHdoaWNoIHdlIGVkaXRlZCB0aGUgZmlyc3QgdmVyc2lvbiBvZiB0aGUgY2Vs bHVsYXIgcmVxdWlyZW1lbnRzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SnVzdCBpbiBjYXNlIGl0IG1pZ2h0IGhhdmUgZXNjYXBlZCBzb21lb25l J3MgYXR0ZW50aW9uLCBJJ2QgbGlrZSB0byBwb2ludCBvdXQgdGhhdCBEYXZpZCwgTW9oYW1lZCwg TmljayBhbmQgUm9zcyBhcmUgbGlzdGVkIGFzIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQsIGFu ZCB0aGF0IGlmIHlvdSdyZSBhbiBhdXRob3Igb2YgdGhlIGRvY3VtZW50LCB5b3UncmUgcHJvYmFi bHkgbGlrZWx5IHRvIGFncmVlIHdpdGgNCiB0aGUgb3RoZXIgYXV0aG9ycyBvbiBpdHMgY29udGVu dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXMgSm9lbCBzYXlzLCBpdCdzIG5vdCBteSByb2xlIHRvIGRlY2xhcmUgY29uc2Vuc3VzLiBCdXQg SSB0aGluayB0aGF0IG9uIHRoaXMgdGhyZWFkIEkgaGF2ZSBzZWVuIG9ubHkgb25lIHN0YXRlbWVu dCBpbiBzdXBwb3J0IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3YXMgbm90IGZyb20gYW4gYXV0aG9y LCBhbmQgc2V2ZXJhbCBzdGF0ZW1lbnRzIGV4cHJlc3NpbmcgcmVzZXJ2YXRpb25zIGFuZCBsYWNr IG9mIHN1cHBvcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933004908E6COPEXCLILM23corp_-- From nobody Wed Feb 11 00:10:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4221A0064 for ; Wed, 11 Feb 2015 00:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk5dQHZImYUV for ; Wed, 11 Feb 2015 00:10:15 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578D81A8035 for ; Wed, 11 Feb 2015 00:10:13 -0800 (PST) Received: by iecat20 with SMTP id at20so2192465iec.12 for ; Wed, 11 Feb 2015 00:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NR0rrlINQ5CvqprSoEkSfofUdzvyAihRWb7UTW9mKgY=; b=QK6YeyqAx8bAQSLRn10kdaKrLVkyiqL2VTgpemGsuseSsNnwCOyQKe1LOYPM8ldNBg zmMqromlRMdbwf0Q0r9Agrmex/rBRavlKBbN9dethQ61UbDAFvRaaLTNw9ClueyiFOoj x1CPurnEBWQK1aMtQ5x9wEnADZvo8iP5TwitQbnYlZ/ZmvfigG1apUoeC/G2+lNIkYPp AwYBdKhc9zGPqiyJRPAvjh3rI6Z0eDDsiV5z+3G/wmQRLdB/FM7k8czePjWgbANOXlEZ L9xv1KGIg4KDBrmsspIyQPRLibCNnXKnHGa83XB695uLFILdvoGNGFix4/US7VwDygLR TZfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NR0rrlINQ5CvqprSoEkSfofUdzvyAihRWb7UTW9mKgY=; b=OD8cFfB+9kCZocetg6Mc5p5hQ1mDaZ3nDueG8fgJsWPcpvmsNesrnyvPCw/khbDPnD 0lUTVXUEc/A4TjV89xsONFLmah322uVsWjQtgYADyNZEg56bGgYNafyNJS06usMZy5kb uDDJxVH0J8n9j0VNbZ5Hqv7kQERzZEECKtRAxEJCpGCa+3mpdqE1QgfechdSObUjFyC9 Ejv9Wa2QWfhB9QC6tR6NaV8gvXmV/yHSdJ5cUv7FKpPedt4wqQgVSfUdwSBP4UZJ+k52 Jw2HYfbo4vLpMGYXhoXWIIM06lgIMCCe5tOfWwQnoPOq1WLBqe6ejDH7TzJswD44wDi5 mWgA== X-Gm-Message-State: ALoCoQlTbigmHPLkGNtCdmL/4kv2z9YV8sJd6rno4PLk7Yj5xYvKXFVChOUUlC7HUaBMbqcmqoUK X-Received: by 10.107.40.131 with SMTP id o125mr28944748ioo.5.1423642212734; Wed, 11 Feb 2015 00:10:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Wed, 11 Feb 2015 00:09:51 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Wed, 11 Feb 2015 00:09:51 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1141c21060bb6b050ecb8807 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 08:10:18 -0000 --001a1141c21060bb6b050ecb8807 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 10, 2015 at 11:31 PM, wrote: > In case you missed the latest version (see the diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16), > we addressed the changes YOU asked for and also those from James and > Barbara (many thanks to them). > > > > What additional changes you would like to see added? > I don't think minor changes to the document would cause me to support it. I have expressed my concerns about this document in the past. For example, I think the document is too broad (in fact, harmfully broad); places too much focus on what features to support and not enough focus on why; reads like a procurement spec and not a technical document. Pretty much what I said already at IETF last call - https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - and what I have been saying since we started discussing this document. The good news for this document is that it does not need my support to advance - one objection is not sufficient. IIRC the chairs/ADs have stated that they want to see "clear consensus" to support it, and if I were the only one objecting, then I suppose that would be clear consensus. After all, clear consensus does not mean unanimity. My observation of this thread, however, is that it's not just me objecting. Most clearly, Brian wrote that this reads like a procurement spec and not an IETF document. Gert wrote that he doesn't see a need for this document. James said he shares my general objections. And so on. You can't address that sort of objection with minor edits. And there doesn't seem to be lots of support for this document, either. I see one statement of support from someone who is not an author, and very little else from the rest of the WG. --001a1141c21060bb6b050ecb8807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 10, 2015 at 11:31 PM, <mohamed.boucadair@orange.com> wrote:

In case you missed the latest version (see the dif= f: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-mobile-device-profile-1= 5&url2=3Ddraft-ietf-v6ops-mobile-device-profile-16), we addressed= the changes YOU asked for and also those from James and Barbara (many than= ks to them).

=C2=A0

What additional changes you would l= ike to see added?


I = don't think minor changes to the document would cause me to support it.=

I have expressed my concerns about this document = in the past. For example, I think the document is too broad (in fact, harmf= ully broad); places too much focus on what features to support and not enou= gh focus on why; reads like a procurement spec and not a technical document= . Pretty much what I said already at IETF last call - https://www.ietf.or= g/mail-archive/web/ietf/current/msg81663.html - and what I have been sa= ying since we started discussing this document.

Th= e good news for this document is that it does not need my support to advanc= e - one objection is not sufficient. IIRC the chairs/ADs have stated that t= hey want to see "clear consensus" to support it, and if I were th= e only one objecting, then I suppose that would be clear consensus. After a= ll, clear consensus does not mean unanimity.

My ob= servation of this thread, however, is that it's not just me objecting. = Most clearly, Brian wrote that this reads like a procurement spec and not a= n IETF document. Gert wrote that he doesn't see a need for this documen= t. James said he shares my general objections. And so on. You can't add= ress that sort of objection with minor edits. And there doesn't seem to= be lots of support for this document, either. I see one statement of suppo= rt from someone who is not an author, and very little else from the rest of= the WG.
--001a1141c21060bb6b050ecb8807-- From nobody Wed Feb 11 00:51:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21D11A1A77 for ; Wed, 11 Feb 2015 00:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAg0NxJJ2HKj for ; Wed, 11 Feb 2015 00:51:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93E71A0406 for ; Wed, 11 Feb 2015 00:51:52 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 11C4618C405; Wed, 11 Feb 2015 09:51:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A103135C0AE; Wed, 11 Feb 2015 09:51:50 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 09:51:50 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQRdIc94KoZb5URc+rHGKXMO3E0JzrGQ+Q Date: Wed, 11 Feb 2015 08:51:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004908F65OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.73029 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 08:51:56 -0000 --_000_787AE7BB302AE849A7480A190F8B933004908F65OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJIGhlYXIgdGhlIHBvaW50IGZyb20gQnJpYW4uIEZXSVcsIHRoaXMgcG9pbnQgaXMg bWVudGlvbmVkIGV4cGxpY2l0bHkgaW4gdGhlIGludHJvZHVjdGlvbjoNCg0KDQoNCiAgIDIuICBI ZWxwIE9wZXJhdG9ycyB3aXRoIHRoZSBkZXRhaWxlZCBkZXZpY2UgcmVxdWlyZW1lbnQgbGlzdA0K DQogICAgICAgcHJlcGFyYXRpb24gKHRvIGJlIGV4Y2hhbmdlZCB3aXRoIGRldmljZSBzdXBwbGll cnMpLiAgVGhpcyBpcw0KDQogICAgICAgYWxzbyBhIGNvbnRyaWJ1dGlvbiB0byBoYXJtb25pemUg T3BlcmF0b3JzJyByZXF1aXJlbWVudHMgdG93YXJkcw0KDQogICAgICAgZGV2aWNlIHZlbmRvcnMu DQoNCg0KDQpUaGlzIHBvaW50IHdhcyBwYXJ0IG9mIHRoZSBkcmFmdCBzaW5jZSB3ZSBzdWJtaXR0 ZWQgdGhlIGZpcnN0IGluZGl2aWR1YWwgc3VibWlzc2lvbi4NCg0KDQoNClRoZSBkb2N1bWVudCB3 YXMgYWRvcHRlZCBieSB0aGUgV0cgYW5kIHBhc3NlZCBib3RoIHRoZSBXRyBhbmQgSUVURiBMQ3Mg d2l0aCB0aGF0IHNjb3BlLiBJIG5haXZlbHkgYXNzdW1lZCB0aGF0IHRoaXMgcG9pbnQgaXMgbm90 IGFueW1vcmUgYW4gaXNzdWUgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgcGFzc2VkIG1ham9yIG1pbGVz dG9uZXMgKHNldmVyYWwgV0dMQ3MsIElFVEYgTEMpIGFuZCB0aGUgSUVURiBjb25zZW5zdXMgZGVj bGFyZWQgZm9yIGl0IG1lYW5zIHRoaXMgaXMgbm90IGFuIGlzc3VlIHRvIGFkdmFuY2UgdGhlIGRv Y3VtZW50Lg0KDQoNCg0KQlRXLCBhbnkgcmVxdWlyZW1lbnQgZG9jdW1lbnQgKENQRSByZXF1aXJl bWVudCBSRkNzLCBmb3IgZXhhbXBsZSkgY2FuIGJlIHR1cm5lZCBpbnRvIGEgInByb2N1cmVtZW50 IHNwZWNpZmljYXRpb24iLiBJdCBpcyBhIG1hdHRlciBvZiBwcmVzZW50YXRpb24gbm90IGEgcXVl c3Rpb24gb2YgdGVjaG5pY2FsIGZvdW5kYXRpb25zLiBXZSBjb3VsZCBvcHRlZCBmb3IgYSBzaW1p bGFyIGZvcm1hdCwgYnV0IHdlIGRlY2lkZWQgdG8gYmUgZGlyZWN0IHRvIHRoZSBwb2ludC4NCg0K DQoNClRoZSBkcmFmdCBpcyBjdXJyZW50bHkgcHJlc2VudGVkIGFzIGEgc3VwZXJzZXQgb2YgZXhp c3RpbmcgUkZDcywgZW5yaWNoZWQgd2l0aCBmZWF0dXJlcyByZXF1aXJlZCBmb3IgSVB2NCBzZXJ2 aWNlIGNvbnRpbnVpdHksIExBTiBjYXBhYmlsaXRpZXMsIGV0Yy4NCg0KQ2hlZXJzLA0KTWVkDQoN CkRlIDogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nD qSA6IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUgMDk6MTANCsOAIDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTg0KQ2MgOiBIZWF0bGV5LCBOaWNrOyBGcmVkIEJha2VyIChmcmVkKTsgZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnOyBWNiBP cHMgTGlzdA0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZp Y2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KT24gVHVlLCBGZWIgMTAsIDIwMTUgYXQgMTE6MzEgUE0s IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPj4gd3JvdGU6DQpJbiBjYXNlIHlvdSBtaXNzZWQgdGhlIGxhdGVzdCB2ZXJzaW9u IChzZWUgdGhlIGRpZmY6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE1JnVybDI9ZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUtMTYpLCB3ZSBhZGRyZXNzZWQgdGhlIGNoYW5nZXMgWU9VIGFz a2VkIGZvciBhbmQgYWxzbyB0aG9zZSBmcm9tIEphbWVzIGFuZCBCYXJiYXJhIChtYW55IHRoYW5r cyB0byB0aGVtKS4NCg0KV2hhdCBhZGRpdGlvbmFsIGNoYW5nZXMgeW91IHdvdWxkIGxpa2UgdG8g c2VlIGFkZGVkPw0KDQpJIGRvbid0IHRoaW5rIG1pbm9yIGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50 IHdvdWxkIGNhdXNlIG1lIHRvIHN1cHBvcnQgaXQuDQoNCkkgaGF2ZSBleHByZXNzZWQgbXkgY29u Y2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBpbiB0aGUgcGFzdC4gRm9yIGV4YW1wbGUsIEkgdGhp bmsgdGhlIGRvY3VtZW50IGlzIHRvbyBicm9hZCAoaW4gZmFjdCwgaGFybWZ1bGx5IGJyb2FkKTsg cGxhY2VzIHRvbyBtdWNoIGZvY3VzIG9uIHdoYXQgZmVhdHVyZXMgdG8gc3VwcG9ydCBhbmQgbm90 IGVub3VnaCBmb2N1cyBvbiB3aHk7IHJlYWRzIGxpa2UgYSBwcm9jdXJlbWVudCBzcGVjIGFuZCBu b3QgYSB0ZWNobmljYWwgZG9jdW1lbnQuIFByZXR0eSBtdWNoIHdoYXQgSSBzYWlkIGFscmVhZHkg YXQgSUVURiBsYXN0IGNhbGwgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2lldGYvY3VycmVudC9tc2c4MTY2My5odG1sIC0gYW5kIHdoYXQgSSBoYXZlIGJlZW4gc2F5aW5n IHNpbmNlIHdlIHN0YXJ0ZWQgZGlzY3Vzc2luZyB0aGlzIGRvY3VtZW50Lg0KDQpUaGUgZ29vZCBu ZXdzIGZvciB0aGlzIGRvY3VtZW50IGlzIHRoYXQgaXQgZG9lcyBub3QgbmVlZCBteSBzdXBwb3J0 IHRvIGFkdmFuY2UgLSBvbmUgb2JqZWN0aW9uIGlzIG5vdCBzdWZmaWNpZW50LiBJSVJDIHRoZSBj aGFpcnMvQURzIGhhdmUgc3RhdGVkIHRoYXQgdGhleSB3YW50IHRvIHNlZSAiY2xlYXIgY29uc2Vu c3VzIiB0byBzdXBwb3J0IGl0LCBhbmQgaWYgSSB3ZXJlIHRoZSBvbmx5IG9uZSBvYmplY3Rpbmcs IHRoZW4gSSBzdXBwb3NlIHRoYXQgd291bGQgYmUgY2xlYXIgY29uc2Vuc3VzLiBBZnRlciBhbGws IGNsZWFyIGNvbnNlbnN1cyBkb2VzIG5vdCBtZWFuIHVuYW5pbWl0eS4NCg0KTXkgb2JzZXJ2YXRp b24gb2YgdGhpcyB0aHJlYWQsIGhvd2V2ZXIsIGlzIHRoYXQgaXQncyBub3QganVzdCBtZSBvYmpl Y3RpbmcuIE1vc3QgY2xlYXJseSwgQnJpYW4gd3JvdGUgdGhhdCB0aGlzIHJlYWRzIGxpa2UgYSBw cm9jdXJlbWVudCBzcGVjIGFuZCBub3QgYW4gSUVURiBkb2N1bWVudC4gR2VydCB3cm90ZSB0aGF0 IGhlIGRvZXNuJ3Qgc2VlIGEgbmVlZCBmb3IgdGhpcyBkb2N1bWVudC4gSmFtZXMgc2FpZCBoZSBz aGFyZXMgbXkgZ2VuZXJhbCBvYmplY3Rpb25zLiBBbmQgc28gb24uIFlvdSBjYW4ndCBhZGRyZXNz IHRoYXQgc29ydCBvZiBvYmplY3Rpb24gd2l0aCBtaW5vciBlZGl0cy4gQW5kIHRoZXJlIGRvZXNu J3Qgc2VlbSB0byBiZSBsb3RzIG9mIHN1cHBvcnQgZm9yIHRoaXMgZG9jdW1lbnQsIGVpdGhlci4g SSBzZWUgb25lIHN0YXRlbWVudCBvZiBzdXBwb3J0IGZyb20gc29tZW9uZSB3aG8gaXMgbm90IGFu IGF1dGhvciwgYW5kIHZlcnkgbGl0dGxlIGVsc2UgZnJvbSB0aGUgcmVzdCBvZiB0aGUgV0cuDQo= --_000_787AE7BB302AE849A7480A190F8B933004908F65OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlRl eHRlYnJ1dENhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgYnJ1dCBDYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgYnJ1dCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgaGVh ciB0aGUgcG9pbnQgZnJvbSBCcmlhbi4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZX SVcsIHRoaXMgcG9pbnQgaXMgbWVudGlvbmVkIGV4cGxpY2l0bHkgaW4gdGhlIGludHJvZHVjdGlv bjoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IEhlbHAg T3BlcmF0b3JzIHdpdGggdGhlIGRldGFpbGVkIGRldmljZSByZXF1aXJlbWVudCBsaXN0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcmVwYXJhdGlvbiAodG8g YmUgZXhjaGFuZ2VkIHdpdGggZGV2aWNlIHN1cHBsaWVycykuJm5ic3A7IFRoaXMgaXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsc28gYSBjb250cmlidXRp b24gdG8gaGFybW9uaXplIE9wZXJhdG9ycycgcmVxdWlyZW1lbnRzIHRvd2FyZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRldmljZSB2ZW5kb3JzLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgcG9pbnQgd2FzIHBhcnQgb2YgdGhlIGRyYWZ0IHNp bmNlIHdlIHN1Ym1pdHRlZCB0aGUgZmlyc3QgaW5kaXZpZHVhbCBzdWJtaXNzaW9uLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZG9jdW1lbnQgd2FzIGFkb3B0ZWQgYnkgdGhlIFdHIGFu ZCBwYXNzZWQgYm90aCB0aGUgV0cgYW5kIElFVEYgTENzIHdpdGggdGhhdCBzY29wZS4gSSBuYWl2 ZWx5IGFzc3VtZWQgdGhhdCB0aGlzIHBvaW50IGlzIG5vdCBhbnltb3JlIGFuIGlzc3VlIGdpdmVu IHRoYXQgdGhlIGRyYWZ0IHBhc3NlZCBtYWpvciBtaWxlc3RvbmVzIChzZXZlcmFsIFdHTENzLCBJ RVRGIExDKQ0KIGFuZCB0aGUgSUVURiBjb25zZW5zdXMgZGVjbGFyZWQgZm9yIGl0IG1lYW5zIHRo aXMgaXMgbm90IGFuIGlzc3VlIHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+QlRXLCBhbnkgcmVxdWlyZW1lbnQgZG9jdW1lbnQgKENQRSByZXF1aXJlbWVu dCBSRkNzLCBmb3IgZXhhbXBsZSkgY2FuIGJlIHR1cm5lZCBpbnRvIGEgJnF1b3Q7cHJvY3VyZW1l bnQgc3BlY2lmaWNhdGlvbiZxdW90Oy4gSXQgaXMgYSBtYXR0ZXIgb2YgcHJlc2VudGF0aW9uIG5v dCBhIHF1ZXN0aW9uIG9mIHRlY2huaWNhbCBmb3VuZGF0aW9ucy4gV2UgY291bGQgb3B0ZWQgZm9y IGEgc2ltaWxhcg0KIGZvcm1hdCwgYnV0IHdlIGRlY2lkZWQgdG8gYmUgZGlyZWN0IHRvIHRoZSBw b2ludC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZHJhZnQgaXMgY3VycmVudGx5IHBy ZXNlbnRlZCBhcyBhIHN1cGVyc2V0IG9mIGV4aXN0aW5nIFJGQ3MsIGVucmljaGVkIHdpdGggZmVh dHVyZXMgcmVxdWlyZWQgZm9yIElQdjQgc2VydmljZSBjb250aW51aXR5LCBMQU4gY2FwYWJpbGl0 aWVzLCBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxMSBmw6l2cmll ciAyMDE1IDA5OjEwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBIZWF0bGV5LCBOaWNrOyBGcmVkIEJha2VyIChmcmVk KTsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYu b3JnOyBWNiBPcHMgTGlzdDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxMCwg MjAxNSBhdCAxMTozMSBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JbiBjYXNlIHlvdSBtaXNzZWQgdGhlIGxh dGVzdCB2ZXJzaW9uIChzZWUgdGhlIGRpZmY6DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2Zp bGUtMTUmYW1wO3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTYi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTUmYW1wO3VybDI9ZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTY8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4pLA0KIHdlIGFkZHJlc3NlZCB0aGUgY2hhbmdlcyBZT1UgYXNrZWQgZm9y IGFuZCBhbHNvIHRob3NlIGZyb20gSmFtZXMgYW5kIEJhcmJhcmEgKG1hbnkgdGhhbmtzIHRvIHRo ZW0pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+V2hhdCBhZGRpdGlvbmFsIGNoYW5nZXMgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGFkZGVkPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIG1pbm9yIGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50IHdv dWxkIGNhdXNlIG1lIHRvIHN1cHBvcnQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBleHByZXNzZWQgbXkgY29uY2VybnMgYWJv dXQgdGhpcyBkb2N1bWVudCBpbiB0aGUgcGFzdC4gRm9yIGV4YW1wbGUsIEkgdGhpbmsgdGhlIGRv Y3VtZW50IGlzIHRvbyBicm9hZCAoaW4gZmFjdCwgaGFybWZ1bGx5IGJyb2FkKTsgcGxhY2VzIHRv byBtdWNoIGZvY3VzIG9uIHdoYXQgZmVhdHVyZXMgdG8gc3VwcG9ydCBhbmQgbm90IGVub3VnaCBm b2N1cyBvbiB3aHk7IHJlYWRzIGxpa2UgYSBwcm9jdXJlbWVudA0KIHNwZWMgYW5kIG5vdCBhIHRl Y2huaWNhbCBkb2N1bWVudC4gUHJldHR5IG11Y2ggd2hhdCBJIHNhaWQgYWxyZWFkeSBhdCBJRVRG IGxhc3QgY2FsbCAtDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2lldGYvY3VycmVudC9tc2c4MTY2My5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2c4MTY2My5odG1sPC9hPiAtIGFuZCB3aGF0IEkg aGF2ZSBiZWVuIHNheWluZyBzaW5jZSB3ZSBzdGFydGVkIGRpc2N1c3NpbmcgdGhpcyBkb2N1bWVu dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGdvb2QgbmV3cyBmb3IgdGhpcyBkb2N1bWVudCBpcyB0aGF0IGl0IGRvZXMgbm90IG5lZWQg bXkgc3VwcG9ydCB0byBhZHZhbmNlIC0gb25lIG9iamVjdGlvbiBpcyBub3Qgc3VmZmljaWVudC4g SUlSQyB0aGUgY2hhaXJzL0FEcyBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgd2FudCB0byBzZWUgJnF1 b3Q7Y2xlYXIgY29uc2Vuc3VzJnF1b3Q7IHRvIHN1cHBvcnQgaXQsIGFuZCBpZiBJIHdlcmUgdGhl IG9ubHkgb25lIG9iamVjdGluZywNCiB0aGVuIEkgc3VwcG9zZSB0aGF0IHdvdWxkIGJlIGNsZWFy IGNvbnNlbnN1cy4gQWZ0ZXIgYWxsLCBjbGVhciBjb25zZW5zdXMgZG9lcyBub3QgbWVhbiB1bmFu aW1pdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk15IG9ic2VydmF0aW9uIG9mIHRoaXMgdGhyZWFkLCBob3dldmVyLCBpcyB0aGF0IGl0J3Mg bm90IGp1c3QgbWUgb2JqZWN0aW5nLiBNb3N0IGNsZWFybHksIEJyaWFuIHdyb3RlIHRoYXQgdGhp cyByZWFkcyBsaWtlIGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGFuIElFVEYgZG9jdW1lbnQu IEdlcnQgd3JvdGUgdGhhdCBoZSBkb2Vzbid0IHNlZSBhIG5lZWQgZm9yIHRoaXMgZG9jdW1lbnQu IEphbWVzIHNhaWQNCiBoZSBzaGFyZXMgbXkgZ2VuZXJhbCBvYmplY3Rpb25zLiBBbmQgc28gb24u IFlvdSBjYW4ndCBhZGRyZXNzIHRoYXQgc29ydCBvZiBvYmplY3Rpb24gd2l0aCBtaW5vciBlZGl0 cy4gQW5kIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBsb3RzIG9mIHN1cHBvcnQgZm9yIHRoaXMg ZG9jdW1lbnQsIGVpdGhlci4gSSBzZWUgb25lIHN0YXRlbWVudCBvZiBzdXBwb3J0IGZyb20gc29t ZW9uZSB3aG8gaXMgbm90IGFuIGF1dGhvciwgYW5kIHZlcnkgbGl0dGxlDQogZWxzZSBmcm9tIHRo ZSByZXN0IG9mIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933004908F65OPEXCLILM23corp_-- From nobody Wed Feb 11 01:44:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86581A87A0 for ; Wed, 11 Feb 2015 01:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApepwEXp6Qn7 for ; Wed, 11 Feb 2015 01:44:17 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E6F1A8798 for ; Wed, 11 Feb 2015 01:44:16 -0800 (PST) Received: by iery20 with SMTP id y20so2712685ier.1 for ; Wed, 11 Feb 2015 01:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H08rC6GF2igvmY6FioFWmU7kxBSnvdXdXP7iixzTsXs=; b=RIZEt08PWZ6I2xcivSCZqRisjpKpkRZ7wkixLfIleofJHjdXoVUUtzCqobX8OQagU1 DXEdoJM49jRnnJzXzVe4uI/fwB5RvMN300GIapzUwS/qKsNzAnLTxEPNV7UywmU36f1R nH5S3H3oyFd9NeKZIkTbRdMqJs1HA58xVr5wg2Kom4wM+BW2nw0rCt36pdKjKoW9SGCy lYQfWG1FiQtp++bO3+V80BKkQamJuSq4qI2xSjPF4ZSAmRl9eRxhaC5Z9iGujYWUyMij gDXVgIzvDtdCr0kC5CD1nNgRUHMgIV55hgR4WztwBC9aQz3jmVGC2hcXKbvuWwaxv/6F 7/mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H08rC6GF2igvmY6FioFWmU7kxBSnvdXdXP7iixzTsXs=; b=EWjoF3J9d7g5SttXbQBQaABdaxWC16MmhKYyXfeCh1rjj8v7NUtoiIPEcQrmAN3Yc0 QjR5Zh7raZQlNbxdDzhlXPgiYwhmzP160nBQQ4HWjRR+zFZdMQgoys0lqpVvsJhoLaOp 3Ekini6I9oRTXMO6A6mWuUW0P3aRcPdKELAJiF2xdlpxJjR3PtQY2MRBG+5wljyic0Ha VJfyk4AA7549bjc1QCM0+y7kk+BDPdvHFd70eqHrtxLXxY86yhD1SKyyWZmPdCrWTLdj aCWiVWQOWXvwlEcvJLTgGigqP/ya2xwgpXUUlNBP0ZFywT7G1BK1YBxO4VNZHr0WkO4q gZZA== X-Gm-Message-State: ALoCoQmkFl24uiJhK/o4LOCPxyJOfuJAUtqPKthCnZELx/ISwSSQ/T92W8jsI7Ks+sZAp7uaSaqU X-Received: by 10.107.136.24 with SMTP id k24mr22398530iod.59.1423647856284; Wed, 11 Feb 2015 01:44:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Wed, 11 Feb 2015 01:43:56 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Wed, 11 Feb 2015 01:43:56 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113ed15ac27bd8050eccd814 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 09:44:18 -0000 --001a113ed15ac27bd8050eccd814 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2015 at 12:51 AM, wrote: > > The document was adopted by the WG and passed both the WG and IETF LCs > with that scope. I naively assumed that this point is not anymore an issu= e > given that the draft passed major milestones (several WGLCs, IETF LC) and > the IETF consensus declared for it means this is not an issue to advance > the document. > I think that assumption is incorrect, given Fred's explicit statement on this thread, "Before I bother the IESG with it a third time, I=E2=80=99d re= ally like to hear a clear consensus, not a rough one." https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html --001a113ed15ac27bd8050eccd814 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 11, 2015 at 12:51 AM, <mohamed.boucadair@orange.com> wrote:=C2=A0

The document was adopted by the WG and passed both = the WG and IETF LCs with that scope. I naively assumed that this point is n= ot anymore an issue given that the draft passed major milestones (several W= GLCs, IETF LC) and the IETF consensus declared for it means this is not an issue to advan= ce the document.

I think that assum= ption is incorrect, given Fred's explicit statement on this thread, &qu= ot;Before I bother the IESG with it a third time, I=E2=80=99d really like t= o hear a clear consensus, not a rough one."

--001a113ed15ac27bd8050eccd814-- From nobody Wed Feb 11 02:08:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04B1A8774 for ; Wed, 11 Feb 2015 02:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.202 X-Spam-Level: *** X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFRih_tIfr3b for ; Wed, 11 Feb 2015 02:08:12 -0800 (PST) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030011A86F6 for ; Wed, 11 Feb 2015 02:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423649291; bh=XSCFalWEiF8UoOI/ni6QoMf4hl/4F/zMSvQ9OccbIu8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Opla1MoWs0MLa7qujuwck1W3fbUgfMZRm30ROBot66UNOO/lgF6gCHdmMccfKLqzAVA+BjYb8DwFX91p4CCVhKjFAb8b0AJQlVmH28nmEa5noiXFnfBN+lRNzOOgjLPSuPxQ3Q7+C8+qTJXf8qN+1VLvrWOwRur2jMEfibh5FJH9pRKqfYv+It9EAuSu7/VdGyArpW7/ST6gPMGAOS2hRdBZU882i1T8TP46xG1igXZvUjug/1HhrZO8W5fvby8vWKpSOFh4twu5RUm58lzOwGSA4ePh/yyMDyYwSEksJd5VXc9TPstQhAWaGAUMVS33/YtQ/mZ8zyX8IxKfVyK80A== Received: from [98.139.215.141] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2015 10:08:11 -0000 Received: from [98.139.212.241] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2015 10:08:11 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 11 Feb 2015 10:08:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 217898.46177.bm@omp1050.mail.bf1.yahoo.com X-YMail-OSG: z0EkUQ8VM1k4bdh0O0LsgJ6lZlnDRHbexEit_9.u8pIKkAQ6plJCgh7r.KN1i0e Zw_hM7kkwa9ZlZ7tf13FoRs4TzOEbHy5tgb44kbauoWTccWOLo8Bi1tY3oxkIlCuTifFwzv68Jba Fr8aSZbzL24RtP00iJygHoZSbYcTSuV3_2X7QCg17FI_jcIY3hICw2R8ahfBKaxoCpo91ds_Aeea c9Ya5p.tndRKIBYZcVfC6slLMAzbFI1tZjyA8oETo05UTBJ7N.V7unh31BHYZERtPCXz.gjihy0V szRM1o8mvj.8yvqSYxM7EYz4yeHCB240HXJdZcA5.oTyfQ3sLFt53q_1u_qDYCRONK39DJPrlk4L I_u8.7.bH6RS6LK3KGQgCye_oZxlZyJVAt9ZVoNs6D2W7ZyeqORc0sTQhOdqJg.P1G534vh5QSVq 6mDYq7X62cUDA0Z_NDdhS0S.UENH3xjzW.omGNc0auE7aH4Xs602OAs1HjEV8igNBs9EHsI_z_Gd ZhWP12CAQ_eOfue8wQmwfleE5xPkZnjlrI08Z.FhwxBsRNJ0- Received: by 66.196.80.119; Wed, 11 Feb 2015 10:08:10 +0000 Date: Wed, 11 Feb 2015 10:08:09 +0000 (UTC) From: Mark ZZZ Smith To: Lorenzo Colitti , "" Message-ID: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3178069_1134467378.1423649289891" Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:08:15 -0000 ------=_Part_3178069_1134467378.1423649289891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Lorenzo and others, and this has made me wonder about perhaps = what might be different philosophies between e.g. the ITU and the IETF rega= rding how to handle devices that have different versions or feature revisio= ns of protocols. In the IETF, major and very significant differences are handled by using a = different protocol version, where as for less significant differences, mand= atory absolute minimums and supported option negotiation is used to cope wi= th those =C2=A0differences. This allows different versions or feature revis= ions of different protocols to co-exist on a IPv6 node, to the point where = an individual node may have a unique combination of protocol versions and p= rotocol feature revisions that no other node has. Reading through this draft and having looked a bit at the telephone standar= ds world, it seems the traditional telephony world has more of an approach = of 'profiles', which specify a snapshot of features across many protocols a= t a particular time. This draft is stating them as recommendations, perhaps= to be more in line with the less prescriptive approach of the IETF. In eff= ect, I think profiles are like having major version numbers, and therefore = mandatory maximums, with no or very little option negotiation. The concern I have about this 'profiles' approach is that I think it probab= ly slows down deployment of new capabilities in the protocols to a device, = because doing so now stops it being "Profile XYZ.ABC" compliant. Perhaps it= stops a phone vendor from deploying new capabilities because they have to = wait until there is a profile that allows it. Perhaps they can't deploy som= e more limited new capabilities because doing so would cause them to have t= o try to comply with a later and newer profile, and that then creates an ob= ligation to support all of the newer profile's capabilities, and the phone'= s hardware just can't support all of them. The other thing I wonder about is what is so special about telephones (anym= ore)? They're fundamentally now nothing more than portable portable compute= rs that just happen to also be used to make phone calls, as well as running= many other types of applications. Their 3GPP link-layer interface is the o= nly thing that makes them specifically different from any other portable co= mputer, and I think the only real need to make IPv6 run on them would have = been to prepare and update any 3GPP link characteristic specific IPv6 RFCs,= that in particular didn't invent new ways of doing what existing non-link = specific IPv6 protocols could already do (e.g., PCOs for DNS instead of ori= ginally just stateless/stateful DHCPv6 and now (although mostly, in my opin= ion, unfortunately) RAs). It seems to me that if smartphone vendors need or needed guidance on what t= hey should implement to support IPv6, they should be or should have been pr= ovided with the IPv6 Node Requirements RFC, and an RFC that specifies how t= o bootstrap IPv6 over an 3GPP link to the point where the non-link type spe= cific standard IPv6 methods could be used, as all of the other IPv6 over Fo= o-link RFCs do. As major computer companies are now in charge of smartphone= development/advancement, that is probably in effect what is mostly happeni= ng anyway. Regards,Mark. From: Lorenzo Colitti To: "" =20 Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" ; V6 Ops List =20 Sent: Wednesday, 11 February 2015, 19:09 Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call =20 On Tue, Feb 10, 2015 at 11:31 PM, wrote: In case you missed the latest version (see the diff:http://www.ietf.org/rfc= diff?url1=3Ddraft-ietf-v6ops-mobile-device-profile-15&url2=3Ddraft-ietf-v6o= ps-mobile-device-profile-16), we addressed the changes YOU asked for and al= so those from James and Barbara (many thanks to them). =C2=A0What additional changes you would like to see added? I don't think minor changes to the document would cause me to support it. I have expressed my concerns about this document in the past. For example, = I think the document is too broad (in fact, harmfully broad); places too mu= ch focus on what features to support and not enough focus on why; reads lik= e a procurement spec and not a technical document. Pretty much what I said = already at IETF last call - https://www.ietf.org/mail-archive/web/ietf/curr= ent/msg81663.html - and what I have been saying since we started discussing= this document. The good news for this document is that it does not need my support to adva= nce - one objection is not sufficient. IIRC the chairs/ADs have stated that= they want to see "clear consensus" to support it, and if I were the only o= ne objecting, then I suppose that would be clear consensus. After all, clea= r consensus does not mean unanimity. My observation of this thread, however, is that it's not just me objecting.= Most clearly, Brian wrote that this reads like a procurement spec and not = an IETF document. Gert wrote that he doesn't see a need for this document. = James said he shares my general objections. And so on. You can't address th= at sort of objection with minor edits. And there doesn't seem to be lots of= support for this document, either. I see one statement of support from som= eone who is not an author, and very little else from the rest of the WG. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_3178069_1134467378.1423649289891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I ag= ree with Lorenzo and others, and this has made me wonder about perhaps what= might be different philosophies between e.g. the ITU and the IETF regardin= g how to handle devices that have different versions or feature revisions o= f protocols.

In the IETF, ma= jor and very significant differences are handled by using a different proto= col version, where as for less significant differences, mandatory absolute = minimums and supported option negotiation is used to cope with those  = differences. This allows different versions or feature revisions of differe= nt protocols to co-exist on a IPv6 node, to the point where an individual n= ode may have a unique combination of protocol versions and protocol feature= revisions that no other node has.

Reading through this draft and having looked a bit at the telephone st= andards world, it seems the traditional telephony world has more of an appr= oach of 'profiles', which specify a snapshot of features across many protoc= ols at a particular time. This draft is stating them as recommendations, pe= rhaps to be more in line with the less prescriptive approach of the IETF. I= n effect, I think profiles are like having major version numbers, and there= fore mandatory maximums, with no or very little option negotiation.<= /div>

The concern I have about this 'profil= es' approach is that I think it probably slows down deployment of new capab= ilities in the protocols to a device, because doing so now stops it being "= Profile XYZ.ABC" compliant. Perhaps it stops a phone vendor from deploying = new capabilities because they have to wait until there is a profile that al= lows it. Perhaps they can't deploy some more limited new capabilities becau= se doing so would cause them to have to try to comply with a later and newe= r profile, and that then creates an obligation to support all of the newer = profile's capabilities, and the phone's hardware just can't support all of = them.
=
The other thing I wonder about is what is so special about telephones = (anymore)? They're fundamentally now nothing more than portable portable co= mputers that just happen to also be used to make phone calls, as well as ru= nning many other types of applications. Their 3GPP link-layer interface is = the only thing that makes them specifically different from any other portab= le computer, and I think the only real need to make IPv6 run on them would = have been to prepare and update any 3GPP link characteristic specific IPv6 = RFCs, that in particular didn't invent new ways of doing what existing non-= link specific IPv6 protocols could already do (e.g., PCOs for DNS instead o= f originally just stateless/stateful DHCPv6 and now (although mostly, in my= opinion, unfortunately) RAs).

It seems to me that if smartphone vendors need or needed guidance= on what they should implement to support IPv6, they should be or should ha= ve been provided with the IPv6 Node Requirements RFC, and an RFC that speci= fies how to bootstrap IPv6 over an 3GPP link to the point where the non-lin= k type specific standard IPv6 methods could be used, as all of the other IP= v6 over Foo-link RFCs do. As major computer companies are now in charge of = smartphone development/advancement, that is probably in effect what is most= ly happening anyway.

Regards,
= Mark.

From:= Lorenzo Colitti <lorenzo@google.com>
To: "<mohamed.boucadair@orange.com>= ;" <mohamed.boucadair@orange.com>
Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.iet= f.org" <draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org>; V= 6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobil= e-device-profile last call



= On Tue, Feb 10, 2015 at 11:31 PM, <mohamed.boucadair@oran= ge.com> wrote:
In= case you missed the latest version (see the diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-mobile-device-profile-1= 5&url2=3Ddraft-ietf-v6ops-mobile-device-profile-16), we addressed the changes YOU asked for and also those = from James and Barbara (many thanks to them).
 =
What additional changes you would like to see added?

I don't thin= k minor changes to the document would cause me to support it.
I have expressed my concerns about this document= in the past. For example, I think the document is too broad (in fact, harm= fully broad); places too much focus on what features to support and not eno= ugh focus on why; reads like a procurement spec and not a technical documen= t. Pretty much what I said already at IETF last call - https://www.ietf.org/mail-archive/web/ietf/= current/msg81663.html - and what I have been saying since we started di= scussing this document.

The good ne= ws for this document is that it does not need my support to advance - one o= bjection is not sufficient. IIRC the chairs/ADs have stated that they want = to see "clear consensus" to support it, and if I were the only one objectin= g, then I suppose that would be clear consensus. After all, clear consensus= does not mean unanimity.

My observ= ation of this thread, however, is that it's not just me objecting. Most cle= arly, Brian wrote that this reads like a procurement spec and not an IETF d= ocument. Gert wrote that he doesn't see a need for this document. James sai= d he shares my general objections. And so on. You can't address that sort o= f objection with minor edits. And there doesn't seem to be lots of support = for this document, either. I see one statement of support from someone who = is not an author, and very little else from the rest of the WG.
=

_______________________________________________
v6o= ps mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


------=_Part_3178069_1134467378.1423649289891-- From nobody Wed Feb 11 02:22:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D481A87BF for ; Wed, 11 Feb 2015 02:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQxo9iplorkx for ; Wed, 11 Feb 2015 02:22:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAF91A1B8C for ; Wed, 11 Feb 2015 02:22:23 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id B376E374212; Wed, 11 Feb 2015 11:22:21 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 8CF99180089; Wed, 11 Feb 2015 11:22:21 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 11:22:21 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQRd9A94KoZb5URc+rHGKXMO3E0JzrOZNQ Date: Wed, 11 Feb 2015 10:22:20 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004908FF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004908FF9OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:22:26 -0000 --_000_787AE7BB302AE849A7480A190F8B933004908FF9OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJIHJlYWxseSB0cnVzdCBhbmQgZGVmZXIgdG8gdGhlIGNoYWlycyB0byBkZWNpZGUg d2hldGhlciB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgc2VudCB0byB0aGUgSUVTRywgdG8g YmUgd2l0aGRyYXduLCB0byBiZSBzZW50IHRvIElTRSwgb3Igd2hhdGV2ZXIgYWN0aW9uIHRoZXkg anVkZ2UgYXBwcm9wcmlhdGUgdG8gcmVmbGVjdCB0aGUgd2cgcG9zaXRpb24uDQoNCk15IGNvbmNl cm4gYXMgYW4gZWRpdG9yIG9mIHRoZSBkb2N1bWVudCBpcyB0byB1bmRlcnN0YW5kIHdoeSB0aGUg ZG9jdW1lbnQgaXMgaGFybWZ1bCB0byBJUHY2IGRlcGxveW1lbnQsIHdoZXRoZXIgaXQgY29udGFp bnMgdGVjaG5pY2FsIGZsYXdzLCB1bmRlcnN0YW5kIHdoYXQgaXMgbWVhbnQgYnkg4oCcaGFybWZ1 bGx5IGFicm9hZOKAnSwgd2hpY2ggYXNwZWN0cyBjYW4gYmUgcmVtb3ZlZC90d2Vha2VkIHNvIHRo YXQgaXQgY2Fubm90IGJlIHNlZW4gYW55bW9yZSDigJxoYXJtZnVsbHkgYWJyb2Fk4oCdLCBldGMu IEnigJltIGluIHRoYXQgc3RhbmQsIG5vdCBzb21ld2hlcmUgZWxzZS4NCg0KSSB3b3VsZCBsaWtl IHRvIHJlbWluZCB0aGF0IHRoZSBJRVRGIGlzIGFsd2F5cyBhc2tpbmcgdG8gYXNzb2NpYXRlIG9w ZXJhdG9ycy4gVGhpcyBkcmFmdCB0cmllcyB0byBoYXZlIGNvbW1vbiB2b2ljZSBmcm9tIGEgZ3Jv dXAgb2Ygb3BlcmF0b3JzIHdobyB0aGluayB0aGVyZSBpcyBhIHZvaWQgaW4gZXhpc3RpbmcgUkZD cyBhbmQgYSBkb2N1bWVudCBpcyBzdGlsbCBuZWVkZWQuIE5vdGUsIHRoZSBpdGVtcyBsaXN0ZWQg aW4gdGhlIGRvY3VtZW50IGFyZSBhbGwgUkZDcyBvciBzcGVjaWZpY2F0aW9ucyBmcm9tIDNHUFAg b3IgR1NNQS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56byBDb2xpdHRpIFttYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUg MTA6NDQNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBIZWF0bGV5LCBOaWNr OyBGcmVkIEJha2VyIChmcmVkKTsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2Zp bGUuYWxsQHRvb2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdA0KT2JqZXQgOiBSZTogW3Y2b3BzXSBk cmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KT24gV2Vk LCBGZWIgMTEsIDIwMTUgYXQgMTI6NTEgQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNClRoZSBkb2N1 bWVudCB3YXMgYWRvcHRlZCBieSB0aGUgV0cgYW5kIHBhc3NlZCBib3RoIHRoZSBXRyBhbmQgSUVU RiBMQ3Mgd2l0aCB0aGF0IHNjb3BlLiBJIG5haXZlbHkgYXNzdW1lZCB0aGF0IHRoaXMgcG9pbnQg aXMgbm90IGFueW1vcmUgYW4gaXNzdWUgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgcGFzc2VkIG1ham9y IG1pbGVzdG9uZXMgKHNldmVyYWwgV0dMQ3MsIElFVEYgTEMpIGFuZCB0aGUgSUVURiBjb25zZW5z dXMgZGVjbGFyZWQgZm9yIGl0IG1lYW5zIHRoaXMgaXMgbm90IGFuIGlzc3VlIHRvIGFkdmFuY2Ug dGhlIGRvY3VtZW50Lg0KSSB0aGluayB0aGF0IGFzc3VtcHRpb24gaXMgaW5jb3JyZWN0LCBnaXZl biBGcmVkJ3MgZXhwbGljaXQgc3RhdGVtZW50IG9uIHRoaXMgdGhyZWFkLCAiQmVmb3JlIEkgYm90 aGVyIHRoZSBJRVNHIHdpdGggaXQgYSB0aGlyZCB0aW1lLCBJ4oCZZCByZWFsbHkgbGlrZSB0byBo ZWFyIGEgY2xlYXIgY29uc2Vuc3VzLCBub3QgYSByb3VnaCBvbmUuIg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjEyMjkuaHRtbA0K --_000_787AE7BB302AE849A7480A190F8B933004908FF9OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkg cmVhbGx5IHRydXN0IGFuZCBkZWZlciB0byB0aGUgY2hhaXJzIHRvIGRlY2lkZSB3aGV0aGVyIHRo ZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBzZW50IHRvIHRoZSBJRVNHLCB0byBiZSB3aXRoZHJh d24sIHRvIGJlIHNlbnQgdG8gSVNFLCBvciB3aGF0ZXZlciBhY3Rpb24NCiB0aGV5IGp1ZGdlIGFw cHJvcHJpYXRlIHRvIHJlZmxlY3QgdGhlIHdnIHBvc2l0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TXkgY29uY2VybiBhcyBhbiBlZGl0b3Ig b2YgdGhlIGRvY3VtZW50IGlzIHRvIHVuZGVyc3RhbmQgd2h5IHRoZSBkb2N1bWVudCBpcyBoYXJt ZnVsIHRvIElQdjYgZGVwbG95bWVudCwgd2hldGhlciBpdCBjb250YWlucyB0ZWNobmljYWwgZmxh d3MsIHVuZGVyc3RhbmQgd2hhdA0KIGlzIG1lYW50IGJ5IOKAnGhhcm1mdWxseSBhYnJvYWTigJ0s IHdoaWNoIGFzcGVjdHMgY2FuIGJlIHJlbW92ZWQvdHdlYWtlZCBzbyB0aGF0IGl0IGNhbm5vdCBi ZSBzZWVuIGFueW1vcmUg4oCcaGFybWZ1bGx5IGFicm9hZOKAnSwgZXRjLiBJ4oCZbSBpbiB0aGF0 IHN0YW5kLCBub3Qgc29tZXdoZXJlIGVsc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgd291bGQgbGlrZSB0byByZW1pbmQgdGhhdCB0aGUgSUVU RiBpcyBhbHdheXMgYXNraW5nIHRvIGFzc29jaWF0ZSBvcGVyYXRvcnMuIFRoaXMgZHJhZnQgdHJp ZXMgdG8gaGF2ZSBjb21tb24gdm9pY2UgZnJvbSBhIGdyb3VwIG9mIG9wZXJhdG9ycyB3aG8gdGhp bmsgdGhlcmUNCiBpcyBhIHZvaWQgaW4gZXhpc3RpbmcgUkZDcyBhbmQgYSBkb2N1bWVudCBpcyBz dGlsbCBuZWVkZWQuIE5vdGUsIHRoZSBpdGVtcyBsaXN0ZWQgaW4gdGhlIGRvY3VtZW50IGFyZSBh bGwgUkZDcyBvciBzcGVjaWZpY2F0aW9ucyBmcm9tIDNHUFAgb3IgR1NNQS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g TG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUgMTA6NDQ8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IEhlYXRsZXksIE5pY2s7IEZyZWQgQmFrZXIgKGZyZWQpOyBkcmFmdC1pZXRmLXY2b3BzLW1v YmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IFY2IE9wcyBMaXN0PGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDExLCAyMDE1IGF0IDEyOjUxIEFNLCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2Js YW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZG9j dW1lbnQgd2FzIGFkb3B0ZWQgYnkgdGhlIFdHIGFuZCBwYXNzZWQgYm90aCB0aGUgV0cgYW5kIElF VEYgTENzIHdpdGggdGhhdCBzY29wZS4gSSBuYWl2ZWx5IGFzc3VtZWQgdGhhdCB0aGlzIHBvaW50 IGlzIG5vdCBhbnltb3JlIGFuIGlzc3VlIGdpdmVuIHRoYXQgdGhlIGRyYWZ0IHBhc3NlZCBtYWpv ciBtaWxlc3RvbmVzIChzZXZlcmFsIFdHTENzLCBJRVRGIExDKSBhbmQgdGhlIElFVEYgY29uc2Vu c3VzDQogZGVjbGFyZWQgZm9yIGl0IG1lYW5zIHRoaXMgaXMgbm90IGFuIGlzc3VlIHRvIGFkdmFu Y2UgdGhlIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IGFzc3VtcHRpb24gaXMgaW5j b3JyZWN0LCBnaXZlbiBGcmVkJ3MgZXhwbGljaXQgc3RhdGVtZW50IG9uIHRoaXMgdGhyZWFkLCAm cXVvdDtCZWZvcmUgSSBib3RoZXIgdGhlIElFU0cgd2l0aCBpdCBhIHRoaXJkIHRpbWUsIEnigJlk IHJlYWxseSBsaWtlIHRvIGhlYXIgYSBjbGVhciBjb25zZW5zdXMsIG5vdCBhIHJvdWdoIG9uZS4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9j dXJyZW50L21zZzIxMjI5Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvdjZvcHMvY3VycmVudC9tc2cyMTIyOS5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933004908FF9OPEXCLILM23corp_-- From nobody Wed Feb 11 02:43:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333A61A87D0 for ; Wed, 11 Feb 2015 02:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srqccdW0DgFu for ; Wed, 11 Feb 2015 02:43:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38631A87CC for ; Wed, 11 Feb 2015 02:43:40 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3F4772644A8; Wed, 11 Feb 2015 11:43:39 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1BB4927C07F; Wed, 11 Feb 2015 11:43:39 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 11:43:38 +0100 From: To: Mark ZZZ Smith Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQReKi94KoZb5URc+rHGKXMO3E0JzrPqHg Date: Wed, 11 Feb 2015 10:43:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004909030@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004909030OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:43:46 -0000 --_000_787AE7BB302AE849A7480A190F8B933004909030OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNYXJrLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdo dHMuIEkgZG8gc2hhcmUgc2V2ZXJhbCBvZiB5b3VyIHBvaW50cy4NCg0KSSB3b3VsZCBsaWtlIHRv IG1ha2UgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KDQrCtyAgICAgICAgIFRoZSBkb2N1bWVu dCBpcyBubyBtb3JlIHRoYW4gYSBzdXBlcnNldCBvZiBleGlzdGluZyBSRkNzIHRoYXQgYXJlIGRl ZmluaW5nIOKAnHByb2ZpbGVz4oCdIHdpdGhvdXQgY2FsbGluZyB0aGVtIGFzIHN1Y2guIOKAnElQ djYgbm9kZSByZXF1aXJlbWVudHPigJ0gb3IgUkZDNzA2NiBhcmUgcHJvZmlsZXMhIFRoaXMgaXMg bWVudGlvbmVkIGluIFNlY3Rpb24gMS4yOg0KDQogICBUaGlzIHByb2ZpbGUgaXMgYSBzdXBlcnNl dCBvZiB0aGF0IG9mIHRoZSBJUHY2IHByb2ZpbGUgZm9yIDNHUFANCiAgIENlbGx1bGFyIEhvc3Rz IFtSRkM3MDY2PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNjY+XSwgd2hpY2ggaXMg aW4gdHVybiBhIHN1cGVyc2V0IG9mIElQdjYgTm9kZQ0KICAgUmVxdWlyZW1lbnRzIFtSRkM2NDM0 PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY0MzQ+XS4gIEl0IHRhcmdldHMgY2VsbHVs YXIgbm9kZXMsIGluY2x1ZGluZyBHUFJTLA0KICAgRVBDIChFdm9sdmVkIFBhY2tldCBDb3JlKSBh bmQgSUVFRSA4MDIuMTEgbmV0d29ya3MsIHRoYXQgcmVxdWlyZQ0KICAgZmVhdHVyZXMgdG8gZW5z dXJlIElQdjQgc2VydmljZSBkZWxpdmVyeSBvdmVyIGFuIElQdjYtb25seSB0cmFuc3BvcnQNCiAg IGluIGFkZGl0aW9uIHRvIHRoZSBiYXNlIElQdjYgc2VydmljZS4gIE1vcmVvdmVyLCB0aGlzIHBy b2ZpbGUgY292ZXJzDQogICBjZWxsdWxhciBDUEVzIHRoYXQgYXJlIHVzZWQgaW4gdmFyaW91cyBk ZXBsb3ltZW50cyB0byBvZmZlciBmaXhlZC0NCiAgIGxpa2Ugc2VydmljZXMuICBSZWNvbW1lbmRh dGlvbnMgaW5zcGlyZWQgZnJvbSByZWFsIGRlcGxveW1lbnQNCiAgIGV4cGVyaWVuY2VzIChlLmcu LCByb2FtaW5nKSBhcmUgaW5jbHVkZWQgaW4gdGhpcyBwcm9maWxlLiAgQWxzbywgdGhpcw0KICAg cHJvZmlsZSBza2V0Y2hlcyByZWNvbW1lbmRhdGlvbnMgZm9yIHRoZSBzYWtlIG9mIGRldGVybWlu aXN0aWMNCiAgIGJlaGF2aW9ycyBvZiBjZWxsdWxhciBkZXZpY2VzIHdoZW4gdGhlIHNhbWUgY29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KICAgaXMgcmVjZWl2ZWQgb3ZlciBzZXZlcmFsIGNoYW5u ZWxzLg0KDQoNCsK3ICAgICAgICAgVGhlcmUgYXJlIGNvbmZsaWN0cyBiZXR3ZWVuIFJGQzcwNjYg YW5kIFJGQzY0MzQgKElQdjYgbm9kZSByZXF1aXJlbWVudHMpOiBUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyB3aGljaCBvbmUgc2hvdWxkIHdpbi4NCg0KDQogICBGb3IgY29uZmxpY3RpbmcgcmVjb21t ZW5kYXRpb25zIGluIFtSRkM3MDY2PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNjY+ XSBhbmQgW1JGQzY0MzQ8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQzND5dIChlLmcu LA0KDQogICBOZWlnaGJvciBEaXNjb3ZlcnkgUHJvdG9jb2wpLCB0aGlzIHByb2ZpbGUgYWRoZXJl cyB0byBbUkZDNzA2NjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDY2Pl0uDQoNCiAg IEluZGVlZCwgdGhlIHN1cHBvcnQgb2YgTmVpZ2hib3IgRGlzY292ZXJ5IFByb3RvY29sIGlzIG1h bmRhdG9yeSBpbg0KDQogICAzR1BQIGNlbGx1bGFyIGVudmlyb25tZW50IGFzIGl0IGlzIHRoZSBv bmx5IHdheSB0byBjb252ZXkgSVB2NiBwcmVmaXgNCg0KICAgdG93YXJkcyB0aGUgM0dQUCBjZWxs dWxhciBkZXZpY2UuICBJbiBwYXJ0aWN1bGFyLCBNVFUgKE1heGltdW0NCg0KICAgVHJhbnNtaXNz aW9uIFVuaXQpIGNvbW11bmljYXRpb24gdmlhIFJvdXRlciBBZHZlcnRpc2VtZW50IG11c3QgYmUN Cg0KICAgc3VwcG9ydGVkIHNpbmNlIG1hbnkgM0dQUCBuZXR3b3JrcyBkbyBub3QgaGF2ZSBhIHN0 YW5kYXJkIE1UVQ0KDQogICBzZXR0aW5nLg0KDQoNCsK3ICAgICAgICAgQWNjZXNzIHRvIG1vYmls ZSBuZXR3b3JrcyBzaG91bGQgYmUgaGFybW9uaXplZCB3aXRoIHRoZSBmaXhlZCBvbmU6IHRoaXMg aXMgZm9yIGluc3RhbmNlIHRoZSByZWFzb24gd2h5IHRoaXMgZG9jdW1lbnQgYWR2b2NhdGVzIGZv ciB0aGUgZm9sbG93aW5nOg0KDQoNCiAgIFRoaXMgcHJvZmlsZSB1c2VzIGEgc3Ryb25nZXIgbGFu Z3VhZ2UgZm9yIHRoZSBzdXBwb3J0IG9mIFByZWZpeA0KDQogICBEZWxlZ2F0aW9uIGNvbXBhcmVk IHRvIFtSRkM3MDY2PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNjY+XS4gIFRoZSBt YWluIG1vdGl2YXRpb24gaXMgdGhhdA0KDQogICBjZWxsdWxhciBuZXR3b3JrcyBhcmUgbW9yZSBh bmQgbW9yZSBwZXJjZWl2ZWQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8NCg0KICAgZml4ZWQgbmV0d29y a3MgZm9yIGhvbWUgSVAtYmFzZWQgc2VydmljZXMgZGVsaXZlcnk7IGVzcGVjaWFsbHkgd2l0aA0K DQogICB0aGUgYWR2ZW50IG9mIHNtYXJ0cGhvbmVzIGFuZCAzR1BQIGRhdGEgZG9uZ2xlcy4gIFRo ZXJlIGlzIGEgbmVlZCBmb3INCg0KICAgYW4gZWZmaWNpZW50IG1lY2hhbmlzbSB0byBhc3NpZ24g c2hvcnRlciBwcmVmaXggdGhhbiAvNjQgdG8gY2VsbHVsYXINCg0KICAgaG9zdHMgc28gdGhhdCBl YWNoIExBTiBzZWdtZW50IGNhbiBnZXQgaXRzIG93biAvNjQgcHJlZml4IGFuZCBtdWx0aS0NCg0K ICAgbGluayBzdWJuZXQgaXNzdWVzIHRvIGJlIGF2b2lkZWQuICBUaGUgc3VwcG9ydCBvZiB0aGlz IGZ1bmN0aW9uYWxpdHkNCg0KICAgaW4gYm90aCBjZWxsdWxhciBhbmQgZml4ZWQgbmV0d29ya3Mg aXMga2V5IGZvciBmaXhlZC1tb2JpbGUNCg0KICAgY29udmVyZ2VuY2UuDQoNCg0KwrcgICAgICAg ICBUaGVyZSBhcmUgKHN0aWxsKSBzb21lIHNwZWNpZmljaXRpZXMgZm9yIG1vYmlsZSBkZXZpY2Vz OiBQRFAgY3JlYXRpb24sIHJvYW1pbmcgYXNwZWN0cywgZXRjLiBIYXZpbmcgYSDigJxzdGFuZGFy ZOKAnSB3aHkgdG8gYWRkcmVzcyB0aG9zZSBpc3N1ZSBpcyBrZXkuDQoNCsK3ICAgICAgICAgSVB2 NCBjb250aW51aXR5IG1lY2hhbmlzbXMgZGVmaW5lZCBmb3IgZml4ZWQgZGV2aWNlcyBkb2VzIG5v dCBhcHBseSBmb3IgdGhlIG1vYmlsZSBuZXR3b3JrOiB0aGUgY291bnRlcnBhcnQgb2YgdGhpcyBw cm9maWxlIGZvciB0aGUgZml4ZWQgY2FzZSBjYW4gYmUgZm9yIGluc3RhbmNlIGZvdW5kIGluIHRo ZSBwcm9maWxlIGRlZmluZWQgaW4gUkZDNzA4NC4gVGhvc2UgbWVjaGFuaXNtcyBhcmUgZGVwbG95 ZWQgaW4gdGhlIG1vYmlsZSBuZXR3b3Jrcy4NCg0KDQrCtyAgICAgICAgIEJlY2F1c2Ugd2UgYXJl IGF3YXJlIGFib3V0IHRoZSB2ZXJzaW9uaW5nIGlzc3VlcywgdGhpcyBkb2N1bWVudCBsaXN0cyB0 aGUgZmVhdHVyZXMgd2l0aG91dCByZWZlcnJpbmcgdGhlIDNHUFAgcmVsZWFzZS4gRmVhdHVyZXMg Y2FuIGJlIHN1cHBvcnRlZCB3aXRob3V0IGJlIOKAnGNvbXBsZXhpZmllZOKAnSB3aXRoIHRoZSBy ZWxlYXNlIGNvbnNpZGVyYXRpb25zLiBUaGlzIGlzIHdoeSB3ZSBpbmNsdWRlZCB0aGlzIHNlbnRl bmNlIGluIHRoZSBkcmFmdDoNCg0K4oCcVGhlIHJlY29tbWVuZGF0aW9ucyBkbyBub3QgaW5jbHVk ZSAzR1BQIHJlbGVhc2UgZGV0YWlscy4g4oCcDQoNCg0KDQrCtyAgICAgICAgIFRoZSBkb2N1bWVu dCBpcyBub3QgYSBzdGFuZGFyZC4gVGhlIGRvY3VtZW50IGNhbiBiZSBzZWVuIGFzIGEg4oCcaGVs cGVy4oCdLg0KDQoNCg0KwrcgICAgICAgICBBIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHZlbmRvcnMg YW5kIG9wZXJhdG9ycyBpcyBlbmNvdXJhZ2VkIGFzIHNvbWUgb2YgdGhlIGZ1bmN0aW9ucyBpbiB0 aGUgdGVybWluYWwgc2lkZSByZXF1aXJlIGZ1bmN0aW9ucyB0byBiZSBlbmFibGVkIGluIHRoZSBu ZXR3b3JrIGFuZCB2aWNlIHZlcnNhLiBUaGlzIGRvY3VtZW50IGFtYml0aW9ucyB0byBlYXNlIHRo YXQgY29sbGFib3JhdGlvbi4NCg0KDQpUaGFuayB5b3UuDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBN YXJrIFpaWiBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXVdDQpFbnZvecOp IDogbWVyY3JlZGkgMTEgZsOpdnJpZXIgMjAxNSAxMTowOA0Kw4AgOiBMb3JlbnpvIENvbGl0dGk7 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUt ZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdA0KT2JqZXQgOiBS ZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNh bGwNCg0KSSBhZ3JlZSB3aXRoIExvcmVuem8gYW5kIG90aGVycywgYW5kIHRoaXMgaGFzIG1hZGUg bWUgd29uZGVyIGFib3V0IHBlcmhhcHMgd2hhdCBtaWdodCBiZSBkaWZmZXJlbnQgcGhpbG9zb3Bo aWVzIGJldHdlZW4gZS5nLiB0aGUgSVRVIGFuZCB0aGUgSUVURiByZWdhcmRpbmcgaG93IHRvIGhh bmRsZSBkZXZpY2VzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgdmVyc2lvbnMgb3IgZmVhdHVyZSByZXZp c2lvbnMgb2YgcHJvdG9jb2xzLg0KDQpJbiB0aGUgSUVURiwgbWFqb3IgYW5kIHZlcnkgc2lnbmlm aWNhbnQgZGlmZmVyZW5jZXMgYXJlIGhhbmRsZWQgYnkgdXNpbmcgYSBkaWZmZXJlbnQgcHJvdG9j b2wgdmVyc2lvbiwgd2hlcmUgYXMgZm9yIGxlc3Mgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMsIG1h bmRhdG9yeSBhYnNvbHV0ZSBtaW5pbXVtcyBhbmQgc3VwcG9ydGVkIG9wdGlvbiBuZWdvdGlhdGlv biBpcyB1c2VkIHRvIGNvcGUgd2l0aCB0aG9zZSAgZGlmZmVyZW5jZXMuIFRoaXMgYWxsb3dzIGRp ZmZlcmVudCB2ZXJzaW9ucyBvciBmZWF0dXJlIHJldmlzaW9ucyBvZiBkaWZmZXJlbnQgcHJvdG9j b2xzIHRvIGNvLWV4aXN0IG9uIGEgSVB2NiBub2RlLCB0byB0aGUgcG9pbnQgd2hlcmUgYW4gaW5k aXZpZHVhbCBub2RlIG1heSBoYXZlIGEgdW5pcXVlIGNvbWJpbmF0aW9uIG9mIHByb3RvY29sIHZl cnNpb25zIGFuZCBwcm90b2NvbCBmZWF0dXJlIHJldmlzaW9ucyB0aGF0IG5vIG90aGVyIG5vZGUg aGFzLg0KDQpSZWFkaW5nIHRocm91Z2ggdGhpcyBkcmFmdCBhbmQgaGF2aW5nIGxvb2tlZCBhIGJp dCBhdCB0aGUgdGVsZXBob25lIHN0YW5kYXJkcyB3b3JsZCwgaXQgc2VlbXMgdGhlIHRyYWRpdGlv bmFsIHRlbGVwaG9ueSB3b3JsZCBoYXMgbW9yZSBvZiBhbiBhcHByb2FjaCBvZiAncHJvZmlsZXMn LCB3aGljaCBzcGVjaWZ5IGEgc25hcHNob3Qgb2YgZmVhdHVyZXMgYWNyb3NzIG1hbnkgcHJvdG9j b2xzIGF0IGEgcGFydGljdWxhciB0aW1lLiBUaGlzIGRyYWZ0IGlzIHN0YXRpbmcgdGhlbSBhcyBy ZWNvbW1lbmRhdGlvbnMsIHBlcmhhcHMgdG8gYmUgbW9yZSBpbiBsaW5lIHdpdGggdGhlIGxlc3Mg cHJlc2NyaXB0aXZlIGFwcHJvYWNoIG9mIHRoZSBJRVRGLiBJbiBlZmZlY3QsIEkgdGhpbmsgcHJv ZmlsZXMgYXJlIGxpa2UgaGF2aW5nIG1ham9yIHZlcnNpb24gbnVtYmVycywgYW5kIHRoZXJlZm9y ZSBtYW5kYXRvcnkgbWF4aW11bXMsIHdpdGggbm8gb3IgdmVyeSBsaXR0bGUgb3B0aW9uIG5lZ290 aWF0aW9uLg0KDQpUaGUgY29uY2VybiBJIGhhdmUgYWJvdXQgdGhpcyAncHJvZmlsZXMnIGFwcHJv YWNoIGlzIHRoYXQgSSB0aGluayBpdCBwcm9iYWJseSBzbG93cyBkb3duIGRlcGxveW1lbnQgb2Yg bmV3IGNhcGFiaWxpdGllcyBpbiB0aGUgcHJvdG9jb2xzIHRvIGEgZGV2aWNlLCBiZWNhdXNlIGRv aW5nIHNvIG5vdyBzdG9wcyBpdCBiZWluZyAiUHJvZmlsZSBYWVouQUJDIiBjb21wbGlhbnQuIFBl cmhhcHMgaXQgc3RvcHMgYSBwaG9uZSB2ZW5kb3IgZnJvbSBkZXBsb3lpbmcgbmV3IGNhcGFiaWxp dGllcyBiZWNhdXNlIHRoZXkgaGF2ZSB0byB3YWl0IHVudGlsIHRoZXJlIGlzIGEgcHJvZmlsZSB0 aGF0IGFsbG93cyBpdC4gUGVyaGFwcyB0aGV5IGNhbid0IGRlcGxveSBzb21lIG1vcmUgbGltaXRl ZCBuZXcgY2FwYWJpbGl0aWVzIGJlY2F1c2UgZG9pbmcgc28gd291bGQgY2F1c2UgdGhlbSB0byBo YXZlIHRvIHRyeSB0byBjb21wbHkgd2l0aCBhIGxhdGVyIGFuZCBuZXdlciBwcm9maWxlLCBhbmQg dGhhdCB0aGVuIGNyZWF0ZXMgYW4gb2JsaWdhdGlvbiB0byBzdXBwb3J0IGFsbCBvZiB0aGUgbmV3 ZXIgcHJvZmlsZSdzIGNhcGFiaWxpdGllcywgYW5kIHRoZSBwaG9uZSdzIGhhcmR3YXJlIGp1c3Qg Y2FuJ3Qgc3VwcG9ydCBhbGwgb2YgdGhlbS4NCg0KVGhlIG90aGVyIHRoaW5nIEkgd29uZGVyIGFi b3V0IGlzIHdoYXQgaXMgc28gc3BlY2lhbCBhYm91dCB0ZWxlcGhvbmVzIChhbnltb3JlKT8gVGhl eSdyZSBmdW5kYW1lbnRhbGx5IG5vdyBub3RoaW5nIG1vcmUgdGhhbiBwb3J0YWJsZSBwb3J0YWJs ZSBjb21wdXRlcnMgdGhhdCBqdXN0IGhhcHBlbiB0byBhbHNvIGJlIHVzZWQgdG8gbWFrZSBwaG9u ZSBjYWxscywgYXMgd2VsbCBhcyBydW5uaW5nIG1hbnkgb3RoZXIgdHlwZXMgb2YgYXBwbGljYXRp b25zLiBUaGVpciAzR1BQIGxpbmstbGF5ZXIgaW50ZXJmYWNlIGlzIHRoZSBvbmx5IHRoaW5nIHRo YXQgbWFrZXMgdGhlbSBzcGVjaWZpY2FsbHkgZGlmZmVyZW50IGZyb20gYW55IG90aGVyIHBvcnRh YmxlIGNvbXB1dGVyLCBhbmQgSSB0aGluayB0aGUgb25seSByZWFsIG5lZWQgdG8gbWFrZSBJUHY2 IHJ1biBvbiB0aGVtIHdvdWxkIGhhdmUgYmVlbiB0byBwcmVwYXJlIGFuZCB1cGRhdGUgYW55IDNH UFAgbGluayBjaGFyYWN0ZXJpc3RpYyBzcGVjaWZpYyBJUHY2IFJGQ3MsIHRoYXQgaW4gcGFydGlj dWxhciBkaWRuJ3QgaW52ZW50IG5ldyB3YXlzIG9mIGRvaW5nIHdoYXQgZXhpc3Rpbmcgbm9uLWxp bmsgc3BlY2lmaWMgSVB2NiBwcm90b2NvbHMgY291bGQgYWxyZWFkeSBkbyAoZS5nLiwgUENPcyBm b3IgRE5TIGluc3RlYWQgb2Ygb3JpZ2luYWxseSBqdXN0IHN0YXRlbGVzcy9zdGF0ZWZ1bCBESENQ djYgYW5kIG5vdyAoYWx0aG91Z2ggbW9zdGx5LCBpbiBteSBvcGluaW9uLCB1bmZvcnR1bmF0ZWx5 KSBSQXMpLg0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IGlmIHNtYXJ0cGhvbmUgdmVuZG9ycyBuZWVk IG9yIG5lZWRlZCBndWlkYW5jZSBvbiB3aGF0IHRoZXkgc2hvdWxkIGltcGxlbWVudCB0byBzdXBw b3J0IElQdjYsIHRoZXkgc2hvdWxkIGJlIG9yIHNob3VsZCBoYXZlIGJlZW4gcHJvdmlkZWQgd2l0 aCB0aGUgSVB2NiBOb2RlIFJlcXVpcmVtZW50cyBSRkMsIGFuZCBhbiBSRkMgdGhhdCBzcGVjaWZp ZXMgaG93IHRvIGJvb3RzdHJhcCBJUHY2IG92ZXIgYW4gM0dQUCBsaW5rIHRvIHRoZSBwb2ludCB3 aGVyZSB0aGUgbm9uLWxpbmsgdHlwZSBzcGVjaWZpYyBzdGFuZGFyZCBJUHY2IG1ldGhvZHMgY291 bGQgYmUgdXNlZCwgYXMgYWxsIG9mIHRoZSBvdGhlciBJUHY2IG92ZXIgRm9vLWxpbmsgUkZDcyBk by4gQXMgbWFqb3IgY29tcHV0ZXIgY29tcGFuaWVzIGFyZSBub3cgaW4gY2hhcmdlIG9mIHNtYXJ0 cGhvbmUgZGV2ZWxvcG1lbnQvYWR2YW5jZW1lbnQsIHRoYXQgaXMgcHJvYmFibHkgaW4gZWZmZWN0 IHdoYXQgaXMgbW9zdGx5IGhhcHBlbmluZyBhbnl3YXkuDQoNClJlZ2FyZHMsDQpNYXJrLg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTG9yZW56byBDb2xpdHRpIDxs b3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+DQpUbzogIjxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj4iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPj4NCkNjOiAiZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXY2 b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc+PjsgVjYgT3BzIExp c3QgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTZW50OiBXZWRuZXNk YXksIDExIEZlYnJ1YXJ5IDIwMTUsIDE5OjA5DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1p ZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwNCg0KDQpPbiBUdWUsIEZl YiAxMCwgMjAxNSBhdCAxMTozMSBQTSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KSW4gY2FzZSB5b3Ug bWlzc2VkIHRoZSBsYXRlc3QgdmVyc2lvbiAoc2VlIHRoZSBkaWZmOiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0x NSZ1cmwyPWRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE2KSwgd2UgYWRk cmVzc2VkIHRoZSBjaGFuZ2VzIFlPVSBhc2tlZCBmb3IgYW5kIGFsc28gdGhvc2UgZnJvbSBKYW1l cyBhbmQgQmFyYmFyYSAobWFueSB0aGFua3MgdG8gdGhlbSkuDQoNCldoYXQgYWRkaXRpb25hbCBj aGFuZ2VzIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBhZGRlZD8NCg0KSSBkb24ndCB0aGluayBtaW5v ciBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCB3b3VsZCBjYXVzZSBtZSB0byBzdXBwb3J0IGl0Lg0K DQpJIGhhdmUgZXhwcmVzc2VkIG15IGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgaW4gdGhl IHBhc3QuIEZvciBleGFtcGxlLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB0b28gYnJvYWQgKGlu IGZhY3QsIGhhcm1mdWxseSBicm9hZCk7IHBsYWNlcyB0b28gbXVjaCBmb2N1cyBvbiB3aGF0IGZl YXR1cmVzIHRvIHN1cHBvcnQgYW5kIG5vdCBlbm91Z2ggZm9jdXMgb24gd2h5OyByZWFkcyBsaWtl IGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGEgdGVjaG5pY2FsIGRvY3VtZW50LiBQcmV0dHkg bXVjaCB3aGF0IEkgc2FpZCBhbHJlYWR5IGF0IElFVEYgbGFzdCBjYWxsIC0gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnODE2NjMuaHRtbCAtIGFu ZCB3aGF0IEkgaGF2ZSBiZWVuIHNheWluZyBzaW5jZSB3ZSBzdGFydGVkIGRpc2N1c3NpbmcgdGhp cyBkb2N1bWVudC4NCg0KVGhlIGdvb2QgbmV3cyBmb3IgdGhpcyBkb2N1bWVudCBpcyB0aGF0IGl0 IGRvZXMgbm90IG5lZWQgbXkgc3VwcG9ydCB0byBhZHZhbmNlIC0gb25lIG9iamVjdGlvbiBpcyBu b3Qgc3VmZmljaWVudC4gSUlSQyB0aGUgY2hhaXJzL0FEcyBoYXZlIHN0YXRlZCB0aGF0IHRoZXkg d2FudCB0byBzZWUgImNsZWFyIGNvbnNlbnN1cyIgdG8gc3VwcG9ydCBpdCwgYW5kIGlmIEkgd2Vy ZSB0aGUgb25seSBvbmUgb2JqZWN0aW5nLCB0aGVuIEkgc3VwcG9zZSB0aGF0IHdvdWxkIGJlIGNs ZWFyIGNvbnNlbnN1cy4gQWZ0ZXIgYWxsLCBjbGVhciBjb25zZW5zdXMgZG9lcyBub3QgbWVhbiB1 bmFuaW1pdHkuDQoNCk15IG9ic2VydmF0aW9uIG9mIHRoaXMgdGhyZWFkLCBob3dldmVyLCBpcyB0 aGF0IGl0J3Mgbm90IGp1c3QgbWUgb2JqZWN0aW5nLiBNb3N0IGNsZWFybHksIEJyaWFuIHdyb3Rl IHRoYXQgdGhpcyByZWFkcyBsaWtlIGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGFuIElFVEYg ZG9jdW1lbnQuIEdlcnQgd3JvdGUgdGhhdCBoZSBkb2Vzbid0IHNlZSBhIG5lZWQgZm9yIHRoaXMg ZG9jdW1lbnQuIEphbWVzIHNhaWQgaGUgc2hhcmVzIG15IGdlbmVyYWwgb2JqZWN0aW9ucy4gQW5k IHNvIG9uLiBZb3UgY2FuJ3QgYWRkcmVzcyB0aGF0IHNvcnQgb2Ygb2JqZWN0aW9uIHdpdGggbWlu b3IgZWRpdHMuIEFuZCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgbG90cyBvZiBzdXBwb3J0IGZv ciB0aGlzIGRvY3VtZW50LCBlaXRoZXIuIEkgc2VlIG9uZSBzdGF0ZW1lbnQgb2Ygc3VwcG9ydCBm cm9tIHNvbWVvbmUgd2hvIGlzIG5vdCBhbiBhdXRob3IsIGFuZCB2ZXJ5IGxpdHRsZSBlbHNlIGZy b20gdGhlIHJlc3Qgb2YgdGhlIFdHLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQoNCg== --_000_787AE7BB302AE849A7480A190F8B933004909030OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0K CXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFu LlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTD qSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTAyNDU5ODA1NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTExODE3MjM2NDQgNTE2NzM0NzYyIDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1 Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTQz NTQ0MDY0NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTIyMTk3MTQ5NCA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2 Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgTWFy ayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgdmVyeSBt dWNoIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuIEkgZG8gc2hhcmUgc2V2ZXJhbCBvZiB5b3Vy IHBvaW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5JIHdvdWxkIGxpa2UgdG8gbWFrZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZG9jdW1lbnQgaXMgbm8gbW9yZSB0aGFuIGEgc3Vw ZXJzZXQgb2YgZXhpc3RpbmcgUkZDcyB0aGF0IGFyZSBkZWZpbmluZyDigJxwcm9maWxlc+KAnSB3 aXRob3V0IGNhbGxpbmcgdGhlbSBhcyBzdWNoLiDigJxJUHY2IG5vZGUgcmVxdWlyZW1lbnRz4oCd IG9yDQogUkZDNzA2NiBhcmUgcHJvZmlsZXMhIFRoaXMgaXMgbWVudGlvbmVkIGluIFNlY3Rpb24g MS4yOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7VGhpcyBwcm9maWxlIGlzIGEgc3VwZXJzZXQgb2YgdGhhdCBvZiB0aGUgSVB2NiBwcm9m aWxlIGZvciAzR1BQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ2VsbHVsYXIgSG9zdHMgWzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA2NiIg dGl0bGU9IiZxdW90O0lQdjYgZm9yIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVj dCAoM0dQUCkgQ2VsbHVsYXIgSG9zdHMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDY2 PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dLA0KIHdoaWNoIGlzIGlu IHR1cm4gYSBzdXBlcnNldCBvZiBJUHY2IE5vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBSZXF1 aXJlbWVudHMgWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjQzNCIgdGl0bGU9IiZxdW90O0lQdjYgTm9kZSBSZXF1aXJlbWVudHMmcXVvdDsi PjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM2NDM0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5dLiZuYnNwOw0KIEl0IHRhcmdldHMgY2VsbHVsYXIgbm9kZXMsIGluY2x1ZGlu ZyBHUFJTLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEVQQyAoRXZvbHZlZCBQYWNrZXQgQ29yZSkg YW5kIElFRUUgODAyLjExIG5ldHdvcmtzLCB0aGF0IHJlcXVpcmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBmZWF0dXJlcyB0byBlbnN1cmUgSVB2NCBzZXJ2aWNlIGRlbGl2ZXJ5IG92ZXIgYW4gSVB2 Ni1vbmx5IHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluIGFkZGl0aW9uIHRvIHRo ZSBiYXNlIElQdjYgc2VydmljZS4mbmJzcDsgTW9yZW92ZXIsIHRoaXMgcHJvZmlsZSBjb3ZlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjZWxsdWxhciBDUEVzIHRoYXQgYXJlIHVzZWQgaW4gdmFy aW91cyBkZXBsb3ltZW50cyB0byBvZmZlciBmaXhlZC08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBs aWtlIHNlcnZpY2VzLiZuYnNwOyBSZWNvbW1lbmRhdGlvbnMgaW5zcGlyZWQgZnJvbSByZWFsIGRl cGxveW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleHBlcmllbmNlcyAoZS5nLiwgcm9hbWlu ZykgYXJlIGluY2x1ZGVkIGluIHRoaXMgcHJvZmlsZS4mbmJzcDsgQWxzbywgdGhpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHByb2ZpbGUgc2tldGNoZXMgcmVjb21tZW5kYXRpb25zIGZvciB0aGUg c2FrZSBvZiBkZXRlcm1pbmlzdGljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmVoYXZpb3JzIG9m IGNlbGx1bGFyIGRldmljZXMgd2hlbiB0aGUgc2FtZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaXMgcmVjZWl2ZWQgb3ZlciBzZXZlcmFsIGNoYW5uZWxz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZSBhcmUgY29uZmxpY3RzIGJldHdl ZW4gUkZDNzA2NiBhbmQgUkZDNjQzNCAoSVB2NiBub2RlIHJlcXVpcmVtZW50cyk6IFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIHdoaWNoIG9uZSBzaG91bGQgd2luLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IEZvciBjb25mbGljdGluZyByZWNvbW1lbmRhdGlvbnMgaW4gWzwvc3Bhbj48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDY2IiB0aXRsZT0iJnF1b3Q7 SVB2NiBmb3IgVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKSBDZWxs dWxhciBIb3N0cyZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzcwNjY8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIj5dIGFuZCBbPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzY0MzQiIHRpdGxlPSImcXVvdDtJUHY2IE5vZGUgUmVxdWlyZW1lbnRzJnF1 b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjQzNDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t VVMiPl0gKGUuZy4sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsgTmVpZ2hib3IgRGlzY292ZXJ5IFByb3RvY29sKSwgdGhpcyBwcm9m aWxlIGFkaGVyZXMgdG8gWzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MDY2IiB0aXRsZT0iJnF1b3Q7SVB2NiBmb3IgVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVy c2hpcCBQcm9qZWN0ICgzR1BQKSBDZWxsdWxhciBIb3N0cyZxdW90OyI+PHNwYW4gbGFuZz0iRU4t VVMiPlJGQzcwNjY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj5dLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IEluZGVlZCwg dGhlIHN1cHBvcnQgb2YgTmVpZ2hib3IgRGlzY292ZXJ5IFByb3RvY29sIGlzIG1hbmRhdG9yeSBp bjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IDNHUFAgY2VsbHVsYXIgZW52aXJvbm1lbnQgYXMgaXQgaXMgdGhlIG9ubHkgd2F5IHRv IGNvbnZleSBJUHY2IHByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHRvd2FyZHMgdGhlIDNHUFAgY2VsbHVsYXIgZGV2aWNl LiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBNVFUgKE1heGltdW08bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBUcmFuc21pc3Npb24gVW5p dCkgY29tbXVuaWNhdGlvbiB2aWEgUm91dGVyIEFkdmVydGlzZW1lbnQgbXVzdCBiZTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHN1 cHBvcnRlZCBzaW5jZSBtYW55IDNHUFAgbmV0d29ya3MgZG8gbm90IGhhdmUgYSBzdGFuZGFyZCBN VFU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyA8L3NwYW4+c2V0dGluZy48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT eW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFjY2VzcyB0 byBtb2JpbGUgbmV0d29ya3Mgc2hvdWxkIGJlIGhhcm1vbml6ZWQgd2l0aCB0aGUgZml4ZWQgb25l OiB0aGlzIGlzIGZvciBpbnN0YW5jZSB0aGUgcmVhc29uIHdoeSB0aGlzIGRvY3VtZW50IGFkdm9j YXRlcyBmb3IgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBUaGlzIHByb2ZpbGUgdXNlcyBhIHN0cm9uZ2VyIGxh bmd1YWdlIGZvciB0aGUgc3VwcG9ydCBvZiBQcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBEZWxlZ2F0aW9uIGNvbXBhcmVk IHRvIFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA2NiIg dGl0bGU9IiZxdW90O0lQdjYgZm9yIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVj dCAoM0dQUCkgQ2VsbHVsYXIgSG9zdHMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDY2 PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XS4mbmJzcDsgVGhlIG1haW4gbW90aXZhdGlv biBpcyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsgY2VsbHVsYXIgbmV0d29ya3MgYXJlIG1vcmUgYW5kIG1vcmUgcGVyY2Vp dmVkIGFzIGFuIGFsdGVybmF0aXZlIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZml4ZWQgbmV0d29ya3MgZm9yIGhvbWUgSVAt YmFzZWQgc2VydmljZXMgZGVsaXZlcnk7IGVzcGVjaWFsbHkgd2l0aDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHRoZSBhZHZlbnQg b2Ygc21hcnRwaG9uZXMgYW5kIDNHUFAgZGF0YSBkb25nbGVzLiZuYnNwOyBUaGVyZSBpcyBhIG5l ZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4g Jm5ic3A7Jm5ic3A7YW4gZWZmaWNpZW50IG1lY2hhbmlzbSB0byBhc3NpZ24gc2hvcnRlciBwcmVm aXggdGhhbiAvNjQgdG8gY2VsbHVsYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBob3N0cyBzbyB0aGF0IGVhY2ggTEFOIHNlZ21l bnQgY2FuIGdldCBpdHMgb3duIC82NCBwcmVmaXggYW5kIG11bHRpLTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGxpbmsgc3VibmV0 IGlzc3VlcyB0byBiZSBhdm9pZGVkLiZuYnNwOyBUaGUgc3VwcG9ydCBvZiB0aGlzIGZ1bmN0aW9u YWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyBpbiBib3RoIGNlbGx1bGFyIGFuZCBmaXhlZCBuZXR3b3JrcyBpcyBrZXkgZm9y IGZpeGVkLW1vYmlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5jb252ZXJnZW5jZS48bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlRoZXJlIGFyZSAoc3RpbGwpIHNvbWUgc3BlY2lmaWNpdGllcyBmb3IgbW9iaWxlIGRl dmljZXM6IFBEUCBjcmVhdGlvbiwgcm9hbWluZyBhc3BlY3RzLCBldGMuIEhhdmluZyBhIOKAnHN0 YW5kYXJk4oCdIHdoeSB0byBhZGRyZXNzIHRob3NlIGlzc3VlIGlzIGtleS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SVB2NCBjb250aW51aXR5IG1l Y2hhbmlzbXMgZGVmaW5lZCBmb3IgZml4ZWQgZGV2aWNlcyBkb2VzIG5vdCBhcHBseSBmb3IgdGhl IG1vYmlsZSBuZXR3b3JrOiB0aGUgY291bnRlcnBhcnQgb2YgdGhpcyBwcm9maWxlIGZvciB0aGUg Zml4ZWQgY2FzZSBjYW4NCiBiZSBmb3IgaW5zdGFuY2UgZm91bmQgaW4gdGhlIHByb2ZpbGUgZGVm aW5lZCBpbiBSRkM3MDg0LiBUaG9zZSBtZWNoYW5pc21zIGFyZSBkZXBsb3llZCBpbiB0aGUgbW9i aWxlIG5ldHdvcmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkJlY2F1c2Ugd2UgYXJlIGF3YXJlIGFib3V0IHRoZSB2ZXJzaW9uaW5n IGlzc3VlcywgdGhpcyBkb2N1bWVudCBsaXN0cyB0aGUgZmVhdHVyZXMgd2l0aG91dCByZWZlcnJp bmcgdGhlIDNHUFAgcmVsZWFzZS4gRmVhdHVyZXMgY2FuIGJlIHN1cHBvcnRlZA0KIHdpdGhvdXQg YmUg4oCcY29tcGxleGlmaWVk4oCdIHdpdGggdGhlIHJlbGVhc2UgY29uc2lkZXJhdGlvbnMuIFRo aXMgaXMgd2h5IHdlIGluY2x1ZGVkIHRoaXMgc2VudGVuY2UgaW4gdGhlIGRyYWZ0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPuKAnFRoZSByZWNvbW1lbmRhdGlvbnMgZG8gbm90IGluY2x1ZGUgM0dQUCByZWxl YXNlIGRldGFpbHMuIOKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg ZG9jdW1lbnQgaXMgbm90IGEgc3RhbmRhcmQuIFRoZSBkb2N1bWVudCBjYW4gYmUgc2VlbiBhcyBh IOKAnGhlbHBlcuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QSBjb29yZGluYXRpb24gYmV0d2VlbiB2ZW5kb3JzIGFu ZCBvcGVyYXRvcnMgaXMgZW5jb3VyYWdlZCBhcyBzb21lIG9mIHRoZSBmdW5jdGlvbnMgaW4gdGhl IHRlcm1pbmFsIHNpZGUgcmVxdWlyZSBmdW5jdGlvbnMgdG8gYmUgZW5hYmxlZCBpbiB0aGUgbmV0 d29yayBhbmQgdmljZSB2ZXJzYS4gVGhpcyBkb2N1bWVudCBhbWJpdGlvbnMgdG8gZWFzZSB0aGF0 IGNvbGxhYm9yYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFyayBaWlogU21pdGggW21haWx0 bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+ IG1lcmNyZWRpIDExIGbDqXZyaWVyIDIwMTUgMTE6MDg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IExv cmVuem8gQ29saXR0aTsgQk9VQ0FEQUlSIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+TW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBkcmFmdC1pZXRmLXY2b3Bz LW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IFY2IE9wcyBMaXN0PGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjM2MzA5NzU0MTJfODQ3NjAiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SSBhZ3JlZSB3aXRoIExvcmVuem8gYW5kIG90aGVycywgYW5kIHRoaXMgaGFzIG1hZGUg bWUgd29uZGVyIGFib3V0IHBlcmhhcHMgd2hhdCBtaWdodCBiZSBkaWZmZXJlbnQgcGhpbG9zb3Bo aWVzIGJldHdlZW4gZS5nLiB0aGUgSVRVIGFuZCB0aGUgSUVURiByZWdhcmRpbmcNCiBob3cgdG8g aGFuZGxlIGRldmljZXMgdGhhdCBoYXZlIGRpZmZlcmVudCB2ZXJzaW9ucyBvciBmZWF0dXJlIHJl dmlzaW9ucyBvZiBwcm90b2NvbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBf MV8xNDIzNjMwOTc1NDEyXzg0NzYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkluIHRoZSBJRVRGLCBtYWpv ciBhbmQgdmVyeSBzaWduaWZpY2FudCBkaWZmZXJlbmNlcyBhcmUgaGFuZGxlZCBieSB1c2luZyBh IGRpZmZlcmVudCBwcm90b2NvbCB2ZXJzaW9uLCB3aGVyZSBhcyBmb3IgbGVzcyBzaWduaWZpY2Fu dCBkaWZmZXJlbmNlcywgbWFuZGF0b3J5DQogYWJzb2x1dGUgbWluaW11bXMgYW5kIHN1cHBvcnRl ZCBvcHRpb24gbmVnb3RpYXRpb24gaXMgdXNlZCB0byBjb3BlIHdpdGggdGhvc2UgJm5ic3A7ZGlm ZmVyZW5jZXMuIFRoaXMgYWxsb3dzIGRpZmZlcmVudCB2ZXJzaW9ucyBvciBmZWF0dXJlIHJldmlz aW9ucyBvZiBkaWZmZXJlbnQgcHJvdG9jb2xzIHRvIGNvLWV4aXN0IG9uIGEgSVB2NiBub2RlLCB0 byB0aGUgcG9pbnQgd2hlcmUgYW4gaW5kaXZpZHVhbCBub2RlIG1heSBoYXZlIGEgdW5pcXVlIGNv bWJpbmF0aW9uDQogb2YgcHJvdG9jb2wgdmVyc2lvbnMgYW5kIHByb3RvY29sIGZlYXR1cmUgcmV2 aXNpb25zIHRoYXQgbm8gb3RoZXIgbm9kZSBoYXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1 aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg0NzYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlYWRpbmcg dGhyb3VnaCB0aGlzIGRyYWZ0IGFuZCBoYXZpbmcgbG9va2VkIGEgYml0IGF0IHRoZSB0ZWxlcGhv bmUgc3RhbmRhcmRzIHdvcmxkLCBpdCBzZWVtcyB0aGUgdHJhZGl0aW9uYWwgdGVsZXBob255IHdv cmxkIGhhcyBtb3JlIG9mIGFuIGFwcHJvYWNoDQogb2YgJ3Byb2ZpbGVzJywgd2hpY2ggc3BlY2lm eSBhIHNuYXBzaG90IG9mIGZlYXR1cmVzIGFjcm9zcyBtYW55IHByb3RvY29scyBhdCBhIHBhcnRp Y3VsYXIgdGltZS4gVGhpcyBkcmFmdCBpcyBzdGF0aW5nIHRoZW0gYXMgcmVjb21tZW5kYXRpb25z LCBwZXJoYXBzIHRvIGJlIG1vcmUgaW4gbGluZSB3aXRoIHRoZSBsZXNzIHByZXNjcmlwdGl2ZSBh cHByb2FjaCBvZiB0aGUgSUVURi4gSW4gZWZmZWN0LCBJIHRoaW5rIHByb2ZpbGVzIGFyZSBsaWtl DQogaGF2aW5nIG1ham9yIHZlcnNpb24gbnVtYmVycywgYW5kIHRoZXJlZm9yZSBtYW5kYXRvcnkg bWF4aW11bXMsIHdpdGggbm8gb3IgdmVyeSBsaXR0bGUgb3B0aW9uIG5lZ290aWF0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjM2MzA5 NzU0MTJfODQ3NjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGUgY29uY2VybiBJIGhhdmUgYWJvdXQgdGhpcyAncHJvZmlsZXMnIGFw cHJvYWNoIGlzIHRoYXQgSSB0aGluayBpdCBwcm9iYWJseSBzbG93cyBkb3duIGRlcGxveW1lbnQg b2YgbmV3IGNhcGFiaWxpdGllcyBpbiB0aGUgcHJvdG9jb2xzIHRvIGEgZGV2aWNlLA0KIGJlY2F1 c2UgZG9pbmcgc28gbm93IHN0b3BzIGl0IGJlaW5nICZxdW90O1Byb2ZpbGUgWFlaLkFCQyZxdW90 OyBjb21wbGlhbnQuIFBlcmhhcHMgaXQgc3RvcHMgYSBwaG9uZSB2ZW5kb3IgZnJvbSBkZXBsb3lp bmcgbmV3IGNhcGFiaWxpdGllcyBiZWNhdXNlIHRoZXkgaGF2ZSB0byB3YWl0IHVudGlsIHRoZXJl IGlzIGEgcHJvZmlsZSB0aGF0IGFsbG93cyBpdC4gUGVyaGFwcyB0aGV5IGNhbid0IGRlcGxveSBz b21lIG1vcmUgbGltaXRlZCBuZXcgY2FwYWJpbGl0aWVzDQogYmVjYXVzZSBkb2luZyBzbyB3b3Vs ZCBjYXVzZSB0aGVtIHRvIGhhdmUgdG8gdHJ5IHRvIGNvbXBseSB3aXRoIGEgbGF0ZXIgYW5kIG5l d2VyIHByb2ZpbGUsIGFuZCB0aGF0IHRoZW4gY3JlYXRlcyBhbiBvYmxpZ2F0aW9uIHRvIHN1cHBv cnQgYWxsIG9mIHRoZSBuZXdlciBwcm9maWxlJ3MgY2FwYWJpbGl0aWVzLCBhbmQgdGhlIHBob25l J3MgaGFyZHdhcmUganVzdCBjYW4ndCBzdXBwb3J0IGFsbCBvZiB0aGVtLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjM2MzA5NzU0MTJfODQ3 NjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5UaGUgb3RoZXIgdGhpbmcgSSB3b25kZXIgYWJvdXQgaXMgd2hhdCBpcyBzbyBzcGVjaWFs IGFib3V0IHRlbGVwaG9uZXMgKGFueW1vcmUpPyBUaGV5J3JlIGZ1bmRhbWVudGFsbHkgbm93IG5v dGhpbmcgbW9yZSB0aGFuIHBvcnRhYmxlIHBvcnRhYmxlIGNvbXB1dGVycw0KIHRoYXQganVzdCBo YXBwZW4gdG8gYWxzbyBiZSB1c2VkIHRvIG1ha2UgcGhvbmUgY2FsbHMsIGFzIHdlbGwgYXMgcnVu bmluZyBtYW55IG90aGVyIHR5cGVzIG9mIGFwcGxpY2F0aW9ucy4gVGhlaXIgM0dQUCBsaW5rLWxh eWVyIGludGVyZmFjZSBpcyB0aGUgb25seSB0aGluZyB0aGF0IG1ha2VzIHRoZW0gc3BlY2lmaWNh bGx5IGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBwb3J0YWJsZSBjb21wdXRlciwgYW5kIEkgdGhp bmsgdGhlIG9ubHkgcmVhbA0KIG5lZWQgdG8gbWFrZSBJUHY2IHJ1biBvbiB0aGVtIHdvdWxkIGhh dmUgYmVlbiB0byBwcmVwYXJlIGFuZCB1cGRhdGUgYW55IDNHUFAgbGluayBjaGFyYWN0ZXJpc3Rp YyBzcGVjaWZpYyBJUHY2IFJGQ3MsIHRoYXQgaW4gcGFydGljdWxhciBkaWRuJ3QgaW52ZW50IG5l dyB3YXlzIG9mIGRvaW5nIHdoYXQgZXhpc3Rpbmcgbm9uLWxpbmsgc3BlY2lmaWMgSVB2NiBwcm90 b2NvbHMgY291bGQgYWxyZWFkeSBkbyAoZS5nLiwgUENPcyBmb3IgRE5TIGluc3RlYWQNCiBvZiBv cmlnaW5hbGx5IGp1c3Qgc3RhdGVsZXNzL3N0YXRlZnVsIERIQ1B2NiBhbmQgbm93IChhbHRob3Vn aCBtb3N0bHksIGluIG15IG9waW5pb24sIHVuZm9ydHVuYXRlbHkpIFJBcykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84 NDc2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg0NzYwIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkl0IHNlZW1zIHRvIG1lIHRoYXQgaWYgc21hcnRwaG9uZSB2ZW5kb3JzIG5lZWQgb3Ig bmVlZGVkIGd1aWRhbmNlIG9uIHdoYXQgdGhleSBzaG91bGQgaW1wbGVtZW50IHRvIHN1cHBvcnQg SVB2NiwgdGhleSBzaG91bGQgYmUgb3Igc2hvdWxkIGhhdmUgYmVlbg0KIHByb3ZpZGVkIHdpdGgg dGhlIElQdjYgTm9kZSBSZXF1aXJlbWVudHMgUkZDLCBhbmQgYW4gUkZDIHRoYXQgc3BlY2lmaWVz IGhvdyB0byBib290c3RyYXAgSVB2NiBvdmVyIGFuIDNHUFAgbGluayB0byB0aGUgcG9pbnQgd2hl cmUgdGhlIG5vbi1saW5rIHR5cGUgc3BlY2lmaWMgc3RhbmRhcmQgSVB2NiBtZXRob2RzIGNvdWxk IGJlIHVzZWQsIGFzIGFsbCBvZiB0aGUgb3RoZXIgSVB2NiBvdmVyIEZvby1saW5rIFJGQ3MgZG8u IEFzIG1ham9yIGNvbXB1dGVyDQogY29tcGFuaWVzIGFyZSBub3cgaW4gY2hhcmdlIG9mIHNtYXJ0 cGhvbmUgZGV2ZWxvcG1lbnQvYWR2YW5jZW1lbnQsIHRoYXQgaXMgcHJvYmFibHkgaW4gZWZmZWN0 IHdoYXQgaXMgbW9zdGx5IGhhcHBlbmluZyBhbnl3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Inl1aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg0NzYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFf MTQyMzYzMDk3NTQxMl84NDc2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NYXJrLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjM2MzA5NzU0MTJfODQ3NjYiPg0KPGRpdiBp ZD0ieXVpXzNfMTZfMF8xXzE0MjM2MzA5NzU0MTJfODQ3NjUiPg0KPGRpdiBpZD0ieXVpXzNfMTZf MF8xXzE0MjM2MzA5NzU0MTJfODQ3NjQiPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3Jlbnpv QGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86PC9iPiAm cXVvdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnIj5k cmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OzsNCiBWNiBPcHMgTGlzdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDExIEZlYnJ1YXJ5IDIwMTUsIDE5OjA5PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlIGxhc3QgY2FsbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1 aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg1NjY3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXY3MjM3MzE2 Nzc3Ij4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg1NjY2Ij4NCjxkaXYg aWQ9Inl1aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEyXzg1NjY1Ij4NCjxkaXYgaWQ9Inl1aV8zXzE2 XzBfMV8xNDIzNjMwOTc1NDEyXzg1NjY0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5aXY3MjM3MzE2Nzc3eXF0ZmQwMzY5OSI+DQo8ZGl2IGlkPSJ5 dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NTY2MyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+T24gVHVlLCBGZWIgMTAsIDIwMTUgYXQgMTE6MzEgUE0sICZsdDs8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NTY2 MSI+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NTY2MCI+DQo8ZGl2IGlk PSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NTY1OSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkluIGNhc2Ug eW91IG1pc3NlZCB0aGUgbGF0ZXN0IHZlcnNpb24gKHNlZSB0aGUgZGlmZjoNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJv ZmlsZS0xNSZhbXA7dXJsMj1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0x NiIgdGFyZ2V0PSJfYmxhbmsiIGlkPSJ5dWlfM18xNl8wXzFfMTQyMzYzMDk3NTQxMl84NTY4NiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtdjZv cHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE1JmFtcDt1cmwyPWRyYWZ0LWlldGYtdjZvcHMtbW9i aWxlLWRldmljZS1wcm9maWxlLTE2PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiksDQogd2UgYWRkcmVzc2VkIHRoZSBjaGFuZ2VzIFlPVSBhc2tlZCBmb3IgYW5kIGFsc28g dGhvc2UgZnJvbSBKYW1lcyBhbmQgQmFyYmFyYSAobWFueSB0aGFua3MgdG8gdGhlbSkuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIzNjMwOTc1NDEy Xzg1NjY4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgYWRkaXRpb25hbCBjaGFuZ2Vz IHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBhZGRlZD88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+SSBkb24ndCB0aGluayBtaW5vciBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCB3 b3VsZCBjYXVzZSBtZSB0byBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SSBoYXZlIGV4cHJlc3NlZCBteSBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGluIHRo ZSBwYXN0LiBGb3IgZXhhbXBsZSwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgdG9vIGJyb2FkIChp biBmYWN0LCBoYXJtZnVsbHkgYnJvYWQpOw0KIHBsYWNlcyB0b28gbXVjaCBmb2N1cyBvbiB3aGF0 IGZlYXR1cmVzIHRvIHN1cHBvcnQgYW5kIG5vdCBlbm91Z2ggZm9jdXMgb24gd2h5OyByZWFkcyBs aWtlIGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGEgdGVjaG5pY2FsIGRvY3VtZW50LiBQcmV0 dHkgbXVjaCB3aGF0IEkgc2FpZCBhbHJlYWR5IGF0IElFVEYgbGFzdCBjYWxsIC0NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWV0Zi9jdXJyZW50L21zZzgx NjYzLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvaWV0Zi9jdXJyZW50L21zZzgxNjYzLmh0bWw8L2E+IC0gYW5kIHdoYXQgSSBoYXZl IGJlZW4gc2F5aW5nIHNpbmNlIHdlIHN0YXJ0ZWQgZGlzY3Vzc2luZyB0aGlzIGRvY3VtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGdvb2QgbmV3cyBmb3IgdGhpcyBkb2N1 bWVudCBpcyB0aGF0IGl0IGRvZXMgbm90IG5lZWQgbXkgc3VwcG9ydCB0byBhZHZhbmNlIC0gb25l IG9iamVjdGlvbiBpcyBub3Qgc3VmZmljaWVudC4gSUlSQyB0aGUgY2hhaXJzL0FEcw0KIGhhdmUg c3RhdGVkIHRoYXQgdGhleSB3YW50IHRvIHNlZSAmcXVvdDtjbGVhciBjb25zZW5zdXMmcXVvdDsg dG8gc3VwcG9ydCBpdCwgYW5kIGlmIEkgd2VyZSB0aGUgb25seSBvbmUgb2JqZWN0aW5nLCB0aGVu IEkgc3VwcG9zZSB0aGF0IHdvdWxkIGJlIGNsZWFyIGNvbnNlbnN1cy4gQWZ0ZXIgYWxsLCBjbGVh ciBjb25zZW5zdXMgZG9lcyBub3QgbWVhbiB1bmFuaW1pdHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5NeSBvYnNlcnZhdGlvbiBvZiB0aGlzIHRocmVhZCwgaG93ZXZlciwgaXMgdGhh dCBpdCdzIG5vdCBqdXN0IG1lIG9iamVjdGluZy4gTW9zdCBjbGVhcmx5LCBCcmlhbiB3cm90ZSB0 aGF0IHRoaXMgcmVhZHMgbGlrZSBhIHByb2N1cmVtZW50DQogc3BlYyBhbmQgbm90IGFuIElFVEYg ZG9jdW1lbnQuIEdlcnQgd3JvdGUgdGhhdCBoZSBkb2Vzbid0IHNlZSBhIG5lZWQgZm9yIHRoaXMg ZG9jdW1lbnQuIEphbWVzIHNhaWQgaGUgc2hhcmVzIG15IGdlbmVyYWwgb2JqZWN0aW9ucy4gQW5k IHNvIG9uLiBZb3UgY2FuJ3QgYWRkcmVzcyB0aGF0IHNvcnQgb2Ygb2JqZWN0aW9uIHdpdGggbWlu b3IgZWRpdHMuIEFuZCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgbG90cyBvZiBzdXBwb3J0IGZv ciB0aGlzDQogZG9jdW1lbnQsIGVpdGhlci4gSSBzZWUgb25lIHN0YXRlbWVudCBvZiBzdXBwb3J0 IGZyb20gc29tZW9uZSB3aG8gaXMgbm90IGFuIGF1dGhvciwgYW5kIHZlcnkgbGl0dGxlIGVsc2Ug ZnJvbSB0aGUgcmVzdCBvZiB0aGUgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBp ZD0ieXF0ZmQ1ODY3MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933004909030OPEXCLILM23corp_-- From nobody Wed Feb 11 02:51:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820641A87F2 for ; Wed, 11 Feb 2015 02:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUeNkfROUgOT for ; Wed, 11 Feb 2015 02:51:48 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956F71A87E7 for ; Wed, 11 Feb 2015 02:51:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1BApbaR016136 for ; Wed, 11 Feb 2015 11:51:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 20C80202CA7 for ; Wed, 11 Feb 2015 11:52:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 192312007F6 for ; Wed, 11 Feb 2015 11:52:30 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1BApYCI014482 for ; Wed, 11 Feb 2015 11:51:37 +0100 Message-ID: <54DB3436.1040801@gmail.com> Date: Wed, 11 Feb 2015 11:51:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:51:50 -0000 Le 11/02/2015 11:08, Mark ZZZ Smith a écrit : [...] > The other thing I wonder about is what is so special about > telephones (anymore)? In principle yes - a smartphone is now as open as an IBM PC on a desk. The end-user independently makes any software that s/he wants to run, provided enough skill is present. > They're fundamentally now nothing more than portable portable > computers that just happen to also be used to make phone calls, as > well as running many other types of applications. Their 3GPP > link-layer interface is the only thing that makes them specifically > different from any other portable computer, and I think the only > real need to make IPv6 run on them would have been to prepare and > update any 3GPP link characteristic specific IPv6 RFCs, This draft is more than just making IPv6 work on it. IPv6 already works on many cell links and there are a couple IPv6-over-cellular RFCs present. This draft makes some new requirements about additional matters of this "IPv6" to work on these links. These requirements are not so clear in the older IPv6-over-cellular RFCs, although they are assumed true by much protocol design happening in IETF. They're just not stated anywhere. And, regardless of these new requirements being clear in this draft, there are still unknowns happening on 3GPP links - they are are maybe left for future specifications (if ever the 3GPP links become open standards). > that in particular didn't invent new ways of doing what existing > non-link specific IPv6 protocols could already do (e.g., PCOs for DNS > instead of originally just stateless/stateful DHCPv6 and now > (although mostly, in my opinion, unfortunately) RAs). > > It seems to me that if smartphone vendors need or needed guidance on > what they should implement to support IPv6, they should be or should > have been provided with the IPv6 Node Requirements RFC, and an RFC > that specifies how to bootstrap IPv6 over an 3GPP link to the point > where the non-link type specific standard IPv6 methods could be > used, as all of the other IPv6 over Foo-link RFCs do. As major > computer companies are now in charge of smartphone > development/advancement, that is probably in effect what is mostly > happening anyway. Mark - there is a host of kinds of smartphone vendors: operators selling them, but also hw manufacturers and B2B resellers, integrators; their interests vary from pure IETF stds to pure 3GPP stds. Even if this draft is titled "mobile device profile", its reqs may well apply to a Machine which is not mobile at all (home automation) or provides mobility for others (trains). Or apply to LTE USB keys connecting specialized platforms, very different than smartphones. For me the important aspect, among its other contents, is that it puts DHCPv6 PD forward - I hope it will lead operators to support it. Alex > > Regards, Mark. > > ------------------------------------------------------------------------ > > > *From:* Lorenzo Colitti > *To:* "" > *Cc:* "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" > ; V6 Ops > List *Sent:* Wednesday, 11 February 2015, 19:09 > *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last > call > > > > On Tue, Feb 10, 2015 at 11:31 PM, > wrote: > > In case you missed the latest version (see the diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-profile-15&url2=draft-ietf-v6ops-mobile-device-profile-16), > > > we addressed the changes YOU asked for and also those from James and > Barbara (many thanks to them). __ __ What additional changes you > would like to see added? > > > I don't think minor changes to the document would cause me to > support it. > > I have expressed my concerns about this document in the past. For > example, I think the document is too broad (in fact, harmfully > broad); places too much focus on what features to support and not > enough focus on why; reads like a procurement spec and not a > technical document. Pretty much what I said already at IETF last > call - > https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - > and what I have been saying since we started discussing this > document. > > The good news for this document is that it does not need my support > to advance - one objection is not sufficient. IIRC the chairs/ADs > have stated that they want to see "clear consensus" to support it, > and if I were the only one objecting, then I suppose that would be > clear consensus. After all, clear consensus does not mean unanimity. > > My observation of this thread, however, is that it's not just me > objecting. Most clearly, Brian wrote that this reads like a > procurement spec and not an IETF document. Gert wrote that he > doesn't see a need for this document. James said he shares my > general objections. And so on. You can't address that sort of > objection with minor edits. And there doesn't seem to be lots of > support for this document, either. I see one statement of support > from someone who is not an author, and very little else from the rest > of the WG. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Feb 11 03:03:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4A1A87ED for ; Wed, 11 Feb 2015 03:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvjz0km7SqWD for ; Wed, 11 Feb 2015 03:03:09 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F031A87BB for ; Wed, 11 Feb 2015 03:03:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1BB30i4003389 for ; Wed, 11 Feb 2015 12:03:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6AB59203A33 for ; Wed, 11 Feb 2015 12:03:53 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 61AE22039F3 for ; Wed, 11 Feb 2015 12:03:53 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1BB2ak6030876 for ; Wed, 11 Feb 2015 12:03:00 +0100 Message-ID: <54DB36CC.90308@gmail.com> Date: Wed, 11 Feb 2015 12:02:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 11:03:13 -0000 Le 11/02/2015 10:43, Lorenzo Colitti a écrit : > On Wed, Feb 11, 2015 at 12:51 AM, > wrote: > > The document was adopted by the WG and passed both the WG and IETF > LCs with that scope. I naively assumed that this point is not > anymore an issue given that the draft passed major milestones > (several WGLCs, IETF LC) and the IETF consensus declared for it > means this is not an issue to advance the document. > > I think that assumption is incorrect, given Fred's explicit statement on > this thread, "Before I bother the IESG with it a third time, I’d really > like to hear a clear consensus, not a rough one." > > https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html LEt me try to understand - are we trying to identify consensus? Or can we still discuss the requirements per se? To me, the latter has its importance as well. For example: > C_REC#1: In order to allow each operator to select their own > strategy regarding IPv6 introduction, the cellular host > must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. > Both IPv6 and IPv4v6 PDP-Contexts must be supported. IPv4, > IPv6 or IPv4v6 PDP-Context request acceptance depends on > the cellular network configuration. I would like this requirement to state that _if_ the smartphone sold by that operator supports IPv4 PDP-context, IPv6 PDP-context and IPv4v6 PDP-context then the operator SHOULD support at least IPv4v6 PDP-context, and ideally the 3 for the same APN; in all cases, the operator SHOULD NOT support only IPv6 PDP-Context or only IPv4 PDP-Context per one APN. As surprising it might seem, some operators take an approach of supporting only IPv6 PDP-Context on one APN, and the other two on other two APNs, regardless of the end-user preference; they have their particular reasons which may not be technical. It is very stimulating in some sense (IPv6-only), or too daring for some customers which see their IPv6 flows interupted if switching to other APN. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Feb 11 04:09:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F194C1A00F3 for ; Wed, 11 Feb 2015 04:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsLPzPkC8cKG for ; Wed, 11 Feb 2015 04:09:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96BA1A0181 for ; Wed, 11 Feb 2015 04:09:45 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 26ACC2DC3FF; Wed, 11 Feb 2015 13:09:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 00BE24C07F; Wed, 11 Feb 2015 13:09:44 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 13:09:43 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QA== Date: Wed, 11 Feb 2015 12:09:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049091C2OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.95721 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:09:53 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049091C2OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpDYW4geW91IGV4cGxpY2l0IHdoYXQgZG8geW91IG1lYW50IGJ5IOKAnGhhcm1mdWxs eSBicm9hZOKAnT8NCihub3RlLCB0aGUgcG9pbnRlciB5b3UgcHJvdmlkZWQgaXMgbm90IHZhbGlk IGJlY2F1c2Ugc2V2ZXJhbCBpdGVtcyBoYXZlIGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBkcmFmdCBz aW5jZSB0aGVuLikNCg0KV2hpY2ggaXRlbXMgYXJlIG5vdCB0ZWNobmljYWxseSBqdXN0aWZpZWQ/ DQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbV0NCkVudm95w6kgOiBtZXJjcmVkaSAxMSBmw6l2cmllciAyMDE1IDA5OjEwDQrD gCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogSGVhdGxleSwgTmljazsgRnJlZCBC YWtlciAoZnJlZCk7IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLmFsbEB0 b29scy5pZXRmLm9yZzsgVjYgT3BzIExpc3QNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0 Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsDQoNCk9uIFR1ZSwgRmViIDEw LCAyMDE1IGF0IDExOjMxIFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSW4gY2FzZSB5b3UgbWlzc2Vk IHRoZSBsYXRlc3QgdmVyc2lvbiAoc2VlIHRoZSBkaWZmOiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMT1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNSZ1cmwy PWRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE2KSwgd2UgYWRkcmVzc2Vk IHRoZSBjaGFuZ2VzIFlPVSBhc2tlZCBmb3IgYW5kIGFsc28gdGhvc2UgZnJvbSBKYW1lcyBhbmQg QmFyYmFyYSAobWFueSB0aGFua3MgdG8gdGhlbSkuDQoNCldoYXQgYWRkaXRpb25hbCBjaGFuZ2Vz IHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBhZGRlZD8NCg0KSSBkb24ndCB0aGluayBtaW5vciBjaGFu Z2VzIHRvIHRoZSBkb2N1bWVudCB3b3VsZCBjYXVzZSBtZSB0byBzdXBwb3J0IGl0Lg0KDQpJIGhh dmUgZXhwcmVzc2VkIG15IGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgaW4gdGhlIHBhc3Qu IEZvciBleGFtcGxlLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB0b28gYnJvYWQgKGluIGZhY3Qs IGhhcm1mdWxseSBicm9hZCk7IHBsYWNlcyB0b28gbXVjaCBmb2N1cyBvbiB3aGF0IGZlYXR1cmVz IHRvIHN1cHBvcnQgYW5kIG5vdCBlbm91Z2ggZm9jdXMgb24gd2h5OyByZWFkcyBsaWtlIGEgcHJv Y3VyZW1lbnQgc3BlYyBhbmQgbm90IGEgdGVjaG5pY2FsIGRvY3VtZW50LiBQcmV0dHkgbXVjaCB3 aGF0IEkgc2FpZCBhbHJlYWR5IGF0IElFVEYgbGFzdCBjYWxsIC0gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnODE2NjMuaHRtbCAtIGFuZCB3aGF0 IEkgaGF2ZSBiZWVuIHNheWluZyBzaW5jZSB3ZSBzdGFydGVkIGRpc2N1c3NpbmcgdGhpcyBkb2N1 bWVudC4NCg0KVGhlIGdvb2QgbmV3cyBmb3IgdGhpcyBkb2N1bWVudCBpcyB0aGF0IGl0IGRvZXMg bm90IG5lZWQgbXkgc3VwcG9ydCB0byBhZHZhbmNlIC0gb25lIG9iamVjdGlvbiBpcyBub3Qgc3Vm ZmljaWVudC4gSUlSQyB0aGUgY2hhaXJzL0FEcyBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgd2FudCB0 byBzZWUgImNsZWFyIGNvbnNlbnN1cyIgdG8gc3VwcG9ydCBpdCwgYW5kIGlmIEkgd2VyZSB0aGUg b25seSBvbmUgb2JqZWN0aW5nLCB0aGVuIEkgc3VwcG9zZSB0aGF0IHdvdWxkIGJlIGNsZWFyIGNv bnNlbnN1cy4gQWZ0ZXIgYWxsLCBjbGVhciBjb25zZW5zdXMgZG9lcyBub3QgbWVhbiB1bmFuaW1p dHkuDQoNCk15IG9ic2VydmF0aW9uIG9mIHRoaXMgdGhyZWFkLCBob3dldmVyLCBpcyB0aGF0IGl0 J3Mgbm90IGp1c3QgbWUgb2JqZWN0aW5nLiBNb3N0IGNsZWFybHksIEJyaWFuIHdyb3RlIHRoYXQg dGhpcyByZWFkcyBsaWtlIGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGFuIElFVEYgZG9jdW1l bnQuIEdlcnQgd3JvdGUgdGhhdCBoZSBkb2Vzbid0IHNlZSBhIG5lZWQgZm9yIHRoaXMgZG9jdW1l bnQuIEphbWVzIHNhaWQgaGUgc2hhcmVzIG15IGdlbmVyYWwgb2JqZWN0aW9ucy4gQW5kIHNvIG9u LiBZb3UgY2FuJ3QgYWRkcmVzcyB0aGF0IHNvcnQgb2Ygb2JqZWN0aW9uIHdpdGggbWlub3IgZWRp dHMuIEFuZCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgbG90cyBvZiBzdXBwb3J0IGZvciB0aGlz IGRvY3VtZW50LCBlaXRoZXIuIEkgc2VlIG9uZSBzdGF0ZW1lbnQgb2Ygc3VwcG9ydCBmcm9tIHNv bWVvbmUgd2hvIGlzIG5vdCBhbiBhdXRob3IsIGFuZCB2ZXJ5IGxpdHRsZSBlbHNlIGZyb20gdGhl IHJlc3Qgb2YgdGhlIFdHLg0K --_000_787AE7BB302AE849A7480A190F8B9330049091C2OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5DYW4geW91IGV4cGxpY2l0IHdoYXQgZG8geW91IG1lYW50IGJ5IOKAnGhhcm1mdWxs eSBicm9hZOKAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPihub3RlLCB0aGUgcG9pbnRlciB5b3Ug cHJvdmlkZWQgaXMgbm90IHZhbGlkIGJlY2F1c2Ugc2V2ZXJhbCBpdGVtcyBoYXZlIGJlZW4gcmVt b3ZlZCBmcm9tIHRoZSBkcmFmdCBzaW5jZSB0aGVuLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2hpY2ggaXRlbXMgYXJlIG5vdCB0ZWNobmljYWxs eSBqdXN0aWZpZWQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxMSBmw6l2 cmllciAyMDE1IDA5OjEwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJ TVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBIZWF0bGV5LCBOaWNrOyBGcmVkIEJha2VyIChm cmVkKTsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRvb2xzLmll dGYub3JnOyBWNiBPcHMgTGlzdDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10g ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAx MCwgMjAxNSBhdCAxMTozMSBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JbiBjYXNlIHlvdSBtaXNzZWQgdGhl IGxhdGVzdCB2ZXJzaW9uIChzZWUgdGhlIGRpZmY6DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUtMTUmYW1wO3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUt MTYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDE9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTUmYW1wO3VybDI9 ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTY8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4pLA0KIHdlIGFkZHJlc3NlZCB0aGUgY2hhbmdlcyBZT1UgYXNrZWQg Zm9yIGFuZCBhbHNvIHRob3NlIGZyb20gSmFtZXMgYW5kIEJhcmJhcmEgKG1hbnkgdGhhbmtzIHRv IHRoZW0pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+V2hhdCBhZGRpdGlvbmFsIGNoYW5nZXMgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGFkZGVk Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIG1pbm9yIGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50 IHdvdWxkIGNhdXNlIG1lIHRvIHN1cHBvcnQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBleHByZXNzZWQgbXkgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCBpbiB0aGUgcGFzdC4gRm9yIGV4YW1wbGUsIEkgdGhpbmsgdGhl IGRvY3VtZW50IGlzIHRvbyBicm9hZCAoaW4gZmFjdCwgaGFybWZ1bGx5IGJyb2FkKTsgcGxhY2Vz IHRvbyBtdWNoIGZvY3VzIG9uIHdoYXQgZmVhdHVyZXMgdG8gc3VwcG9ydCBhbmQgbm90IGVub3Vn aCBmb2N1cyBvbiB3aHk7IHJlYWRzIGxpa2UgYSBwcm9jdXJlbWVudA0KIHNwZWMgYW5kIG5vdCBh IHRlY2huaWNhbCBkb2N1bWVudC4gUHJldHR5IG11Y2ggd2hhdCBJIHNhaWQgYWxyZWFkeSBhdCBJ RVRGIGxhc3QgY2FsbCAtDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2lldGYvY3VycmVudC9tc2c4MTY2My5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2c4MTY2My5odG1sPC9hPiAtIGFuZCB3aGF0 IEkgaGF2ZSBiZWVuIHNheWluZyBzaW5jZSB3ZSBzdGFydGVkIGRpc2N1c3NpbmcgdGhpcyBkb2N1 bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIGdvb2QgbmV3cyBmb3IgdGhpcyBkb2N1bWVudCBpcyB0aGF0IGl0IGRvZXMgbm90IG5l ZWQgbXkgc3VwcG9ydCB0byBhZHZhbmNlIC0gb25lIG9iamVjdGlvbiBpcyBub3Qgc3VmZmljaWVu dC4gSUlSQyB0aGUgY2hhaXJzL0FEcyBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgd2FudCB0byBzZWUg JnF1b3Q7Y2xlYXIgY29uc2Vuc3VzJnF1b3Q7IHRvIHN1cHBvcnQgaXQsIGFuZCBpZiBJIHdlcmUg dGhlIG9ubHkgb25lIG9iamVjdGluZywNCiB0aGVuIEkgc3VwcG9zZSB0aGF0IHdvdWxkIGJlIGNs ZWFyIGNvbnNlbnN1cy4gQWZ0ZXIgYWxsLCBjbGVhciBjb25zZW5zdXMgZG9lcyBub3QgbWVhbiB1 bmFuaW1pdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk15IG9ic2VydmF0aW9uIG9mIHRoaXMgdGhyZWFkLCBob3dldmVyLCBpcyB0aGF0IGl0 J3Mgbm90IGp1c3QgbWUgb2JqZWN0aW5nLiBNb3N0IGNsZWFybHksIEJyaWFuIHdyb3RlIHRoYXQg dGhpcyByZWFkcyBsaWtlIGEgcHJvY3VyZW1lbnQgc3BlYyBhbmQgbm90IGFuIElFVEYgZG9jdW1l bnQuIEdlcnQgd3JvdGUgdGhhdCBoZSBkb2Vzbid0IHNlZSBhIG5lZWQgZm9yIHRoaXMgZG9jdW1l bnQuIEphbWVzIHNhaWQNCiBoZSBzaGFyZXMgbXkgZ2VuZXJhbCBvYmplY3Rpb25zLiBBbmQgc28g b24uIFlvdSBjYW4ndCBhZGRyZXNzIHRoYXQgc29ydCBvZiBvYmplY3Rpb24gd2l0aCBtaW5vciBl ZGl0cy4gQW5kIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBsb3RzIG9mIHN1cHBvcnQgZm9yIHRo aXMgZG9jdW1lbnQsIGVpdGhlci4gSSBzZWUgb25lIHN0YXRlbWVudCBvZiBzdXBwb3J0IGZyb20g c29tZW9uZSB3aG8gaXMgbm90IGFuIGF1dGhvciwgYW5kIHZlcnkgbGl0dGxlDQogZWxzZSBmcm9t IHRoZSByZXN0IG9mIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B9330049091C2OPEXCLILM23corp_-- From nobody Wed Feb 11 04:47:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3591A888C for ; Wed, 11 Feb 2015 04:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctZYFkKwcwhV for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5A91A8881 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125; q=dns/txt; s=iport; t=1423658823; x=1424868423; h=date:from:message-id:to:subject:cc; bh=A5VVlA5BupNbaE6LYjd36XkygK0RYVuBcXYJ89y6vCA=; b=a7aQ4+il+ZwcsPAG4pnRJZE7pPfxiFzt3NR46lpv2ud5Cz5WrRzCDANX gGr2MLpqYOVBAVGOC1TWXI7V1xYxzt7bbsfLquee99xuJnemApxLpKesF eWqHfHOJbQcoYm+PQzdiNRl/qbLKf02A2EBWp4ULBZUVZ6px3ekXdKXNS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgJACVO21StJA2I/2dsb2JhbABbgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0VABAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="395574821" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl27m024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl1Nv003471; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1tp003442; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1tp003442@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-chen-v6ops-nfv-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:11 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6. Please take a look at it and comment. From nobody Wed Feb 11 04:47:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575891A8881 for ; Wed, 11 Feb 2015 04:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-AIttEDS7Zh for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3149E1A886A for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130; q=dns/txt; s=iport; t=1423658824; x=1424868424; h=date:from:message-id:to:subject:cc; bh=xUAyegG4uI6ZEyg7VgffJ4zBmtbWzABOXHCvSoe7Lvk=; b=A3ihCKfUsJKde4rO70DZuNbRb2cTTfhvY5hiTPBqeqydE37Q2PC750cg 6xbITYZRIt2PeiURMGte/nnbOgzkXz8mP2k7LtMmmsD4oKCdvCp2eeLN7 sayF0pQ6lKMiI2G3rinYVmkziJfBFL0Lj9oIbZdY+Bn+1atuTSEgz9lAo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQChTttU/49dJa1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0UYBAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122553075" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2GQ023434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl1Qu003479; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1ma003456; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1ma003456@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:14 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Wed Feb 11 04:47:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42561A886A for ; Wed, 11 Feb 2015 04:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1rqY3Pz0MM6 for ; Wed, 11 Feb 2015 04:47:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485671A8884 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1423658823; x=1424868423; h=date:from:message-id:to:subject:cc; bh=HgjdZK9MGBX/RE+oMsIFjBP4zR4IBvqoqAN4GkOHuNo=; b=dKuBXYY8+bJgJwVXWtpeOhqX6wzBMLPCIOPpL8hBoXaihADSnqkI1qE0 ALXaQTD0X0dMfYSAavhN05ZsQv0pQb4IfJOkMTXkRxyU5FSXEO04wnAz2 +bjIYAB+bjhVy2wxrFPT3N85LAVFFoI33mkY1vxvZQxAuZ23CGRtNPFgD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQABTttU/4MNJK1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0VABAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122486309" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 11 Feb 2015 12:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2DX007313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl178003515; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1Ek003460; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:17 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. From nobody Wed Feb 11 04:47:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144011A8884 for ; Wed, 11 Feb 2015 04:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn4XOInCogaR for ; Wed, 11 Feb 2015 04:47:13 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3E91A8886 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=138; q=dns/txt; s=iport; t=1423658824; x=1424868424; h=date:from:message-id:to:subject:cc; bh=vZpRNKMPFZiwfd937dZl6rKfv3SJrJ+c0ATHVFmUlEY=; b=fCc6MwYi/N4GhicDKNsmdX8jnx/bHgaGkjFMQQUIRS1vyMvHxaftxROF GOEQw2WV6wh1wR0UVz7TSXd4FkFCVYwVV2acwgwDOub8XzXXtC5hauDOE yitdJliGTPtHZlVCUwaRTSfmbWJo8tos11rI0GlJxlUfiX8oh5puLxP4m E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgJAOVN21StJA2J/2dsb2JhbABbgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0U8BAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="392103511" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2aq026022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl17x003483; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1nc003464; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1nc003464@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org Subject: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:19 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery. Please take a look at it and comment. From nobody Wed Feb 11 04:47:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC5E1A8884 for ; Wed, 11 Feb 2015 04:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9csGnly90J7 for ; Wed, 11 Feb 2015 04:47:17 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6521A8885 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130; q=dns/txt; s=iport; t=1423658824; x=1424868424; h=date:from:message-id:to:subject:cc; bh=5q7bCeHPipM6igSubjFFnmBC1Einc9LVMph9b/ckGZ0=; b=mctGY45eIF4v3wqwmktbGZxJ7LHcCTSbUghVGtd1uI/4SReng0aP3QZX tiV4mPcWuKGtbQvWDcuM9h/E2BELSsx+zwrYC5k8Fs/7o+gaYiPkB3FOj K4SmmoTKS/yp+cFQCZIxGshiJDeEnq90NG222Yg87SzwWqWJgzwqgAXc9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQBOTttU/4UNJK1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0VABAQEHAQEBAR6Pdx2DAIEUBYosiEiGdTaCTo5dIoQPgxEBAQE X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122559724" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2QA009190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl16A003474; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1OA003454; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1OA003454@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-siit-dc-2xlat@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-siit-dc-2xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:19 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat. Please take a look at it and comment. From nobody Wed Feb 11 04:47:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B551A8884 for ; Wed, 11 Feb 2015 04:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqlsXnbrDPu8 for ; Wed, 11 Feb 2015 04:47:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3671A8882 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142; q=dns/txt; s=iport; t=1423658824; x=1424868424; h=date:from:message-id:to:subject:cc; bh=autJoK6zlB/2Ncoobjd8j/lit3h+/6BInA0ywx0pH9E=; b=AXga6vT7jjhDETdw2bZVogX63CE9Xf44o89tdhhwiBa4itc1A9y33K/g TwuFLKwq90X/isae6Yk2SFuRAWD4M9rK3UQHyPaA7yMgBEknn589XfXhQ bim3WZdxyw81QG56Y1oNFdcIxyekVY5cNFDhSPbTEJDEGJ3bKawhpODp5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQChTttU/5FdJa1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0UYBAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122555489" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2Y6012170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl1sR003480; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1vO003446; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1vO003446@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:21 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. Please take a look at it and comment. From nobody Wed Feb 11 04:47:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B911A8892 for ; Wed, 11 Feb 2015 04:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f305tRzICWlH for ; Wed, 11 Feb 2015 04:47:19 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F6E1A8888 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=124; q=dns/txt; s=iport; t=1423658823; x=1424868423; h=date:from:message-id:to:subject:cc; bh=LBO1knLYG75lp6tmTXEm5TSmvyNKCQy9gfIe/4rvZdg=; b=I68Bip9CbwEEzOTHdTZ5Z48OgP+8NUWdso/4IfP2dvkzclFaeK2zt/aR lsPR4r5GdHMAb83tBW/4pLeLyG90eHVvXJFkUFbv4UOvHqmr1lXDsCIm6 9uPRyzJaA66j2FkRFhgLXwpeBre+2e3XvkG2tqCeC5pFFNiGX8muIgd3h A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQChTttU/4MNJK1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0UYBCwEfj3cdhBQFiiyISIZ1NoJOjl0ihA+DEQEBAQ X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122561301" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 11 Feb 2015 12:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl29I007312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl1Hl003505; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1Ka003452; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1Ka003452@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-siit-dc@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-siit-dc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:23 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc. Please take a look at it and comment. From nobody Wed Feb 11 04:47:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A461A88A6 for ; Wed, 11 Feb 2015 04:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F36oIzHYXPz for ; Wed, 11 Feb 2015 04:47:20 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8E01A8887 for ; Wed, 11 Feb 2015 04:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135; q=dns/txt; s=iport; t=1423658824; x=1424868424; h=date:from:message-id:to:subject:cc; bh=Spr5dnxpDPjso+XT+ei3hBDI4ijvvsspkhyFCNCwOos=; b=ZKO7lF1+IrIcgqTshCb+mQeLb2fD5OOzv+RFkpmtYR0kzjGdT3nXQ5Z/ IJ6Jfp8g3ghJWc2xJLaAvm22RFgORQ7dzuPT03XegvmoU5F7U8JTSAiqa 1/rFIbuxiYtUayEfZX4AoECA9v+odm9N/WQPEiOQvcekqlDWAWTRVE7eQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCQBOTttU/4YNJK1bgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0VABAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="122559726" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 11 Feb 2015 12:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2mQ011991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl11p003477; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1WL003468; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1WL003468@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ybai-v6ops-ipv6-for-openstack@tools.ietf.org Subject: [v6ops] new draft: draft-ybai-v6ops-ipv6-for-openstack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:28 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ybai-v6ops-ipv6-for-openstack. Please take a look at it and comment. From nobody Wed Feb 11 04:47:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605391A8886 for ; Wed, 11 Feb 2015 04:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmLrv7orjIQ6 for ; Wed, 11 Feb 2015 04:47:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342FA1A889D for ; Wed, 11 Feb 2015 04:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1423658846; x=1424868446; h=date:from:message-id:to:subject:cc; bh=e4tJ7avB90fwfpaK6tHDNqllvikNeBs3WP8e2Uvdo4g=; b=GCkf0/52ApAzG+QkILZyMXeJuNTvrAqZH7Ui+saJMHxGKftf3+2yu9qr My0SkvLsTWsNCkzMROP2OSQH/yk/5UqYvnl2sh4Uf7jS1fzncOMc2sXne 6MHeZ2WLKAW7End+BnV/41dqv13519ZH5Z+qrCopEgnoIw0Rq/xqWrpIt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgJABdP21StJA2J/2dsb2JhbABbgwZSW7NYAY8shWgJgStDAQEBAQEBfIUMPDSJDQEN0UUBAQgCAR+Pdx2EFAWKLIhIhnU2gk6OXSKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="395236357" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 11 Feb 2015 12:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1BCl2sb026020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 12:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t1BCl1Xt003472; Wed, 11 Feb 2015 04:47:01 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t1BCl1Fu003450; Wed, 11 Feb 2015 04:47:01 -0800 Date: Wed, 11 Feb 2015 04:47:01 -0800 From: fred@cisco.com Message-Id: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:47:40 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment. From nobody Wed Feb 11 05:08:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896901A8886 for ; Wed, 11 Feb 2015 05:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUmmoKxdb8iP for ; Wed, 11 Feb 2015 05:07:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDC01A8880 for ; Wed, 11 Feb 2015 05:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=630; q=dns/txt; s=iport; t=1423660077; x=1424869677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eSXzX4pWISNtSjdzs1zgMPI9S6lqu+yrZLegvoDwVrY=; b=bpBEuJ8GWgKDrSLAWestsu/5kpaCbKd/0thC1QsZTc4LOujn/STFdmcz cCpik0Ei3EhFGycUP/j0Zjdg72dYAPzSs98Hj5ttVJKxvFbxApizsA/1i qJcKAYwej+5qj8arA9wh/igiWYt6mA7InTPZ/lv9PUBLuQZ8NggLd5Cv4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAMpT21StJV2U/2dsb2JhbABbgwZSWgTCeAqFcQKBKEMBAQEBAQF8hAwBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIiCUN0VgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0YxBwaDEIEUAQSPIoNShnU2gk6CSIwVIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="395240506" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 11 Feb 2015 13:07:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1BD7u1I019869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 13:07:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 07:07:56 -0600 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem Thread-Index: AQHQRfj2LTX60O5eCESXxbQSm9DBs5zraz0g Date: Wed, 11 Feb 2015 13:07:56 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891680166F@xmb-rcd-x06.cisco.com> References: <201502111247.t1BCl1ma003456@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1ma003456@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-v6ops-pmtud-ecmp-problem@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:07:59 -0000 I read this document and support the work of this document. Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, February 11, 2015 7:47 AM To: v6ops@ietf.org Cc: draft-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-pmtud-ecmp-problem A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-pmtu= d-ecmp-problem. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 11 05:30:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C47D1A88C5 for ; Wed, 11 Feb 2015 05:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDuzRKQXE2SX for ; Wed, 11 Feb 2015 05:30:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276DA1A88B3 for ; Wed, 11 Feb 2015 05:30:04 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 42BFF26455A; Wed, 11 Feb 2015 14:30:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1C4002380D5; Wed, 11 Feb 2015 14:30:02 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 14:30:02 +0100 From: To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs Thread-Index: AQHQRepeymjVZe85zUW29rq1hiHps5zrb8Eg Date: Wed, 11 Feb 2015 13:30:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490931C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB36CC.90308@gmail.com> In-Reply-To: <54DB36CC.90308@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.95721 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:30:07 -0000 Hi Alex, The draft includes this text:=20 Some of the features listed in this profile document require to activate dedicated functions at the network side. It is out of scope of this document to list these network-side functions. This I-D cannot mandate the behavior of the network side as it is up to the= taste of each operator. Saying that, if you believe there is a service/application brokenness risk = due to some kind of policy enforced at the network side with regards to the= management of PDP contexts and APNs, I see a value in adding a "note" to r= ecord it. Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petres= cu Envoy=E9=A0: mercredi 11 f=E9vrier 2015 12:03 =C0=A0: v6ops@ietf.org Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4= /v6 PDP-contexts and APNs Le 11/02/2015 10:43, Lorenzo Colitti a =E9crit : > On Wed, Feb 11, 2015 at 12:51 AM, > wrote: > > The document was adopted by the WG and passed both the WG and IETF > LCs with that scope. I naively assumed that this point is not > anymore an issue given that the draft passed major milestones > (several WGLCs, IETF LC) and the IETF consensus declared for it > means this is not an issue to advance the document. > > I think that assumption is incorrect, given Fred's explicit statement on > this thread, "Before I bother the IESG with it a third time, I'd really > like to hear a clear consensus, not a rough one." > > https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html LEt me try to understand - are we trying to identify consensus? Or can=20 we still discuss the requirements per se? To me, the latter has its importance as well. For example: > C_REC#1: In order to allow each operator to select their own > strategy regarding IPv6 introduction, the cellular host > must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. > Both IPv6 and IPv4v6 PDP-Contexts must be supported. IPv4, > IPv6 or IPv4v6 PDP-Context request acceptance depends on > the cellular network configuration. I would like this requirement to state that _if_ the smartphone sold by=20 that operator supports IPv4 PDP-context, IPv6 PDP-context and IPv4v6=20 PDP-context then the operator SHOULD support at least IPv4v6=20 PDP-context, and ideally the 3 for the same APN; in all cases, the=20 operator SHOULD NOT support only IPv6 PDP-Context or only IPv4=20 PDP-Context per one APN. As surprising it might seem, some operators take an approach of=20 supporting only IPv6 PDP-Context on one APN, and the other two on other=20 two APNs, regardless of the end-user preference; they have their=20 particular reasons which may not be technical. It is very stimulating=20 in some sense (IPv6-only), or too daring for some customers which see=20 their IPv6 flows interupted if switching to other APN. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 11 05:36:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF58B1A88B3 for ; Wed, 11 Feb 2015 05:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6IEJPayFmq6 for ; Wed, 11 Feb 2015 05:36:02 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151CB1A88E9 for ; Wed, 11 Feb 2015 05:36:00 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t1BDZuud093869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 13:35:57 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <54DB5ABA.7090703@foobar.org> Date: Wed, 11 Feb 2015 13:35:54 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:36:12 -0000 On 11/02/2015 12:47, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment. I agree with the sentiment of this document but as an observation, unrestricted longest-prefix-match lookup tends to be circumvented by vendors in order to provide increased forwarding table capacity. There's a curious practical example in the "Cisco Nexus 5000 Series Configuration Limits" document: Dynamic routes 16,384 (includes IPv4 and IPv6 routes) V6 LPM routes 128 entries It would be interesting to see why the difference between v4 and v6 lpm lookup entries is greater than 4x. Otherwise, I support this doc. Nick From nobody Wed Feb 11 06:15:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776301A0203 for ; Wed, 11 Feb 2015 06:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3KUoFiqM4Jx for ; Wed, 11 Feb 2015 06:15:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650AB1A01FA for ; Wed, 11 Feb 2015 06:15:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1BEFH90023419; Wed, 11 Feb 2015 15:15:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1A1D02068B6; Wed, 11 Feb 2015 15:16:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0E8602068B3; Wed, 11 Feb 2015 15:16:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1BEF47T029709; Wed, 11 Feb 2015 15:15:17 +0100 Message-ID: <54DB63E8.7020205@gmail.com> Date: Wed, 11 Feb 2015 15:15:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "v6ops@ietf.org" References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB36CC.90308@gmail.com> <787AE7BB302AE849A7480A190F8B93300490931C@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490931C@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 14:15:23 -0000 Le 11/02/2015 14:30, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > The draft includes this text: > > Some of the features listed in this profile document require to > activate dedicated functions at the network side. It is out of > scope of this document to list these network-side functions. > > This I-D cannot mandate the behavior of the network side as it is up > to the taste of each operator. > > Saying that, if you believe there is a service/application brokenness > risk due to some kind of policy enforced at the network side with > regards to the management of PDP contexts and APNs, I see a value in > adding a "note" to record it. Note: a smartphone changing its connection between an APN-v6 and an APN-v4 block-restarts the ongoing applications. This is a brokenness situation. Alex > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : mercredi 11 février 2015 12:03 À : v6ops@ietf.org Objet : > Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 > PDP-contexts and APNs > > Le 11/02/2015 10:43, Lorenzo Colitti a écrit : >> On Wed, Feb 11, 2015 at 12:51 AM, > > wrote: >> >> The document was adopted by the WG and passed both the WG and IETF >> LCs with that scope. I naively assumed that this point is not >> anymore an issue given that the draft passed major milestones >> (several WGLCs, IETF LC) and the IETF consensus declared for it >> means this is not an issue to advance the document. >> >> I think that assumption is incorrect, given Fred's explicit >> statement on this thread, "Before I bother the IESG with it a third >> time, I'd really like to hear a clear consensus, not a rough one." >> >> https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html > > LEt me try to understand - are we trying to identify consensus? Or > can we still discuss the requirements per se? > > To me, the latter has its importance as well. > > For example: >> C_REC#1: In order to allow each operator to select their own >> strategy regarding IPv6 introduction, the cellular host must >> support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. Both IPv6 and >> IPv4v6 PDP-Contexts must be supported. IPv4, IPv6 or IPv4v6 >> PDP-Context request acceptance depends on the cellular network >> configuration. > > I would like this requirement to state that _if_ the smartphone sold > by that operator supports IPv4 PDP-context, IPv6 PDP-context and > IPv4v6 PDP-context then the operator SHOULD support at least IPv4v6 > PDP-context, and ideally the 3 for the same APN; in all cases, the > operator SHOULD NOT support only IPv6 PDP-Context or only IPv4 > PDP-Context per one APN. > > As surprising it might seem, some operators take an approach of > supporting only IPv6 PDP-Context on one APN, and the other two on > other two APNs, regardless of the end-user preference; they have > their particular reasons which may not be technical. It is very > stimulating in some sense (IPv6-only), or too daring for some > customers which see their IPv6 flows interupted if switching to other > APN. > > Alex > >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Wed Feb 11 06:26:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844D41A01AE for ; Wed, 11 Feb 2015 06:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4XZDXkzBv3z for ; Wed, 11 Feb 2015 06:26:46 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7681A0250 for ; Wed, 11 Feb 2015 06:26:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 152FE871625; Wed, 11 Feb 2015 15:26:31 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB4ybZkln5Ww; Wed, 11 Feb 2015 15:26:31 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E0165870069; Wed, 11 Feb 2015 15:26:30 +0100 (CET) Message-ID: <54DB6695.70900@globis.net> Date: Wed, 11 Feb 2015 15:26:29 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: fred@cisco.com References: <201502111247.t1BCl1tp003442@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1tp003442@irp-lnx1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-chen-v6ops-nfv-ipv6@tools.ietf.org Subject: Re: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 14:26:48 -0000 fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6. Please take a look at it and comment. > > I have read this draft. I'm not convinced that it should be adopted by the WG at this time (if that was the question). -- Regards, RayH From nobody Wed Feb 11 06:31:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42C61A020B for ; Wed, 11 Feb 2015 06:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzMyuXgK_l2A for ; Wed, 11 Feb 2015 06:31:52 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82171A0203 for ; Wed, 11 Feb 2015 06:31:51 -0800 (PST) X-Envelope-To: Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t1BEVkQj094150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Feb 2015 14:31:46 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <54DB67D1.2080909@foobar.org> Date: Wed, 11 Feb 2015 14:31:45 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201502111247.t1BCl1tp003442@irp-lnx1.cisco.com> <54DB6695.70900@globis.net> In-Reply-To: <54DB6695.70900@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 14:31:55 -0000 On 11/02/2015 14:26, Ray Hunter wrote: > fred@cisco.com wrote: >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6. Please take a look >> at it and comment. > > I have read this draft. I'm not convinced that it should be adopted by the > WG at this time (if that was the question). i think Fred may have had a script hiccup. All these drafts were updated some months ago. Nick From nobody Wed Feb 11 06:45:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423761A8937 for ; Wed, 11 Feb 2015 06:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1KBF7ap6zEx for ; Wed, 11 Feb 2015 06:44:52 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAE1A8935 for ; Wed, 11 Feb 2015 06:44:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1F012871625; Wed, 11 Feb 2015 15:44:51 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uon8-264gF9n; Wed, 11 Feb 2015 15:44:51 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E1894870069; Wed, 11 Feb 2015 15:44:50 +0100 (CET) Message-ID: <54DB6AE1.4040504@globis.net> Date: Wed, 11 Feb 2015 15:44:49 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: v6ops@ietf.org References: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 14:44:59 -0000 fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. > > I have read this draft. I'm quite frankly surprised that anyone would still attempt to link a source IP address and a session cookie at the server end. Use of NAT pools on IPv4-only firewalls have created identical operational problems for years. Still, the mitigation advice is pretty sound: "don't do it" Perhaps the draft could be even more generic: don't assume that an IPv4/IPv6 address can be used as a invariant key in a one-to-one mapping to an application-layer session table, especially where there isn't guaranteed underlying transport-layer-persistence. This problem isn't happy eyeballs specific, nor HTTP specific. -- Regards, RayH From nobody Wed Feb 11 07:00:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7FA1A00A7 for ; Wed, 11 Feb 2015 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOZaGZN0ETiu for ; Wed, 11 Feb 2015 07:00:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201811A0066 for ; Wed, 11 Feb 2015 07:00:52 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 687DF264275; Wed, 11 Feb 2015 16:00:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 407392380E9; Wed, 11 Feb 2015 16:00:50 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 16:00:47 +0100 From: To: Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQP+Yf94KoZb5URc+rHGKXMO3E0JzgE6EAgAAFywCAC3sbgA== Date: Wed, 11 Feb 2015 15:00:46 +0000 Message-ID: <1dfc278f-9761-4198-b185-c33a87eca8e3@OPEXCLILH01.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <3309_1423037455_54D1D40F_3309_6880_2_5cf9a995-53cb-40ee-b1ce-4fd9ca52b55a@OPEXCLILH02.corporate.adroot.infra.ftgroup> <20150204083138.GB34798@Space.Net> In-Reply-To: <20150204083138.GB34798@Space.Net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 15:00:54 -0000 Gert, You can check slide 13 of this prez http://www.ipv6observatory.eu/wp-conten= t/uploads/2012/11/01-05-Christian-Jacquenet.pdf to see examples of IPv6 ser= vices offered by our group. I hope we can focus on technical aspects of the document rather than discus= sing specific business matters.=20 Thank you. Cheers, Med =20 -----Message d'origine----- De=A0: Gert Doering [mailto:gert@space.net]=20 Envoy=E9=A0: mercredi 4 f=E9vrier 2015 09:32 =C0=A0: BINET David IMT/OLN Cc=A0: Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN; draft-ietf-v6ops-mobil= e-device-profile.all@tools.ietf.org; V6 Ops List Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Hi, On Wed, Feb 04, 2015 at 08:10:54AM +0000, david.binet@orange.com wrote: > some people think that IPv6 deployment is done if 3% of the world populat= ion can benefit of some IPv6 connectivity.=20 I notice that those that actually do deploy IPv6 are not those that complai= n about non-deployment. So, how's Orange's IPv6 deployment coming on? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Feb 11 07:07:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A6D1A0377 for ; Wed, 11 Feb 2015 07:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQe_-tEWKFP1 for ; Wed, 11 Feb 2015 07:07:27 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7193B1A00A7 for ; Wed, 11 Feb 2015 07:07:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0279C871625; Wed, 11 Feb 2015 16:07:26 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CfHyDnAqQ7J; Wed, 11 Feb 2015 16:07:25 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id C8975871617; Wed, 11 Feb 2015 16:07:25 +0100 (CET) Message-ID: <54DB702B.1050409@globis.net> Date: Wed, 11 Feb 2015 16:07:23 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: v6ops@ietf.org References: <201502111247.t1BCl1vO003446@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1vO003446@irp-lnx1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 15:07:39 -0000 fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes. Please take a look at it and comment. > > I've read this draft. IMHO It should be blindingly obvious to anyone configuring up an IPv6 network, whether physical or virtual, that if you connect up multiple customers at L2, then they will be able to communicate with both unicast and multicast. "Works as designed." Now perhaps good-practice design-experience for IPv6 might need to be re-learned from IPv4 hosting, but I don't see anything earth-shaking in the problem description. Existing mitigation mechanisms could include: assigning a SVI/VLAN with a unique /64 per customer ± uRPF ± ACL's ± PBR, or L2 Private VLANs. All are already widely available from a vendor near you, both in real and virtual form. -- Regards, RayH From nobody Wed Feb 11 07:16:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3D1A01FA for ; Wed, 11 Feb 2015 07:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm9unAgwu0un for ; Wed, 11 Feb 2015 07:16:49 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7E01A038C for ; Wed, 11 Feb 2015 07:15:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 71AAD871625; Wed, 11 Feb 2015 16:15:58 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U+5AIDvR38N; Wed, 11 Feb 2015 16:15:58 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4AFC6871617; Wed, 11 Feb 2015 16:15:58 +0100 (CET) Message-ID: <54DB722C.9020303@globis.net> Date: Wed, 11 Feb 2015 16:15:56 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: v6ops@ietf.org References: <201502111247.t1BCl1WL003468@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1WL003468@irp-lnx1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ybai-v6ops-ipv6-for-openstack@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ybai-v6ops-ipv6-for-openstack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 15:16:51 -0000 fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-ybai-v6ops-ipv6-for-openstack. Please take a look at it and comment. > > I have read this draft. There seems to be a significant overlap between draft-ybai-v6ops-ipv6-for-openstack and existing WG drafts http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc + https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat. -- Regards, RayH From nobody Wed Feb 11 08:32:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C881A1A0B for ; Wed, 11 Feb 2015 08:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikw1bP4R25Jk for ; Wed, 11 Feb 2015 08:31:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB65D1A1A04 for ; Wed, 11 Feb 2015 08:31:53 -0800 (PST) Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB586.namprd04.prod.outlook.com (10.141.196.145) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 11 Feb 2015 16:31:52 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0081.018; Wed, 11 Feb 2015 16:31:52 +0000 From: "Metzler, Dan J" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie Thread-Index: AQHQRfkIV1AJCFSpgEGU5Tc0I0UCFpzrjvNg Date: Wed, 11 Feb 2015 16:31:51 +0000 Message-ID: References: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:0:e50:1001:9117:8526:3257:a27e] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB586; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB586; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(89122001)(106116001)(76576001)(2501002)(1720100001)(62966003)(77156002)(75432002)(230783001)(99286002)(90282001)(76176999)(54356999)(50986999)(19580405001)(19580395003)(2656002)(40100003)(87936001)(46102003)(88552001)(33656002)(77096005)(2900100001)(15975445007)(2950100001)(92566002)(86362001)(122556002)(102836002)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB586; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2015 16:31:51.5116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB586 Archived-At: Cc: "draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:31:57 -0000 A few comments on this " 5. Potential Mitgation" - Obviously, correct the spelling of Mitigation. - IMHO, I would remove the word "Potential". (See below) " 7. Security Considerations" - I would qualify the first phrase by rewording somewhat like as follows,= (or remove the phrase altogether): The association of the session cookie with the user-agent IP address has so= me security value as it can help prevent "session cookie stealing" in some = limited situations... - It should be understood that the desire to protect a cookie from cookie= stealing often implies that a potential attacker has already gained access= to the cookie, and is close enough in proximity to the transmission path(s= ), or endpoints, that any assumptions, about the attacker's address always = being different, are no longer valid assumptions; even without a man-in-the= -middle attack. NAT, mobile devices, and server hosted client apps are all= examples of situations where addresses can be shared and/or swapped betwee= n multiple users. I would think that exchange of random keys at the beginn= ing of session establishment, along with some type of validation algorithm,= is a much better way to address this type of security consideration than u= sing an address as the key. - Dan > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > Sent: Wednesday, February 11, 2015 6:47 AM=20 > To: v6ops@ietf.org > Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org > Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v= 6ops- > happy-eyeballs-cookie. Please take a look at it and comment. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 11 09:33:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7860C1A0AF7 for ; Wed, 11 Feb 2015 09:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVj8VECYQCpK for ; Wed, 11 Feb 2015 09:32:58 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEFA1A046D for ; Wed, 11 Feb 2015 09:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1244; q=dns/txt; s=iport; t=1423675979; x=1424885579; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gYH3xQCFsC6rFWkhFbw1TTGDs4esy5iuy2sYBxchG38=; b=Jzjm6gEVgGHBysAL5M2nSPQ4m9bPszSZg6c7yqjkmgNvmOSC0G7OzkjG W6a0j18LkU6yu9oZ+2ptU84OlynTbkQ7t9hinK2VIqjpHnp2FhxKiq9JB OpOpADdS3oNxJBjgCMfeR6cFEKmM6keiurnSE75sH8kpBpdzvH2Tonj+o M=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoFAOKR21StJA2M/2dsb2JhbABbgwaBLASCfcV2AoEoQwEBAQEBAXyEDAEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOiBcIu3qWegEBAQEBAQEBAQEBAQEBAQEBAQEBAReLDIRtB4JoLoEUBY8lgVeBLoYskn8ig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,559,1418083200"; d="asc'?scan'208";a="392181288" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2015 17:32:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1BHWlJd021615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Feb 2015 17:32:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 11:32:47 -0600 From: "Fred Baker (fred)" To: Nick Hilliard Thread-Topic: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 Thread-Index: AQHQRiC/MoTEq0cad0iao80UQ78kPA== Date: Wed, 11 Feb 2015 17:32:46 +0000 Message-ID: References: <201502111247.t1BCl1tp003442@irp-lnx1.cisco.com> <54DB6695.70900@globis.net> <54DB67D1.2080909@foobar.org> In-Reply-To: <54DB67D1.2080909@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_40160FAC-3632-4CF5-AC08-433E07CC1A7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:33:00 -0000 --Apple-Mail=_40160FAC-3632-4CF5-AC08-433E07CC1A7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 11, 2015, at 6:31 AM, Nick Hilliard wrote: >=20 > i think Fred may have had a script hiccup. I must have. I=E2=80=99m seeing a lot of things that don=E2=80=99t quite = make sense. Now I have to go ask silly questions about the script... --Apple-Mail=_40160FAC-3632-4CF5-AC08-433E07CC1A7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVNuSPZ9ieig10VPpAQJwmgf9FArNXqtzfl3Uk9Hz4wty+l85ZiqwLCMt Gjrx7MV61owcV5g9AqsjW39SyUHPyClainjJw1r6OdiP2fq1CHcpyguy/S2wVqOR VCD4NOT6S2qqAHtbmOdDoRLLudmYkEO/L0LMm0NS3yCbqAEWEHPlvbqrhYu0b4PO gbioqlH8sJHRIresdrr2weQ+JlxWTFM/kQ4N1ysIVIzcS0RWVrALsOd/8kmq6yPZ bX2eroZiaabGHT1Xixz/DczPuD4UAc6k5wtMirwn9u9ubjqiUUmDav2y238rE7fs NcPz1fQ8IKZgn2Qt8E6S+/pUEeNgEbV/DChrtO0rV3Go6RmlaBK4Ww== =OGry -----END PGP SIGNATURE----- --Apple-Mail=_40160FAC-3632-4CF5-AC08-433E07CC1A7D-- From nobody Wed Feb 11 09:51:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236DC1A1A79 for ; Wed, 11 Feb 2015 09:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9ifpcKcNp-J for ; Wed, 11 Feb 2015 09:51:28 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947231A1A0B for ; Wed, 11 Feb 2015 09:51:28 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id u20so19591479oif.11 for ; Wed, 11 Feb 2015 09:51:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IdWjOIQ1cPuQywRdKZ78oVka1bnJI3FYdFD5WOpqyLw=; b=lhDIf5Klg4/ACSRLhoWU+7ZzM6rRXRZ8oScoXerQHuGHkLxZ5JAgK8hS4g+O81mDlj JQNHXmp3GooSa0+kVO/XHIz5CX+ffR4hqdW2/K6ylhLveRQk50h3smXrFEauk6j0hTsz 1TxIE8zpDDpxsGZkSAJsvIbPoETBQwADofcOsWvMiZDQbSwquC0HEFTUWC8FfoKcnSW5 cQfKv9qE9MtBETRuw1B0UsS41YBaV/Rhu2V9VJ4zNvMT33Q9KDHC/4uWy57/ro52gb9e t1UIPROLPWfLg3degbxhPZUEbKwPkP/AIE92hlTRnOttAjfr9ODsnQn9T/AiZFFumoEu SA7g== X-Gm-Message-State: ALoCoQlTjXfosI2VdUUghKxb+fblWi1yjPGqwNpiLtUCuTpx7WJrB/0XOkcWd/cWoMFivD1UhXIh MIME-Version: 1.0 X-Received: by 10.60.176.34 with SMTP id cf2mr19853820oec.52.1423677087877; Wed, 11 Feb 2015 09:51:27 -0800 (PST) Received: by 10.76.150.2 with HTTP; Wed, 11 Feb 2015 09:51:27 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Wed, 11 Feb 2015 09:51:27 -0800 Message-ID: From: James Woodyatt To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=089e01182b88191e0f050ed3a72e Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:51:35 -0000 --089e01182b88191e0f050ed3a72e Content-Type: text/plain; charset=UTF-8 On Wed, Feb 11, 2015 at 4:09 AM, wrote: > > > Which items are not technically justified? > Others may have other items that bug them, and additional items may spring to my mind later if I put my mind to it, but I see no technical justification to recommend a simple firewall by default for tethered hosts according to RFC 6092. I consider that recommendation to be actively harmful. -- james woodyatt Nest Labs, Communications Engineering --089e01182b88191e0f050ed3a72e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 11, 2015 at 4:09 AM, <mohamed.boucadair@orange.com= > wrote:

=C2=A0

Which items are not technically= justified?


Others m= ay have other items that bug them, and additional items may spring to my mi= nd later if I put my mind to it, but I see no technical justification to re= commend a simple firewall by default for tethered hosts according to RFC 60= 92. I consider that recommendation to be actively harmful.


--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering
--089e01182b88191e0f050ed3a72e-- From nobody Wed Feb 11 10:00:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB38D1A1ABF for ; Wed, 11 Feb 2015 09:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.654 X-Spam-Level: X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFILE1=2.555, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7c5dtClnHP8 for ; Wed, 11 Feb 2015 09:59:55 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F961A1AC1 for ; Wed, 11 Feb 2015 09:59:47 -0800 (PST) Received: from DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) by DBXPR07MB207.eurprd07.prod.outlook.com (10.242.143.21) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 11 Feb 2015 17:54:41 +0000 Received: from pc6 (81.151.167.59) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 11 Feb 2015 17:54:40 +0000 Message-ID: <041b01d04623$939416e0$4001a8c0@gateway.2wire.net> From: t.petch To: Mark ZZZ Smith , Lorenzo Colitti , References: <436846349.3178070.1423649289900.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 11 Feb 2015 17:46:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0012.eurprd03.prod.outlook.com (25.160.39.150) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) Authentication-Results: yahoo.com.au; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB062; X-Forefront-PRVS: 0484063412 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(51444003)(66654002)(122386002)(14496001)(50226001)(50466002)(44736004)(86362001)(1456003)(40100003)(15975445007)(77096005)(81816999)(50986999)(81686999)(76176999)(62966003)(61296003)(42186005)(77156002)(116806002)(47776003)(87976001)(23676002)(92566002)(19580395003)(19580405001)(84392001)(62236002)(44716002)(66066001)(33646002)(2521001)(230783001)(46102003)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 17:54:40.4383 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB207; X-OriginatorOrg: btconnect.com Archived-At: Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org, V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:59:59 -0000 ----- Original Message ----- From: "Mark ZZZ Smith" Sent: Wednesday, February 11, 2015 10:08 AM I agree with Lorenzo and others, and this has made me wonder about perhaps what might be different philosophies between e.g. the ITU and the IETF regarding how to handle devices that have different versions or feature revisions of protocols. In the IETF, major and very significant differences are handled by using a different protocol version, where as for less significant differences, mandatory absolute minimums and supported option negotiation is used to cope with those differences. This allows different versions or feature revisions of different protocols to co-exist on a IPv6 node, to the point where an individual node may have a unique combination of protocol versions and protocol feature revisions that no other node has. Reading through this draft and having looked a bit at the telephone standards world, it seems the traditional telephony world has more of an approach of 'profiles', which specify a snapshot of features across many protocols at a particular time. This draft is stating them as recommendations, perhaps to be more in line with the less prescriptive approach of the IETF. In effect, I think profiles are like having major version numbers, and therefore mandatory maximums, with no or very little option negotiation. The concern I have about this 'profiles' approach is that I think it probably slows down deployment of new capabilities in the protocols to a device, because doing so now stops it being "Profile XYZ.ABC" compliant. Perhaps it stops a phone vendor from deploying new capabilities because they have to wait until there is a profile that allows it. Perhaps they can't deploy some more limited new capabilities because doing so would cause them to have to try to comply with a later and newer profile, and that then creates an obligation to support all of the newer profile's capabilities, and the phone's hardware just can't support all of them. I think that you make a good point but that there is another one alongside it, that ITU-T Recommendations, at least in aggregate, are much, much more complex than IETF RFC and so the idea of profiling them, to produce something that can be implemented and interwork, is desirable, if not necessary. IETF RFC are, for the most part, much simpler and do not require such an action. MPLS-TP, perhaps not surprisingly, has a strong flavour of ITU-T about it and does include profiles - it needed them. IPv6? Probably the most complex protocol, or family thereof, that the IETF has produced, which, for me, is why the take up is so poor (nonexistent around me, on a small offshore island:-). So the idea of a profile seems to be not just right, quite likely essential, to make IPv6 get deployed. Tom Petch The other thing I wonder about is what is so special about telephones (anymore)? They're fundamentally now nothing more than portable portable computers that just happen to also be used to make phone calls, as well as running many other types of applications. Their 3GPP link-layer interface is the only thing that makes them specifically different from any other portable computer, and I think the only real need to make IPv6 run on them would have been to prepare and update any 3GPP link characteristic specific IPv6 RFCs, that in particular didn't invent new ways of doing what existing non-link specific IPv6 protocols could already do (e.g., PCOs for DNS instead of originally just stateless/stateful DHCPv6 and now (although mostly, in my opinion, unfortunately) RAs). It seems to me that if smartphone vendors need or needed guidance on what they should implement to support IPv6, they should be or should have been provided with the IPv6 Node Requirements RFC, and an RFC that specifies how to bootstrap IPv6 over an 3GPP link to the point where the non-link type specific standard IPv6 methods could be used, as all of the other IPv6 over Foo-link RFCs do. As major computer companies are now in charge of smartphone development/advancement, that is probably in effect what is mostly happening anyway. Regards,Mark. From: Lorenzo Colitti Sent: Wednesday, 11 February 2015, 19:09 On Tue, Feb 10, 2015 at 11:31 PM, wrote: In case you missed the latest version (see the diff:http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-mobile-device-pro file-15&url2=draft-ietf-v6ops-mobile-device-profile-16), we addressed the changes YOU asked for and also those from James and Barbara (many thanks to them). What additional changes you would like to see added? I don't think minor changes to the document would cause me to support it. I have expressed my concerns about this document in the past. For example, I think the document is too broad (in fact, harmfully broad); places too much focus on what features to support and not enough focus on why; reads like a procurement spec and not a technical document. Pretty much what I said already at IETF last call - https://www.ietf.org/mail-archive/web/ietf/current/msg81663.html - and what I have been saying since we started discussing this document. The good news for this document is that it does not need my support to advance - one objection is not sufficient. IIRC the chairs/ADs have stated that they want to see "clear consensus" to support it, and if I were the only one objecting, then I suppose that would be clear consensus. After all, clear consensus does not mean unanimity. My observation of this thread, however, is that it's not just me objecting. Most clearly, Brian wrote that this reads like a procurement spec and not an IETF document. Gert wrote that he doesn't see a need for this document. James said he shares my general objections. And so on. You can't address that sort of objection with minor edits. And there doesn't seem to be lots of support for this document, either. I see one statement of support from someone who is not an author, and very little else from the rest of the WG. _______________________________________________ From nobody Wed Feb 11 14:41:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3952B1A00D8 for ; Wed, 11 Feb 2015 14:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW1fO2yWSaR3 for ; Wed, 11 Feb 2015 14:41:24 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083361A00A8 for ; Wed, 11 Feb 2015 14:41:23 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9C8522000C for ; Wed, 11 Feb 2015 17:41:22 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 11 Feb 2015 17:41:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type; s= smtpout; bh=NGcHVaVDDbY1Q+2OHj8Drndk7NI=; b=eXmjp/Bq5YNt2v22skYp RSCTiX39yZOoKv+9HTUeYV8ydj8PigWQbUqcEP3B4sZq46S18SNK0XYADU78ftYd 8mpSCGXW1gttubB7ev26ZPRwEakgPbD2PWyM3O1Bq39teyH3qyQrXxX2Unf968KZ Yn7G/DkF360joJ3RECPzhqM= X-Sasl-enc: i0RqzaJadtYIMSvXBA4sIMyKQW1w/RPi2m3ft3kuGRyu 1423694482 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 698826800CA; Wed, 11 Feb 2015 17:41:22 -0500 (EST) Message-ID: <54DBDA89.90605@network-heretics.com> Date: Wed, 11 Feb 2015 17:41:13 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020200070907030900020703" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:41:26 -0000 This is a multi-part message in MIME format. --------------020200070907030900020703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 02/11/2015 12:51 PM, James Woodyatt wrote: > On Wed, Feb 11, 2015 at 4:09 AM, > wrote: > > > Which items are not technically justified? > > > Others may have other items that bug them, and additional items may > spring to my mind later if I put my mind to it, but I see no technical > justification to recommend a simple firewall by default for tethered > hosts according to RFC 6092. I consider that recommendation to be > actively harmful. +1 --------------020200070907030900020703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 02/11/2015 12:51 PM, James Woodyatt wrote:
On Wed, Feb 11, 2015 at 4:09 AM, <mohamed.boucadair@orange.com> wrote:

 

Which items are not technically justified?


Others may have other items that bug them, and additional items may spring to my mind later if I put my mind to it, but I see no technical justification to recommend a simple firewall by default for tethered hosts according to RFC 6092. I consider that recommendation to be actively harmful.
+1

--------------020200070907030900020703-- From nobody Wed Feb 11 18:10:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C041A1A46 for ; Wed, 11 Feb 2015 18:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AQmXExSJq1l for ; Wed, 11 Feb 2015 18:10:38 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8A1A0166 for ; Wed, 11 Feb 2015 18:10:37 -0800 (PST) Received: from [127.0.0.1] (unknown [123.114.58.164]) by centos (Coremail) with SMTP id AQAAf3CbTwZpCtxUQtppAA--.1795S5; Thu, 12 Feb 2015 10:05:30 +0800 (CST) Message-ID: <54DC0B9D.20409@cernet.edu.cn> Date: Thu, 12 Feb 2015 10:10:37 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ray Hunter References: <201502111247.t1BCl1WL003468@irp-lnx1.cisco.com> <54DB722C.9020303@globis.net> In-Reply-To: <54DB722C.9020303@globis.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CbTwZpCtxUQtppAA--.1795S5 X-Coremail-Antispam: 1UD129KBjvJXoW7tFyrKFykKw1fJr4xtr1UWrg_yoW8JFWrpa 1qqanxGw1kJF1kJF4kWr1rWw1Y934aga4kAFnrJwn0vw43AF1qyr1qkrnFqrZFqrykWa1q qr45W3s5XrsxXaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU6C14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAF wI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082 IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCF04 k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1r MI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJV WUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWU JVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr UvcSsGvfC2KfnxnUUI43ZEXa7VU1QtxDUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: draft-ybai-v6ops-ipv6-for-openstack@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ybai-v6ops-ipv6-for-openstack X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:10:41 -0000 Hi, Ray, Thanks for your mail. Ray Hunter 写é“: > fred@cisco.com wrote: >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-ybai-v6ops-ipv6-for-openstack. >> Please take a look at it and comment. >> >> > I have read this draft. There seems to be a significant overlap > between draft-ybai-v6ops-ipv6-for-openstack and existing WG drafts > http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc + > https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat. Yes, these drafts are using stateless NAT64 translation (RFC6145) for providing IPv4 services for IPv6-only server. However, the differences are: (1) http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc is introducing Static Address Mapping rather then using RFC6052, while our draft is based on RFC6052. (2) Our draft discusses the OpenStack VMs IPv6 configuration using ND proxy, while http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc does not addresses the issues for VMs. (3) Our draft discuss the A+P/ALG model to share the public IPv4 addresses, which is very critical for the developing countries. (4) https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat discusses the dual translation, while our draft does not do so. Best regards, xing From nobody Wed Feb 11 19:08:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902271A1B9A for ; Wed, 11 Feb 2015 19:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DemN3T_-Cs_6 for ; Wed, 11 Feb 2015 19:08:36 -0800 (PST) Received: from nm35-vm0.bullet.mail.bf1.yahoo.com (nm35-vm0.bullet.mail.bf1.yahoo.com [72.30.238.72]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971A21A8A77 for ; Wed, 11 Feb 2015 19:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1423710494; bh=4SmykbXunNDP8LJLZQhAMuCI3ISQ/yx3KE//kCDqUVk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=jy8DP31nOosAEFxuML6oH8FxLhZYgm6CJ8wRx1tKFomvBtAQeCmeO3h8ShuIhKtxlKelu1NyFH/nEkNy+wa0C2htkQxMKsEk+jYAnXDPQi/O6siIcKMCoFCjxqtUZjupUqPTPFX55m8Xu40ivBhMZuBKsiv0VCEi3N8HAcv7eM9uFPvBgh5zU3EEk2yjYXuqq3Sjz8sh6XxsWBvJfzzW05d1DXd+FcKVRxFFU9pWE0H003kIazRN6ejYgG4mkgizcje2Gm/yqOWsXYy/7qu3rEXV8CtaR41aCkfji+N5vG23/NDngRIoI/gRjPnum/q6oIZfxcnu8oviohqM0kv8Og== Received: from [98.139.215.143] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2015 03:08:14 -0000 Received: from [98.139.212.195] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2015 03:08:14 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 12 Feb 2015 03:08:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 886671.38716.bm@omp1004.mail.bf1.yahoo.com X-YMail-OSG: N0DjEMgVM1ntgEw3pULJzspYwsHy9CTQ9wd_X7CxyflYtKicx8gJrLaWgFJ8J_Z ZnMjVF6rbDofFpnUynmYNncf2QVkr3EE2MGX1TaaN4fIFb8ROwzj0MsfMzK3lZH0Z5Pytha2DzJ0 TRcqcHOUpkxqm8bum3JBZXdoxluzdcNkepKBIYhGo22HEGa17nnfXm2RVf2AWZyMs9Bbw7iIypqF asAuo0ezu117zbMzBCqr0.QHMDVlqAXFF8pAdhHdLUrQCAvMI6nJIhwL84Lc1nE3CsmyHkIC0NQg PBhp.JGByRDxkXDUM9E3mzcDzwmsD0nyeNE.dUhE189h0M5LLp1cYaZB2QIEVP_poWGVpFGuGCDh hw3Zg.BP.H.sCZ04Xf9kTlkv6QqfJ1f3ZR9KfIq8Et8KsUor3Z1ycShVbI9yCET3ggY8FdeyWNTd 9dbhNTCcFXFkUMuBc3dJO1dcBktizzh2hKJmIonwptnGyoDEjV7jB8Y4d5ShA5dAG_zMiD48Z9Jd 9WYT7nwp6Y13B4rLWXO9S.tCVWLkA0FRSzF9syBQapZ5A0Ix_8A-- Received: by 66.196.81.105; Thu, 12 Feb 2015 03:08:14 +0000 Date: Thu, 12 Feb 2015 03:08:01 +0000 (UTC) From: Mark ZZZ Smith To: "fred@cisco.com" , "v6ops@ietf.org" Message-ID: <488920676.3641546.1423710481890.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> References: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 03:08:42 -0000 I think this is a good draft, and I agree with what it says, however I think perhaps it really belongs in the httpbis working group, as they're the HTTP experts? The only other thought I've had is that it might be worth documenting that MPTCP shouldn't suffer from this problem as if an application cares about IP addresses, then only the first subflow's IP addresses are exposed to the application, even if a later subflow uses a different address family. There may be a little confusion in this area as MPTCP and HE might appear to be fairly similar at face value (and I think HE techniques applied to initial MPTCP subflow setup might improve the MPTCP establishment performance.). Regards, Mark. ----- Original Message ----- From: "fred@cisco.com" To: v6ops@ietf.org Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Sent: Wednesday, 11 February 2015, 23:47 Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 11 22:39:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9970C1A9077 for ; Wed, 11 Feb 2015 22:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAAdEhn1z_YB for ; Wed, 11 Feb 2015 22:39:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0B21A9074 for ; Wed, 11 Feb 2015 22:39:39 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 3DA962DC25F; Thu, 12 Feb 2015 07:39:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 19EE927C0AF; Thu, 12 Feb 2015 07:39:37 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 07:39:37 +0100 From: To: James Woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQRiNlJyo/dj7ROEKfd3r0ZcS7TZzsjIhg Date: Thu, 12 Feb 2015 06:39:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004909864OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 06:39:42 -0000 --_000_787AE7BB302AE849A7480A190F8B933004909864OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGlzIHBvaW50IGFzIGl0IGhlbHBz IHRvIGNsYXJpZnkgYSBjb25mdXNpb24uDQoNClRoaXMgZG9jdW1lbnQgRE9FUyBOT1QgUkVDT01N RU5UIFJGQzYwOTIgZm9yIHRldGhlcmVkIGhvc3RzLg0KDQpJIGd1ZXNzIHlvdSBhcmUgcmVmZXJy aW5nIHRvIHRoaXMgaXRlbToNCg0KICAgTF9SRUMjMjogIFRoZSBjZWxsdWxhciBDUEUgbXVzdCBi ZSBjb21wbGlhbnQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgc3BlY2lmaWVk IGluIFtSRkM3MDg0PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwODQ+XS4NCg0KICAg ICAgICAgICAgICAgIFRoZXJlIGFyZSBzZXZlcmFsIGRlcGxveW1lbnRzLCBwYXJ0aWN1bGFybHkg aW4gZW1lcmdpbmcNCiAgICAgICAgICAgICAgICBjb3VudHJpZXMsIHRoYXQgcmVsaWVzIG9uIG1v YmlsZSBuZXR3b3JrcyB0byBwcm92aWRlDQogICAgICAgICAgICAgICAgYnJvYWRiYW5kIHNlcnZp Y2VzIChlLmcuLCBjdXN0b21lcnMgYXJlIHByb3ZpZGVkIHdpdGgNCiAgICAgICAgICAgICAgICBt b2JpbGUgQ1BFcykuDQoNCiAgICAgICAgICAgICAgICBOb3RlLCB0aGlzIHByb2ZpbGUgZG9lcyBu b3QgcmVxdWlyZSBJUHY0IHNlcnZpY2UNCiAgICAgICAgICAgICAgICBjb250aW51aXR5IHRlY2hu aXF1ZXMgbGlzdGVkIGluIFtSRkM3MDg0PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcw ODQ+XSBiZWNhdXNlIHRob3NlDQogICAgICAgICAgICAgICAgYXJlIHNwZWNpZmljIHRvIGZpeGVk IG5ldHdvcmtzLiAgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkNCiAgICAgICAgICAgICAgICB0ZWNo bmlxdWVzIHNwZWNpZmljIHRvIHRoZSBtb2JpbGUgbmV0d29ya3MgYXJlIGluY2x1ZGVkDQogICAg ICAgICAgICAgICAgaW4gdGhpcyBwcm9maWxlLg0KDQpUaGlzIGlzIGFib3V0IGNlbGx1bGFyICoq IENQRSAqKiBub3QgdGV0aGVyZWQgZGV2aWNlcyAoWW91IG1heSBub3RpY2VkIHRoYXQgdGhpcyBp dGVtIHVzZWQgZXhwbGljaXRseSDigJxjZWxsdWxhciBDUEXigJ0gd2hpbGUgb3RoZXIgaXRlbXMg aW4gdGhpcyBzZWN0aW9uIHVzZXMg4oCcY2VsbHVsYXIgZGV2aWNl4oCdKS4gUkZDNzA4NCBpcyBy ZXF1aXJlZCBmb3IgdGhpcyBjYXNlIHRvIGVuc3VyZSBhIGZ1bmN0aW9uYWwgcGFyaXR5IHdpdGgg Zml4ZWQgQ1BFcy4NCg0KQlRXLCB0aGUgdGV4dCB5b3Ugc3VnZ2VzdGVkIGFib3V0IFJGQzYwOTIg aXMgaW4gdGhlIGRyYWZ0Og0KDQoNCiAgIEluIHRoZSBjYXNlIG9mIGNlbGx1bGFyIGRldmljZXMg dGhhdCBwcm92aWRlIExBTiBmZWF0dXJlcywgY29tcGxpYW5jZQ0KDQogICB3aXRoIExfUkVDIzIg ZW50YWlscyBjb21wbGlhbmNlIHdpdGggW1JGQzcwODQ8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzA4ND5dLCB3aGljaCBpbiB0dXJuDQoNCiAgIHJlY29tbWVuZHMgY29tcGxpYW5jZSB3 aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmlsaXRpZXMNCg0KICAgaW4gQ3Vz dG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IChDUEUpIGZvciBQcm92aWRpbmcgUmVzaWRlbnRpYWwg SVB2Ng0KDQogICBJbnRlcm5ldCBTZXJ2aWNlIFtSRkM2MDkyPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzYwOTI+XS4gIFRoZXJlZm9yZSwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z DQoNCiAgIGluIFNlY3Rpb24gNiBvZiBbUkZDNjA5Ml08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjA5MiNzZWN0aW9uLTY+IGFyZSByZWxldmFudC4gIEluIHBhcnRpY3VsYXIsIGl0IGJl YXJzDQoNCiAgIHJlcGVhdGluZyBoZXJlIHRoYXQgdGhlIHRydWUgaW1wYWN0IG9mIHN0YXRlZnVs IGZpbHRlcmluZyBtYXkgYmUgYQ0KDQogICByZWR1Y3Rpb24gaW4gc2VjdXJpdHksIGFuZCB0aGF0 IElFVEYgbWFrZSBubyBzdGF0ZW1lbnQsIGV4cHJlc3NlZCBvcg0KDQogICBpbXBsaWVkLCBhcyB0 byB3aGV0aGVyIHVzaW5nIHRoZSBjYXBhYmlsaXRpZXMgZGVzY3JpYmVkIGluIGFueSBvZg0KDQog ICB0aGVzZSBkb2N1bWVudHMgdWx0aW1hdGVseSBpbXByb3ZlcyBzZWN1cml0eSBmb3IgYW55IGlu ZGl2aWR1YWwgdXNlcnMNCg0KICAgb3IgZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkgYXMgYSB3 aG9sZS4NCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBtb2JpbGUgQ1BFIHNob3VsZCBub3Qg aGF2ZSB0aGUgc2FtZSBmdW5jdGlvbmFsaXRpZXMgYXMgdGhlIGZpeGVkIG9uZSwgYW5kIHRoZXJl Zm9yZSBSRkM3MDg0IHNob3VsZCBub3QgYmUgY2l0ZWQgaW4gdGhpcyBJLUQ/IE9yIHlvdSBhcmUg c3VnZ2VzdGluZyB0aGF0IFJGQzcwODQgaXMgaGFybWZ1bD8NCg0KVGhhbmsgeW91Lg0KDQpDaGVl cnMsDQpNZWQNCg0KRGUgOiBKYW1lcyBXb29keWF0dCBbbWFpbHRvOmpod0BuZXN0bGFicy5jb21d DQpFbnZvecOpIDogbWVyY3JlZGkgMTEgZsOpdnJpZXIgMjAxNSAxODo1MQ0Kw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IElQdjYgT3BzIFdHDQpPYmpldCA6IFJlOiBbdjZvcHNd IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1m dWxseSBicm9hZCI/DQoNCk9uIFdlZCwgRmViIDExLCAyMDE1IGF0IDQ6MDkgQU0sIDxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Pj4gd3JvdGU6DQoNCldoaWNoIGl0ZW1zIGFyZSBub3QgdGVjaG5pY2FsbHkganVzdGlmaWVkPw0K DQpPdGhlcnMgbWF5IGhhdmUgb3RoZXIgaXRlbXMgdGhhdCBidWcgdGhlbSwgYW5kIGFkZGl0aW9u YWwgaXRlbXMgbWF5IHNwcmluZyB0byBteSBtaW5kIGxhdGVyIGlmIEkgcHV0IG15IG1pbmQgdG8g aXQsIGJ1dCBJIHNlZSBubyB0ZWNobmljYWwganVzdGlmaWNhdGlvbiB0byByZWNvbW1lbmQgYSBz aW1wbGUgZmlyZXdhbGwgYnkgZGVmYXVsdCBmb3IgdGV0aGVyZWQgaG9zdHMgYWNjb3JkaW5nIHRv IFJGQyA2MDkyLiBJIGNvbnNpZGVyIHRoYXQgcmVjb21tZW5kYXRpb24gdG8gYmUgYWN0aXZlbHkg aGFybWZ1bC4NCg0KDQotLQ0KamFtZXMgd29vZHlhdHQgPGpod0BuZXN0bGFicy5jb208bWFpbHRv Ompod0BuZXN0bGFicy5jb20+Pg0KTmVzdCBMYWJzLCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmlu Zw0K --_000_787AE7BB302AE849A7480A190F8B933004909864OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIEph bWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGFuayB5b3UgZm9yIHJhaXNpbmcgdGhpcyBwb2ludCBhcyBpdCBoZWxwcyB0byBjbGFyaWZ5IGEg Y29uZnVzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5UaGlzIGRvY3VtZW50IERPRVMgTk9UIFJFQ09NTUVOVCBSRkM2MDkyIGZvciB0ZXRoZXJl ZCBob3N0cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5JIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgaXRlbToNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTF9SRUMjMjombmJzcDsg VGhlIGNlbGx1bGFyIENQRSBtdXN0IGJlIGNvbXBsaWFudCB3aXRoIHRoZSByZXF1aXJlbWVudHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gWzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA4NCIgdGl0bGU9IiZxdW90 O0Jhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lciBFZGdlIFJvdXRlcnMmcXVvdDsi PjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDg0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgYXJlIHNldmVyYWwgZGVwbG95bWVudHMsIHBhcnRpY3Vs YXJseSBpbiBlbWVyZ2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvdW50cmllcywgdGhhdCByZWxpZXMgb24gbW9iaWxlIG5ldHdvcmtzIHRvIHByb3ZpZGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBicm9hZGJhbmQgc2Vy dmljZXMgKGUuZy4sIGN1c3RvbWVycyBhcmUgcHJvdmlkZWQgd2l0aDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vYmlsZSBDUEVzKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdGUsIHRoaXMg cHJvZmlsZSBkb2VzIG5vdCByZXF1aXJlIElQdjQgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRpbnVpdHkgdGVjaG5pcXVlcyBsaXN0ZWQgaW4g Wzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzA4NCIgdGl0bGU9IiZxdW90O0Jhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lciBF ZGdlIFJvdXRlcnMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDg0PC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogYmVjYXVzZSB0aG9zZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSBzcGVjaWZpYyB0byBmaXhlZCBu ZXR3b3Jrcy4mbmJzcDsgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0ZWNobmlxdWVzIHNwZWNpZmljIHRvIHRoZSBtb2Jp bGUgbmV0d29ya3MgYXJlIGluY2x1ZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW4gdGhpcyBwcm9maWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIGlzIGFib3V0IGNlbGx1bGFyICoqIENQRSAqKiBu b3QgdGV0aGVyZWQgZGV2aWNlcyAoWW91IG1heSBub3RpY2VkIHRoYXQgdGhpcyBpdGVtIHVzZWQg ZXhwbGljaXRseSDigJxjZWxsdWxhciBDUEXigJ0gd2hpbGUgb3RoZXIgaXRlbXMgaW4gdGhpcyBz ZWN0aW9uIHVzZXMNCiDigJxjZWxsdWxhciBkZXZpY2XigJ0pLiBSRkM3MDg0IGlzIHJlcXVpcmVk IGZvciB0aGlzIGNhc2UgdG8gZW5zdXJlIGEgZnVuY3Rpb25hbCBwYXJpdHkgd2l0aCBmaXhlZCBD UEVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5C VFcsIHRoZSB0ZXh0IHlvdSBzdWdnZXN0ZWQgYWJvdXQgUkZDNjA5MiBpcyBpbiB0aGUgZHJhZnQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgSW4gdGhlIGNhc2Ugb2YgY2VsbHVsYXIg ZGV2aWNlcyB0aGF0IHByb3ZpZGUgTEFOIGZlYXR1cmVzLCBjb21wbGlhbmNlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgd2l0aCBM X1JFQyMyIGVudGFpbHMgY29tcGxpYW5jZSB3aXRoIFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzA4NCIgdGl0bGU9IiZxdW90O0Jhc2ljIFJlcXVpcmVtZW50 cyBmb3IgSVB2NiBDdXN0b21lciBFZGdlIFJvdXRlcnMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SRkM3MDg0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XSwgd2hpY2ggaW4gdHVybjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IHJlY29tbWVuZHMgY29tcGxpYW5jZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0 eSBDYXBhYmlsaXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyBpbiBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1lbnQgKENQRSkg Zm9yIFByb3ZpZGluZyBSZXNpZGVudGlhbCBJUHY2PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgSW50ZXJuZXQgU2VydmljZSBbPC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwOTIiIHRpdGxlPSIm cXVvdDtSZWNvbW1lbmRlZCBTaW1wbGUgU2VjdXJpdHkgQ2FwYWJpbGl0aWVzIGluIEN1c3RvbWVy IFByZW1pc2VzIEVxdWlwbWVudCAoQ1BFKSBmb3IgUHJvdmlkaW5nIFJlc2lkZW50aWFsIElQdjYg SW50ZXJuZXQgU2VydmljZSZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzYwOTI8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj5dLiZuYnNwOyBUaGVyZWZvcmUsIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7ICZuYnNwO2luIDwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2MDkyI3NlY3Rpb24tNiI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24mbmJz cDs2IG9mIFtSRkM2MDkyXTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiBhcmUgcmVsZXZh bnQuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGl0IGJlYXJzPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgcmVwZWF0aW5nIGhlcmUgdGhh dCB0aGUgdHJ1ZSBpbXBhY3Qgb2Ygc3RhdGVmdWwgZmlsdGVyaW5nIG1heSBiZSBhPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgcmVk dWN0aW9uIGluIHNlY3VyaXR5LCBhbmQgdGhhdCBJRVRGIG1ha2Ugbm8gc3RhdGVtZW50LCBleHBy ZXNzZWQgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyBpbXBsaWVkLCBhcyB0byB3aGV0aGVyIHVzaW5nIHRoZSBjYXBhYmlsaXRp ZXMgZGVzY3JpYmVkIGluIGFueSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHRoZXNlIGRvY3VtZW50cyB1bHRpbWF0ZWx5IGlt cHJvdmVzIHNlY3VyaXR5IGZvciBhbnkgaW5kaXZpZHVhbCB1c2VyczxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IG9yIGZvciB0aGUg SW50ZXJuZXQgY29tbXVuaXR5IGFzIGEgd2hvbGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBtb2Jp bGUgQ1BFIHNob3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBmdW5jdGlvbmFsaXRpZXMgYXMgdGhlIGZp eGVkIG9uZSwgYW5kIHRoZXJlZm9yZSBSRkM3MDg0IHNob3VsZCBub3QgYmUgY2l0ZWQgaW4gdGhp cyBJLUQ/IE9yDQogeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgUkZDNzA4NCBpcyBoYXJtZnVsPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5 b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBKYW1lcyBXb29keWF0dCBbbWFpbHRvOmpod0BuZXN0bGFicy5jb21dDQo8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTEgZsOpdnJpZXIgMjAxNSAxODo1 MTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxi PkNjJm5ic3A7OjwvYj4gSVB2NiBPcHMgV0c8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBb djZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0g JnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTEsIDIwMTUgYXQgNDowOSBBTSwg Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2hpY2ggaXRlbXMg YXJlIG5vdCB0ZWNobmljYWxseSBqdXN0aWZpZWQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk90aGVycyBtYXkgaGF2 ZSBvdGhlciBpdGVtcyB0aGF0IGJ1ZyB0aGVtLCBhbmQgYWRkaXRpb25hbCBpdGVtcyBtYXkgc3By aW5nIHRvIG15IG1pbmQgbGF0ZXIgaWYgSSBwdXQgbXkgbWluZCB0byBpdCwgYnV0IEkgc2VlIG5v IHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uIHRvIHJlY29tbWVuZCBhIHNpbXBsZSBmaXJld2FsbCBi eSBkZWZhdWx0IGZvciB0ZXRoZXJlZCBob3N0cyBhY2NvcmRpbmcgdG8gUkZDIDYwOTIuDQogSSBj b25zaWRlciB0aGF0IHJlY29tbWVuZGF0aW9uIHRvIGJlIGFjdGl2ZWx5IGhhcm1mdWwuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5qYW1lcyB3b29k eWF0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20iIHRhcmdldD0iX2JsYW5r Ij5qaHdAbmVzdGxhYnMuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5OZXN0IExhYnMsIENvbW11bmljYXRpb25zIEVuZ2luZWVyaW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933004909864OPEXCLILM23corp_-- From nobody Thu Feb 12 01:36:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FFD1A1B5A for ; Thu, 12 Feb 2015 01:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y30MW6pvWW8H for ; Thu, 12 Feb 2015 01:36:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B321A0382 for ; Thu, 12 Feb 2015 01:36:06 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C320A2AC822; Thu, 12 Feb 2015 10:36:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9B39618008F; Thu, 12 Feb 2015 10:36:01 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 10:36:01 +0100 From: To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs Thread-Index: AQHQRgUtzAYjqu7Rk0WZRGPJq6Oxf5zswc7g Date: Thu, 12 Feb 2015 09:36:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004909AC1@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB36CC.90308@gmail.com> <787AE7BB302AE849A7480A190F8B93300490931C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB63E8.7020205@gmail.com> In-Reply-To: <54DB63E8.7020205@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.90918 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 09:36:09 -0000 Hi Alex, I think this note can be added to C_REC#6 not C_REC#1. I made this change i= n my local copy: OLD:=20 C_REC#6: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#2 discusses the default behavior for requesting PDP-Context type(s). This feature is useful to drive the behavior of the UE to be aligned with: (1) service-specific constraints such as the use of IPv6-only for VoLTE (Voice over LTE), (2) network conditions with regards to the support of specific PDP types (e.g., IPv4v6 PDP-Context is not supported), (3) IPv4 sunset objectives, (4) subscription data, etc. NEW: C_REC#6: The cellular host must be able to be configured to limit PDP type(s) for a given APN. The default mode is to allow all supported PDP types. Note, C_REC#2 discusses the default behavior for requesting PDP-Context type(s). This feature is useful to drive the behavior of the UE to be aligned with: (1) service-specific constraints such as the use of IPv6-only for VoLTE (Voice over LTE), (2) network conditions with regards to the support of specific PDP types (e.g., IPv4v6 PDP-Context is not supported), (3) IPv4 sunset objectives, (4) subscription data, etc. Note, a cellular host changing its connection between an IPv6-specific APN and an IPv4-specific APN restarts the ongoing applications. This is a brokenness situation. Please let me know if this is OK. Thank you. Cheers, Med -----Message d'origine----- De=A0: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Envoy=E9=A0: mercredi 11 f=E9vrier 2015 15:15 =C0=A0: BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4= /v6 PDP-contexts and APNs Le 11/02/2015 14:30, mohamed.boucadair@orange.com a =E9crit : > Hi Alex, > > The draft includes this text: > > Some of the features listed in this profile document require to > activate dedicated functions at the network side. It is out of > scope of this document to list these network-side functions. > > This I-D cannot mandate the behavior of the network side as it is up > to the taste of each operator. > > Saying that, if you believe there is a service/application brokenness > risk due to some kind of policy enforced at the network side with > regards to the management of PDP contexts and APNs, I see a value in > adding a "note" to record it. Note: a smartphone changing its connection between an APN-v6 and an=20 APN-v4 block-restarts the ongoing applications. This is a brokenness=20 situation. Alex > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoy=E9 : mercredi 11 f=E9vrier 2015 12:03 =C0 : v6ops@ietf.org Objet : > Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 > PDP-contexts and APNs > > Le 11/02/2015 10:43, Lorenzo Colitti a =E9crit : >> On Wed, Feb 11, 2015 at 12:51 AM, > > wrote: >> >> The document was adopted by the WG and passed both the WG and IETF >> LCs with that scope. I naively assumed that this point is not >> anymore an issue given that the draft passed major milestones >> (several WGLCs, IETF LC) and the IETF consensus declared for it >> means this is not an issue to advance the document. >> >> I think that assumption is incorrect, given Fred's explicit >> statement on this thread, "Before I bother the IESG with it a third >> time, I'd really like to hear a clear consensus, not a rough one." >> >> https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html > > LEt me try to understand - are we trying to identify consensus? Or > can we still discuss the requirements per se? > > To me, the latter has its importance as well. > > For example: >> C_REC#1: In order to allow each operator to select their own >> strategy regarding IPv6 introduction, the cellular host must >> support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. Both IPv6 and >> IPv4v6 PDP-Contexts must be supported. IPv4, IPv6 or IPv4v6 >> PDP-Context request acceptance depends on the cellular network >> configuration. > > I would like this requirement to state that _if_ the smartphone sold > by that operator supports IPv4 PDP-context, IPv6 PDP-context and > IPv4v6 PDP-context then the operator SHOULD support at least IPv4v6 > PDP-context, and ideally the 3 for the same APN; in all cases, the > operator SHOULD NOT support only IPv6 PDP-Context or only IPv4 > PDP-Context per one APN. > > As surprising it might seem, some operators take an approach of > supporting only IPv6 PDP-Context on one APN, and the other two on > other two APNs, regardless of the end-user preference; they have > their particular reasons which may not be technical. It is very > stimulating in some sense (IPv6-only), or too daring for some > customers which see their IPv6 flows interupted if switching to other > APN. > > Alex > >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Feb 12 01:41:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9461A1B5A for ; Thu, 12 Feb 2015 01:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jorr_Hysxtmk for ; Thu, 12 Feb 2015 01:41:01 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D3A1A0382 for ; Thu, 12 Feb 2015 01:41:01 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1C9ex6C024877; Thu, 12 Feb 2015 10:40:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 126A4205C25; Thu, 12 Feb 2015 10:41:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 06E2B205BCA; Thu, 12 Feb 2015 10:41:53 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1C9eXDT027755; Thu, 12 Feb 2015 10:40:58 +0100 Message-ID: <54DC7511.40400@gmail.com> Date: Thu, 12 Feb 2015 10:40:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "v6ops@ietf.org" References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908E6C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004908F65@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB36CC.90308@gmail.com> <787AE7BB302AE849A7480A190F8B93300490931C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DB63E8.7020205@gmail.com> <787AE7BB302AE849A7480A190F8B933004909AC1@OPEXCLILM23.corporate.adroot.infra.! ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004909AC1@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 09:41:04 -0000 Le 12/02/2015 10:36, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > I think this note can be added to C_REC#6 not C_REC#1. I made this change in my local copy: > > OLD: > C_REC#6: The cellular host must be able to be configured to limit > PDP type(s) for a given APN. The default mode is to allow > all supported PDP types. Note, C_REC#2 discusses the > default behavior for requesting PDP-Context type(s). > > This feature is useful to drive the behavior of the UE > to be aligned with: (1) service-specific constraints > such as the use of IPv6-only for VoLTE (Voice over LTE), > (2) network conditions with regards to the support of > specific PDP types (e.g., IPv4v6 PDP-Context is not > supported), (3) IPv4 sunset objectives, (4) subscription > data, etc. > > NEW: > > C_REC#6: The cellular host must be able to be configured to limit > PDP type(s) for a given APN. The default mode is to allow > all supported PDP types. Note, C_REC#2 discusses the > default behavior for requesting PDP-Context type(s). > > This feature is useful to drive the behavior of the UE > to be aligned with: (1) service-specific constraints > such as the use of IPv6-only for VoLTE (Voice over LTE), > (2) network conditions with regards to the support of > specific PDP types (e.g., IPv4v6 PDP-Context is not > supported), (3) IPv4 sunset objectives, (4) subscription > data, etc. > > Note, a cellular host changing its connection between an > IPv6-specific APN and an IPv4-specific APN restarts the > ongoing applications. This is a brokenness situation. > > > Please let me know if this is OK. Thank you. YEs, this note is OK, thanks. Alex > > Cheers, > Med > > -----Message d'origine----- > De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Envoyé : mercredi 11 février 2015 15:15 > À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org > Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 PDP-contexts and APNs > > Le 11/02/2015 14:30, mohamed.boucadair@orange.com a écrit : >> Hi Alex, >> >> The draft includes this text: >> >> Some of the features listed in this profile document require to >> activate dedicated functions at the network side. It is out of >> scope of this document to list these network-side functions. >> >> This I-D cannot mandate the behavior of the network side as it is up >> to the taste of each operator. >> >> Saying that, if you believe there is a service/application brokenness >> risk due to some kind of policy enforced at the network side with >> regards to the management of PDP contexts and APNs, I see a value in >> adding a "note" to record it. > > Note: a smartphone changing its connection between an APN-v6 and an > APN-v4 block-restarts the ongoing applications. This is a brokenness > situation. > > Alex > >> >> Cheers, Med >> >> -----Message d'origine----- De : v6ops >> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoyé : mercredi 11 février 2015 12:03 À : v6ops@ietf.org Objet : >> Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call - v4/v6 >> PDP-contexts and APNs >> >> Le 11/02/2015 10:43, Lorenzo Colitti a écrit : >>> On Wed, Feb 11, 2015 at 12:51 AM, >> > wrote: >>> >>> The document was adopted by the WG and passed both the WG and IETF >>> LCs with that scope. I naively assumed that this point is not >>> anymore an issue given that the draft passed major milestones >>> (several WGLCs, IETF LC) and the IETF consensus declared for it >>> means this is not an issue to advance the document. >>> >>> I think that assumption is incorrect, given Fred's explicit >>> statement on this thread, "Before I bother the IESG with it a third >>> time, I'd really like to hear a clear consensus, not a rough one." >>> >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg21229.html >> >> LEt me try to understand - are we trying to identify consensus? Or >> can we still discuss the requirements per se? >> >> To me, the latter has its importance as well. >> >> For example: >>> C_REC#1: In order to allow each operator to select their own >>> strategy regarding IPv6 introduction, the cellular host must >>> support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. Both IPv6 and >>> IPv4v6 PDP-Contexts must be supported. IPv4, IPv6 or IPv4v6 >>> PDP-Context request acceptance depends on the cellular network >>> configuration. >> >> I would like this requirement to state that _if_ the smartphone sold >> by that operator supports IPv4 PDP-context, IPv6 PDP-context and >> IPv4v6 PDP-context then the operator SHOULD support at least IPv4v6 >> PDP-context, and ideally the 3 for the same APN; in all cases, the >> operator SHOULD NOT support only IPv6 PDP-Context or only IPv4 >> PDP-Context per one APN. >> >> As surprising it might seem, some operators take an approach of >> supporting only IPv6 PDP-Context on one APN, and the other two on >> other two APNs, regardless of the end-user preference; they have >> their particular reasons which may not be technical. It is very >> stimulating in some sense (IPv6-only), or too daring for some >> customers which see their IPv6 flows interupted if switching to other >> APN. >> >> Alex >> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > > From nobody Thu Feb 12 04:42:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283101A6EE1; Thu, 12 Feb 2015 04:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie_8tKAW7z0O; Thu, 12 Feb 2015 04:42:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844441A87B9; Thu, 12 Feb 2015 04:42:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 04:42:26 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:42:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages : 18 Date : 2015-02-12 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network) with a special focus on IPv4 service continuity features. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 12 04:48:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683701A87BC for ; Thu, 12 Feb 2015 04:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjxQfzTkXQtf for ; Thu, 12 Feb 2015 04:48:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075341A87B9 for ; Thu, 12 Feb 2015 04:48:07 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 398EB3B4574; Thu, 12 Feb 2015 13:48:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1BAF427C108; Thu, 12 Feb 2015 13:48:05 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 13:48:05 +0100 From: To: "STARK, BARBARA H" Thread-Topic: OECD report on the economics of the transition to IPv6 Thread-Index: AdBBUu5tbgSRe7A7SVys6lHBYT/52wFbrYZA Date: Thu, 12 Feb 2015 12:48:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004909D3A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E61130F11F49@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F11F49@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] OECD report on the economics of the transition to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:48:09 -0000 Hi Barbara, Thank you for sharing this report.=20 I added a pointer to it in the new revision of the mobile profile I-D.=20 Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA H Envoy=E9=A0: jeudi 5 f=E9vrier 2015 15:59 =C0=A0: IPv6 Ops WG Objet=A0: [v6ops] OECD report on the economics of the transition to IPv6 Given some of the recent discussion regarding the mobile-device-profile dra= ft, I thought some people might be interested in this report on the economi= cs of transition to IPv6 that was commissioned by OECD and published in Nov= ember 2014. A number of people who participate in v6ops were interviewed fo= r this report. Barbara [If the link gets broken across lines, just paste it together again.] http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=3DDSTI= /ICCP/CISP%282014%293/FINAL&docLanguage=3DEn=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 12 05:56:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9661A87BE for ; Thu, 12 Feb 2015 05:56:43 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3CZpge3f-d1 for ; Thu, 12 Feb 2015 05:56:42 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46F71A86FA for ; Thu, 12 Feb 2015 05:56:41 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so3760325iga.0 for ; Thu, 12 Feb 2015 05:56:41 -0800 (PST) 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=080SBbONHwoqiBJvWX73zVL4YRwZvYMRGB3ymDk/RGI=; b=buRN7xBQbRmljEmiLl9YnS0gc6KxCQqui0hOv+6R8+9dvL4nRZslHh17402tyPqR4L xAZ0tS4XpAcptiEmG2lZR6DDcLMrGy3gsuTTXVCt6h9U0DPsnvjW9v+jDQ6ckLEyh6VR G2L2HF58EEVfyRfR1A+srCuUFTUrqQAPbd8sTzt5yumnhNiYL87CmU/AfLMApEt0DBYX xzslTJEY7X5moRWFSNKgFMwCoshFAxk6LGBjdHLKT7YpXFkHGbBCkwrYL42dt4IyHud4 hhrHbvhc5i77QbY8nXgiZsi+z+1OIgfXzKTYwQnmhzrJiZa91ymRHYXh1yRH670tXvHM VYEQ== MIME-Version: 1.0 X-Received: by 10.42.106.203 with SMTP id a11mr8625197icp.2.1423749401076; Thu, 12 Feb 2015 05:56:41 -0800 (PST) Received: by 10.36.69.168 with HTTP; Thu, 12 Feb 2015 05:56:41 -0800 (PST) In-Reply-To: <54DB5ABA.7090703@foobar.org> References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> <54DB5ABA.7090703@foobar.org> Date: Thu, 12 Feb 2015 08:56:41 -0500 Message-ID: From: Rick Casarez To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=20cf304352c84ced48050ee47db7 Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:56:44 -0000 --20cf304352c84ced48050ee47db7 Content-Type: text/plain; charset=UTF-8 I know I have run into vendors who have optimized their data structures for /64 but not for anything smaller. We are already pushing them on that front to do it for all prefix-lengths. I support this document. ------------------- Cheers, Rick Experiences not things. On Wed, Feb 11, 2015 at 8:35 AM, Nick Hilliard wrote: > On 11/02/2015 12:47, fred@cisco.com wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a > look at it and comment. > > I agree with the sentiment of this document but as an observation, > unrestricted longest-prefix-match lookup tends to be circumvented by > vendors in order to provide increased forwarding table capacity. There's a > curious practical example in the "Cisco Nexus 5000 Series Configuration > Limits" document: > > Dynamic routes 16,384 (includes IPv4 and IPv6 routes) > V6 LPM routes 128 entries > > It would be interesting to see why the difference between v4 and v6 lpm > lookup entries is greater than 4x. > > Otherwise, I support this doc. > > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf304352c84ced48050ee47db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know I have run into vendors who have optimized the= ir data structures for /64 but not for anything smaller. We are already pus= hing them on that front to do it for all prefix-lengths.

I sup= port this document.

<= div>
-------------------
= Cheers, Rick

Experiences not things.

On Wed, Feb 11, 2015 at 8:35 AM, Nick Hillia= rd <nick@foobar.org> wrote:
= On 11/02/2015 12:47, fred@cisco.com w= rote:
> A new draft has been posted, at http://tools.ietf.org/html/= draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

I agree with the sentiment of this document but as an observation,
unrestricted longest-prefix-match lookup tends to be circumvented by
vendors in order to provide increased forwarding table capacity.=C2=A0 Ther= e's a
curious practical example in the "Cisco Nexus 5000 Series Configuratio= n
Limits" document:

Dynamic routes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16,384 (includes IPv4 and = IPv6 routes)
V6 LPM routes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0128 entries

It would be interesting to see why the difference between v4 and v6 lpm
lookup entries is greater than 4x.

Otherwise, I support this doc.


Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--20cf304352c84ced48050ee47db7-- From nobody Thu Feb 12 08:27:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B421F1A007C for ; Thu, 12 Feb 2015 08:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtPf0AJzmjmK for ; Thu, 12 Feb 2015 08:27:48 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D5C1A0070 for ; Thu, 12 Feb 2015 08:27:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1CGRkj9022754 for ; Thu, 12 Feb 2015 17:27:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7042E2070F4 for ; Thu, 12 Feb 2015 17:28:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 66FF9206F96 for ; Thu, 12 Feb 2015 17:28:40 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1CGRH0t009525 for ; Thu, 12 Feb 2015 17:27:45 +0100 Message-ID: <54DCD464.3000907@gmail.com> Date: Thu, 12 Feb 2015 17:27:16 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> In-Reply-To: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:27:53 -0000 Hello, Thank you for this new version of the draft. I have a doubt with respect to the 464XLAT requirement: > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the > Customer Side Translator (CLAT, [RFC6877]) function which > is compliant with [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows for IPv4-only > application and IPv4-referals to work on an IPv6-only > connectivity. CLAT function requires a NAT64 capability > [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by CLAT is > defined in [RFC7335]. I think this requirement leads to a situation where the network operator deploys IPv6-native-only and IPv4 as an add-on partial feature. On one hand, it is encouraging to see native IPv6 and no IPv4. On another hand, _partial_ IPv4 support is a temptation which deceives in the end - it leads to turn off IPv6 and come back to good ol' IPv4 and no IPv6. The 464XLAT is partial IPv4 support: does not offer full IPv4 connectivity to the smartphone. It is not possible to address the smartphone by its IPv4 address - DNS is required; this makes it impossible to make a VPN tunnel, or Mobile IP. One can not a deploy a wireless IPv4 router along the road in a remote area, for example. This leads to a situation where the operator requires end user to switch to another APN which is less IPv6. I think it is not a happy situation. I would suggest to qualify this requirement by another requirement. This initial requirement would state that _first_, before any v4-v6 conversion mechanism is considered, both the network and the end user MUST implement a native IPv4 stack and a native IPv6 stack (not say 'dual' stack, which is much overloaded). We dont want to block IPv4 use when IPv6 arrives. Alex 12/02/2015 13:42, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Gang Chen > Nick Heatley > Ross Chandler > Filename : draft-ietf-v6ops-mobile-device-profile-17.txt > Pages : 18 > Date : 2015-02-12 > > Abstract: > This document defines a profile that is a superset of that of the > connection to IPv6 cellular networks defined in the IPv6 for Third > Generation Partnership Project (3GPP) Cellular Hosts document. This > document defines an IPv6 profile that a number of operators recommend > in order to connect 3GPP mobile devices to an IPv6-only or dual-stack > wireless network (including 3GPP cellular network and IEEE 802.11 > network) with a special focus on IPv4 service continuity features. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-17 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Feb 12 11:14:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F221A00A8 for ; Thu, 12 Feb 2015 11:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4us6joU9xlg for ; Thu, 12 Feb 2015 11:13:53 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177211A1AB3 for ; Thu, 12 Feb 2015 11:13:52 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id nt9so11764777obb.13 for ; Thu, 12 Feb 2015 11:13:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SvD/2y6J3fDelAB3YjrYxcC75nzi5GD2ja/dRDPFhDI=; b=LfgbzvBmQd0lRxxRD1kB9/ckIVZA01wlZN5mVoWhhOkDyfgQbp5GzvkK0QISAjnhdL ksw0kCOM9uDbjbHFRibtr++G8QEJY+qH79iPiJNXCPsLeHvTr1EzXXdu9d+VWmKqRfdr L19GUnAX78UI+WvkBtV76F+7vACn0fq72dSIBQ0AwpGjcsCcULqR3PAXz7cntCKop1+E CIp2uhV9bd8n6J+55cSxtarZ8vANK6BZxahowKPRpRcqo3I8akRElolU9rUd73Os8lnG nvQLnMNpQ3Wd+INutsrMBllcdbSI7KOscF8Hmsbp9F8IPvfV9vmklOLMYII62reAFjNi Xd6Q== X-Gm-Message-State: ALoCoQnwyak2B+7hNEA8GRUZ4z3wtBk47RlQQtw1yuFGVwPEX0mI8FRku6VK8XE/sl9qZc27rcNS MIME-Version: 1.0 X-Received: by 10.202.95.2 with SMTP id t2mr3609853oib.104.1423768432459; Thu, 12 Feb 2015 11:13:52 -0800 (PST) Received: by 10.76.150.2 with HTTP; Thu, 12 Feb 2015 11:13:52 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Thu, 12 Feb 2015 11:13:52 -0800 Message-ID: From: James Woodyatt To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a113cdccea8deb5050ee8eb76 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 19:13:57 -0000 --001a113cdccea8deb5050ee8eb76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mr. Boucadair=E2=80=94 Yes, there is a problem. The draft seems to conflate the behavior of residential broadband CPE gateways with 3GPP radios and mobile telephony handsets with tethering interfaces. I tend not to fight too hard against RFC 6092 in residential gateway scenarios, but I've always been opposed to seeing those recommendations applied more widely, especially if it seems=E2= =80=94 like it does in this case=E2=80=94 that the recommendation is being made ou= t of rote repetition rather than by careful technical consideration. Please forgive this digression: I have *never* wavered in my opposition to any recommendation or specification that calls for unmanaged network layer gateways to block unsolicited inbound transport layer flows by default. I have always preferred explicit recommendations to leave RFC 6092 filtering transparency mode by default, and to require an authorized human to "opt into" the blocking of inbound flows. Yes, RFC 6092 contains no such a recommendation. To my everlasting shame. Because I was the technical editor for RFC 6092, and I was concerned about conducting myself in that role with equanimity and fairness, I was grudgingly willing to suspend my objections on this topic when the working group settled on language that expressly makes no recommendation on whether transparency should or should not the default. That seemed to reflect consensus at the time. If I had not been the technical editor for that document, then I would have more vigorously expressed my personal objections. On a personal level, I'm no longer sure it's better to have a document that carefully describes the behavior of these ubiquitous and harmful firewalls than to have them go undocumented as was the case with IPv4/NAT firewalls. I haven't yet come to regret withholding my personal objections to RFC 6092, but I sometimes find that strong beer can dull the pain. I *was* opposed to RFC 7084 (and its predecessor) because it did not take the view that RFC 6092 firewall capability SHOULD be set for transparency by default. I didn't win that argument, and I expect I will lose it again in the context of this draft=E2=80=94 which I oppose for other reasons as w= ell, but this is the one that animates me before the others. I'm especially concerned that I-D.ietf-v6ops-mobile-device-profile seems to be too easily read to recommend the application of RFC 6092 firewalls inside mobile telephony handsets for tethered users. That's an expansion of the scope intended for RFC 6092 beyond the usage case of residential gateways, and I really wouldn't like to see that. Shorter james: - I've got BIG problems recommending RFC 6092 firewalls for mobile telephony handsets with tethered hosts. - I've got BIG problems whenever it even looks like IETF might be recommending RFC 6092 firewalls should be non-transparent by default. - I've also got problems with recommending RFC 6092 firewalls without expressly cautioning that IETF takes no position on whether they should = be transparent by default. - I'm slightly annoyed whenever RFC 6092 firewalls are even recommended at all, but I can get over that with strong enough beer. On Wed, Feb 11, 2015 at 10:39 PM, wrote: > Hi James, > > > > Thank you for raising this point as it helps to clarify a confusion. > > > > This document DOES NOT RECOMMENT RFC6092 for tethered hosts. > > > > I guess you are referring to this item: > > > > L_REC#2: The cellular CPE must be compliant with the requirements > > specified in [RFC7084 ]. > > > > There are several deployments, particularly in emerging > > countries, that relies on mobile networks to provide > > broadband services (e.g., customers are provided with > > mobile CPEs). > > > > Note, this profile does not require IPv4 service > > continuity techniques listed in [RFC7084 > ] because those > > are specific to fixed networks. IPv4 service continuity > > techniques specific to the mobile networks are included > > in this profile. > > > > This is about cellular ** CPE ** not tethered devices (You may noticed > that this item used explicitly =E2=80=9Ccellular CPE=E2=80=9D while other= items in this > section uses =E2=80=9Ccellular device=E2=80=9D). RFC7084 is required for = this case to > ensure a functional parity with fixed CPEs. > > > > BTW, the text you suggested about RFC6092 is in the draft: > > > > In the case of cellular devices that provide LAN features, compliance > > with L_REC#2 entails compliance with [RFC7084 ], which in turn > > recommends compliance with Recommended Simple Security Capabilities > > in Customer Premises Equipment (CPE) for Providing Residential IPv6 > > Internet Service [RFC6092 ]. Ther= efore, the security considerations > > in Section 6 of [RFC6092] are relevant. In particular, it bears > > repeating here that the true impact of stateful filtering may be a > > reduction in security, and that IETF make no statement, expressed or > > implied, as to whether using the capabilities described in any of > > these documents ultimately improves security for any individual users > > or for the Internet community as a whole. > > > > Are you suggesting that a mobile CPE should not have the same > functionalities as the fixed one, and therefore RFC7084 should not be cit= ed > in this I-D? Or you are suggesting that RFC7084 is harmful? > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* James Woodyatt [mailto:jhw@nestlabs.com] > *Envoy=C3=A9 :* mercredi 11 f=C3=A9vrier 2015 18:51 > *=C3=80 :* BOUCADAIR Mohamed IMT/OLN > *Cc :* IPv6 Ops WG > *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > On Wed, Feb 11, 2015 at 4:09 AM, wrote: > > > > Which items are not technically justified? > > > > Others may have other items that bug them, and additional items may sprin= g > to my mind later if I put my mind to it, but I see no technical > justification to recommend a simple firewall by default for tethered host= s > according to RFC 6092. I consider that recommendation to be actively > harmful. > > > > > -- > > james woodyatt > > Nest Labs, Communications Engineering > --=20 james woodyatt Nest Labs, Communications Engineering --001a113cdccea8deb5050ee8eb76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mr. Boucadair=E2=80=94

Yes, there is a = problem. The draft seems to conflate the behavior of residential broadband = CPE gateways with 3GPP radios and mobile telephony handsets with tethering = interfaces. I tend not to fight too hard against RFC 6092 in residential ga= teway scenarios, but I've always been opposed to seeing those recommend= ations applied more widely, especially if it seems=E2=80=94 like it does in= this case=E2=80=94 that the recommendation is being made out of rote repet= ition rather than by careful technical consideration.

<= div>Please forgive this digression: I have *never* wavered in my opposition= to any recommendation or specification that calls for unmanaged network la= yer gateways to block unsolicited inbound transport layer flows by default.= I have always preferred explicit recommendations to leave RFC 6092 filteri= ng transparency mode by default, and to require an authorized human to &quo= t;opt into" the blocking of inbound flows.

Ye= s, RFC 6092 contains no such a recommendation. To my everlasting shame.

Because I was the technical editor for RFC 6092, and = I was concerned about conducting myself in that role with equanimity and fa= irness, I was grudgingly willing to suspend my objections on this topic whe= n the working group settled on language that expressly makes no recommendat= ion on whether transparency should or should not the default. That seemed t= o reflect consensus at the time. If I had not been the technical editor for= that document, then I would have more vigorously expressed my personal obj= ections.

On a personal level, I'm no longer su= re it's better to have a document that carefully describes the behavior= of these ubiquitous and harmful firewalls than to have them go undocumente= d as was the case with IPv4/NAT firewalls. I haven't yet come to regret= withholding my personal objections to RFC 6092, but I sometimes find that = strong beer can dull the pain.

I *was* opposed to = RFC 7084 (and its predecessor) because it did not take the view that RFC 60= 92 firewall capability SHOULD be set for transparency by default. I didn= 9;t win that argument, and I expect I will lose it again in the context of = this draft=E2=80=94 which I oppose for other reasons as well, but this is t= he one that animates me before the others.

I'm= especially concerned that I-D.ietf-v6ops-mobile-device-profile seems to be= too easily read to recommend the application of RFC 6092 firewalls inside = mobile telephony handsets for tethered users. That's an expansion of th= e scope intended for RFC 6092 beyond the usage case of residential gateways= , and I really wouldn't like to see that.

Shor= ter james:
  • I've got BIG problems recommending RFC 609= 2 firewalls for mobile telephony handsets with tethered hosts.
  • I= 9;ve got BIG problems whenever it even looks like IETF might be recommendin= g RFC 6092 firewalls should be non-transparent by default.
  • I= 9;ve also got problems with recommending RFC 6092 firewalls without express= ly cautioning that IETF takes no position on whether they should be transpa= rent by default.
  • I'm slightly annoyed whenever RFC 6092 fir= ewalls are even recommended at all, but I can get over that with strong eno= ugh beer.

On Wed, Feb 11, 2015 at 10:39 PM, <= mohamed.b= oucadair@orange.com> wrote:

Hi James,<= /p>

=C2=A0

Thank you for raising this poin= t as it helps to clarify a confusion.

=C2=A0

This document DOES NOT RECOMMEN= T RFC6092 for tethered hosts.

=C2=A0

I guess you are referring to th= is item:

=C2=A0

=C2=A0=C2=A0 L_REC#2:=C2=A0 The cellular CP= E must be compliant with the requirements

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specified in [RFC7084].

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are several deployme= nts, particularly in emerging

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 countries, that relies on = mobile networks to provide

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 broadband services (e.g., = customers are provided with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mobile CPEs).

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note, this profile does no= t require IPv4 service

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continuity techniques list= ed in [RFC7084] because those

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are specific to fixed netw= orks.=C2=A0 IPv4 service continuity

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 techniques specific to the= mobile networks are included

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in this profile.=

=C2=A0

This is about cellular ** CPE *= * not tethered devices (You may noticed that this item used explicitly =E2= =80=9Ccellular CPE=E2=80=9D while other items in this section uses =E2=80=9Ccellular device=E2=80=9D). RFC7084 is required for this case to e= nsure a functional parity with fixed CPEs.

=C2=A0

BTW, the text you suggested abo= ut RFC6092 is in the draft:

=C2=A0

=C2=A0=C2=A0 In the case of cellular devices that=
 provide LAN features, compliance
=C2=A0=C2=A0 with L_REC#2 entails compliance with=
 [RFC7084], which in turn=

=C2=A0=C2=A0 recommends compliance with Recommend=
ed Simple Security Capabilities
=C2=A0=C2=A0 in Customer Premises Equipment (CPE)=
 for Providing Residential IPv6
=C2=A0=C2=A0 Internet Service [RF=
C6092].=C2=A0 Therefore, the security consi=
derations
=C2=A0 =C2=A0in Secti=
on=C2=A06 of [RFC6092] are relevant.=C2=A0 =
In particular, it bears
=C2=A0=C2=A0 repeating here that the true impact =
of stateful filtering may be a
=C2=A0=C2=A0 reduction in security, and that IETF=
 make no statement, expressed or
=C2=A0=C2=A0 implied, as to whether using the cap=
abilities described in any of
=C2=A0=C2=A0 these documents ultimately improves =
security for any individual users
=C2=A0=C2=A0 or for the Internet community as a w=
hole.

=C2=A0

Are you suggesting that a mobil= e CPE should not have the same functionalities as the fixed one, and theref= ore RFC7084 should not be cited in this I-D? Or you are suggesting that RFC7084 is harmful?

=C2=A0

Thank you.=

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Jame= s Woodyatt [mailto:jh= w@nestlabs.com]
Envoy=C3=A9=C2=A0: mercredi 11 f=C3=A9vrier 2015 18:51
=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN
Cc=C2=A0: IPv6 Ops WG
Objet=C2=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last= call- "harmfully broad"?

=C2=A0

On Wed, Feb 11, 2015 at 4:09 AM, <mohamed.boucadair@orange= .com> wrote:

=C2=A0

Which items are not technically= justified?

=C2=A0

Others may have other items that bug them, and addit= ional items may spring to my mind later if I put my mind to it, but I see n= o technical justification to recommend a simple firewall by default for tet= hered hosts according to RFC 6092. I consider that recommendation to be actively harmful.


=C2=A0

--

james woodyatt <jhw@nestlabs.com>

Nest Labs, Communications Engineering<= /p>




--
james woodyatt <jhw@nestlabs.com>
Nest Labs,= Communications Engineering
--001a113cdccea8deb5050ee8eb76-- From nobody Thu Feb 12 11:39:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642D01A1BCD for ; Thu, 12 Feb 2015 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TYWMQW7b2b9 for ; Thu, 12 Feb 2015 11:39:14 -0800 (PST) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by ietfa.amsl.com (Postfix) with SMTP id E361B1A1C02 for ; Thu, 12 Feb 2015 11:39:13 -0800 (PST) Received: (qmail 63612 messnum 2468176 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 12 Feb 2015 19:39:11 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail00.svc.cra.dublin.eircom.net (qp 63612) with SMTP; 12 Feb 2015 19:39:11 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id rXf81p00J4BK5ly01XfBWn; Thu, 12 Feb 2015 19:39:11 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: <54DCD464.3000907@gmail.com> Date: Thu, 12 Feb 2015 19:39:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 19:39:21 -0000 > On 12 Feb 2015, at 16:27, Alexandru Petrescu = wrote: >=20 > Hello, >=20 > Thank you for this new version of the draft. >=20 > I have a doubt with respect to the 464XLAT requirement: >> C_REC#9: In order to ensure IPv4 service continuity in an = IPv6-only >> deployment context, the cellular host should implement = the >> Customer Side Translator (CLAT, [RFC6877]) function which >> is compliant with [RFC6052][RFC6145][RFC6146]. >>=20 >> CLAT function in the cellular host allows for = IPv4-only >> application and IPv4-referals to work on an IPv6-only >> connectivity. CLAT function requires a NAT64 = capability >> [RFC6146] in the core network. >>=20 >> The IPv4 Service Continuity Prefix used by CLAT is >> defined in [RFC7335]. >=20 > I think this requirement leads to a situation where the network = operator deploys IPv6-native-only and IPv4 as an add-on partial feature. >=20 > On one hand, it is encouraging to see native IPv6 and no IPv4. >=20 > On another hand, _partial_ IPv4 support is a temptation which deceives = in the end - it leads to turn off IPv6 and come back to good ol' IPv4 = and no IPv6. >=20 > The 464XLAT is partial IPv4 support: does not offer full IPv4 = connectivity to the smartphone. It is not possible to address the = smartphone by its IPv4 address - DNS is required; this makes it = impossible to make a VPN tunnel, or Mobile IP. One can not a deploy a = wireless IPv4 router along the road in a remote area, for example. Alex, Are you saying all VPNs impossible or just ones not that don=92t go = through NAPT because they don=92t use TCP/UDP or something else? Openvpn = and IPSec over TCP/UDP work. In the pure IPv4 case their can also be = problems with PPTP if the CGN doesn=92t have an ALG. > This leads to a situation where the operator requires end user to = switch to another APN which is less IPv6. >=20 > I think it is not a happy situation. >=20 > I would suggest to qualify this requirement by another requirement. = This initial requirement would state that _first_, before any v4-v6 = conversion mechanism is considered, both the network and the end user = MUST implement a native IPv4 stack and a native IPv6 stack (not say = 'dual' stack, which is much overloaded). >=20 > We dont want to block IPv4 use when IPv6 arrives. >=20 > Alex Perhaps it could be clarified in C_REC#9 that the IPv6-only deployment = context refers to the 3GPP device? The data APN it accesses could = support IPv4, IPv6 and dual-stack IPv4v6 PDP/PDNs. BR Ross= From nobody Thu Feb 12 14:24:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8132A1A0451 for ; Thu, 12 Feb 2015 14:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSo3Yc0tcxXz for ; Thu, 12 Feb 2015 14:23:57 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAAA1A044D for ; Thu, 12 Feb 2015 14:23:56 -0800 (PST) Received: by iecrl12 with SMTP id rl12so13112766iec.4 for ; Thu, 12 Feb 2015 14:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HetCTz/BVP9chFyep0bvmtXhKuFtYN2EalohWFhsAd8=; b=fVxdg4Lh4051iSjOwD+UrOez8XKOYqR19iRbTHXSu9XHnm9NINj9nUuzygD17TBYUm ihpJKrXXxk3p9NWTo61T3ki/Dujt6dMPrHKNa1AwnXUsZs6mwwenSV2X+4tMfcl3LqrI 8SjtrXBD8qljLjSgA4+edTqcxXpwpwIJPv3WeBMBLefsmmD0I3emPmZPNQZu82NhW4Kn SVJXsTig8vdAYochbvfubkGpplZ0ScKQaDRIgSAvfrLQwOGbGvw91l+uHgt6Y1VQ3LMd 1dX/VIauKxX+tQi0FVPYI1CdLi1MCpjRuFIvbbJCo+m7DjD0tS9kEqnIw4j78h+VJLay FuLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HetCTz/BVP9chFyep0bvmtXhKuFtYN2EalohWFhsAd8=; b=S3BJUexEUYGd9UocOC3Ps02j++N966t7/rvIiFlnelLh/I9+x1vxsAnN8XR+8QP//2 2rsp9BiGQszg0oNEGXBPlmDb8QKcGcmpWtt8OL/v7m5TWJPt2vZ2UvdmL1x8Br+h2CEJ 8bUyi0pNGjM5AZShTARXz8Qss/O8YXAIYScKz5Cvdrhkgkwv/77lzHVWr10p0EA5ZnN9 MsXuZMkyYChzceNOoX6Gbxb3WLWewPgvv6Nnf8e9OPahulRjFHOX4Kyp4MYbyfAcCbs7 53lARfGnmNTIVD/cb9UzcnLYiRdBgWAtLeI7Ut+P8VqIzJ6kVfB88V4xpWCh27LqO47P uJTw== X-Gm-Message-State: ALoCoQknQnZ7FCm8NVVLoYguk6tXwbQKuippKGCJ+sNmovGXJ1ManHT9mod6+BMVQvo/4GE751VN X-Received: by 10.107.134.103 with SMTP id i100mr7615018iod.90.1423779836274; Thu, 12 Feb 2015 14:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 12 Feb 2015 14:23:36 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 12 Feb 2015 14:23:36 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113ece62614a77050eeb93db Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:23:59 -0000 --001a113ece62614a77050eeb93db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2015 at 4:09 AM, wrote: > Can you explicit what do you meant by =E2=80=9Charmfully broad=E2=80=9D? > > (note, the pointer you provided is not valid because several items have > been removed from the draft since then.) > Ok, then. Since you ask, let me copy and paste the text from the pointer, then, and we can discuss why it is no longer valid. =3D=3D=3D=3D=3D I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. =3D=3D=3D=3D The way I see it, the recent changes made to the document do nothing to address the substance of those points. It's true that the document no longer lists 34 features, only 23, but it looks like the reduction has been mostly effected by removing features that were already mandatory IETF or 3GPP requirements (e.g., REQ#1, "must support IPv6 addressing architecture and ICMPv6 node requirements", REQ#6, "must support IPv6 neighbour discovery") and coalescing multiple features into one, (e.g., REQ_2 and REQ_3 were merged into C_REC#2). --001a113ece62614a77050eeb93db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 11, 2015 at 4:09 AM, <mohamed.boucadair@orange.com= > wrote:

Can you explicit what do you meant by =E2=80=9Char= mfully broad=E2=80=9D?

(note, the pointer you provided is = not valid because several items have been removed from the draft since then= .)


Ok, then. Since y= ou ask, let me copy and paste the text from the pointer, then, and we can d= iscuss why it is no longer valid.

=3D=3D=3D=3D=3D<= /div>
I object to this document on the grounds that it is little m= ore than a list of (34!) features with little technical justification. I se= e this as a problem because:

1. It is out of the I= ETF's mandate. It is not the IETF's job to specify which features o= r protocols should or should not be implemented in hosts. Even the hosts re= quirements RFCs are careful and sparing in their language. The IETF is cert= ainly not in the business of rubberstamping feature wishlists without good = technical reasons. I would challenge the authors to find a precedent RFC co= ntaining such broad requirements.

2. It is over-br= oad. The vast majority of the features are in no way necessary to build a m= obile device that works well over IPv6. Today, the overwhelming majority of= mobile device traffic comes from devices that implement only a handful of = these requirements. More specifically, requirements #3, #9, #10, #11, #12, = #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (= a whole RFC!), #28, #29, #31, #32 (which cover all applications running on = the device - yes, all of them), and #34, are not necessary to connect to IP= v6 mobile networks.

3. It is so daunting as to act= as a deterrent to IPv6 deployment. I would challenge the authors to find a= single product today that implements all, or even a substantial majority, = of these requirements. It seems to me that the sheer length of the list, an= d the fact that is not prioritized, create a real risk that implementors wi= ll simply write it off as wishful thinking or even shy away in terror.

4. The document has few technical contributions of its= own. Most of the requirements are simply listed one after another.

I'm all for IPv6 deployment in mobile networks, but m= aking a list of what seems like all the features that the IETF has ever dev= eloped, and then saying that they all need to be implemented, is not the wa= y to get there. The way to do it is to document use cases and working scena= rios gleaned from operational experience.
=3D=3D=3D=3D

The way I see it, the recent changes made to the docum= ent do nothing to address the substance of those points.

It's true that the document no longer lists 34 features, only 23= , but it looks like the reduction has been mostly effected by removing feat= ures that were already mandatory IETF or 3GPP requirements (e.g., REQ#1, &q= uot;must support IPv6 addressing architecture and ICMPv6 node requirements&= quot;, REQ#6, "must support IPv6 neighbour discovery") and coales= cing multiple features into one, (e.g., REQ_2 and REQ_3 were merged into C_= REC#2).
--001a113ece62614a77050eeb93db-- From nobody Thu Feb 12 14:27:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79961A03A0 for ; Thu, 12 Feb 2015 14:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUWQQBLmBYrB for ; Thu, 12 Feb 2015 14:26:58 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4581A039F for ; Thu, 12 Feb 2015 14:26:58 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so7020192igb.2 for ; Thu, 12 Feb 2015 14:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yA8vTPfEYaNBe65yXQAbAT8NmUIRD3XcabiD8bUXQvk=; b=J7nvCLAVDUy0/9ndCCne2aEgSH2WYN0Xj34FMvbK274K60p9CcLDTvPTR+0vHuzdif yeKaewsPqhrP3scc1WyZ8n6SdAgsEsWusE0bBV/T4+4GD64XGOYy4VdkvZNHAX5r/EY4 0BMYA3hLnNM51iUK6zAgEA+TzikCPN8wFnba0KM4wwVdIVg3B97KV9HRdmUxoPrenS7i v8FJ9zZkEZzLQ4OHzgW/0mr1igaJDsIyjXGs3ObdI5a9D9EQglfLszswACKhtGZEEzSS W9PfEDJMjaqpnkzULW9irNSfxQx/9Q7NznwE4sGyLrYc9oKkeAhYTgU5nQFS/ID4ikcW WFnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yA8vTPfEYaNBe65yXQAbAT8NmUIRD3XcabiD8bUXQvk=; b=cU066FfcA9bfzIPJqn/QHZFMms+ujKJrsbfUoobPWF9i6m8yCWqOC25CdtjCwsSP1z eSlrYZKe4Ybu4TrV2dfA7AI0QSS3AEh88sQjFwPqsdPDtY1ssQOr5w6SoJeonZwEPKZ0 44n5Gy3b5pT5rX9wyMHSGBwhwuNqaETa+ZXFZDdq2XV9QpTWWDOxlC6kgg3MWpOyvlm5 TcwHjquywdxLTJVEr4zDAwXOSabpBMKiyFPi4XhaJNnXjcIqqtmgCvApAHACd7DVDiAY GHe9jNJd8TOMDFXVpYSpcGht2GPLJvYDnT8G2EkCxe26sk213ag8acKZCuVFoqPdkYuf KsDg== X-Gm-Message-State: ALoCoQlTaIwYqfZWAh55VFsqIJ5T+FU/w/rfQnPP+f/5FjSxanL4VjE4du/a3e0IE5MRJmKU8S/K X-Received: by 10.50.117.41 with SMTP id kb9mr6881565igb.37.1423780017654; Thu, 12 Feb 2015 14:26:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 12 Feb 2015 14:26:37 -0800 (PST) In-Reply-To: <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> From: Lorenzo Colitti Date: Thu, 12 Feb 2015 14:26:37 -0800 Message-ID: To: Ross Chandler Content-Type: multipart/alternative; boundary=089e011605cc31050f050eeb9e96 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:27:00 -0000 --089e011605cc31050f050eeb9e96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2015 at 11:39 AM, Ross Chandler wrote: > Are you saying all VPNs impossible or just ones not that don=E2=80=99t go= through > NAPT because they don=E2=80=99t use TCP/UDP or something else? Openvpn an= d IPSec > over TCP/UDP work. In the pure IPv4 case their can also be problems with > PPTP if the CGN doesn=E2=80=99t have an ALG. > "IPsec over UDP works" is an overstatement. For example, GRE VPN does not work without an ALG for GRE, and IPsec over UDP using certificates does not work unless the NAT64 properly supports fragmentation. I have seen at least one large deployment where that is not the case. --089e011605cc31050f050eeb9e96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 12, 2015 at 11:39 AM, Ross Chandler <ross@eircom.net> wrote:
Are you saying all VPNs impossib= le or just ones not that don=E2=80=99t go through NAPT because they don=E2= =80=99t use TCP/UDP or something else? Openvpn and IPSec over TCP/UDP work.= In the pure IPv4 case their can also be problems with PPTP if the CGN does= n=E2=80=99t have an ALG.

"IPsec ov= er UDP works" is an overstatement. For example, GRE VPN does not work = without an ALG for GRE, and IPsec over UDP using certificates does not work= unless the NAT64 properly supports fragmentation. I have seen at least one= large deployment where that is not the case.
--089e011605cc31050f050eeb9e96-- From nobody Thu Feb 12 16:00:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105F61A00FF for ; Thu, 12 Feb 2015 16:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HajBgVXDbuVN for ; Thu, 12 Feb 2015 16:00:04 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F1E1A0149 for ; Thu, 12 Feb 2015 16:00:04 -0800 (PST) Received: by iecat20 with SMTP id at20so15958138iec.12 for ; Thu, 12 Feb 2015 16:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LIhNGfI6NFJi1ZvjraREB1u2/onmyW08yy01xzMviUU=; b=GRTSwwZrh6AToKfSJDjmPi/sr+hCHYIoDpnl4XIsV+Aumj0mpLKRtKaVsfiU0lMZm0 2aSe08YMv20PQbvptcq5waVRIjrDI0JkaSlQI6w31R7o0UZrWhBrL8EEF0joIL0f8/QA cUA4zk91ZSMNcEXT9pb2PnOs/62XGG52E87+Db2koKU/tq7RI0SrbKyUGAzpbSzR/4lh qXLAZJ5YTXhmRtj/Qxwzkg8zmXy12GRcsW6yMqqd7bOkwprsRlFOrn6wXqcleUWcfob7 E+BCkMW2vVG2QwP8FaPMI3rq+guUApghjbGcZYFxT+DZ4BAnxGv+IcF6vMMhlSsRlN5n jUAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LIhNGfI6NFJi1ZvjraREB1u2/onmyW08yy01xzMviUU=; b=One+7bHEEIJadz7kfgheJzJ8FMAKRe9JKpe0VK3PdBD+YmpCfx4NohF5tJJk1SqiGS k1IOHwOULkW2/jLAqdxDeKRTWZpxmvEYW3HMr6lEx3ZNzxLC6C7u6p3afuOY7YLKwLZb 4EHrCglMIDPDo/gqT/PAc69ridxlr6SF65kY482jTuf6HCrEWt88DHyxgumiJuICCIQW WDkRuv/Ebj7nIquqLBkhipB91F+e64pmp+BKTqMr/twtjkVm0tdv8diY+LTzq30bVINq KPIQl3VtzPbZxaJ1CPh1eVTCq0+RxE6Oc8RnYmSPyOA0jFzj1S1Wo9b2aBsOyXB4JbMJ rN4g== X-Gm-Message-State: ALoCoQkifGWb73U9drcvS7FWUu9Axhm5yJ4Bog6+mitunsZhRSnpHxo7AytIBjDlRXoyCECsHn6J X-Received: by 10.107.128.169 with SMTP id k41mr8320249ioi.30.1423785603575; Thu, 12 Feb 2015 16:00:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 12 Feb 2015 15:59:43 -0800 (PST) In-Reply-To: References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> <54DB5ABA.7090703@foobar.org> From: Lorenzo Colitti Date: Thu, 12 Feb 2015 15:59:43 -0800 Message-ID: To: Rick Casarez Content-Type: multipart/alternative; boundary=001a113f8e9a235597050eeceb8a Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:00:07 -0000 --001a113f8e9a235597050eeceb8a Content-Type: text/plain; charset=UTF-8 I don't believe we should dictate routing table sizes. We can state that it must be possible to route on prefix levels up to /128, but we cannot state how many entries the hardware must support. Because /64 is a common maximum prefix length, it makes sense to treat 64-bit routing entries and 128-bit routing entries differently in hardware. Reality dictates that routing on 128 bits consumes more resources than routing on 64 bits. Attempting to enforce that all routing table entries must be full 128 bits wide will either result in the hardware supporting fewer routing table entries or in the hardware costing more, neither of which to anyone's gain. So, for example, if a given router did not support /123-bit long entries at all, then that would not fit in this best practice. But if the router supported 1024 /128 entries and 64k /64 entries, I think that would comply. On Thu, Feb 12, 2015 at 5:56 AM, Rick Casarez wrote: > I know I have run into vendors who have optimized their data structures > for /64 but not for anything smaller. We are already pushing them on that > front to do it for all prefix-lengths. > > I support this document. > > ------------------- > Cheers, Rick > > Experiences not things. > > On Wed, Feb 11, 2015 at 8:35 AM, Nick Hilliard wrote: > >> On 11/02/2015 12:47, fred@cisco.com wrote: >> > A new draft has been posted, at >> http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix. Please take a >> look at it and comment. >> >> I agree with the sentiment of this document but as an observation, >> unrestricted longest-prefix-match lookup tends to be circumvented by >> vendors in order to provide increased forwarding table capacity. There's >> a >> curious practical example in the "Cisco Nexus 5000 Series Configuration >> Limits" document: >> >> Dynamic routes 16,384 (includes IPv4 and IPv6 routes) >> V6 LPM routes 128 entries >> >> It would be interesting to see why the difference between v4 and v6 lpm >> lookup entries is greater than 4x. >> >> Otherwise, I support this doc. >> >> >> Nick >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113f8e9a235597050eeceb8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't believe we should dictate routing table sizes.= We can state that it must be possible to route on prefix levels up to /128= , but we cannot state how many entries the hardware must support.

<= /div>
Because /64 is a common maximum prefix length, it makes sense to = treat 64-bit routing entries and 128-bit routing entries differently in har= dware.

Reality dictates that routing on 128 bits c= onsumes more resources than routing on 64 bits. Attempting to enforce that = all routing table entries must be full 128 bits wide will either result in = the hardware supporting fewer routing table entries or in the hardware cost= ing more, neither of which to anyone's gain.

S= o, for example, if a given router did not support /123-bit long entries at = all, then that would not fit in this best practice. But if the router suppo= rted 1024 /128 entries and 64k /64 entries, I think that would comply.
<= /div>

On Thu= , Feb 12, 2015 at 5:56 AM, Rick Casarez <rick.casarez@gmail.com&g= t; wrote:
I = know I have run into vendors who have optimized their data structures for /= 64 but not for anything smaller. We are already pushing them on that front = to do it for all prefix-lengths.

I support this document.
<= /div>

-------------------
Cheers, Rick

Experiences not things.
<= /div>

On Wed, Feb 11, 2015 at 8:35 AM, Nick Hillia= rd <nick@foobar.org> wrote:
= On 11/02/2015 12:47, fr= ed@cisco.com wrote:
> A new draft has been posted, at http://tools.ietf.org/html/= draft-ietf-v6ops-cidr-prefix. Please take a look at it and comment.

I agree with the sentiment of this document but as an observation,
unrestricted longest-prefix-match lookup tends to be circumvented by
vendors in order to provide increased forwarding table capacity.=C2=A0 Ther= e's a
curious practical example in the "Cisco Nexus 5000 Series Configuratio= n
Limits" document:

Dynamic routes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16,384 (includes IPv4 and = IPv6 routes)
V6 LPM routes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0128 entries

It would be interesting to see why the difference between v4 and v6 lpm
lookup entries is greater than 4x.

Otherwise, I support this doc.


Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--001a113f8e9a235597050eeceb8a-- From nobody Thu Feb 12 22:49:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBE51A09C9 for ; Thu, 12 Feb 2015 22:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyTJstW3_72w for ; Thu, 12 Feb 2015 22:49:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49981A0AF1 for ; Thu, 12 Feb 2015 22:49:24 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5076418C4D1; Fri, 13 Feb 2015 07:49:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A958A23815B; Fri, 13 Feb 2015 07:49:21 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 07:49:21 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDkZAjCWymvpku8SqF2CiTh9ZzuH5Wg Date: Fri, 13 Feb 2015 06:49:20 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> In-Reply-To: <54DCD464.3000907@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 06:49:28 -0000 Hi Alex,=20 The intent of this reco is to address broken IPv4-only applications over an= IPv6-only connectivity. Ideally applications running on the device should = be AF-independent.=20 The draft relies on the IPv6 node requirements RFC that mandates the suppor= ts of IPv6. Also, the I-D calls out applications that are provided by the v= endor of the device:=20 =3D=3D APP_REC#2: Applications provided by the mobile device vendor must be independent of the underlying IP address family. =3D=3D Wouldn't this reco addresses your concern? Thank you. Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petres= cu Envoy=E9=A0: jeudi 12 f=E9vrier 2015 17:27 =C0=A0: v6ops@ietf.org Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17= .txt - C_REC#9 464XLAT Hello, Thank you for this new version of the draft. I have a doubt with respect to the 464XLAT requirement: > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the > Customer Side Translator (CLAT, [RFC6877]) function which > is compliant with [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows for IPv4-only > application and IPv4-referals to work on an IPv6-only > connectivity. CLAT function requires a NAT64 capability > [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by CLAT is > defined in [RFC7335]. I think this requirement leads to a situation where the network operator=20 deploys IPv6-native-only and IPv4 as an add-on partial feature. On one hand, it is encouraging to see native IPv6 and no IPv4. On another hand, _partial_ IPv4 support is a temptation which deceives=20 in the end - it leads to turn off IPv6 and come back to good ol' IPv4=20 and no IPv6. The 464XLAT is partial IPv4 support: does not offer full IPv4=20 connectivity to the smartphone. It is not possible to address the=20 smartphone by its IPv4 address - DNS is required; this makes it=20 impossible to make a VPN tunnel, or Mobile IP. One can not a deploy a=20 wireless IPv4 router along the road in a remote area, for example. This leads to a situation where the operator requires end user to switch=20 to another APN which is less IPv6. I think it is not a happy situation. I would suggest to qualify this requirement by another requirement.=20 This initial requirement would state that _first_, before any v4-v6=20 conversion mechanism is considered, both the network and the end user=20 MUST implement a native IPv4 stack and a native IPv6 stack (not say=20 'dual' stack, which is much overloaded). We dont want to block IPv4 use when IPv6 arrives. Alex 12/02/2015 13:42, internet-drafts@ietf.org a =E9crit : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the I= ETF. > > Title : An Internet Protocol Version 6 (IPv6) Profile = for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Gang Chen > Nick Heatley > Ross Chandler > Filename : draft-ietf-v6ops-mobile-device-profile-17.txt > Pages : 18 > Date : 2015-02-12 > > Abstract: > This document defines a profile that is a superset of that of the > connection to IPv6 cellular networks defined in the IPv6 for Third > Generation Partnership Project (3GPP) Cellular Hosts document. This > document defines an IPv6 profile that a number of operators recommend > in order to connect 3GPP mobile devices to an IPv6-only or dual-stack > wireless network (including 3GPP cellular network and IEEE 802.11 > network) with a special focus on IPv4 service continuity features. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile= -17 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 12 23:22:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1951A1B62 for ; Thu, 12 Feb 2015 23:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMigtLoCWtQc for ; Thu, 12 Feb 2015 23:21:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791871A1B53 for ; Thu, 12 Feb 2015 23:21:53 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0B77A264229; Fri, 13 Feb 2015 08:21:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E065723805C; Fri, 13 Feb 2015 08:21:51 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 08:21:51 +0100 From: To: James Woodyatt Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQRvgMtdv8/yjdEkq8+myPex9ad5zuJKIw Date: Fri, 13 Feb 2015 07:21:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490A7FF@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490A7FFOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.42120 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 07:21:59 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490A7FFOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBK YW1lcyBXb29keWF0dCBbbWFpbHRvOmpod0BuZXN0bGFicy5jb21dDQpFbnZvecOpIDogamV1ZGkg MTIgZsOpdnJpZXIgMjAxNSAyMDoxNA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpD YyA6IElQdjYgT3BzIFdHDQpPYmpldCA6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9i aWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk1yLiBC b3VjYWRhaXLigJQNCg0KWWVzLCB0aGVyZSBpcyBhIHByb2JsZW0uIFRoZSBkcmFmdCBzZWVtcyB0 byBjb25mbGF0ZSB0aGUgYmVoYXZpb3Igb2YgcmVzaWRlbnRpYWwgYnJvYWRiYW5kIENQRSBnYXRl d2F5cyB3aXRoIDNHUFAgcmFkaW9zIGFuZCBtb2JpbGUgdGVsZXBob255IGhhbmRzZXRzIHdpdGgg dGV0aGVyaW5nIGludGVyZmFjZXMuDQoNCltNZWRdIE5vLiBUaGUgcmVjb21tZW5kYXRpb24gaXMg YWJvdXQg4oCcbW9iaWxlIENQReKAnSB1c2VkIGluIHZhcmlvdXMgZGVwbG95bWVudCB0byBwcm92 aWRlIGJyb2FkYmFuZCBzZXJ2aWNlcy4gQW4gZXhhbXBsZSBjYW4gYmUgZm91bmQgaGVyZSAoaHR0 cDovL3d3dy5vcmFuZ2UudG4vZml4ZS1ldC1pbnRlcm5ldC9waWQzODItbGEtZmx5Ym94LW9yYW5n ZS5odG1sKS4gRXhjZXB0IHRoZSBhY2Nlc3MgdGVjaG5vbG9neSwgc2VydmljZXMgb2ZmZXJlZCB1 c2luZyB0aGVzZSBDUEUgYXJlIHRoZSBzYW1lIGFzIGFueSBmaXhlZCBDUEUuIFBsZWFzZSBsZXQg bWUgcmVpdGVyYXRlIHRoZSBmb2xsb3dpbmc6IHRoaXMgZHJhZnQgZG9lcyBub3QgcmVjb21tZW5k IHRoZSBzdXBwb3J0IG9mIFJGQzcwODQgZm9yIGV2ZXJ5IOKAnDNHUFAgcmFkaW9zIGFuZCBtb2Jp bGUgdGVsZXBob255IGhhbmRzZXRzIHdpdGggdGV0aGVyaW5nIGludGVyZmFjZXPigJ0uIEkgYWRk ZWQgYSBDQVVUSU9OIHRleHQgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uIHRvIG1ha2UgdGhpcyBjbGVh cjoNCg0KICAgICAgICAgICAgICAgIENBVVRJT046IFRoaXMgcmVjb21tZW5kYXRpb24gZG9lcyBu b3QgYXBwbHkgdG8gYW55DQogICAgICAgICAgICAgICAgY2VsbHVsYXIgZGV2aWNlIHdpdGggTEFO IGNhcGFiaWxpdGllczsgaXQgaXMgc3BlY2lmaWMgdG8NCiAgICAgICAgICAgICAgICBjZWxsdWxh ciBDUEVzIGluIG9yZGVyIHRvIGVuc3VyZSB0aGUgc2FtZSBJUHY2DQogICAgICAgICAgICAgICAg ZnVuY3Rpb25hbCBwYXJpdHkgZm9yIGJvdGggZml4ZWQgYW5kIGNlbGx1bGFyIENQRXMuDQoNCg0K SSB0ZW5kIG5vdCB0byBmaWdodCB0b28gaGFyZCBhZ2FpbnN0IFJGQyA2MDkyIGluIHJlc2lkZW50 aWFsIGdhdGV3YXkgc2NlbmFyaW9zLCBidXQgSSd2ZSBhbHdheXMgYmVlbiBvcHBvc2VkIHRvIHNl ZWluZyB0aG9zZSByZWNvbW1lbmRhdGlvbnMgYXBwbGllZCBtb3JlIHdpZGVseSwgZXNwZWNpYWxs eSBpZiBpdCBzZWVtc+KAlCBsaWtlIGl0IGRvZXMgaW4gdGhpcyBjYXNl4oCUIHRoYXQgdGhlIHJl Y29tbWVuZGF0aW9uIGlzIGJlaW5nIG1hZGUgb3V0IG9mIHJvdGUgcmVwZXRpdGlvbiByYXRoZXIg dGhhbiBieSBjYXJlZnVsIHRlY2huaWNhbCBjb25zaWRlcmF0aW9uLg0KDQpbTWVkXSBJdCBpcyBu b3QgYWJvdXQgcmVwZXRpdGlvbiBidXQgYWJvdXQgYSB0ZWNobmljYWwgc3RyYXRlZ3kgdGhhdCBh aW1zIHRvIGVuc3VyZSB0aGUgc2FtZSBmdW5jdGlvbmFsIHBhcml0eSB3aGF0ZXZlciB0aGUgYWNj ZXNzIHRlY2hub2xvZ3kgdXNlZCB0byBzZXJ2aWNlIGEgY3VzdG9tZXIuIFRoaXMgaXMga2V5IGZv ciBtb2JpbGUtZml4ZSBjb252ZXJnZW5jZSwgbXV0dWFsaXppbmcgY29kZSwgZW5naW5lZXJpbmcg cHJhY3RpY2VzLCBzZXJ2aWNlIGRlc2lnbiBhbmQgb3BlcmF0aW9ucywgYW5kIG1vcmUgaW1wb3J0 YW50IHRlc3RpbmcgYW5kIHZhbGlkYXRpb24gcmVzb3VyY2VzIGFuZCBlZmZvcnQuDQoNClBsZWFz ZSBmb3JnaXZlIHRoaXMgZGlncmVzc2lvbjogSSBoYXZlICpuZXZlciogd2F2ZXJlZCBpbiBteSBv cHBvc2l0aW9uIHRvIGFueSByZWNvbW1lbmRhdGlvbiBvciBzcGVjaWZpY2F0aW9uIHRoYXQgY2Fs bHMgZm9yIHVubWFuYWdlZCBuZXR3b3JrIGxheWVyIGdhdGV3YXlzIHRvIGJsb2NrIHVuc29saWNp dGVkIGluYm91bmQgdHJhbnNwb3J0IGxheWVyIGZsb3dzIGJ5IGRlZmF1bHQuIEkgaGF2ZSBhbHdh eXMgcHJlZmVycmVkIGV4cGxpY2l0IHJlY29tbWVuZGF0aW9ucyB0byBsZWF2ZSBSRkMgNjA5MiBm aWx0ZXJpbmcgdHJhbnNwYXJlbmN5IG1vZGUgYnkgZGVmYXVsdCwgYW5kIHRvIHJlcXVpcmUgYW4g YXV0aG9yaXplZCBodW1hbiB0byAib3B0IGludG8iIHRoZSBibG9ja2luZyBvZiBpbmJvdW5kIGZs b3dzLg0KDQpbTWVkXSBJ4oCZbSBwZXJzb25hbGx5IHdpdGggdHJhbnNwYXJlbnQgbW9kZSBzZXQg YnkgZGVmYXVsdC4gSWYgdGhlcmUgaXMgbm8gb2JqZWN0aW9uIGZyb20gdGhlIHdvcmtpbmcgZ3Jv dXAsIHRoaXMgY2FuIGJlIGFkZGVkIHVuZGVyIHNlY3VyaXR5IHNlY3Rpb24uDQoNClllcywgUkZD IDYwOTIgY29udGFpbnMgbm8gc3VjaCBhIHJlY29tbWVuZGF0aW9uLiBUbyBteSBldmVybGFzdGlu ZyBzaGFtZS4NCg0KQmVjYXVzZSBJIHdhcyB0aGUgdGVjaG5pY2FsIGVkaXRvciBmb3IgUkZDIDYw OTIsIGFuZCBJIHdhcyBjb25jZXJuZWQgYWJvdXQgY29uZHVjdGluZyBteXNlbGYgaW4gdGhhdCBy b2xlIHdpdGggZXF1YW5pbWl0eSBhbmQgZmFpcm5lc3MsIEkgd2FzIGdydWRnaW5nbHkgd2lsbGlu ZyB0byBzdXNwZW5kIG15IG9iamVjdGlvbnMgb24gdGhpcyB0b3BpYyB3aGVuIHRoZSB3b3JraW5n IGdyb3VwIHNldHRsZWQgb24gbGFuZ3VhZ2UgdGhhdCBleHByZXNzbHkgbWFrZXMgbm8gcmVjb21t ZW5kYXRpb24gb24gd2hldGhlciB0cmFuc3BhcmVuY3kgc2hvdWxkIG9yIHNob3VsZCBub3QgdGhl IGRlZmF1bHQuIFRoYXQgc2VlbWVkIHRvIHJlZmxlY3QgY29uc2Vuc3VzIGF0IHRoZSB0aW1lLiBJ ZiBJIGhhZCBub3QgYmVlbiB0aGUgdGVjaG5pY2FsIGVkaXRvciBmb3IgdGhhdCBkb2N1bWVudCwg dGhlbiBJIHdvdWxkIGhhdmUgbW9yZSB2aWdvcm91c2x5IGV4cHJlc3NlZCBteSBwZXJzb25hbCBv YmplY3Rpb25zLg0KDQpPbiBhIHBlcnNvbmFsIGxldmVsLCBJJ20gbm8gbG9uZ2VyIHN1cmUgaXQn cyBiZXR0ZXIgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgY2FyZWZ1bGx5IGRlc2NyaWJlcyB0aGUg YmVoYXZpb3Igb2YgdGhlc2UgdWJpcXVpdG91cyBhbmQgaGFybWZ1bCBmaXJld2FsbHMgdGhhbiB0 byBoYXZlIHRoZW0gZ28gdW5kb2N1bWVudGVkIGFzIHdhcyB0aGUgY2FzZSB3aXRoIElQdjQvTkFU IGZpcmV3YWxscy4gSSBoYXZlbid0IHlldCBjb21lIHRvIHJlZ3JldCB3aXRoaG9sZGluZyBteSBw ZXJzb25hbCBvYmplY3Rpb25zIHRvIFJGQyA2MDkyLCBidXQgSSBzb21ldGltZXMgZmluZCB0aGF0 IHN0cm9uZyBiZWVyIGNhbiBkdWxsIHRoZSBwYWluLg0KDQpbTWVkXSBZb3UgY2FuIHRyeSBhbiBv cmFuZ2UganVpY2UgdG9vIDstKQ0KDQpJICp3YXMqIG9wcG9zZWQgdG8gUkZDIDcwODQgKGFuZCBp dHMgcHJlZGVjZXNzb3IpIGJlY2F1c2UgaXQgZGlkIG5vdCB0YWtlIHRoZSB2aWV3IHRoYXQgUkZD IDYwOTIgZmlyZXdhbGwgY2FwYWJpbGl0eSBTSE9VTEQgYmUgc2V0IGZvciB0cmFuc3BhcmVuY3kg YnkgZGVmYXVsdC4gSSBkaWRuJ3Qgd2luIHRoYXQgYXJndW1lbnQsIGFuZCBJIGV4cGVjdCBJIHdp bGwgbG9zZSBpdCBhZ2FpbiBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ04oCUIHdoaWNoIEkg b3Bwb3NlIGZvciBvdGhlciByZWFzb25zIGFzIHdlbGwsIGJ1dCB0aGlzIGlzIHRoZSBvbmUgdGhh dCBhbmltYXRlcyBtZSBiZWZvcmUgdGhlIG90aGVycy4NCg0KSSdtIGVzcGVjaWFsbHkgY29uY2Vy bmVkIHRoYXQgSS1ELmlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIHNlZW1zIHRvIGJl IHRvbyBlYXNpbHkgcmVhZCB0byByZWNvbW1lbmQgdGhlIGFwcGxpY2F0aW9uIG9mIFJGQyA2MDky IGZpcmV3YWxscyBpbnNpZGUgbW9iaWxlIHRlbGVwaG9ueSBoYW5kc2V0cyBmb3IgdGV0aGVyZWQg dXNlcnMuDQoNCltNZWRdIEFzIEkgZXhwbGFpbmVkIGFib3ZlIHRoaXMgaXMgbm90IHRoZSBpbnRl bnQuIEkgYWRkZWQgYSBDQVVUSU9OIGZvciB0aGF0IHB1cnBvc2UgYnV0IGlmIHlvdSBzdGlsbCB0 aGluayB0aGVyZSBpcyBzdGlsbCBhIHJpc2ssIEkgY2FuIGNoZWNrIGhvdyBiZXR0ZXIgdG8gYWRk cmVzcyB5b3VyIGlzc3VlLg0KDQpUaGF0J3MgYW4gZXhwYW5zaW9uIG9mIHRoZSBzY29wZSBpbnRl bmRlZCBmb3IgUkZDIDYwOTIgYmV5b25kIHRoZSB1c2FnZSBjYXNlIG9mIHJlc2lkZW50aWFsIGdh dGV3YXlzLCBhbmQgSSByZWFsbHkgd291bGRuJ3QgbGlrZSB0byBzZWUgdGhhdC4NCg0KW01lZF0g VGhlcmUgaXMgbm8gZXhwYW5zaW9uIG9mIHRoZSBzY29wZTogYSBjZWxsdWxhciBDUEUgaXMgYSBm bGF2b3Igb2YgcmVzaWRlbnRpYWwgZ2F0ZXdheSBpbiBwYXJ0IG9mIGEgY291bnRyeSB3aGVyZSBm aXhlZCBpbmZyYXN0cnVjdHVyZSBpcyBpbmV4aXN0ZW50IG9yIGluZWZmaWNpZW50Lg0KDQpTaG9y dGVyIGphbWVzOg0KDQogICogICBJJ3ZlIGdvdCBCSUcgcHJvYmxlbXMgcmVjb21tZW5kaW5nIFJG QyA2MDkyIGZpcmV3YWxscyBmb3IgbW9iaWxlIHRlbGVwaG9ueSBoYW5kc2V0cyB3aXRoIHRldGhl cmVkIGhvc3RzLg0KICAqICAgSSd2ZSBnb3QgQklHIHByb2JsZW1zIHdoZW5ldmVyIGl0IGV2ZW4g bG9va3MgbGlrZSBJRVRGIG1pZ2h0IGJlIHJlY29tbWVuZGluZyBSRkMgNjA5MiBmaXJld2FsbHMg c2hvdWxkIGJlIG5vbi10cmFuc3BhcmVudCBieSBkZWZhdWx0Lg0KICAqICAgSSd2ZSBhbHNvIGdv dCBwcm9ibGVtcyB3aXRoIHJlY29tbWVuZGluZyBSRkMgNjA5MiBmaXJld2FsbHMgd2l0aG91dCBl eHByZXNzbHkgY2F1dGlvbmluZyB0aGF0IElFVEYgdGFrZXMgbm8gcG9zaXRpb24gb24gd2hldGhl ciB0aGV5IHNob3VsZCBiZSB0cmFuc3BhcmVudCBieSBkZWZhdWx0Lg0KICAqICAgSSdtIHNsaWdo dGx5IGFubm95ZWQgd2hlbmV2ZXIgUkZDIDYwOTIgZmlyZXdhbGxzIGFyZSBldmVuIHJlY29tbWVu ZGVkIGF0IGFsbCwgYnV0IEkgY2FuIGdldCBvdmVyIHRoYXQgd2l0aCBzdHJvbmcgZW5vdWdoIGJl ZXIuDQoNCk9uIFdlZCwgRmViIDExLCAyMDE1IGF0IDEwOjM5IFBNLCA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3Rl Og0KSGkgSmFtZXMsDQoNClRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGlzIHBvaW50IGFzIGl0IGhl bHBzIHRvIGNsYXJpZnkgYSBjb25mdXNpb24uDQoNClRoaXMgZG9jdW1lbnQgRE9FUyBOT1QgUkVD T01NRU5UIFJGQzYwOTIgZm9yIHRldGhlcmVkIGhvc3RzLg0KDQpJIGd1ZXNzIHlvdSBhcmUgcmVm ZXJyaW5nIHRvIHRoaXMgaXRlbToNCg0KICAgTF9SRUMjMjogIFRoZSBjZWxsdWxhciBDUEUgbXVz dCBiZSBjb21wbGlhbnQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgc3BlY2lm aWVkIGluIFtSRkM3MDg0PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwODQ+XS4NCg0K ICAgICAgICAgICAgICAgIFRoZXJlIGFyZSBzZXZlcmFsIGRlcGxveW1lbnRzLCBwYXJ0aWN1bGFy bHkgaW4gZW1lcmdpbmcNCiAgICAgICAgICAgICAgICBjb3VudHJpZXMsIHRoYXQgcmVsaWVzIG9u IG1vYmlsZSBuZXR3b3JrcyB0byBwcm92aWRlDQogICAgICAgICAgICAgICAgYnJvYWRiYW5kIHNl cnZpY2VzIChlLmcuLCBjdXN0b21lcnMgYXJlIHByb3ZpZGVkIHdpdGgNCiAgICAgICAgICAgICAg ICBtb2JpbGUgQ1BFcykuDQoNCiAgICAgICAgICAgICAgICBOb3RlLCB0aGlzIHByb2ZpbGUgZG9l cyBub3QgcmVxdWlyZSBJUHY0IHNlcnZpY2UNCiAgICAgICAgICAgICAgICBjb250aW51aXR5IHRl Y2huaXF1ZXMgbGlzdGVkIGluIFtSRkM3MDg0PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzcwODQ+XSBiZWNhdXNlIHRob3NlDQogICAgICAgICAgICAgICAgYXJlIHNwZWNpZmljIHRvIGZp eGVkIG5ldHdvcmtzLiAgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkNCiAgICAgICAgICAgICAgICB0 ZWNobmlxdWVzIHNwZWNpZmljIHRvIHRoZSBtb2JpbGUgbmV0d29ya3MgYXJlIGluY2x1ZGVkDQog ICAgICAgICAgICAgICAgaW4gdGhpcyBwcm9maWxlLg0KDQpUaGlzIGlzIGFib3V0IGNlbGx1bGFy ICoqIENQRSAqKiBub3QgdGV0aGVyZWQgZGV2aWNlcyAoWW91IG1heSBub3RpY2VkIHRoYXQgdGhp cyBpdGVtIHVzZWQgZXhwbGljaXRseSDigJxjZWxsdWxhciBDUEXigJ0gd2hpbGUgb3RoZXIgaXRl bXMgaW4gdGhpcyBzZWN0aW9uIHVzZXMg4oCcY2VsbHVsYXIgZGV2aWNl4oCdKS4gUkZDNzA4NCBp cyByZXF1aXJlZCBmb3IgdGhpcyBjYXNlIHRvIGVuc3VyZSBhIGZ1bmN0aW9uYWwgcGFyaXR5IHdp dGggZml4ZWQgQ1BFcy4NCg0KQlRXLCB0aGUgdGV4dCB5b3Ugc3VnZ2VzdGVkIGFib3V0IFJGQzYw OTIgaXMgaW4gdGhlIGRyYWZ0Og0KDQoNCiAgIEluIHRoZSBjYXNlIG9mIGNlbGx1bGFyIGRldmlj ZXMgdGhhdCBwcm92aWRlIExBTiBmZWF0dXJlcywgY29tcGxpYW5jZQ0KDQogICB3aXRoIExfUkVD IzIgZW50YWlscyBjb21wbGlhbmNlIHdpdGggW1JGQzcwODQ8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzA4ND5dLCB3aGljaCBpbiB0dXJuDQoNCiAgIHJlY29tbWVuZHMgY29tcGxpYW5j ZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmlsaXRpZXMNCg0KICAgaW4g Q3VzdG9tZXIgUHJlbWlzZXMgRXF1aXBtZW50IChDUEUpIGZvciBQcm92aWRpbmcgUmVzaWRlbnRp YWwgSVB2Ng0KDQogICBJbnRlcm5ldCBTZXJ2aWNlIFtSRkM2MDkyPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzYwOTI+XS4gIFRoZXJlZm9yZSwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zDQoNCiAgIGluIFNlY3Rpb24gNiBvZiBbUkZDNjA5Ml08aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjA5MiNzZWN0aW9uLTY+IGFyZSByZWxldmFudC4gIEluIHBhcnRpY3VsYXIsIGl0 IGJlYXJzDQoNCiAgIHJlcGVhdGluZyBoZXJlIHRoYXQgdGhlIHRydWUgaW1wYWN0IG9mIHN0YXRl ZnVsIGZpbHRlcmluZyBtYXkgYmUgYQ0KDQogICByZWR1Y3Rpb24gaW4gc2VjdXJpdHksIGFuZCB0 aGF0IElFVEYgbWFrZSBubyBzdGF0ZW1lbnQsIGV4cHJlc3NlZCBvcg0KDQogICBpbXBsaWVkLCBh cyB0byB3aGV0aGVyIHVzaW5nIHRoZSBjYXBhYmlsaXRpZXMgZGVzY3JpYmVkIGluIGFueSBvZg0K DQogICB0aGVzZSBkb2N1bWVudHMgdWx0aW1hdGVseSBpbXByb3ZlcyBzZWN1cml0eSBmb3IgYW55 IGluZGl2aWR1YWwgdXNlcnMNCg0KICAgb3IgZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkgYXMg YSB3aG9sZS4NCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYSBtb2JpbGUgQ1BFIHNob3VsZCBu b3QgaGF2ZSB0aGUgc2FtZSBmdW5jdGlvbmFsaXRpZXMgYXMgdGhlIGZpeGVkIG9uZSwgYW5kIHRo ZXJlZm9yZSBSRkM3MDg0IHNob3VsZCBub3QgYmUgY2l0ZWQgaW4gdGhpcyBJLUQ/IE9yIHlvdSBh cmUgc3VnZ2VzdGluZyB0aGF0IFJGQzcwODQgaXMgaGFybWZ1bD8NCg0KVGhhbmsgeW91Lg0KDQpD aGVlcnMsDQpNZWQNCg0KRGUgOiBKYW1lcyBXb29keWF0dCBbbWFpbHRvOmpod0BuZXN0bGFicy5j b208bWFpbHRvOmpod0BuZXN0bGFicy5jb20+XQ0KRW52b3nDqSA6IG1lcmNyZWRpIDExIGbDqXZy aWVyIDIwMTUgMTg6NTENCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBJUHY2 IE9wcyBXRw0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZp Y2UtcHJvZmlsZSBsYXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBXZWQsIEZlYiAx MSwgMjAxNSBhdCA0OjA5IEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KDQpXaGljaCBpdGVtcyBhcmUg bm90IHRlY2huaWNhbGx5IGp1c3RpZmllZD8NCg0KT3RoZXJzIG1heSBoYXZlIG90aGVyIGl0ZW1z IHRoYXQgYnVnIHRoZW0sIGFuZCBhZGRpdGlvbmFsIGl0ZW1zIG1heSBzcHJpbmcgdG8gbXkgbWlu ZCBsYXRlciBpZiBJIHB1dCBteSBtaW5kIHRvIGl0LCBidXQgSSBzZWUgbm8gdGVjaG5pY2FsIGp1 c3RpZmljYXRpb24gdG8gcmVjb21tZW5kIGEgc2ltcGxlIGZpcmV3YWxsIGJ5IGRlZmF1bHQgZm9y IHRldGhlcmVkIGhvc3RzIGFjY29yZGluZyB0byBSRkMgNjA5Mi4gSSBjb25zaWRlciB0aGF0IHJl Y29tbWVuZGF0aW9uIHRvIGJlIGFjdGl2ZWx5IGhhcm1mdWwuDQoNCg0KLS0NCmphbWVzIHdvb2R5 YXR0IDxqaHdAbmVzdGxhYnMuY29tPG1haWx0bzpqaHdAbmVzdGxhYnMuY29tPj4NCk5lc3QgTGFi cywgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcNCg0KDQoNCi0tDQpqYW1lcyB3b29keWF0dCA8 amh3QG5lc3RsYWJzLmNvbTxtYWlsdG86amh3QG5lc3RsYWJzLmNvbT4+DQpOZXN0IExhYnMsIENv bW11bmljYXRpb25zIEVuZ2luZWVyaW5nDQo= --_000_787AE7BB302AE849A7480A190F8B93300490A7FFOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QcmZvcm1h dEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjEyOTAwOTExMjk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03MTY5NDc4 NjI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4 OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SGkgSmFtZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFtZXMg V29vZHlhdHQgW21haWx0bzpqaHdAbmVzdGxhYnMuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNw Ozo8L2I+IGpldWRpIDEyIGbDqXZyaWVyIDIwMTUgMjA6MTQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+ IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IElQdjYgT3Bz IFdHPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3Bz LW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90O2hhcm1mdWxseSBicm9hZCZx dW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nci4gQm91Y2FkYWly 4oCUPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRo ZXJlIGlzIGEgcHJvYmxlbS4gVGhlIGRyYWZ0IHNlZW1zIHRvIGNvbmZsYXRlIHRoZSBiZWhhdmlv ciBvZiByZXNpZGVudGlhbCBicm9hZGJhbmQgQ1BFIGdhdGV3YXlzIHdpdGggM0dQUCByYWRpb3Mg YW5kIG1vYmlsZSB0ZWxlcGhvbnkgaGFuZHNldHMgd2l0aCB0ZXRoZXJpbmcgaW50ZXJmYWNlcy48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBOby4gVGhlIHJlY29tbWVuZGF0aW9uIGlzIGFib3V0 IOKAnG1vYmlsZSBDUEXigJ0gdXNlZCBpbiB2YXJpb3VzIGRlcGxveW1lbnQgdG8gcHJvdmlkZSBi cm9hZGJhbmQgc2VydmljZXMuIEFuIGV4YW1wbGUgY2FuIGJlIGZvdW5kIGhlcmUgKDxhIGhyZWY9 Imh0dHA6Ly93d3cub3JhbmdlLnRuL2ZpeGUtZXQtaW50ZXJuZXQvcGlkMzgyLWxhLWZseWJveC1v cmFuZ2UuaHRtbCI+aHR0cDovL3d3dy5vcmFuZ2UudG4vZml4ZS1ldC1pbnRlcm5ldC9waWQzODIt bGEtZmx5Ym94LW9yYW5nZS5odG1sPC9hPikuDQogRXhjZXB0IHRoZSBhY2Nlc3MgdGVjaG5vbG9n eSwgc2VydmljZXMgb2ZmZXJlZCB1c2luZyB0aGVzZSBDUEUgYXJlIHRoZSBzYW1lIGFzIGFueSBm aXhlZCBDUEUuIFBsZWFzZSBsZXQgbWUgcmVpdGVyYXRlIHRoZSBmb2xsb3dpbmc6IHRoaXMgZHJh ZnQgZG9lcyBub3QgcmVjb21tZW5kIHRoZSBzdXBwb3J0IG9mIFJGQzcwODQgZm9yIGV2ZXJ5IOKA nDNHUFAgcmFkaW9zIGFuZCBtb2JpbGUgdGVsZXBob255IGhhbmRzZXRzIHdpdGggdGV0aGVyaW5n IGludGVyZmFjZXPigJ0uDQogSSBhZGRlZCBhIENBVVRJT04gdGV4dCBpbiB0aGUgbGF0ZXN0IHZl cnNpb24gdG8gbWFrZSB0aGlzIGNsZWFyOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENBVVRJT046IFRoaXMg cmVjb21tZW5kYXRpb24gZG9lcyBub3QgYXBwbHkgdG8gYW55PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2VsbHVsYXIgZGV2aWNlIHdpdGggTEFOIGNhcGFiaWxp dGllczsgaXQgaXMgc3BlY2lmaWMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtjZWxsdWxhciBDUEVzIGluIG9yZGVyIHRvIGVuc3VyZSB0aGUgc2FtZSBJUHY2 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnVuY3Rpb25hbCBw YXJpdHkgZm9yIGJvdGggZml4ZWQgYW5kIGNlbGx1bGFyIENQRXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRlbmQgbm90 IHRvIGZpZ2h0IHRvbyBoYXJkIGFnYWluc3QgUkZDIDYwOTIgaW4gcmVzaWRlbnRpYWwgZ2F0ZXdh eSBzY2VuYXJpb3MsIGJ1dCBJJ3ZlIGFsd2F5cyBiZWVuIG9wcG9zZWQgdG8gc2VlaW5nIHRob3Nl IHJlY29tbWVuZGF0aW9ucyBhcHBsaWVkIG1vcmUgd2lkZWx5LCBlc3BlY2lhbGx5IGlmIGl0IHNl ZW1z4oCUIGxpa2UgaXQgZG9lcyBpbiB0aGlzIGNhc2XigJQgdGhhdA0KIHRoZSByZWNvbW1lbmRh dGlvbiBpcyBiZWluZyBtYWRlIG91dCBvZiByb3RlIHJlcGV0aXRpb24gcmF0aGVyIHRoYW4gYnkg Y2FyZWZ1bCB0ZWNobmljYWwgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSXQgaXMgbm90IGFib3V0IHJlcGV0aXRp b24gYnV0IGFib3V0IGEgdGVjaG5pY2FsIHN0cmF0ZWd5IHRoYXQgYWltcyB0byBlbnN1cmUgdGhl IHNhbWUgZnVuY3Rpb25hbCBwYXJpdHkgd2hhdGV2ZXIgdGhlIGFjY2VzcyB0ZWNobm9sb2d5IHVz ZWQgdG8gc2VydmljZQ0KIGEgY3VzdG9tZXIuIFRoaXMgaXMga2V5IGZvciBtb2JpbGUtZml4ZSBj b252ZXJnZW5jZSwgbXV0dWFsaXppbmcgY29kZSwgZW5naW5lZXJpbmcgcHJhY3RpY2VzLCBzZXJ2 aWNlIGRlc2lnbiBhbmQgb3BlcmF0aW9ucywgYW5kIG1vcmUgaW1wb3J0YW50IHRlc3RpbmcgYW5k IHZhbGlkYXRpb24gcmVzb3VyY2VzIGFuZCBlZmZvcnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGxlYXNlIGZvcmdpdmUgdGhpcyBkaWdyZXNzaW9uOiBJIGhhdmUgKm5ldmVyKiB3 YXZlcmVkIGluIG15IG9wcG9zaXRpb24gdG8gYW55IHJlY29tbWVuZGF0aW9uIG9yIHNwZWNpZmlj YXRpb24gdGhhdCBjYWxscyBmb3IgdW5tYW5hZ2VkIG5ldHdvcmsgbGF5ZXIgZ2F0ZXdheXMgdG8g YmxvY2sgdW5zb2xpY2l0ZWQgaW5ib3VuZCB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MgYnkgZGVmYXVs dC4gSSBoYXZlIGFsd2F5cw0KIHByZWZlcnJlZCBleHBsaWNpdCByZWNvbW1lbmRhdGlvbnMgdG8g bGVhdmUgUkZDIDYwOTIgZmlsdGVyaW5nIHRyYW5zcGFyZW5jeSBtb2RlIGJ5IGRlZmF1bHQsIGFu ZCB0byByZXF1aXJlIGFuIGF1dGhvcml6ZWQgaHVtYW4gdG8gJnF1b3Q7b3B0IGludG8mcXVvdDsg dGhlIGJsb2NraW5nIG9mIGluYm91bmQgZmxvd3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSBJ4oCZbSBwZXJzb25hbGx5IHdpdGggdHJhbnNwYXJlbnQgbW9kZSBzZXQgYnkg ZGVmYXVsdC4gSWYgdGhlcmUgaXMgbm8gb2JqZWN0aW9uIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAs IHRoaXMgY2FuIGJlIGFkZGVkIHVuZGVyIHNlY3VyaXR5IHNlY3Rpb24uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBSRkMgNjA5MiBjb250YWlucyBubyBzdWNoIGEgcmVjb21t ZW5kYXRpb24uIFRvIG15IGV2ZXJsYXN0aW5nIHNoYW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIEkgd2FzIHRoZSB0ZWNobmlj YWwgZWRpdG9yIGZvciBSRkMgNjA5MiwgYW5kIEkgd2FzIGNvbmNlcm5lZCBhYm91dCBjb25kdWN0 aW5nIG15c2VsZiBpbiB0aGF0IHJvbGUgd2l0aCBlcXVhbmltaXR5IGFuZCBmYWlybmVzcywgSSB3 YXMgZ3J1ZGdpbmdseSB3aWxsaW5nIHRvIHN1c3BlbmQgbXkgb2JqZWN0aW9ucyBvbiB0aGlzIHRv cGljIHdoZW4gdGhlIHdvcmtpbmcgZ3JvdXAgc2V0dGxlZCBvbiBsYW5ndWFnZQ0KIHRoYXQgZXhw cmVzc2x5IG1ha2VzIG5vIHJlY29tbWVuZGF0aW9uIG9uIHdoZXRoZXIgdHJhbnNwYXJlbmN5IHNo b3VsZCBvciBzaG91bGQgbm90IHRoZSBkZWZhdWx0LiBUaGF0IHNlZW1lZCB0byByZWZsZWN0IGNv bnNlbnN1cyBhdCB0aGUgdGltZS4gSWYgSSBoYWQgbm90IGJlZW4gdGhlIHRlY2huaWNhbCBlZGl0 b3IgZm9yIHRoYXQgZG9jdW1lbnQsIHRoZW4gSSB3b3VsZCBoYXZlIG1vcmUgdmlnb3JvdXNseSBl eHByZXNzZWQgbXkgcGVyc29uYWwNCiBvYmplY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBhIHBlcnNvbmFsIGxldmVsLCBJJ20g bm8gbG9uZ2VyIHN1cmUgaXQncyBiZXR0ZXIgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgY2FyZWZ1 bGx5IGRlc2NyaWJlcyB0aGUgYmVoYXZpb3Igb2YgdGhlc2UgdWJpcXVpdG91cyBhbmQgaGFybWZ1 bCBmaXJld2FsbHMgdGhhbiB0byBoYXZlIHRoZW0gZ28gdW5kb2N1bWVudGVkIGFzIHdhcyB0aGUg Y2FzZSB3aXRoIElQdjQvTkFUIGZpcmV3YWxscy4gSSBoYXZlbid0DQogeWV0IGNvbWUgdG8gcmVn cmV0IHdpdGhob2xkaW5nIG15IHBlcnNvbmFsIG9iamVjdGlvbnMgdG8gUkZDIDYwOTIsIGJ1dCBJ IHNvbWV0aW1lcyBmaW5kIHRoYXQgc3Ryb25nIGJlZXIgY2FuIGR1bGwgdGhlIHBhaW4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBZb3UgY2FuIHRyeSBhbiBvcmFuZ2UganVp Y2UgdG9vIDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JICp3YXMqIG9wcG9zZWQg dG8gUkZDIDcwODQgKGFuZCBpdHMgcHJlZGVjZXNzb3IpIGJlY2F1c2UgaXQgZGlkIG5vdCB0YWtl IHRoZSB2aWV3IHRoYXQgUkZDIDYwOTIgZmlyZXdhbGwgY2FwYWJpbGl0eSBTSE9VTEQgYmUgc2V0 IGZvciB0cmFuc3BhcmVuY3kgYnkgZGVmYXVsdC4gSSBkaWRuJ3Qgd2luIHRoYXQgYXJndW1lbnQs IGFuZCBJIGV4cGVjdCBJIHdpbGwgbG9zZSBpdCBhZ2FpbiBpbiB0aGUgY29udGV4dA0KIG9mIHRo aXMgZHJhZnTigJQgd2hpY2ggSSBvcHBvc2UgZm9yIG90aGVyIHJlYXNvbnMgYXMgd2VsbCwgYnV0 IHRoaXMgaXMgdGhlIG9uZSB0aGF0IGFuaW1hdGVzIG1lIGJlZm9yZSB0aGUgb3RoZXJzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SSdtIGVzcGVjaWFsbHkgY29uY2VybmVkIHRoYXQgSS1ELmlldGYtdjZvcHMt bW9iaWxlLWRldmljZS1wcm9maWxlIHNlZW1zIHRvIGJlIHRvbyBlYXNpbHkgcmVhZCB0byByZWNv bW1lbmQgdGhlIGFwcGxpY2F0aW9uIG9mIFJGQyA2MDkyIGZpcmV3YWxscyBpbnNpZGUgbW9iaWxl IHRlbGVwaG9ueSBoYW5kc2V0cyBmb3IgdGV0aGVyZWQgdXNlcnMuDQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+W01lZF0gQXMgSSBleHBsYWluZWQgYWJvdmUgdGhpcyBpcyBub3QgdGhlIGlu dGVudC4gSSBhZGRlZCBhIENBVVRJT04gZm9yIHRoYXQgcHVycG9zZSBidXQgaWYgeW91IHN0aWxs IHRoaW5rIHRoZXJlIGlzIHN0aWxsIGEgcmlzaywgSSBjYW4gY2hlY2sgaG93IGJldHRlcg0KIHRv IGFkZHJlc3MgeW91ciBpc3N1ZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhhdCdzIGFuIGV4cGFuc2lvbiBvZiB0aGUgc2NvcGUgaW50ZW5kZWQgZm9yIFJGQyA2MDkyIGJl eW9uZCB0aGUgdXNhZ2UgY2FzZSBvZiByZXNpZGVudGlhbCBnYXRld2F5cywgYW5kIEkgcmVhbGx5 IHdvdWxkbid0IGxpa2UgdG8gc2VlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFRoZXJlIGlzIG5vIGV4cGFuc2lvbiBvZiB0aGUg c2NvcGU6IGEgY2VsbHVsYXIgQ1BFIGlzIGEgZmxhdm9yIG9mIHJlc2lkZW50aWFsIGdhdGV3YXkg aW4gcGFydCBvZiBhIGNvdW50cnkgd2hlcmUgZml4ZWQgaW5mcmFzdHJ1Y3R1cmUgaXMgaW5leGlz dGVudA0KIG9yIGluZWZmaWNpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG9y dGVyIGphbWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJJ3Zl IGdvdCBCSUcgcHJvYmxlbXMgcmVjb21tZW5kaW5nIFJGQyA2MDkyIGZpcmV3YWxscyBmb3IgbW9i aWxlIHRlbGVwaG9ueSBoYW5kc2V0cyB3aXRoIHRldGhlcmVkIGhvc3RzLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkkndmUg Z290IEJJRyBwcm9ibGVtcyB3aGVuZXZlciBpdCBldmVuIGxvb2tzIGxpa2UgSUVURiBtaWdodCBi ZSByZWNvbW1lbmRpbmcgUkZDIDYwOTIgZmlyZXdhbGxzIHNob3VsZCBiZSBub24tdHJhbnNwYXJl bnQgYnkgZGVmYXVsdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJJ3ZlIGFsc28gZ290IHByb2JsZW1zIHdpdGggcmVjb21t ZW5kaW5nIFJGQyA2MDkyIGZpcmV3YWxscyB3aXRob3V0IGV4cHJlc3NseSBjYXV0aW9uaW5nIHRo YXQgSUVURiB0YWtlcyBubyBwb3NpdGlvbiBvbiB3aGV0aGVyIHRoZXkgc2hvdWxkIGJlIHRyYW5z cGFyZW50IGJ5IGRlZmF1bHQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSSdtIHNsaWdodGx5IGFubm95ZWQgd2hlbmV2ZXIg UkZDIDYwOTIgZmlyZXdhbGxzIGFyZSBldmVuIHJlY29tbWVuZGVkIGF0IGFsbCwgYnV0IEkgY2Fu IGdldCBvdmVyIHRoYXQgd2l0aCBzdHJvbmcgZW5vdWdoIGJlZXIuPG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDEx LCAyMDE1IGF0IDEwOjM5IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBKYW1lcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo YW5rIHlvdSBmb3IgcmFpc2luZyB0aGlzIHBvaW50IGFzIGl0IGhlbHBzIHRvIGNsYXJpZnkgYSBj b25mdXNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGlzIGRvY3VtZW50IERPRVMgTk9UIFJFQ09NTUVOVCBSRkM2MDkyIGZvciB0ZXRo ZXJlZCBob3N0cy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+SSBndWVzcyB5b3UgYXJlIHJlZmVycmluZyB0byB0aGlzIGl0ZW06DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBMX1JF QyMyOiZuYnNwOyBUaGUgY2VsbHVsYXIgQ1BFIG11c3QgYmUgY29tcGxpYW50IHdpdGggdGhlIHJl cXVpcmVtZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWVkIGluIFs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwODQi IHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7QmFzaWMgUmVxdWlyZW1lbnRzIGZvciBJUHY2 IEN1c3RvbWVyIEVkZ2UgUm91dGVycyZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzcwODQ8 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUg YXJlIHNldmVyYWwgZGVwbG95bWVudHMsIHBhcnRpY3VsYXJseSBpbiBlbWVyZ2luZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY291bnRyaWVzLCB0aGF0IHJl bGllcyBvbiBtb2JpbGUgbmV0d29ya3MgdG8gcHJvdmlkZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnJvYWRiYW5kIHNlcnZpY2VzIChlLmcuLCBjdXN0b21l cnMgYXJlIHByb3ZpZGVkIHdpdGg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG1vYmlsZSBDUEVzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb3RlLCB0aGlzIHByb2ZpbGUgZG9lcyBu b3QgcmVxdWlyZSBJUHY0IHNlcnZpY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbnRpbnVpdHkgdGVjaG5pcXVlcyBsaXN0ZWQgaW4gWzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA4NCIgdGFyZ2V0 PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9t ZXIgRWRnZSBSb3V0ZXJzJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNzA4NDwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XQ0KIGJlY2F1c2UgdGhvc2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSBzcGVjaWZpYyB0byBm aXhlZCBuZXR3b3Jrcy4mbmJzcDsgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRlY2huaXF1ZXMgc3BlY2lmaWMgdG8g dGhlIG1vYmlsZSBuZXR3b3JrcyBhcmUgaW5jbHVkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHRoaXMgcHJvZmlsZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgaXMgYWJvdXQgY2VsbHVs YXIgKiogQ1BFICoqIG5vdCB0ZXRoZXJlZCBkZXZpY2VzIChZb3UgbWF5IG5vdGljZWQgdGhhdCB0 aGlzIGl0ZW0gdXNlZCBleHBsaWNpdGx5DQog4oCcY2VsbHVsYXIgQ1BF4oCdIHdoaWxlIG90aGVy IGl0ZW1zIGluIHRoaXMgc2VjdGlvbiB1c2VzIOKAnGNlbGx1bGFyIGRldmljZeKAnSkuIFJGQzcw ODQgaXMgcmVxdWlyZWQgZm9yIHRoaXMgY2FzZSB0byBlbnN1cmUgYSBmdW5jdGlvbmFsIHBhcml0 eSB3aXRoIGZpeGVkIENQRXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5CVFcsIHRoZSB0ZXh0IHlvdSBzdWdnZXN0ZWQgYWJvdXQgUkZDNjA5 MiBpcyBpbiB0aGUgZHJhZnQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBJbiB0 aGUgY2FzZSBvZiBjZWxsdWxhciBkZXZpY2VzIHRoYXQgcHJvdmlkZSBMQU4gZmVhdHVyZXMsIGNv bXBsaWFuY2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyB3aXRoIExfUkVDIzIgZW50YWlscyBjb21wbGlhbmNlIHdpdGggWzwvc3Bh bj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDg0IiB0YXJnZXQ9Il9i bGFuayIgdGl0bGU9IiZxdW90O0Jhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lciBF ZGdlIFJvdXRlcnMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDg0PC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+XSwgd2hpY2ggaW4gdHVybjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHJlY29tbWVuZHMgY29tcGxp YW5jZSB3aXRoIFJlY29tbWVuZGVkIFNpbXBsZSBTZWN1cml0eSBDYXBhYmlsaXRpZXM8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBp biBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1lbnQgKENQRSkgZm9yIFByb3ZpZGluZyBSZXNpZGVu dGlhbCBJUHY2PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsgSW50ZXJuZXQgU2VydmljZSBbPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYwOTIiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7 UmVjb21tZW5kZWQgU2ltcGxlIFNlY3VyaXR5IENhcGFiaWxpdGllcyBpbiBDdXN0b21lciBQcmVt aXNlcyBFcXVpcG1lbnQgKENQRSkgZm9yIFByb3ZpZGluZyBSZXNpZGVudGlhbCBJUHY2IEludGVy bmV0IFNlcnZpY2UmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM2MDkyPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+XS4mbmJzcDsgVGhlcmVmb3JlLCB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDtpbiA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjA5MiNzZWN0aW9uLTYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ U2VjdGlvbiZuYnNwOzYgb2YgW1JGQzYwOTJdPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+ IGFyZSByZWxldmFudC4mbmJzcDsgSW4gcGFydGljdWxhciwgaXQgYmVhcnM8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyByZXBlYXRp bmcgaGVyZSB0aGF0IHRoZSB0cnVlIGltcGFjdCBvZiBzdGF0ZWZ1bCBmaWx0ZXJpbmcgbWF5IGJl IGE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyByZWR1Y3Rpb24gaW4gc2VjdXJpdHksIGFuZCB0aGF0IElFVEYgbWFrZSBubyBzdGF0 ZW1lbnQsIGV4cHJlc3NlZCBvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGltcGxpZWQsIGFzIHRvIHdoZXRoZXIgdXNpbmcgdGhl IGNhcGFiaWxpdGllcyBkZXNjcmliZWQgaW4gYW55IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdGhlc2UgZG9jdW1lbnRzIHVs dGltYXRlbHkgaW1wcm92ZXMgc2VjdXJpdHkgZm9yIGFueSBpbmRpdmlkdWFsIHVzZXJzPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg b3IgZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkgYXMgYSB3aG9sZS48L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXJlIHlvdSBzdWdnZXN0 aW5nIHRoYXQgYSBtb2JpbGUgQ1BFIHNob3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBmdW5jdGlvbmFs aXRpZXMgYXMgdGhlIGZpeGVkIG9uZSwNCiBhbmQgdGhlcmVmb3JlIFJGQzcwODQgc2hvdWxkIG5v dCBiZSBjaXRlZCBpbiB0aGlzIEktRD8gT3IgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgUkZDNzA4 NCBpcyBoYXJtZnVsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+VGhhbmsgeW91Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJz cDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbWVzIFdvb2R5YXR0 IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20iIHRhcmdldD0iX2JsYW5r Ij5qaHdAbmVzdGxhYnMuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJj cmVkaSAxMSBmw6l2cmllciAyMDE1IDE4OjUxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBJUHY2IE9wcyBXRzxicj4N CjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUt ZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIEZlYiAxMSwgMjAxNSBhdCA0OjA5IEFNLCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGljaCBpdGVtcyBhcmUgbm90IHRlY2hu aWNhbGx5IGp1c3RpZmllZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk90aGVycyBtYXkgaGF2ZSBvdGhlciBp dGVtcyB0aGF0IGJ1ZyB0aGVtLCBhbmQgYWRkaXRpb25hbCBpdGVtcyBtYXkgc3ByaW5nIHRvIG15 IG1pbmQgbGF0ZXIgaWYgSSBwdXQgbXkgbWluZCB0byBpdCwgYnV0IEkgc2VlIG5vIHRlY2huaWNh bCBqdXN0aWZpY2F0aW9uIHRvIHJlY29tbWVuZCBhIHNpbXBsZSBmaXJld2FsbA0KIGJ5IGRlZmF1 bHQgZm9yIHRldGhlcmVkIGhvc3RzIGFjY29yZGluZyB0byBSRkMgNjA5Mi4gSSBjb25zaWRlciB0 aGF0IHJlY29tbWVuZGF0aW9uIHRvIGJlIGFjdGl2ZWx5IGhhcm1mdWwuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5qYW1lcyB3b29k eWF0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20iIHRhcmdldD0iX2JsYW5r Ij5qaHdAbmVzdGxhYnMuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk5lc3QgTGFicywgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmc8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5qYW1lcyB3b29keWF0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20i IHRhcmdldD0iX2JsYW5rIj5qaHdAbmVzdGxhYnMuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXN0IExhYnMsIENvbW11bmljYXRpb25zIEVu Z2luZWVyaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300490A7FFOPEXCLILM23corp_-- From nobody Fri Feb 13 00:46:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290B51A00BF for ; Fri, 13 Feb 2015 00:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqfKaJ2oq6q7 for ; Fri, 13 Feb 2015 00:46:03 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id E01F01A1B5C for ; Fri, 13 Feb 2015 00:46:02 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 13 Feb 2015 02:46:01 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f182.google.com [209.85.213.182] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f182.google.com with SMTP id h15so9309779igd.3 for ; Fri, 13 Feb 2015 00:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to; bh=BTSTv2M39BITYJSUY9Fgke2n0PMpvGViaDLF0An1Epg=; b=l0vvlsVpQ+fXy+3GHNOllx38aoMraQV4qbFFwmf74wE0Tqvg4utRyYp100dssr1kED FJ5H0isHDXfcDGba3NUnLdWZy8SwQ2UlTZsyojcdPf3OZQn0qZ2AvN9Jan3FAFCqDzzt NmikYCtZRxFEtSMfEb8RqtdN+UUhl55eEt04c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:from:subject:date:to; bh=BTSTv2M39BITYJSUY9Fgke2n0PMpvGViaDLF0An1Epg=; b=l5TmRs9ey5uxDKy4BgWPqW42MNwZsTYcPlrksj12jfXHMqmeYWW2GtpgXlDoenDPvi 5mYPxfyFKRDcyY2RkQRzHVrdT8R/zTsUXKVlXzGV1ec2YT8yTH6nYVmpyiEZr8xHoe1z /rI6Vgaikhtg3Vz+u6VysIdQgJtvP3KYOhyIUb7N/Ci6SnXXgXTEQEHGLzOWKIrYLybZ PVhT9hvddHGzQXYtTxz/U+wCGwydf0Ae+SY5VUWzNyTy75pq92U4odaxl7ke4kGA4WnC MTHgpIYZRYYy3o0q3yqj1BQIE5NfLxq/l33wUlx/rQ6V/SFVWwWAVguvHgmE7P+bAxOk VHZw== X-Gm-Message-State: ALoCoQkABi6WSsmQyouILzed1aicNwc0XpTGBZxiTmVIJho1XcctaSe8tSRPfg9aBvjBWIBhWPdKVdXvWpgQmRSJpUr711SfzoIzKUngNBwCq9GYNQQN9x6NSi/X8m+MY7N7HWS1ZEb2 X-Received: by 10.42.79.76 with SMTP id q12mr1922465ick.16.1423817161244; Fri, 13 Feb 2015 00:46:01 -0800 (PST) X-Received: by 10.42.79.76 with SMTP id q12mr1922455ick.16.1423817161095; Fri, 13 Feb 2015 00:46:01 -0800 (PST) Received: from ?IPv6:2601:2:5b00:a9f:287a:168f:ef00:e809? ([2601:2:5b00:a9f:287a:168f:ef00:e809]) by mx.google.com with ESMTPSA id vk4sm2881096igc.11.2015.02.13.00.45.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 00:46:00 -0800 (PST) References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> In-Reply-To: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-6EFD3D70-3E97-4AF0-B707-61AA41E40887 Message-Id: <5E9ECF06-885F-479A-B76D-2AE6A8B7814D@umn.edu> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (12B466) From: David Farmer Date: Fri, 13 Feb 2015 02:45:57 -0600 To: "v6ops@ietf.org" Archived-At: Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:46:07 -0000 --Apple-Mail-6EFD3D70-3E97-4AF0-B707-61AA41E40887 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Feb 11, 2015, at 04:47, fred@cisco.com wrote: >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6op= s-cidr-prefix. Please take a look at it and comment. I support the draft. However, I have some suggested improvements for the cu= rrent text. 1. I'm worried as phrased, section 1, paragraph 3 could be misinterpreted a= s implying a /64 is a valid end-site prefix. A detailed analysis of the 64-bit boundary in IPv6 addressing=20 together with the implication for end-site prefix assignment are=20 documented in [RFC7421], but no recommendation is included=20 in that document. Maybe just eliminate "together with the implication for end-site prefix assi= gnment", I'm not sure it's necessary or adds much to this discussion to talk= about end-site prefix assignments anyway. However, then the only thing the= paragraph says beyond what is in the first paragraph is "but no recommendat= ion is included in that document." So, how about just deleting this paragra= ph altogether and adding a version of that idea to the end of the first para= graph, maybe something like this; However, such a recommendation was out of scope for that document. 2. I'd like to see the evolution of the IPv6 Addressing Architecture discus= sed and used as part of the argument too. How about the following added as t= he second paragraph of section 1; As discussed in [RFC7421], "the notion of a /64 boundary in the=20 address was introduced after the initial design of IPv6, following a=20 period when it was expected to be at /80." This evolution of the IPv6=20= Addressing Architecture, resulting in [RFC4921], and followed with the=20= addition of /127 prefixes for point-to-point links in [RFC6164], clearly= =20 demonstrates the intent for future IPv6 protocol developments to have=20= the flexibility to change this part of the architecture when necessary=20= and justified.=20 3. I think the first paragraph of section 2 would be clearer if it said; IPv6 implementations MUST... 4. The last paragraph of section 2 makes me think of the scene from Star Wa= rs where Obi-Wan uses the Jedi mind trick on the storm troopers saying, "the= se aren't the droids you're looking for." This recommendation does not conflict with the 64-bit boundary for=20 some IPv6 stateless address autoconfiguration (SLAAC, [RFC4864])=20 based schemes such as [RFC2464]. Why doesn't it conflict? Just because we said so? How about something like= this instead; This recommendation might seem to conflict with with the 64-bit=20 boundary for some IPv6 stateless address autoconfiguration (SLAAC, [RFC4864]) based schemes such as [RFC2464]. However, [RFC7421]=20 clarifies this is only a parameter in the SLAAC process and using=20 DHCPv6 [RFC3315] or manual configuration other longer prefix lengths=20 are in operational use.=20 But does this paragraph even belong in this section? Maybe move it up into s= ection 1, as well as providing reasons why it does conflict. How about maki= ng this the second paragraph and #2 above the third paragraph of section 1. 5. Maybe additional informative references to RFC4942 and draft-ietf-opsec-= v6 would in order for the security considerations section. Only referencing= RFC4291's security considerations, which says the following, seems really k= ind of wimpy by today's standards. IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined=20 in [AUTH].=20 (AUTH =3D RFC 2402) How about; This document does not introduce security issues in addition to what=20 is discussed in [RFC4291]. Overall IPv6 security issues are more=20 completely discussed in [RFC4942] and [draft-ietf-opsec-v6]. Thanks --=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 David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-6EFD3D70-3E97-4AF0-B707-61AA41E40887 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Feb 11, 2015, at 04:47, fred@cisco.com wrote:

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-cidr-p= refix. Please take a look at it and comment.

I support the draft.  However, I have some suggested improve= ments for the current text.

1.  I'm worried as= phrased, section 1, paragraph 3 could be misinterpreted as implying a /64 i= s a valid end-site prefix.

    A detailed analysis of th=
e 64-bit boundary in IPv6 addressing 
    together with t=
he implication for end-site prefix assignment are 
<= pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; page-bre= ak-before: always;">    do= cumented in [RFC7421], but no recommendation is included = 
  &nbs=
p; in that
   document.

Maybe just elimina= te "together with t= he implication for end-site prefix assignment", I'm not sure it's necessary o= r adds much to this discussion to talk about end-site prefix assignments any= way.  However, then th= e only thing the paragraph says beyond what is in the first paragraph is "but no recommendatio= n is included in that document."  So, how about just deleting this para= graph altogether and adding a version of that idea to the end of the first p= aragraph, maybe something like this;

    Howe= ver, such a recommendation was out of scope for that document.

= 
2.  I'=
d like to see the evolution of the IPv6 Addressing Architecture discuss=
ed and used as part of the argument too.  How about the following added=
 as the second paragraph of section 1;

    As disc=
ussed in [RFC7421], "the notion of a /64 boundary in the 
&nbs=
p;   address was introduced after the initial design of IPv6, foll=
owing a 
    period when it was expected to be at /80." T=
his evolution of the IPv6 
    Addressing Architecture, r=
esulting in [RFC4921], and followed with the 
<= pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; page-bre= ak-before: always;">    ad= dition of /127 prefixes for point-to-point links in [RFC6164], cle= arly 
    demonstrates the intent for future IPv6 pro=
tocol developments to have 
    the flexibility=
 to change this part of the architecture when necessary =

    and justified. 

3.  I think the first=
 paragraph of section 2 would be clearer if it said;

<= /pre>
    IPv6 implementations MUST...

4= .  The last paragraph of section 2 makes me think of the scene from Sta= r Wars where Obi-Wan uses the Jedi mind trick on the storm troopers saying, "= these aren't the droids you're looking for."

   This rec=
ommendation does not conflict with the 64-bit boundary for 
  &=
nbsp;some IPv6 stateless address autoconfiguration (SLAAC, [RFC4864]) <=
/span>
   based schemes such as [RFC2464].

Why doesn't it conflict?  Just because we said so?  How abo=
ut something like this instead;

   This recommendatio=
n might seem to conflict with with the 64-bit 
= 
   bo=
undary for some IP=
v6 stateless address autoconfiguration (SLAAC,
   [RFC4864]) based schemes such as [RFC2464].  However, =
[RFC7421] 
   clari= fies this is only a parameter in the SLAAC process and using 
   =
DHCPv6 [RFC3315] or manual configuration other lon=
ger prefix lengths 
   are in operational use. 

But does this paragraph even belong in t=
his section?  Maybe move it up into section 1, as well as providing rea=
sons why it does conflict.  How about making this the second paragraph a=
nd #2 above the third paragraph of section 1.

5.  Maybe additional informat=
ive references to RFC4942 and draft-ietf-opsec-v6 would in order for the sec=
urity considerations section.  Only referencing RFC4291's <=
font face=3D"UICTFontTextStyleBody">security considerations=
, which says the following, seems rea=
lly kind of wimpy by today's standards.

    IPv6=
 addressing documents do not have any direct impact on Internet
  &nbs=
p; infrastructure security.  Authentication of IPv6 packets is defined =

    in [AUTH]. 
<=
font face=3D"UICTFontTextStyleBody">
(AUTH =3D RFC 2402)

=

How about;

    This doc=
ument does not introduce security issues in addition to what 
    is discussed in [RFC4291].  Overall IPv6 security issues are more 
    compl=
etely discussed in [RFC4942] and [draft-ietf-opsec-v6].

Thanks

-- <= 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
<= div>David Farmer                 &nb= sp;        Email: farm= er@umn.edu
Office of Information Technology
Universi= ty of Minnesota    
2218 University Ave SE    =     Phone: +1-612-626-0815
Minneapolis, MN 55414-3029 &= nbsp; Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D



= --Apple-Mail-6EFD3D70-3E97-4AF0-B707-61AA41E40887-- From nobody Fri Feb 13 01:15:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0C1A1B74 for ; Fri, 13 Feb 2015 01:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-KeH7SoqH0z for ; Fri, 13 Feb 2015 01:15:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8031A1BEE for ; Fri, 13 Feb 2015 01:15:33 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5F76A190642; Fri, 13 Feb 2015 10:15:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 32B0F1800CB; Fri, 13 Feb 2015 10:15:31 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 10:15:28 +0100 From: To: David Farmer Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix Thread-Index: AQHQR2mLmlM4gy1d90m2or8sao43r5zuS/Vg Date: Fri, 13 Feb 2015 09:15:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490A89A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> <5E9ECF06-885F-479A-B76D-2AE6A8B7814D@umn.edu> In-Reply-To: <5E9ECF06-885F-479A-B76D-2AE6A8B7814D@umn.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490A89AOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.70318 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 09:15:37 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490A89AOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBEYXZpZCwNCg0KVGhhbmsgeW91IGZvciB0aGVzZSBjb21tZW50cy4NCg0KSeKAmW0gT0sg d2l0aCBhbG1vc3QgYWxsIHlvdXIgZWRpdHMuDQoNCkEgbmV3IHJldmlzaW9uIHdpdGggdGhlc2Ug Y2hhbmdlcyB3aWxsIGJlIGF2YWlsYWJsZSB2ZXJ5IHNvb24uDQoNClRoYW5rIHlvdS4NCg0KQ2hl ZXJzLA0KTWVkDQoNCkRlIDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIERhdmlkIEZhcm1lcg0KRW52b3nDqSA6IHZlbmRyZWRpIDEzIGbDqXZyaWVy IDIwMTUgMDk6NDYNCsOAIDogdjZvcHNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFt2Nm9wc10gbmV3 IGRyYWZ0OiBkcmFmdC1pZXRmLXY2b3BzLWNpZHItcHJlZml4DQoNCg0KT24gRmViIDExLCAyMDE1 LCBhdCAwNDo0NywgZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPiB3cm90ZToN CkEgbmV3IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy1jaWRyLXByZWZpeC4gUGxlYXNlIHRha2UgYSBsb29rIGF0IGl0 IGFuZCBjb21tZW50Lg0KDQpJIHN1cHBvcnQgdGhlIGRyYWZ0LiAgSG93ZXZlciwgSSBoYXZlIHNv bWUgc3VnZ2VzdGVkIGltcHJvdmVtZW50cyBmb3IgdGhlIGN1cnJlbnQgdGV4dC4NCg0KMS4gIEkn bSB3b3JyaWVkIGFzIHBocmFzZWQsIHNlY3Rpb24gMSwgcGFyYWdyYXBoIDMgY291bGQgYmUgbWlz aW50ZXJwcmV0ZWQgYXMgaW1wbHlpbmcgYSAvNjQgaXMgYSB2YWxpZCBlbmQtc2l0ZSBwcmVmaXgu DQoNCg0KICAgIEEgZGV0YWlsZWQgYW5hbHlzaXMgb2YgdGhlIDY0LWJpdCBib3VuZGFyeSBpbiBJ UHY2IGFkZHJlc3NpbmcNCg0KICAgIHRvZ2V0aGVyIHdpdGggdGhlIGltcGxpY2F0aW9uIGZvciBl bmQtc2l0ZSBwcmVmaXggYXNzaWdubWVudCBhcmUNCg0KICAgIGRvY3VtZW50ZWQgaW4gW1JGQzc0 MjFdLCBidXQgbm8gcmVjb21tZW5kYXRpb24gaXMgaW5jbHVkZWQNCg0KICAgIGluIHRoYXQgZG9j dW1lbnQuDQoNCk1heWJlIGp1c3QgZWxpbWluYXRlICJ0b2dldGhlciB3aXRoIHRoZSBpbXBsaWNh dGlvbiBmb3IgZW5kLXNpdGUgcHJlZml4IGFzc2lnbm1lbnQiLCBJJ20gbm90IHN1cmUgaXQncyBu ZWNlc3Nhcnkgb3IgYWRkcyBtdWNoIHRvIHRoaXMgZGlzY3Vzc2lvbiB0byB0YWxrIGFib3V0IGVu ZC1zaXRlIHByZWZpeCBhc3NpZ25tZW50cyBhbnl3YXkuICBIb3dldmVyLCB0aGVuIHRoZSBvbmx5 IHRoaW5nIHRoZSBwYXJhZ3JhcGggc2F5cyBiZXlvbmQgd2hhdCBpcyBpbiB0aGUgZmlyc3QgcGFy YWdyYXBoIGlzICJidXQgbm8gcmVjb21tZW5kYXRpb24gaXMgaW5jbHVkZWQgaW4gdGhhdCBkb2N1 bWVudC4iICBTbywgaG93IGFib3V0IGp1c3QgZGVsZXRpbmcgdGhpcyBwYXJhZ3JhcGggYWx0b2dl dGhlciBhbmQgYWRkaW5nIGEgdmVyc2lvbiBvZiB0aGF0IGlkZWEgdG8gdGhlIGVuZCBvZiB0aGUg Zmlyc3QgcGFyYWdyYXBoLCBtYXliZSBzb21ldGhpbmcgbGlrZSB0aGlzOw0KDQoNCiAgICBIb3dl dmVyLCBzdWNoIGEgcmVjb21tZW5kYXRpb24gd2FzIG91dCBvZiBzY29wZSBmb3IgdGhhdCBkb2N1 bWVudC4NCg0KDQoyLiAgSSdkIGxpa2UgdG8gc2VlIHRoZSBldm9sdXRpb24gb2YgdGhlIElQdjYg QWRkcmVzc2luZyBBcmNoaXRlY3R1cmUgZGlzY3Vzc2VkIGFuZCB1c2VkIGFzIHBhcnQgb2YgdGhl IGFyZ3VtZW50IHRvby4gIEhvdyBhYm91dCB0aGUgZm9sbG93aW5nIGFkZGVkIGFzIHRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMTsNCg0KDQogICAgQXMgZGlzY3Vzc2VkIGluIFtSRkM3 NDIxXSwgInRoZSBub3Rpb24gb2YgYSAvNjQgYm91bmRhcnkgaW4gdGhlDQoNCiAgICBhZGRyZXNz IHdhcyBpbnRyb2R1Y2VkIGFmdGVyIHRoZSBpbml0aWFsIGRlc2lnbiBvZiBJUHY2LCBmb2xsb3dp bmcgYQ0KDQogICAgcGVyaW9kIHdoZW4gaXQgd2FzIGV4cGVjdGVkIHRvIGJlIGF0IC84MC4iIFRo aXMgZXZvbHV0aW9uIG9mIHRoZSBJUHY2DQoNCiAgICBBZGRyZXNzaW5nIEFyY2hpdGVjdHVyZSwg cmVzdWx0aW5nIGluIFtSRkM0OTIxXSwgYW5kIGZvbGxvd2VkIHdpdGggdGhlDQoNCiAgICBhZGRp dGlvbiBvZiAvMTI3IHByZWZpeGVzIGZvciBwb2ludC10by1wb2ludCBsaW5rcyBpbiBbUkZDNjE2 NF0sIGNsZWFybHkNCg0KICAgIGRlbW9uc3RyYXRlcyB0aGUgaW50ZW50IGZvciBmdXR1cmUgSVB2 NiBwcm90b2NvbCBkZXZlbG9wbWVudHMgdG8gaGF2ZQ0KDQogICAgdGhlIGZsZXhpYmlsaXR5IHRv IGNoYW5nZSB0aGlzIHBhcnQgb2YgdGhlIGFyY2hpdGVjdHVyZSB3aGVuIG5lY2Vzc2FyeQ0KDQog ICAgYW5kIGp1c3RpZmllZC4NCg0KDQozLiAgSSB0aGluayB0aGUgZmlyc3QgcGFyYWdyYXBoIG9m IHNlY3Rpb24gMiB3b3VsZCBiZSBjbGVhcmVyIGlmIGl0IHNhaWQ7DQoNCg0KICAgIElQdjYgaW1w bGVtZW50YXRpb25zIE1VU1QuLi4NCg0KDQo0LiAgVGhlIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rp b24gMiBtYWtlcyBtZSB0aGluayBvZiB0aGUgc2NlbmUgZnJvbSBTdGFyIFdhcnMgd2hlcmUgT2Jp LVdhbiB1c2VzIHRoZSBKZWRpIG1pbmQgdHJpY2sgb24gdGhlIHN0b3JtIHRyb29wZXJzIHNheWlu ZywgInRoZXNlIGFyZW4ndCB0aGUgZHJvaWRzIHlvdSdyZSBsb29raW5nIGZvci4iDQoNCg0KICAg VGhpcyByZWNvbW1lbmRhdGlvbiBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSA2NC1iaXQgYm91 bmRhcnkgZm9yDQoNCiAgIHNvbWUgSVB2NiBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJh dGlvbiAoU0xBQUMsIFtSRkM0ODY0XSkNCg0KICAgYmFzZWQgc2NoZW1lcyBzdWNoIGFzIFtSRkMy NDY0XS4NCg0KDQpXaHkgZG9lc24ndCBpdCBjb25mbGljdD8gIEp1c3QgYmVjYXVzZSB3ZSBzYWlk IHNvPyAgSG93IGFib3V0IHNvbWV0aGluZyBsaWtlIHRoaXMgaW5zdGVhZDsNCg0KDQogICBUaGlz IHJlY29tbWVuZGF0aW9uIG1pZ2h0IHNlZW0gdG8gY29uZmxpY3Qgd2l0aCB3aXRoIHRoZSA2NC1i aXQNCg0KICAgYm91bmRhcnkgZm9yIHNvbWUgSVB2NiBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29u ZmlndXJhdGlvbiAoU0xBQUMsDQoNCiAgIFtSRkM0ODY0XSkgYmFzZWQgc2NoZW1lcyBzdWNoIGFz IFtSRkMyNDY0XS4gIEhvd2V2ZXIsIFtSRkM3NDIxXQ0KDQogICBjbGFyaWZpZXMgdGhpcyBpcyBv bmx5IGEgcGFyYW1ldGVyIGluIHRoZSBTTEFBQyBwcm9jZXNzIGFuZCB1c2luZw0KDQogICBESENQ djYgW1JGQzMzMTVdIG9yIG1hbnVhbCBjb25maWd1cmF0aW9uIG90aGVyIGxvbmdlciBwcmVmaXgg bGVuZ3Rocw0KDQogICBhcmUgaW4gb3BlcmF0aW9uYWwgdXNlLg0KDQoNCkJ1dCBkb2VzIHRoaXMg cGFyYWdyYXBoIGV2ZW4gYmVsb25nIGluIHRoaXMgc2VjdGlvbj8gIE1heWJlIG1vdmUgaXQgdXAg aW50byBzZWN0aW9uIDEsIGFzIHdlbGwgYXMgcHJvdmlkaW5nIHJlYXNvbnMgd2h5IGl0IGRvZXMg Y29uZmxpY3QuICBIb3cgYWJvdXQgbWFraW5nIHRoaXMgdGhlIHNlY29uZCBwYXJhZ3JhcGggYW5k ICMyIGFib3ZlIHRoZSB0aGlyZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxLg0KDQoNCjUuICBNYXli ZSBhZGRpdGlvbmFsIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gUkZDNDk0MiBhbmQgZHJhZnQt aWV0Zi1vcHNlYy12NiB3b3VsZCBpbiBvcmRlciBmb3IgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHNlY3Rpb24uICBPbmx5IHJlZmVyZW5jaW5nIFJGQzQyOTEncyBzZWN1cml0eSBjb25zaWRl cmF0aW9ucywgd2hpY2ggc2F5cyB0aGUgZm9sbG93aW5nLCBzZWVtcyByZWFsbHkga2luZCBvZiB3 aW1weSBieSB0b2RheSdzIHN0YW5kYXJkcy4NCg0KDQogICAgSVB2NiBhZGRyZXNzaW5nIGRvY3Vt ZW50cyBkbyBub3QgaGF2ZSBhbnkgZGlyZWN0IGltcGFjdCBvbiBJbnRlcm5ldA0KDQogICAgaW5m cmFzdHJ1Y3R1cmUgc2VjdXJpdHkuIEF1dGhlbnRpY2F0aW9uIG9mIElQdjYgcGFja2V0cyBpcyBk ZWZpbmVkDQoNCiAgICBpbiBbQVVUSF0uDQoNCg0KKEFVVEggPSBSRkMgMjQwMikNCg0KDQpIb3cg YWJvdXQ7DQoNCg0KICAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIHNlY3VyaXR5 IGlzc3VlcyBpbiBhZGRpdGlvbiB0byB3aGF0DQoNCiAgICBpcyBkaXNjdXNzZWQgaW4gW1JGQzQy OTE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQyOTE+XS4gIE92ZXJhbGwgSVB2NiBz ZWN1cml0eSBpc3N1ZXMgYXJlIG1vcmUNCg0KICAgIGNvbXBsZXRlbHkgZGlzY3Vzc2VkIGluIFtS RkM0OTQyXSBhbmQgW2RyYWZ0LWlldGYtb3BzZWMtdjZdLg0KDQoNClRoYW5rcw0KDQotLQ0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRhdmlkIEZhcm1l ciAgICAgICAgICAgICAgICAgICAgICAgICAgRW1haWw6IGZhcm1lckB1bW4uZWR1PG1haWx0bzpm YXJtZXJAdW1uLmVkdT4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJz aXR5IG9mIE1pbm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgIFBob25lOiAr MS02MTItNjI2LTA4MTUNCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAgQ2VsbDogKzEtNjEy LTgxMi05OTUyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQoNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B93300490A89AOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVC b2R5Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0 w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUt c3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5EZWFyIERhdmlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5r IHlvdSBmb3IgdGhlc2UgY29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SeKAmW0gT0sgd2l0aCBhbG1vc3QgYWxsIHlvdXIgZWRpdHMu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QSBu ZXcgcmV2aXNpb24gd2l0aCB0aGVzZSBjaGFuZ2VzIHdpbGwgYmUgYXZhaWxhYmxlIHZlcnkgc29v bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4g RGF2aWQgRmFybWVyPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDEzIGbDqXZy aWVyIDIwMTUgMDk6NDY8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdjZv cHMtY2lkci1wcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5PbiBGZWIgMTEsIDIwMTUsIGF0IDA0OjQ3LCA8YSBocmVmPSJtYWlsdG86 ZnJlZEBjaXNjby5jb20iPg0KZnJlZEBjaXNjby5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIG5ldyBkcmFmdCBoYXMg YmVlbiBwb3N0ZWQsIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdjZvcHMtY2lkci1wcmVmaXgiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi12Nm9wcy1jaWRyLXByZWZpeDwvYT4uIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBpdCBh bmQgY29tbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzdXBwb3J0IHRoZSBkcmFmdC4gJm5ic3A7SG93ZXZlciwgSSBoYXZlIHNvbWUg c3VnZ2VzdGVkIGltcHJvdmVtZW50cyBmb3IgdGhlIGN1cnJlbnQgdGV4dC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gJm5ic3A7SSdtIHdv cnJpZWQgYXMgcGhyYXNlZCwgc2VjdGlvbiAxLCBwYXJhZ3JhcGggMyBjb3VsZCBiZSBtaXNpbnRl cnByZXRlZCBhcyBpbXBseWluZyBhIC82NCBpcyBhIHZhbGlkIGVuZC1zaXRlIHByZWZpeC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5 bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7IEEgZGV0YWlsZWQg YW5hbHlzaXMgb2YgdGhlIDY0LWJpdCBib3VuZGFyeSBpbiBJUHY2IGFkZHJlc3NpbmcmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9k eSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyB0b2dldGhlciB3aXRoIHRo ZSBpbXBsaWNhdGlvbiBmb3IgZW5kLXNpdGUgcHJlZml4IGFzc2lnbm1lbnQgYXJlJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDsgZG9jdW1lbnRlZCBpbiBbUkZD NzQyMV0sIGJ1dCBubyByZWNvbW1lbmRhdGlvbiBpcyBpbmNsdWRlZCZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7IGluIHRoYXQgZG9jdW1lbnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1h eWJlIGp1c3QgZWxpbWluYXRlICZxdW90O3RvZ2V0aGVyIHdpdGggdGhlIGltcGxpY2F0aW9uIGZv ciBlbmQtc2l0ZSBwcmVmaXggYXNzaWdubWVudCZxdW90OywgSSdtIG5vdCBzdXJlIGl0J3MgbmVj ZXNzYXJ5IG9yIGFkZHMgbXVjaCB0byB0aGlzIGRpc2N1c3Npb24gdG8gdGFsayBhYm91dCBlbmQt c2l0ZSBwcmVmaXggYXNzaWdubWVudHMgYW55d2F5LiAmbmJzcDtIb3dldmVyLDxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwO3RoZW4NCiB0aGUgb25seSB0aGluZyB0aGUgcGFyYWdyYXBoIHNheXMg YmV5b25kIHdoYXQgaXMgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBpcyAmcXVvdDtidXQgbm8gcmVj b21tZW5kYXRpb24gaXMgaW5jbHVkZWQmbmJzcDs8L3NwYW4+aW4gdGhhdCBkb2N1bWVudC4mcXVv dDsgJm5ic3A7U28sIGhvdyBhYm91dCBqdXN0IGRlbGV0aW5nIHRoaXMgcGFyYWdyYXBoIGFsdG9n ZXRoZXIgYW5kIGFkZGluZyBhIHZlcnNpb24gb2YgdGhhdCBpZGVhIHRvIHRoZSBlbmQgb2YgdGhl IGZpcnN0IHBhcmFncmFwaCwNCiBtYXliZSBzb21ldGhpbmcgbGlrZSB0aGlzOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IEhvd2V2ZXIsIHN1Y2ggYSByZWNvbW1lbmRhdGlvbiB3YXMgb3V0IG9mIHNjb3BlIGZv ciB0aGF0IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0i YWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Mi4gJm5i c3A7SSdkIGxpa2UgdG8gc2VlIHRoZSBldm9sdXRpb24gb2YgdGhlJm5ic3A7SVB2NiBBZGRyZXNz aW5nIEFyY2hpdGVjdHVyZSBkaXNjdXNzZWQgYW5kIHVzZWQgYXMgcGFydCBvZiB0aGUgYXJndW1l bnQgdG9vLiAmbmJzcDtIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyBhZGRlZCBhcyB0aGUgc2Vjb25k IHBhcmFncmFwaCBvZiBzZWN0aW9uIDE7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHls ZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxi ciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7ICZuYnNwOyBBcyZuYnNwO2Rpc2N1c3NlZCBpbiBbUkZDNzQyMV0sICZxdW90O3Ro ZSBub3Rpb24gb2YgYSZuYnNwOy82NCBib3VuZGFyeSBpbiB0aGUmbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyBhZGRyZXNzIHdhcyBpbnRyb2R1Y2VkIGFmdGVy IHRoZSBpbml0aWFsIGRlc2lnbiBvZiZuYnNwO0lQdjYsIGZvbGxvd2luZyBhJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDsgcGVyaW9kIHdoZW4gaXQgd2FzIGV4 cGVjdGVkIHRvIGJlIGF0IC84MC4mcXVvdDsgVGhpcyBldm9sdXRpb24gb2YgdGhlIElQdjYmbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxl Qm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyBBZGRyZXNzaW5nIEFy Y2hpdGVjdHVyZSwgcmVzdWx0aW5nIGluIFtSRkM0OTIxXSwgYW5kIGZvbGxvd2VkIHdpdGgmbmJz cDt0aGUmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250 VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyBhZGRp dGlvbiBvZiAvMTI3Jm5ic3A7cHJlZml4ZXMgZm9yIHBvaW50LXRvLXBvaW50IGxpbmtzIGluIFtS RkM2MTY0XSwmbmJzcDtjbGVhcmx5Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyAmbmJzcDsgZGVtb25zdHJhdGVzIHRoZSBpbnRlbnQgZm9yIGZ1dHVyZSBJUHY2Jm5ic3A7 cHJvdG9jb2wmbmJzcDtkZXZlbG9wbWVudHMgdG8mbmJzcDtoYXZlJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDsgdGhlIGZsZXhpYmlsaXR5Jm5ic3A7dG8mbmJz cDtjaGFuZ2UgdGhpcyBwYXJ0IG9mIHRoZSBhcmNoaXRlY3R1cmUgd2hlbiZuYnNwO25lY2Vzc2Fy eSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0 U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7IGFuZCBqdXN0 aWZpZWQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0iYWxs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+My4gJm5ic3A7 SSB0aGluayB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMiB3b3VsZCBiZSBjbGVhcmVy IGlmIGl0IHNhaWQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0iYWxs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7ICZu YnNwOyBJUHY2IGltcGxlbWVudGF0aW9ucyBNVVNULi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj40LiAmbmJzcDtUaGUgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAy IG1ha2VzIG1lIHRoaW5rIG9mIHRoZSBzY2VuZSBmcm9tIFN0YXIgV2FycyB3aGVyZSBPYmktV2Fu IHVzZXMgdGhlIEplZGkgbWluZCB0cmljayBvbiB0aGUgc3Rvcm0gdHJvb3BlcnMgc2F5aW5nLCAm cXVvdDt0aGVzZSBhcmVuJ3QgdGhlIGRyb2lkcyB5b3UncmUgbG9va2luZyBmb3IuJnF1b3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7VGhpcyByZWNvbW1lbmRhdGlv biBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSA2NC1iaXQgYm91bmRhcnkgZm9yJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtzb21lIElQdjYgc3RhdGVsZXNz IGFkZHJlc3MgYXV0b2NvbmZpZ3VyYXRpb24gKFNMQUFDLCBbUkZDNDg2NF0pJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtiYXNlZCBzY2hlbWVzIHN1Y2ggYXMg W1JGQzI0NjRdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj48YnIgY2xlYXI9ImFsbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtV SUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPldoeSBkb2Vzbid0 IGl0IGNvbmZsaWN0PyAmbmJzcDtKdXN0IGJlY2F1c2Ugd2Ugc2FpZCBzbz8gJm5ic3A7SG93IGFi b3V0IHNvbWV0aGluZyBsaWtlIHRoaXMgaW5zdGVhZDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250 VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpGUiI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0K PC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7VGhpcyByZWNvbW1lbmRhdGlvbiBtaWdodCBzZWVtIHRv IGNvbmZsaWN0IHdpdGgmbmJzcDt3aXRoIHRoZSA2NC1iaXQmbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO2JvdW5kYXJ5IGZvciZuYnNwO3NvbWUgSVB2NiBzdGF0 ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiAoU0xBQUMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtbUkZDNDg2NF0pJm5ic3A7YmFzZWQgc2NoZW1lcyBzdWNo IGFzIFtSRkMyNDY0XS4gJm5ic3A7SG93ZXZlciwgW1JGQzc0MjFdJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtjbGFyaWZpZXMgdGhpcyBpcyBvbmx5IGEgcGFy YW1ldGVyIGluIHRoZSBTTEFBQyBwcm9jZXNzIGFuZCB1c2luZyZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7REhDUHY2IFtSRkMzMzE1XSBvciBtYW51YWwgY29u ZmlndXJhdGlvbiZuYnNwO290aGVyJm5ic3A7bG9uZ2VyIHByZWZpeCBsZW5ndGhzJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDthcmUgaW4mbmJzcDtvcGVyYXRp b25hbCB1c2UuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0i YWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnV0IGRv ZXMgdGhpcyBwYXJhZ3JhcGggZXZlbiBiZWxvbmcgaW4gdGhpcyBzZWN0aW9uPyAmbmJzcDtNYXli ZSBtb3ZlIGl0IHVwIGludG8gc2VjdGlvbiAxLCBhcyB3ZWxsIGFzIHByb3ZpZGluZyByZWFzb25z IHdoeSBpdCBkb2VzIGNvbmZsaWN0LiAmbmJzcDtIb3cgYWJvdXQgbWFraW5nIHRoaXMgdGhlIHNl Y29uZCBwYXJhZ3JhcGggYW5kICMyIGFib3ZlIHRoZSB0aGlyZCBwYXJhZ3JhcGggb2Ygc2VjdGlv biAxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9u dFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjUuICZuYnNwO01heWJlIGFk ZGl0aW9uYWwgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB0byBSRkM0OTQyIGFuZCBkcmFmdC1pZXRm LW9wc2VjLXY2IHdvdWxkIGluIG9yZGVyIGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbi4gJm5ic3A7T25seSByZWZlcmVuY2luZyBSRkM0MjkxJ3MmbmJzcDtzZWN1cml0eSBj b25zaWRlcmF0aW9ucywgd2hpY2ggc2F5cyB0aGUgZm9sbG93aW5nLCBzZWVtcyByZWFsbHkga2lu ZCBvZiB3aW1weSBieSB0b2RheSdzIHN0YW5kYXJkcy48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250 VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpGUiI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0K PC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7IElQdjYgYWRkcmVzc2luZyBkb2N1bWVudHMgZG8gbm90 IGhhdmUgYW55IGRpcmVjdCBpbXBhY3Qgb24gSW50ZXJuZXQ8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7ICZuYnNwOyBpbmZyYXN0cnVjdHVyZSBzZWN1cml0eS4gQXV0aGVudGljYXRp b24gb2YgSVB2NiBwYWNrZXRzIGlzIGRlZmluZWQmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7ICZuYnNwOyBpbiBbQVVUSF0uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNU Rm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlIiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+KEFVVEggPSBSRkMgMjQwMik8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250 VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpGUiI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0K PC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5Ib3cgYWJvdXQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJv ZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBj bGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBzZWN1cml0eSBp c3N1ZXMgaW4gYWRkaXRpb24gdG8gd2hhdCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7IGlzIGRpc2N1c3NlZCBpbiBbPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjkxIiB0aXRsZT0iJnF1b3Q7SVAgVmVyc2lvbiA2IEFk ZHJlc3NpbmcgQXJjaGl0ZWN0dXJlJnF1b3Q7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5SRkM0Mjkx PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5 bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5dLiAmbmJzcDtPdmVyYWxsIElQdjYgc2Vj dXJpdHkgaXNzdWVzIGFyZSBtb3JlJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyAmbmJzcDsgY29tcGxldGVseSBkaXNjdXNzZWQgaW4gW1JGQzQ5NDJdIGFuZCBbZHJhZnQt aWV0Zi1vcHNlYy12Nl0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0i YWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtz PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1zdHlsZS1zcGFuIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGF2aWQgRmFybWVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0VtYWlsOiA8YSBocmVmPSJtYWlsdG86ZmFybWVyQHVtbi5lZHUiPg0KZmFybWVyQHVtbi5lZHU8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P ZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEgJm5ic3A7 ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhv bmU6ICYjNDM7MS02MTItNjI2LTA4MTU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICZuYnNwOyBDZWxs OiAmIzQzOzEtNjEyLTgxMi05OTUyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490A89AOPEXCLILM23corp_-- From nobody Fri Feb 13 01:31:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5C1A1BF3; Fri, 13 Feb 2015 01:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSiS232ysxso; Fri, 13 Feb 2015 01:31:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 726931A1EB7; Fri, 13 Feb 2015 01:31:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213093118.31597.4754.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 01:31:18 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-cidr-prefix-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 09:31:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Prefix Length Recommendation for Forwarding Authors : Mohamed Boucadair Alexandre Petrescu Fred Baker Filename : draft-ietf-v6ops-cidr-prefix-01.txt Pages : 5 Date : 2015-02-13 Abstract: IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software algorithms should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cidr-prefix-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 13 01:52:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292B1A6EFB for ; Fri, 13 Feb 2015 01:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdQ5SZeI9TSe for ; Fri, 13 Feb 2015 01:52:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB7A1A6EE8 for ; Fri, 13 Feb 2015 01:52:05 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 467D73B42F4; Fri, 13 Feb 2015 10:52:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D3174C07E; Fri, 13 Feb 2015 10:52:03 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 10:52:02 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQRxKKtdv8/yjdEkq8+myPex9ad5zuLyGg Date: Fri, 13 Feb 2015 09:52:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490A964@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490A964OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 09:52:10 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490A964OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmsgeW91IGZvciBjb3B5aW5nL3Bhc3RpbmcgdGhlIGxpc3QgYnV0 IEkgaGF2ZSB0cm91YmxlcyB0byBtYXAgdGhvc2UgdG8gdGhlIG5ldyB2ZXJzaW9uIGJlY2F1c2Ug c2V2ZXJhbCBjaGFuZ2VzIHdlcmUgbWFkZSBzaW5jZSB0aGVuLiBJdCBtaWdodCBiZSBtb3JlIHNp bXBsZSBpZiB3ZSB1c2UgdGhlIHJlY28gIyBvZiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRy YWZ0Lg0KDQo9PT09PQ0KMi4gSXQgaXMgb3Zlci1icm9hZC4gVGhlIHZhc3QgbWFqb3JpdHkgb2Yg dGhlIGZlYXR1cmVzIGFyZSBpbiBubyB3YXkgbmVjZXNzYXJ5IHRvIGJ1aWxkIGEgbW9iaWxlIGRl dmljZSB0aGF0IHdvcmtzIHdlbGwgb3ZlciBJUHY2LiBUb2RheSwgdGhlIG92ZXJ3aGVsbWluZyBt YWpvcml0eSBvZiBtb2JpbGUgZGV2aWNlIHRyYWZmaWMgY29tZXMgZnJvbSBkZXZpY2VzIHRoYXQg aW1wbGVtZW50IG9ubHkgYSBoYW5kZnVsIG9mIHRoZXNlIHJlcXVpcmVtZW50cy4gTW9yZSBzcGVj aWZpY2FsbHksIHJlcXVpcmVtZW50cyAjMywgIzksICMxMCwgIzExLCAjMTIsICMxMywgIzE0LCAj MTUsICMxNiwgIzE3LCAjMTgsICMxOSwgIzIwLCAjMjEsICMyMiwgIzIzLCAjMjQsICMyNSwgIzI2 LCAjMjcgKGEgd2hvbGUgUkZDISksICMyOCwgIzI5LCAjMzEsICMzMiAod2hpY2ggY292ZXIgYWxs IGFwcGxpY2F0aW9ucyBydW5uaW5nIG9uIHRoZSBkZXZpY2UgLSB5ZXMsIGFsbCBvZiB0aGVtKSwg YW5kICMzNCwgYXJlIG5vdCBuZWNlc3NhcnkgdG8gY29ubmVjdCB0byBJUHY2IG1vYmlsZSBuZXR3 b3Jrcy4NCj09PT0NCg0KU29tZSBwcmVsaW1pbmFyeSBjb21tZW50czoNCg0KDQrCtyAgICAgICAg IFRoZSBkb2N1bWVudCBpcyBub3cgYnVpbHQgYXMgYSBzdXBlcnNldCBvZiBleGlzdGluZyBSRkNz OiBSRkM3MDY2IGFuZCBSRkM2NDM0LiBTZXZlcmFsIG9mIHRoZSBpdGVtcyB5b3UgaW5jbHVkZWQg aW4geW91ciDigJxicm9hZOKAnSBsaXN0IGFyZSBhbHJlYWR5IGNpdGVkIGluIFJGQzcwNjYgYW5k IFJGQzY0MzQgIChlLmcuLCAjOSwgIzEwLCBldGMuKS4NCg0KDQrCtyAgICAgICAgIFRoZSBJLUQg aW4gKiogbm90ICoqIG9ubHkgYWJvdXQgSVB2NiBjb25uZWN0aXZpdHkgYnV0IGl0cyBzY29wZSBp cyBhcyBmb2xsb3dzOg0KDQoNCiAgIFRoaXMgcHJvZmlsZSBpcyBhIHN1cGVyc2V0IG9mIHRoYXQg b2YgdGhlIElQdjYgcHJvZmlsZSBmb3IgM0dQUA0KDQogICBDZWxsdWxhciBIb3N0cyBbUkZDNzA2 NjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDY2Pl0sIHdoaWNoIGlzIGluIHR1cm4g YSBzdXBlcnNldCBvZiBJUHY2IE5vZGUNCg0KICAgUmVxdWlyZW1lbnRzIFtSRkM2NDM0PGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY0MzQ+XS4gIEl0IHRhcmdldHMgY2VsbHVsYXIgbm9k ZXMsIGluY2x1ZGluZyBHUFJTLA0KDQogICBFUEMgKEV2b2x2ZWQgUGFja2V0IENvcmUpIGFuZCBJ RUVFIDgwMi4xMSBuZXR3b3JrcywgdGhhdCByZXF1aXJlDQoNCiAgIGZlYXR1cmVzIHRvIGVuc3Vy ZSBJUHY0IHNlcnZpY2UgZGVsaXZlcnkgb3ZlciBhbiBJUHY2LW9ubHkgdHJhbnNwb3J0DQoNCiAg IGluIGFkZGl0aW9uIHRvIHRoZSBiYXNlIElQdjYgc2VydmljZS4gIE1vcmVvdmVyLCB0aGlzIHBy b2ZpbGUgY292ZXJzDQoNCiAgIGNlbGx1bGFyIENQRXMgdGhhdCBhcmUgdXNlZCBpbiB2YXJpb3Vz IGRlcGxveW1lbnRzIHRvIG9mZmVyIGZpeGVkLQ0KDQogICBsaWtlIHNlcnZpY2VzLiAgUmVjb21t ZW5kYXRpb25zIGluc3BpcmVkIGZyb20gcmVhbCBkZXBsb3ltZW50DQoNCiAgIGV4cGVyaWVuY2Vz IChlLmcuLCByb2FtaW5nKSBhcmUgaW5jbHVkZWQgaW4gdGhpcyBwcm9maWxlLiAgQWxzbywgdGhp cw0KDQogICBwcm9maWxlIHNrZXRjaGVzIHJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIHNha2Ugb2Yg ZGV0ZXJtaW5pc3RpYw0KDQogICBiZWhhdmlvcnMgb2YgY2VsbHVsYXIgZGV2aWNlcyB3aGVuIHRo ZSBzYW1lIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCg0KICAgaXMgcmVjZWl2ZWQgb3ZlciBz ZXZlcmFsIGNoYW5uZWxzLg0KDQoNCsK3ICAgICAgICAgQSBkZXZpY2UgY2FuIGJlIGNvbXBsaWFu dCB3aXRoIHRoZSBwcm9maWxlIHdpdGhvdXQgc3VwcG9ydGluZyBhbGwgdGhlIGl0ZW1zIGxpc3Rl ZCBpbiBpdC4gVGhhdOKAmXMgbm90IHNwZWNpZmljIHRvIHRoaXMgZG9jdW1lbnQuDQoNCsK3ICAg ICAgICAgSXRlbXMgYXJlIGxpc3RlZCBpbiBhIHByaW9yaXR5IG9yZGVyLiBUaGlzIGlzIG5vdCBl eHBsaWNpdGx5IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQgYnV0IHdlIGNhbiBhZGQgYSBzZW50ZW5j ZSB0byBwcmVjaXNlIGl0Lg0KDQoNCkluIG9yZGVyIHRvIG1ha2UgY29uY3JldGUgcHJvZ3Jlc3Mg d2hpbGUgYWRkcmVzc2luZyB5b3VyIGNvbmNlcm4gYWJvdXQgdGhlIHNjb3BlLCB3b3VsZCB5b3Ug YmUgY29tZm9ydGFibGUgd2l0aCB0aGUgZm9sbG93aW5nIGRpcmVjdGlvbjoNCg0KwrcgICAgICAg ICBFeGNsdWRlIFdMQU4gYW5kIGFwcGxpY2F0aW9uLXJlbGF0ZWQgY29uc2lkZXJhdGlvbnMgZnJv bSB0aGUgc2NvcGUgb2YgdGhlIEktRC4gVGhpcyB3aWxsIGhhdmUgdGhlIGNvbnNlcXVlbmNlIG9m IHJlbW92aW5nIGJvdGggc2VjdGlvbiAyLjEgYW5kIFNlY3Rpb24gNS4NCg0KwrcgICAgICAgICBB ZGQgc29tZSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVtaW5kIHRoZSBpbXBvcnRhbmNl IG9mIEFGLWluZGVwZW5kZW50IGFwcGxpY2F0aW9ucy9BUElzLg0KDQrCtyAgICAgICAgIEFkZCBh biBleHBsaWNpdCBzZW50ZW5jZSB0byBzYXkgdGhlIHN1cHBvcnQgb2YgdGhpcyBwcm9maWxlIGRv ZXMgbm90IG1lYW4gdGhhdCBhbGwgaXRlbXMgTVVTVCBiZSBzdXBwb3J0ZWQuDQoNCsK3ICAgICAg ICAgQWRkIGEgc2VudGVuY2UgdG8gZXhwbGljaXQgaXRlbXMgdW5kZXIgZWFjaCBzZWN0aW9uIGFy ZSBjbGFzc2lmaWVkIGluIGEgcHJpb3JpdHkgb3JkZXIuDQoNCkRvaW5nIHNvIHdpbGwgbGVhZCB0 byBhIGxpc3Qgb2YgMTggaXRlbXMgdGhhdCBpcyBhbG1vc3QgMS8yIG9mIHRoZSBpbml0aWFsIDM0 IGxpc3QgOy0pDQoNClRoYW5rIHlvdS4NCkNoZWVycywNCk1lZA0KDQpEZSA6IExvcmVuem8gQ29s aXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCkVudm95w6kgOiBqZXVkaSAxMiBmw6l2 cmllciAyMDE1IDIzOjI0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogSGVh dGxleSwgTmljazsgRnJlZCBCYWtlciAoZnJlZCk7IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlLmFsbEB0b29scy5pZXRmLm9yZzsgVjYgT3BzIExpc3QNCk9iamV0IDogUmU6 IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxs LSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24gV2VkLCBGZWIgMTEsIDIwMTUgYXQgNDowOSBBTSwg PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+PiB3cm90ZToNCkNhbiB5b3UgZXhwbGljaXQgd2hhdCBkbyB5b3UgbWVhbnQgYnkg 4oCcaGFybWZ1bGx5IGJyb2Fk4oCdPw0KKG5vdGUsIHRoZSBwb2ludGVyIHlvdSBwcm92aWRlZCBp cyBub3QgdmFsaWQgYmVjYXVzZSBzZXZlcmFsIGl0ZW1zIGhhdmUgYmVlbiByZW1vdmVkIGZyb20g dGhlIGRyYWZ0IHNpbmNlIHRoZW4uKQ0KDQpPaywgdGhlbi4gU2luY2UgeW91IGFzaywgbGV0IG1l IGNvcHkgYW5kIHBhc3RlIHRoZSB0ZXh0IGZyb20gdGhlIHBvaW50ZXIsIHRoZW4sIGFuZCB3ZSBj YW4gZGlzY3VzcyB3aHkgaXQgaXMgbm8gbG9uZ2VyIHZhbGlkLg0KDQo9PT09PQ0KSSBvYmplY3Qg dG8gdGhpcyBkb2N1bWVudCBvbiB0aGUgZ3JvdW5kcyB0aGF0IGl0IGlzIGxpdHRsZSBtb3JlIHRo YW4gYSBsaXN0IG9mICgzNCEpIGZlYXR1cmVzIHdpdGggbGl0dGxlIHRlY2huaWNhbCBqdXN0aWZp Y2F0aW9uLiBJIHNlZSB0aGlzIGFzIGEgcHJvYmxlbSBiZWNhdXNlOg0KDQoxLiBJdCBpcyBvdXQg b2YgdGhlIElFVEYncyBtYW5kYXRlLiBJdCBpcyBub3QgdGhlIElFVEYncyBqb2IgdG8gc3BlY2lm eSB3aGljaCBmZWF0dXJlcyBvciBwcm90b2NvbHMgc2hvdWxkIG9yIHNob3VsZCBub3QgYmUgaW1w bGVtZW50ZWQgaW4gaG9zdHMuIEV2ZW4gdGhlIGhvc3RzIHJlcXVpcmVtZW50cyBSRkNzIGFyZSBj YXJlZnVsIGFuZCBzcGFyaW5nIGluIHRoZWlyIGxhbmd1YWdlLiBUaGUgSUVURiBpcyBjZXJ0YWlu bHkgbm90IGluIHRoZSBidXNpbmVzcyBvZiBydWJiZXJzdGFtcGluZyBmZWF0dXJlIHdpc2hsaXN0 cyB3aXRob3V0IGdvb2QgdGVjaG5pY2FsIHJlYXNvbnMuIEkgd291bGQgY2hhbGxlbmdlIHRoZSBh dXRob3JzIHRvIGZpbmQgYSBwcmVjZWRlbnQgUkZDIGNvbnRhaW5pbmcgc3VjaCBicm9hZCByZXF1 aXJlbWVudHMuDQoNCjIuIEl0IGlzIG92ZXItYnJvYWQuIFRoZSB2YXN0IG1ham9yaXR5IG9mIHRo ZSBmZWF0dXJlcyBhcmUgaW4gbm8gd2F5IG5lY2Vzc2FyeSB0byBidWlsZCBhIG1vYmlsZSBkZXZp Y2UgdGhhdCB3b3JrcyB3ZWxsIG92ZXIgSVB2Ni4gVG9kYXksIHRoZSBvdmVyd2hlbG1pbmcgbWFq b3JpdHkgb2YgbW9iaWxlIGRldmljZSB0cmFmZmljIGNvbWVzIGZyb20gZGV2aWNlcyB0aGF0IGlt cGxlbWVudCBvbmx5IGEgaGFuZGZ1bCBvZiB0aGVzZSByZXF1aXJlbWVudHMuIE1vcmUgc3BlY2lm aWNhbGx5LCByZXF1aXJlbWVudHMgIzMsICM5LCAjMTAsICMxMSwgIzEyLCAjMTMsICMxNCwgIzE1 LCAjMTYsICMxNywgIzE4LCAjMTksICMyMCwgIzIxLCAjMjIsICMyMywgIzI0LCAjMjUsICMyNiwg IzI3IChhIHdob2xlIFJGQyEpLCAjMjgsICMyOSwgIzMxLCAjMzIgKHdoaWNoIGNvdmVyIGFsbCBh cHBsaWNhdGlvbnMgcnVubmluZyBvbiB0aGUgZGV2aWNlIC0geWVzLCBhbGwgb2YgdGhlbSksIGFu ZCAjMzQsIGFyZSBub3QgbmVjZXNzYXJ5IHRvIGNvbm5lY3QgdG8gSVB2NiBtb2JpbGUgbmV0d29y a3MuDQoNCjMuIEl0IGlzIHNvIGRhdW50aW5nIGFzIHRvIGFjdCBhcyBhIGRldGVycmVudCB0byBJ UHY2IGRlcGxveW1lbnQuIEkgd291bGQgY2hhbGxlbmdlIHRoZSBhdXRob3JzIHRvIGZpbmQgYSBz aW5nbGUgcHJvZHVjdCB0b2RheSB0aGF0IGltcGxlbWVudHMgYWxsLCBvciBldmVuIGEgc3Vic3Rh bnRpYWwgbWFqb3JpdHksIG9mIHRoZXNlIHJlcXVpcmVtZW50cy4gSXQgc2VlbXMgdG8gbWUgdGhh dCB0aGUgc2hlZXIgbGVuZ3RoIG9mIHRoZSBsaXN0LCBhbmQgdGhlIGZhY3QgdGhhdCBpcyBub3Qg cHJpb3JpdGl6ZWQsIGNyZWF0ZSBhIHJlYWwgcmlzayB0aGF0IGltcGxlbWVudG9ycyB3aWxsIHNp bXBseSB3cml0ZSBpdCBvZmYgYXMgd2lzaGZ1bCB0aGlua2luZyBvciBldmVuIHNoeSBhd2F5IGlu IHRlcnJvci4NCg0KNC4gVGhlIGRvY3VtZW50IGhhcyBmZXcgdGVjaG5pY2FsIGNvbnRyaWJ1dGlv bnMgb2YgaXRzIG93bi4gTW9zdCBvZiB0aGUgcmVxdWlyZW1lbnRzIGFyZSBzaW1wbHkgbGlzdGVk IG9uZSBhZnRlciBhbm90aGVyLg0KDQpJJ20gYWxsIGZvciBJUHY2IGRlcGxveW1lbnQgaW4gbW9i aWxlIG5ldHdvcmtzLCBidXQgbWFraW5nIGEgbGlzdCBvZiB3aGF0IHNlZW1zIGxpa2UgYWxsIHRo ZSBmZWF0dXJlcyB0aGF0IHRoZSBJRVRGIGhhcyBldmVyIGRldmVsb3BlZCwgYW5kIHRoZW4gc2F5 aW5nIHRoYXQgdGhleSBhbGwgbmVlZCB0byBiZSBpbXBsZW1lbnRlZCwgaXMgbm90IHRoZSB3YXkg dG8gZ2V0IHRoZXJlLiBUaGUgd2F5IHRvIGRvIGl0IGlzIHRvIGRvY3VtZW50IHVzZSBjYXNlcyBh bmQgd29ya2luZyBzY2VuYXJpb3MgZ2xlYW5lZCBmcm9tIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Uu DQo9PT09DQoNClRoZSB3YXkgSSBzZWUgaXQsIHRoZSByZWNlbnQgY2hhbmdlcyBtYWRlIHRvIHRo ZSBkb2N1bWVudCBkbyBub3RoaW5nIHRvIGFkZHJlc3MgdGhlIHN1YnN0YW5jZSBvZiB0aG9zZSBw b2ludHMuDQoNCkl0J3MgdHJ1ZSB0aGF0IHRoZSBkb2N1bWVudCBubyBsb25nZXIgbGlzdHMgMzQg ZmVhdHVyZXMsIG9ubHkgMjMsIGJ1dCBpdCBsb29rcyBsaWtlIHRoZSByZWR1Y3Rpb24gaGFzIGJl ZW4gbW9zdGx5IGVmZmVjdGVkIGJ5IHJlbW92aW5nIGZlYXR1cmVzIHRoYXQgd2VyZSBhbHJlYWR5 IG1hbmRhdG9yeSBJRVRGIG9yIDNHUFAgcmVxdWlyZW1lbnRzIChlLmcuLCBSRVEjMSwgIm11c3Qg c3VwcG9ydCBJUHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGFuZCBJQ01QdjYgbm9kZSByZXF1 aXJlbWVudHMiLCBSRVEjNiwgIm11c3Qgc3VwcG9ydCBJUHY2IG5laWdoYm91ciBkaXNjb3Zlcnki KSBhbmQgY29hbGVzY2luZyBtdWx0aXBsZSBmZWF0dXJlcyBpbnRvIG9uZSwgKGUuZy4sIFJFUV8y IGFuZCBSRVFfMyB3ZXJlIG1lcmdlZCBpbnRvIENfUkVDIzIpLg0K --_000_787AE7BB302AE849A7480A190F8B93300490A964OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQpzcGFuLmdyZXkNCgl7bXNvLXN0eWxlLW5hbWU6Z3JleTt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo2OTIzNDA3Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjExMzk1NDYxMzYgMjAwNzU2ODggNjc4OTUyOTkgNjc4OTUzMDEgNjc4 OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxNzY0MjU4NjM4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTgxOTYyOTAxOCAyMDA3NTY4OCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5 NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkhpIExvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlRoYW5rIHlvdSBmb3IgY29weWluZy9wYXN0aW5nIHRoZSBsaXN0IGJ1dCBJIGhh dmUgdHJvdWJsZXMgdG8gbWFwIHRob3NlIHRvIHRoZSBuZXcgdmVyc2lvbiBiZWNhdXNlIHNldmVy YWwgY2hhbmdlcyB3ZXJlIG1hZGUgc2luY2UgdGhlbi4gSXQgbWlnaHQgYmUgbW9yZQ0KIHNpbXBs ZSBpZiB3ZSB1c2UgdGhlIHJlY28gIyBvZiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0 LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09 PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjIuIEl0IGlzIG92ZXItYnJvYWQuIFRoZSB2YXN0IG1h am9yaXR5IG9mIHRoZSBmZWF0dXJlcyBhcmUgaW4gbm8gd2F5IG5lY2Vzc2FyeSB0byBidWlsZCBh IG1vYmlsZSBkZXZpY2UgdGhhdCB3b3JrcyB3ZWxsIG92ZXIgSVB2Ni4gVG9kYXksIHRoZSBvdmVy d2hlbG1pbmcNCiBtYWpvcml0eSBvZiBtb2JpbGUgZGV2aWNlIHRyYWZmaWMgY29tZXMgZnJvbSBk ZXZpY2VzIHRoYXQgaW1wbGVtZW50IG9ubHkgYSBoYW5kZnVsIG9mIHRoZXNlIHJlcXVpcmVtZW50 cy4gTW9yZSBzcGVjaWZpY2FsbHksIHJlcXVpcmVtZW50cyAjMywgIzksICMxMCwgIzExLCAjMTIs ICMxMywgIzE0LCAjMTUsICMxNiwgIzE3LCAjMTgsICMxOSwgIzIwLCAjMjEsICMyMiwgIzIzLCAj MjQsICMyNSwgIzI2LCAjMjcgKGEgd2hvbGUgUkZDISksICMyOCwNCiAjMjksICMzMSwgIzMyICh3 aGljaCBjb3ZlciBhbGwgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdGhlIGRldmljZSAtIHllcywg YWxsIG9mIHRoZW0pLCBhbmQgIzM0LCBhcmUgbm90IG5lY2Vzc2FyeSB0byBjb25uZWN0IHRvIElQ djYgbW9iaWxlIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Tb21lIHByZWxpbWluYXJ5 IGNvbW1lbnRzOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7 Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkb2N1bWVudCBp cyBub3cgYnVpbHQgYXMgYSBzdXBlcnNldCBvZiBleGlzdGluZyBSRkNzOiBSRkM3MDY2IGFuZCBS RkM2NDM0LiBTZXZlcmFsIG9mIHRoZSBpdGVtcyB5b3UgaW5jbHVkZWQgaW4geW91ciDigJxicm9h ZOKAnSBsaXN0IGFyZSBhbHJlYWR5DQogY2l0ZWQgaW4gUkZDNzA2NiBhbmQgUkZDNjQzNCZuYnNw OyAoZS5nLiwgIzksICMxMCwgZXRjLikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZSBJLUQgaW4gKiogbm90ICoqIG9ubHkgYWJvdXQgSVB2NiBjb25uZWN0aXZpdHkgYnV0IGl0cyBz Y29wZSBpcyBhcyBmb2xsb3dzOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhp cyBwcm9maWxlIGlzIGEgc3VwZXJzZXQgb2YgdGhhdCBvZiB0aGUgSVB2NiBwcm9maWxlIGZvciAz R1BQPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsgQ2VsbHVsYXIgSG9zdHMgWzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MDY2IiB0aXRsZT0iJnF1b3Q7SVB2NiBmb3IgVGhpcmQgR2VuZXJhdGlv biBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKSBDZWxsdWxhciBIb3N0cyZxdW90OyI+PHNwYW4g bGFuZz0iRU4tVVMiPlJGQzcwNjY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj5dLCB3aGlj aCBpcyBpbiB0dXJuIGEgc3VwZXJzZXQgb2YgSVB2NiBOb2RlPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgUmVxdWlyZW1lbnRzIFs8 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQzNCIgdGl0bGU9 IiZxdW90O0lQdjYgTm9kZSBSZXF1aXJlbWVudHMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5S RkM2NDM0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XS4mbmJzcDsgSXQgdGFyZ2V0cyBj ZWxsdWxhciBub2RlcywgaW5jbHVkaW5nIEdQUlMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgRVBDIChFdm9sdmVkIFBhY2tldCBD b3JlKSBhbmQgSUVFRSA4MDIuMTEgbmV0d29ya3MsIHRoYXQgcmVxdWlyZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZlYXR1cmVz IHRvIGVuc3VyZSBJUHY0IHNlcnZpY2UgZGVsaXZlcnkgb3ZlciBhbiBJUHY2LW9ubHkgdHJhbnNw b3J0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsgaW4gYWRkaXRpb24gdG8gdGhlIGJhc2UgSVB2NiBzZXJ2aWNlLiZuYnNwOyBNb3Jl b3ZlciwgdGhpcyBwcm9maWxlIGNvdmVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGNlbGx1bGFyIENQRXMgdGhhdCBhcmUgdXNl ZCBpbiB2YXJpb3VzIGRlcGxveW1lbnRzIHRvIG9mZmVyIGZpeGVkLTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGxpa2Ugc2Vydmlj ZXMuJm5ic3A7IFJlY29tbWVuZGF0aW9ucyBpbnNwaXJlZCBmcm9tIHJlYWwgZGVwbG95bWVudDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IGV4cGVyaWVuY2VzIChlLmcuLCByb2FtaW5nKSBhcmUgaW5jbHVkZWQgaW4gdGhpcyBwcm9m aWxlLiZuYnNwOyBBbHNvLCB0aGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgcHJvZmlsZSBza2V0Y2hlcyByZWNvbW1lbmRhdGlv bnMgZm9yIHRoZSBzYWtlIG9mIGRldGVybWluaXN0aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBiZWhhdmlvcnMgb2YgY2VsbHVs YXIgZGV2aWNlcyB3aGVuIHRoZSBzYW1lIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBp cyByZWNlaXZlZCBvdmVyIHNldmVyYWwgY2hhbm5lbHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+QSBkZXZpY2UgY2FuIGJlIGNvbXBsaWFudCB3aXRoIHRoZSBwcm9maWxlIHdpdGhv dXQgc3VwcG9ydGluZyBhbGwgdGhlIGl0ZW1zIGxpc3RlZCBpbiBpdC4gVGhhdOKAmXMgbm90IHNw ZWNpZmljIHRvIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JdGVtcyBhcmUgbGlzdGVkIGluIGEgcHJpb3JpdHkg b3JkZXIuIFRoaXMgaXMgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkIGluIHRoZSBkcmFmdCBidXQg d2UgY2FuIGFkZCBhIHNlbnRlbmNlIHRvIHByZWNpc2UgaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+SW4gb3JkZXIgdG8gbWFrZSBjb25jcmV0ZSBwcm9ncmVzcyB3aGlsZSBhZGRyZXNzaW5nIHlv dXIgY29uY2VybiBhYm91dCB0aGUgc2NvcGUsIHdvdWxkIHlvdSBiZSBjb21mb3J0YWJsZSB3aXRo IHRoZSBmb2xsb3dpbmcgZGlyZWN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+RXhjbHVkZSBXTEFOIGFuZCBhcHBsaWNhdGlvbi1y ZWxhdGVkIGNvbnNpZGVyYXRpb25zIGZyb20gdGhlIHNjb3BlIG9mIHRoZSBJLUQuIFRoaXMgd2ls bCBoYXZlIHRoZSBjb25zZXF1ZW5jZSBvZiByZW1vdmluZyBib3RoIHNlY3Rpb24gMi4xIGFuZCBT ZWN0aW9uDQogNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkFkZCBzb21lIHRleHQgaW4gdGhlIGludHJvZHVjdGlvbiB0byByZW1pbmQg dGhlIGltcG9ydGFuY2Ugb2YgQUYtaW5kZXBlbmRlbnQgYXBwbGljYXRpb25zL0FQSXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BZGQg YW4gZXhwbGljaXQgc2VudGVuY2UgdG8gc2F5IHRoZSBzdXBwb3J0IG9mIHRoaXMgcHJvZmlsZSBk b2VzIG5vdCBtZWFuIHRoYXQgYWxsIGl0ZW1zIE1VU1QgYmUgc3VwcG9ydGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWRkIGEgc2Vu dGVuY2UgdG8gZXhwbGljaXQgaXRlbXMgdW5kZXIgZWFjaCBzZWN0aW9uIGFyZSBjbGFzc2lmaWVk IGluIGEgcHJpb3JpdHkgb3JkZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+RG9pbmcgc28gd2lsbCBsZWFkIHRvIGEgbGlzdCBvZiAxOCBpdGVt cyB0aGF0IGlzIGFsbW9zdCAxLzIgb2YgdGhlIGluaXRpYWwgMzQgbGlzdCA7LSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAx MiBmw6l2cmllciAyMDE1IDIzOjI0PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9o YW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBIZWF0bGV5LCBOaWNrOyBGcmVkIEJh a2VyIChmcmVkKTsgZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUuYWxsQHRv b2xzLmlldGYub3JnOyBWNiBPcHMgTGlzdDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2 Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAm cXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMSwgMjAxNSBhdCA0OjA5IEFNLCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkNhbiB5b3UgZXhwbGljaXQgd2hhdCBkbyB5b3UgbWVhbnQgYnkg4oCcaGFy bWZ1bGx5IGJyb2Fk4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4obm90ZSwgdGhlIHBvaW50 ZXIgeW91IHByb3ZpZGVkIGlzIG5vdCB2YWxpZCBiZWNhdXNlIHNldmVyYWwgaXRlbXMgaGF2ZSBi ZWVuIHJlbW92ZWQgZnJvbSB0aGUgZHJhZnQNCiBzaW5jZSB0aGVuLik8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2ss IHRoZW4uIFNpbmNlIHlvdSBhc2ssIGxldCBtZSBjb3B5IGFuZCBwYXN0ZSB0aGUgdGV4dCBmcm9t IHRoZSBwb2ludGVyLCB0aGVuLCBhbmQgd2UgY2FuIGRpc2N1c3Mgd2h5IGl0IGlzIG5vIGxvbmdl ciB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIG9iamVjdCB0byB0aGlzIGRvY3VtZW50IG9uIHRoZSBncm91bmRzIHRo YXQgaXQgaXMgbGl0dGxlIG1vcmUgdGhhbiBhIGxpc3Qgb2YgKDM0ISkgZmVhdHVyZXMgd2l0aCBs aXR0bGUgdGVjaG5pY2FsIGp1c3RpZmljYXRpb24uIEkgc2VlIHRoaXMgYXMgYSBwcm9ibGVtIGJl Y2F1c2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjEuIEl0IGlzIG91dCBvZiB0aGUgSUVURidzIG1hbmRhdGUuIEl0IGlzIG5vdCB0aGUgSUVU RidzIGpvYiB0byBzcGVjaWZ5IHdoaWNoIGZlYXR1cmVzIG9yIHByb3RvY29scyBzaG91bGQgb3Ig c2hvdWxkIG5vdCBiZSBpbXBsZW1lbnRlZCBpbiBob3N0cy4gRXZlbiB0aGUgaG9zdHMgcmVxdWly ZW1lbnRzIFJGQ3MgYXJlIGNhcmVmdWwgYW5kIHNwYXJpbmcgaW4gdGhlaXIgbGFuZ3VhZ2UuIFRo ZSBJRVRGIGlzIGNlcnRhaW5seQ0KIG5vdCBpbiB0aGUgYnVzaW5lc3Mgb2YgcnViYmVyc3RhbXBp bmcgZmVhdHVyZSB3aXNobGlzdHMgd2l0aG91dCBnb29kIHRlY2huaWNhbCByZWFzb25zLiBJIHdv dWxkIGNoYWxsZW5nZSB0aGUgYXV0aG9ycyB0byBmaW5kIGEgcHJlY2VkZW50IFJGQyBjb250YWlu aW5nIHN1Y2ggYnJvYWQgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBJdCBpcyBvdmVyLWJyb2FkLiBUaGUgdmFzdCBt YWpvcml0eSBvZiB0aGUgZmVhdHVyZXMgYXJlIGluIG5vIHdheSBuZWNlc3NhcnkgdG8gYnVpbGQg YSBtb2JpbGUgZGV2aWNlIHRoYXQgd29ya3Mgd2VsbCBvdmVyIElQdjYuIFRvZGF5LCB0aGUgb3Zl cndoZWxtaW5nIG1ham9yaXR5IG9mIG1vYmlsZSBkZXZpY2UgdHJhZmZpYyBjb21lcyBmcm9tIGRl dmljZXMgdGhhdCBpbXBsZW1lbnQgb25seSBhIGhhbmRmdWwNCiBvZiB0aGVzZSByZXF1aXJlbWVu dHMuIE1vcmUgc3BlY2lmaWNhbGx5LCByZXF1aXJlbWVudHMgIzMsICM5LCAjMTAsICMxMSwgIzEy LCAjMTMsICMxNCwgIzE1LCAjMTYsICMxNywgIzE4LCAjMTksICMyMCwgIzIxLCAjMjIsICMyMywg IzI0LCAjMjUsICMyNiwgIzI3IChhIHdob2xlIFJGQyEpLCAjMjgsICMyOSwgIzMxLCAjMzIgKHdo aWNoIGNvdmVyIGFsbCBhcHBsaWNhdGlvbnMgcnVubmluZyBvbiB0aGUgZGV2aWNlIC0geWVzLCBh bGwgb2YgdGhlbSksDQogYW5kICMzNCwgYXJlIG5vdCBuZWNlc3NhcnkgdG8gY29ubmVjdCB0byBJ UHY2IG1vYmlsZSBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+My4gSXQgaXMgc28gZGF1bnRpbmcgYXMgdG8gYWN0IGFzIGEgZGV0 ZXJyZW50IHRvIElQdjYgZGVwbG95bWVudC4gSSB3b3VsZCBjaGFsbGVuZ2UgdGhlIGF1dGhvcnMg dG8gZmluZCBhIHNpbmdsZSBwcm9kdWN0IHRvZGF5IHRoYXQgaW1wbGVtZW50cyBhbGwsIG9yIGV2 ZW4gYSBzdWJzdGFudGlhbCBtYWpvcml0eSwgb2YgdGhlc2UgcmVxdWlyZW1lbnRzLiBJdCBzZWVt cyB0byBtZSB0aGF0IHRoZSBzaGVlciBsZW5ndGgNCiBvZiB0aGUgbGlzdCwgYW5kIHRoZSBmYWN0 IHRoYXQgaXMgbm90IHByaW9yaXRpemVkLCBjcmVhdGUgYSByZWFsIHJpc2sgdGhhdCBpbXBsZW1l bnRvcnMgd2lsbCBzaW1wbHkgd3JpdGUgaXQgb2ZmIGFzIHdpc2hmdWwgdGhpbmtpbmcgb3IgZXZl biBzaHkgYXdheSBpbiB0ZXJyb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjQuIFRoZSBkb2N1bWVudCBoYXMgZmV3IHRlY2huaWNhbCBjb250 cmlidXRpb25zIG9mIGl0cyBvd24uIE1vc3Qgb2YgdGhlIHJlcXVpcmVtZW50cyBhcmUgc2ltcGx5 IGxpc3RlZCBvbmUgYWZ0ZXIgYW5vdGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFsbCBmb3IgSVB2NiBkZXBsb3ltZW50IGluIG1v YmlsZSBuZXR3b3JrcywgYnV0IG1ha2luZyBhIGxpc3Qgb2Ygd2hhdCBzZWVtcyBsaWtlIGFsbCB0 aGUgZmVhdHVyZXMgdGhhdCB0aGUgSUVURiBoYXMgZXZlciBkZXZlbG9wZWQsIGFuZCB0aGVuIHNh eWluZyB0aGF0IHRoZXkgYWxsIG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQsIGlzIG5vdCB0aGUgd2F5 IHRvIGdldCB0aGVyZS4gVGhlIHdheSB0byBkbyBpdA0KIGlzIHRvIGRvY3VtZW50IHVzZSBjYXNl cyBhbmQgd29ya2luZyBzY2VuYXJpb3MgZ2xlYW5lZCBmcm9tIG9wZXJhdGlvbmFsIGV4cGVyaWVu Y2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPj09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIHdheSBJIHNlZSBpdCwgdGhlIHJlY2VudCBjaGFuZ2VzIG1hZGUgdG8gdGhl IGRvY3VtZW50IGRvIG5vdGhpbmcgdG8gYWRkcmVzcyB0aGUgc3Vic3RhbmNlIG9mIHRob3NlIHBv aW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQncyB0cnVlIHRoYXQgdGhlIGRvY3VtZW50IG5vIGxvbmdlciBsaXN0cyAzNCBmZWF0dXJl cywgb25seSAyMywgYnV0IGl0IGxvb2tzIGxpa2UgdGhlIHJlZHVjdGlvbiBoYXMgYmVlbiBtb3N0 bHkgZWZmZWN0ZWQgYnkgcmVtb3ZpbmcgZmVhdHVyZXMgdGhhdCB3ZXJlIGFscmVhZHkgbWFuZGF0 b3J5IElFVEYgb3IgM0dQUCByZXF1aXJlbWVudHMgKGUuZy4sIFJFUSMxLCAmcXVvdDttdXN0IHN1 cHBvcnQgSVB2NiBhZGRyZXNzaW5nDQogYXJjaGl0ZWN0dXJlIGFuZCBJQ01QdjYgbm9kZSByZXF1 aXJlbWVudHMmcXVvdDssIFJFUSM2LCAmcXVvdDttdXN0IHN1cHBvcnQgSVB2NiBuZWlnaGJvdXIg ZGlzY292ZXJ5JnF1b3Q7KSBhbmQgY29hbGVzY2luZyBtdWx0aXBsZSBmZWF0dXJlcyBpbnRvIG9u ZSwgKGUuZy4sIFJFUV8yIGFuZCBSRVFfMyB3ZXJlIG1lcmdlZCBpbnRvIENfUkVDIzIpLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490A964OPEXCLILM23corp_-- From nobody Fri Feb 13 02:13:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B711A6F2E for ; Fri, 13 Feb 2015 02:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qs2ZlskkS_R for ; Fri, 13 Feb 2015 02:13:20 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E081A6F2A for ; Fri, 13 Feb 2015 02:13:19 -0800 (PST) Received: from [85.158.136.35] by server-12.bemta-5.messagelabs.com id B2/42-02810-D3ECDD45; Fri, 13 Feb 2015 10:13:17 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-5.tower-125.messagelabs.com!1423822397!37961441!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16876 invoked from network); 13 Feb 2015 10:13:17 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-5.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 10:13:17 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Fri, 13 Feb 2015 10:13:10 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 13 Feb 2015 10:13:16 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 10:13:15 +0000 From: "Heatley, Nick" To: "mohamed.boucadair@orange.com" , "Alexandru Petrescu" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZzuJKAAgAA1/FA= Date: Fri, 13 Feb 2015 10:13:16 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 10:13:29 -0000 QSBzdGF0ZW1lbnQgc3VjaCBhcyANCj5UaGUgZGV2aWNlIHNob3VsZCBvbmx5IGludm9rZSB0aGUg Q0xBVCBpbiB0aGUgYWJzZW5jZSBvZiBhIHRoZSBJUHY0IEFGIGkuZS4gd2hlbiB0aGUgbmV0d29y ayBkb2VzIG5vdCBhc3NpZ24gYW4gSVB2NCBjZWxsdWxhciBhZGRyZXNzDQpjb3VsZCBiZSBoZWxw ZnVsPw0KDQpUbyBnbyBmdXJ0aGVyLCBhbmQgZGVmaW5lIGFueSBhZGRpdGlvbmFsIHJlcXVpcmVt ZW50LCB0aGVuIHRoYXQgd291bGQgYmUgZGVmaW5pbmcgaG93IGFuIE9wZXJhdG9yIGNvdWxkL3No b3VsZCBtYW5hZ2UgdGhlaXIgcmVtYWluaW5nIElQdjQgcHVibGljIGFuZCBwcml2YXRlIGFkZHJl c3NpbmcuDQpUaGlzIHBhcGVyIHNob3VsZCBvbmx5IGZvY3VzIG9uIHRoZSByZXF1aXJlZCBkZXZp Y2UgYmVoYXZpb3VyLg0KDQpBcyBhbiBhc2lkZSA0NjR4bGF0IGlzIGEgZGlyZWN0IHJlcGxhY2Vt ZW50IGZvciB0aGUgTkFUNDQgZW52aXJvbm1lbnRzLCB0eXBpY2FsIGluIG1vYmlsZSBvcGVyYXRv cnMgd2l0aCBsYXJnZSBjb25zdW1lciBiYXNlcy4NCklkZWFsIGlmIGFuIG9wZXJhdG9yIGlzIGV4 aGF1c3RpbmcgYm90aCBwdWJsaWMgYW5kIHByaXZhdGUgYWRkcmVzcyBzcGFjZS4NCklmIGFuIG9w ZXJhdG9yIGhhcyBhbXBsZSBwdWJsaWMgSVB2NCBhbmQgaGFzIGNvbnN1bWVyIHByb2R1Y3RzIHRo YXQgYXJlIE5BVDQ0LWZyZWUsIHRoZW4gdGhleSBhcmUgaW4gYSBkaWZmZXJlbnQgcGxhY2UgKGEg dXRvcGlhKS4NCk5pY2sNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KU2VudDogMTMgRmVicnVhcnkgMjAxNSAwNjo0OQ0KVG86IEFs ZXhhbmRydSBQZXRyZXNjdQ0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNy50 eHQgLSBDX1JFQyM5IDQ2NFhMQVQNCg0KSGkgQWxleCwgDQoNClRoZSBpbnRlbnQgb2YgdGhpcyBy ZWNvIGlzIHRvIGFkZHJlc3MgYnJva2VuIElQdjQtb25seSBhcHBsaWNhdGlvbnMgb3ZlciBhbiBJ UHY2LW9ubHkgY29ubmVjdGl2aXR5LiBJZGVhbGx5IGFwcGxpY2F0aW9ucyBydW5uaW5nIG9uIHRo ZSBkZXZpY2Ugc2hvdWxkIGJlIEFGLWluZGVwZW5kZW50LiANCg0KVGhlIGRyYWZ0IHJlbGllcyBv biB0aGUgSVB2NiBub2RlIHJlcXVpcmVtZW50cyBSRkMgdGhhdCBtYW5kYXRlcyB0aGUgc3VwcG9y dHMgb2YgSVB2Ni4gQWxzbywgdGhlIEktRCBjYWxscyBvdXQgYXBwbGljYXRpb25zIHRoYXQgYXJl IHByb3ZpZGVkIGJ5IHRoZSB2ZW5kb3Igb2YgdGhlIGRldmljZTogDQoNCj09DQogICBBUFBfUkVD IzI6ICBBcHBsaWNhdGlvbnMgcHJvdmlkZWQgYnkgdGhlIG1vYmlsZSBkZXZpY2UgdmVuZG9yIG11 c3QgYmUNCiAgICAgICAgICAgICAgIGluZGVwZW5kZW50IG9mIHRoZSB1bmRlcmx5aW5nIElQIGFk ZHJlc3MgZmFtaWx5Lg0KPT0NCg0KV291bGRuJ3QgdGhpcyByZWNvIGFkZHJlc3NlcyB5b3VyIGNv bmNlcm4/DQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KRGXCoDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIEFsZXhhbmRydSBQZXRyZXNjdSBFbnZvecOpwqA6IGpldWRpIDEyIGbDqXZy aWVyIDIwMTUgMTc6Mjcgw4DCoDogdjZvcHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFt2Nm9wc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0 IC0gQ19SRUMjOSA0NjRYTEFUDQoNCkhlbGxvLA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgbmV3IHZl cnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpJIGhhdmUgYSBkb3VidCB3aXRoIHJlc3BlY3QgdG8gdGhl IDQ2NFhMQVQgcmVxdWlyZW1lbnQ6DQo+ICAgIENfUkVDIzk6ICBJbiBvcmRlciB0byBlbnN1cmUg SVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkgaW4gYW4gSVB2Ni1vbmx5DQo+ICAgICAgICAgICAgICBk ZXBsb3ltZW50IGNvbnRleHQsIHRoZSBjZWxsdWxhciBob3N0IHNob3VsZCBpbXBsZW1lbnQgdGhl DQo+ICAgICAgICAgICAgICBDdXN0b21lciBTaWRlIFRyYW5zbGF0b3IgKENMQVQsIFtSRkM2ODc3 XSkgZnVuY3Rpb24gd2hpY2gNCj4gICAgICAgICAgICAgIGlzIGNvbXBsaWFudCB3aXRoIFtSRkM2 MDUyXVtSRkM2MTQ1XVtSRkM2MTQ2XS4NCj4NCj4gICAgICAgICAgICAgICAgIENMQVQgZnVuY3Rp b24gaW4gdGhlIGNlbGx1bGFyIGhvc3QgYWxsb3dzIGZvciBJUHY0LW9ubHkNCj4gICAgICAgICAg ICAgICAgIGFwcGxpY2F0aW9uIGFuZCBJUHY0LXJlZmVyYWxzIHRvIHdvcmsgb24gYW4gSVB2Ni1v bmx5DQo+ICAgICAgICAgICAgICAgICBjb25uZWN0aXZpdHkuICBDTEFUIGZ1bmN0aW9uIHJlcXVp cmVzIGEgTkFUNjQgY2FwYWJpbGl0eQ0KPiAgICAgICAgICAgICAgICAgW1JGQzYxNDZdIGluIHRo ZSBjb3JlIG5ldHdvcmsuDQo+DQo+ICAgICAgICAgICAgICAgICBUaGUgSVB2NCBTZXJ2aWNlIENv bnRpbnVpdHkgUHJlZml4IHVzZWQgYnkgQ0xBVCBpcw0KPiAgICAgICAgICAgICAgICAgZGVmaW5l ZCBpbiBbUkZDNzMzNV0uDQoNCkkgdGhpbmsgdGhpcyByZXF1aXJlbWVudCBsZWFkcyB0byBhIHNp dHVhdGlvbiB3aGVyZSB0aGUgbmV0d29yayBvcGVyYXRvciBkZXBsb3lzIElQdjYtbmF0aXZlLW9u bHkgYW5kIElQdjQgYXMgYW4gYWRkLW9uIHBhcnRpYWwgZmVhdHVyZS4NCg0KT24gb25lIGhhbmQs IGl0IGlzIGVuY291cmFnaW5nIHRvIHNlZSBuYXRpdmUgSVB2NiBhbmQgbm8gSVB2NC4NCg0KT24g YW5vdGhlciBoYW5kLCBfcGFydGlhbF8gSVB2NCBzdXBwb3J0IGlzIGEgdGVtcHRhdGlvbiB3aGlj aCBkZWNlaXZlcyBpbiB0aGUgZW5kIC0gIGl0IGxlYWRzIHRvIHR1cm4gb2ZmIElQdjYgYW5kIGNv bWUgYmFjayB0byBnb29kIG9sJyBJUHY0IGFuZCBubyBJUHY2Lg0KDQpUaGUgNDY0WExBVCBpcyBw YXJ0aWFsIElQdjQgc3VwcG9ydDogZG9lcyBub3Qgb2ZmZXIgZnVsbCBJUHY0IGNvbm5lY3Rpdml0 eSB0byB0aGUgc21hcnRwaG9uZS4gIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBhZGRyZXNzIHRoZSBz bWFydHBob25lIGJ5IGl0cyBJUHY0IGFkZHJlc3MgLSBETlMgaXMgcmVxdWlyZWQ7IHRoaXMgbWFr ZXMgaXQgaW1wb3NzaWJsZSB0byBtYWtlIGEgVlBOIHR1bm5lbCwgb3IgTW9iaWxlIElQLiAgT25l IGNhbiBub3QgYSBkZXBsb3kgYSB3aXJlbGVzcyBJUHY0IHJvdXRlciBhbG9uZyB0aGUgcm9hZCBp biBhIHJlbW90ZSBhcmVhLCBmb3IgZXhhbXBsZS4NCg0KVGhpcyBsZWFkcyB0byBhIHNpdHVhdGlv biB3aGVyZSB0aGUgb3BlcmF0b3IgcmVxdWlyZXMgZW5kIHVzZXIgdG8gc3dpdGNoIHRvIGFub3Ro ZXIgQVBOIHdoaWNoIGlzIGxlc3MgSVB2Ni4NCg0KSSB0aGluayBpdCBpcyBub3QgYSBoYXBweSBz aXR1YXRpb24uDQoNCkkgd291bGQgIHN1Z2dlc3QgdG8gcXVhbGlmeSB0aGlzIHJlcXVpcmVtZW50 IGJ5IGFub3RoZXIgcmVxdWlyZW1lbnQuIA0KVGhpcyBpbml0aWFsIHJlcXVpcmVtZW50IHdvdWxk IHN0YXRlIHRoYXQgX2ZpcnN0XywgYmVmb3JlIGFueSB2NC12NiBjb252ZXJzaW9uIG1lY2hhbmlz bSBpcyBjb25zaWRlcmVkLCBib3RoIHRoZSBuZXR3b3JrIGFuZCB0aGUgZW5kIHVzZXIgTVVTVCBp bXBsZW1lbnQgYSBuYXRpdmUgSVB2NCBzdGFjayBhbmQgYSBuYXRpdmUgSVB2NiBzdGFjayAobm90 IHNheSAnZHVhbCcgc3RhY2ssIHdoaWNoIGlzIG11Y2ggb3ZlcmxvYWRlZCkuDQoNCldlIGRvbnQg d2FudCB0byBibG9jayBJUHY0IHVzZSB3aGVuIElQdjYgYXJyaXZlcy4NCg0KQWxleA0KDQoxMi8w Mi8yMDE1IDEzOjQyLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgYSDDqWNyaXQgOg0KPg0KPiBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSVB2NiBPcGVyYXRpb25zIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAg ICAgIFRpdGxlICAgICAgICAgICA6IEFuIEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2 NikgUHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNlcw0KPiAgICAgICAgICBBdXRob3JzICAg ICAgICAgOiBEYXZpZCBCaW5ldA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb2hhbWVk IEJvdWNhZGFpcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGVzIFZpemRhbA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHYW5nIENoZW4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgTmljayBIZWF0bGV5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvc3Mg Q2hhbmRsZXINCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlLTE3LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTgNCj4gCURhdGUgICAg ICAgICAgICA6IDIwMTUtMDItMTINCj4NCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBwcm9maWxlIHRoYXQgaXMgYSBzdXBlcnNldCBvZiB0aGF0IG9mIHRoZQ0KPiAg ICAgY29ubmVjdGlvbiB0byBJUHY2IGNlbGx1bGFyIG5ldHdvcmtzIGRlZmluZWQgaW4gdGhlIElQ djYgZm9yIFRoaXJkDQo+ICAgICBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFAp IENlbGx1bGFyIEhvc3RzIGRvY3VtZW50LiAgVGhpcw0KPiAgICAgZG9jdW1lbnQgZGVmaW5lcyBh biBJUHY2IHByb2ZpbGUgdGhhdCBhIG51bWJlciBvZiBvcGVyYXRvcnMgcmVjb21tZW5kDQo+ICAg ICBpbiBvcmRlciB0byBjb25uZWN0IDNHUFAgbW9iaWxlIGRldmljZXMgdG8gYW4gSVB2Ni1vbmx5 IG9yIGR1YWwtc3RhY2sNCj4gICAgIHdpcmVsZXNzIG5ldHdvcmsgKGluY2x1ZGluZyAzR1BQIGNl bGx1bGFyIG5ldHdvcmsgYW5kIElFRUUgODAyLjExDQo+ICAgICBuZXR3b3JrKSB3aXRoIGEgc3Bl Y2lhbCBmb2N1cyBvbiBJUHY0IHNlcnZpY2UgY29udGludWl0eSBmZWF0dXJlcy4NCj4NCj4gICAg IEJvdGggaG9zdHMgYW5kIGRldmljZXMgd2l0aCBjYXBhYmlsaXR5IHRvIHNoYXJlIHRoZWlyIFdB TiAoV2lkZSBBcmVhDQo+ICAgICBOZXR3b3JrKSBjb25uZWN0aXZpdHkgYXJlIGluIHNjb3BlLg0K Pg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbA0KPiBlLw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcNCj4NCj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsDQo+IGUt MTcNCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj4gSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g djZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPg0KPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCk5PVElD RSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMp IGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHks IGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBv ciB1c2UgZm9yIGFueSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcg YW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2Ug aGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50 cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJp bGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4g DQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkg UmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBU cmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEw IDlCVy4NCg== From nobody Fri Feb 13 03:53:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D351A6FF7 for ; Fri, 13 Feb 2015 03:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rMnkaZO6-5B for ; Fri, 13 Feb 2015 03:53:09 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882B71A6FEF for ; Fri, 13 Feb 2015 03:53:09 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t1DBqx7H013897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 11:53:00 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54DDE59A.8070708@foobar.org> Date: Fri, 13 Feb 2015 11:52:58 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti , Rick Casarez References: <201502111247.t1BCl1Fu003450@irp-lnx1.cisco.com> <54DB5ABA.7090703@foobar.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-v6ops-cidr-prefix@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 11:53:12 -0000 On 12/02/2015 23:59, Lorenzo Colitti wrote: > Reality dictates that routing on 128 bits consumes more resources than > routing on 64 bits. Attempting to enforce that all routing table entries > must be full 128 bits wide will either result in the hardware supporting > fewer routing table entries or in the hardware costing more, neither of > which to anyone's gain. the concern people have is that if you end up with hardware which effectively dictates /64 due to lpm optimisation constraints, this will make it really troublesome to use other prefix lengths. This might or might not be ok for individual boxes with a couple of connected /64s, but once you link this into a routing domain it can cause serious trouble. E.g. in the case of the N5K previously quoted, 16k ipv4 entries makes it a fine box for certain types of ipv4 edge deployment, but the limit of 128 longest prefix match entries for ipv6 means that it's impossible to hook this into an ipv6 IGP routing domain, which means that from a generic ipv6 l3 deployment point of view, the box is nearly useless. >From this point of view, it may be useful to have an RFC to say to vendors "please don't do this because it is actively harmful". Otherwise everyone acknowledges that there is a balance to be drawn between cost and scalability. Maybe this balance could be made more explicit in the draft. Nick From nobody Fri Feb 13 04:28:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF31A700A for ; Fri, 13 Feb 2015 04:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXiAoeNmB06u for ; Fri, 13 Feb 2015 04:28:08 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8072D1A700E for ; Fri, 13 Feb 2015 04:28:06 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DCS0id019684; Fri, 13 Feb 2015 13:28:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7EA1E2041B0; Fri, 13 Feb 2015 13:28:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 73142203F98; Fri, 13 Feb 2015 13:28:56 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DCRadZ028915; Fri, 13 Feb 2015 13:28:00 +0100 Message-ID: <54DDEDB8.90001@gmail.com> Date: Fri, 13 Feb 2015 13:27:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ross Chandler References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> In-Reply-To: <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:28:11 -0000 Le 12/02/2015 20:39, Ross Chandler a écrit : > >> On 12 Feb 2015, at 16:27, Alexandru Petrescu >> wrote: >> >> Hello, >> >> Thank you for this new version of the draft. >> >> I have a doubt with respect to the 464XLAT requirement: >>> C_REC#9: In order to ensure IPv4 service continuity in an >>> IPv6-only deployment context, the cellular host should implement >>> the Customer Side Translator (CLAT, [RFC6877]) function which is >>> compliant with [RFC6052][RFC6145][RFC6146]. >>> >>> CLAT function in the cellular host allows for IPv4-only >>> application and IPv4-referals to work on an IPv6-only >>> connectivity. CLAT function requires a NAT64 capability >>> [RFC6146] in the core network. >>> >>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>> [RFC7335]. >> >> I think this requirement leads to a situation where the network >> operator deploys IPv6-native-only and IPv4 as an add-on partial >> feature. >> >> On one hand, it is encouraging to see native IPv6 and no IPv4. >> >> On another hand, _partial_ IPv4 support is a temptation which >> deceives in the end - it leads to turn off IPv6 and come back to >> good ol' IPv4 and no IPv6. >> >> The 464XLAT is partial IPv4 support: does not offer full IPv4 >> connectivity to the smartphone. It is not possible to address the >> smartphone by its IPv4 address - DNS is required; this makes it >> impossible to make a VPN tunnel, or Mobile IP. One can not a >> deploy a wireless IPv4 router along the road in a remote area, for >> example. > > Alex, > > Are you saying all VPNs impossible or just ones not that don’t go > through NAPT because they don’t use TCP/UDP or something else? > Openvpn and IPSec over TCP/UDP work. In the pure IPv4 case their can > also be problems with PPTP if the CGN doesn’t have an ALG. Maybe some work, I dont doubt. I doubt however a VPN tool which does not query the DNS will work behind 464XLAT. >> This leads to a situation where the operator requires end user to >> switch to another APN which is less IPv6. >> >> I think it is not a happy situation. >> >> I would suggest to qualify this requirement by another >> requirement. This initial requirement would state that _first_, >> before any v4-v6 conversion mechanism is considered, both the >> network and the end user MUST implement a native IPv4 stack and a >> native IPv6 stack (not say 'dual' stack, which is much >> overloaded). >> >> We dont want to block IPv4 use when IPv6 arrives. >> >> Alex > > Perhaps it could be clarified in C_REC#9 that the IPv6-only > deployment context refers to the 3GPP device? The data APN it > accesses could support IPv4, IPv6 and dual-stack IPv4v6 PDP/PDNs. I think the current deployments of 464XLAT use the same APN for both 3GPP and data services. Alex > > > > > BR Ross > From nobody Fri Feb 13 04:38:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01C1A1EF5 for ; Fri, 13 Feb 2015 04:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5OOFcI-lpSR for ; Fri, 13 Feb 2015 04:38:29 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A861A1BA7 for ; Fri, 13 Feb 2015 04:38:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DCcRm6023156 for ; Fri, 13 Feb 2015 13:38:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1883B204227 for ; Fri, 13 Feb 2015 13:39:23 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0F707203CE8 for ; Fri, 13 Feb 2015 13:39:23 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DCc4cf004826 for ; Fri, 13 Feb 2015 13:38:27 +0100 Message-ID: <54DDF02C.8020903@gmail.com> Date: Fri, 13 Feb 2015 13:38:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:38:32 -0000 Lorenzo, I wanted to express my oppinion. I have read your email at the time, and now. When I go through procurements often the vendors ask the RFC list that need to be there. This criterion - the implemented RFC list - primes over all others such as software management, dimensions, price tags, electrical, temperature and noise features. If it were not for these little RFCs there would be no reasonable procurement. That said, I also agree with you when you imply that the list of features in this draft may be too long, or too hard see coherence. If so, then maybe we can try to reduce it a bit? Finally, 'profile' is probably not the right title. It should qualify both the end-user device and the network device. Alex Le 12/02/2015 23:23, Lorenzo Colitti a écrit : > On Wed, Feb 11, 2015 at 4:09 AM, > wrote: > > Can you explicit what do you meant by “harmfully broad”? > > (note, the pointer you provided is not valid because several items > have been removed from the draft since then.) > > > Ok, then. Since you ask, let me copy and paste the text from the > pointer, then, and we can discuss why it is no longer valid. > > ===== > I object to this document on the grounds that it is little more than a > list of (34!) features with little technical justification. I see this > as a problem because: > > 1. It is out of the IETF's mandate. It is not the IETF's job to specify > which features or protocols should or should not be implemented in > hosts. Even the hosts requirements RFCs are careful and sparing in their > language. The IETF is certainly not in the business of rubberstamping > feature wishlists without good technical reasons. I would challenge the > authors to find a precedent RFC containing such broad requirements. > > 2. It is over-broad. The vast majority of the features are in no way > necessary to build a mobile device that works well over IPv6. Today, the > overwhelming majority of mobile device traffic comes from devices that > implement only a handful of these requirements. More specifically, > requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, > #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, > #32 (which cover all applications running on the device - yes, all of > them), and #34, are not necessary to connect to IPv6 mobile networks. > > 3. It is so daunting as to act as a deterrent to IPv6 deployment. I > would challenge the authors to find a single product today that > implements all, or even a substantial majority, of these requirements. > It seems to me that the sheer length of the list, and the fact that is > not prioritized, create a real risk that implementors will simply write > it off as wishful thinking or even shy away in terror. > > 4. The document has few technical contributions of its own. Most of the > requirements are simply listed one after another. > > I'm all for IPv6 deployment in mobile networks, but making a list of > what seems like all the features that the IETF has ever developed, and > then saying that they all need to be implemented, is not the way to get > there. The way to do it is to document use cases and working scenarios > gleaned from operational experience. > ==== > > The way I see it, the recent changes made to the document do nothing to > address the substance of those points. > > It's true that the document no longer lists 34 features, only 23, but it > looks like the reduction has been mostly effected by removing features > that were already mandatory IETF or 3GPP requirements (e.g., REQ#1, > "must support IPv6 addressing architecture and ICMPv6 node > requirements", REQ#6, "must support IPv6 neighbour discovery") and > coalescing multiple features into one, (e.g., REQ_2 and REQ_3 were > merged into C_REC#2). > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Feb 13 04:50:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39171A7013 for ; Fri, 13 Feb 2015 04:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9to-tfSELooi for ; Fri, 13 Feb 2015 04:50:32 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959F31A6F29 for ; Fri, 13 Feb 2015 04:50:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DCoTiX011700; Fri, 13 Feb 2015 13:50:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11DE1204205; Fri, 13 Feb 2015 13:51:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 06B42200C80; Fri, 13 Feb 2015 13:51:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DCoD7U015219; Fri, 13 Feb 2015 13:50:29 +0100 Message-ID: <54DDF305.8080401@gmail.com> Date: Fri, 13 Feb 2015 13:50:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:50:35 -0000 Le 13/02/2015 07:49, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > The intent of this reco is to address broken IPv4-only applications > over an IPv6-only connectivity. Ok, makes sense. > Ideally applications running on the device should be AF-independent. That is an ideal, laudable goal. There a number of professional applications that are Address Family dependent, and which do not query DNS to find an address. They may distribute it by SDN. > The draft relies on the IPv6 node requirements RFC that mandates the > supports of IPv6. Also, the I-D calls out applications that are > provided by the vendor of the device: > > == APP_REC#2: Applications provided by the mobile device vendor > must be independent of the underlying IP address family. == > > Wouldn't this reco addresses your concern? PArtially yes. But is it feasible to recommend something to the 3rd party providers of applications? Is the mobile device vendor realizing that the 3rd party providers may prefer to connect to an IPv4-only APN instead of a 464XLAT APN? Alex > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : Re: > [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT requirement: >> C_REC#9: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular host should implement >> the Customer Side Translator (CLAT, [RFC6877]) function which is >> compliant with [RFC6052][RFC6145][RFC6146]. >> >> CLAT function in the cellular host allows for IPv4-only >> application and IPv4-referals to work on an IPv6-only connectivity. >> CLAT function requires a NAT64 capability [RFC6146] in the core >> network. >> >> The IPv4 Service Continuity Prefix used by CLAT is defined in >> [RFC7335]. > > I think this requirement leads to a situation where the network > operator deploys IPv6-native-only and IPv4 as an add-on partial > feature. > > On one hand, it is encouraging to see native IPv6 and no IPv4. > > On another hand, _partial_ IPv4 support is a temptation which > deceives in the end - it leads to turn off IPv6 and come back to > good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not offer full IPv4 > connectivity to the smartphone. It is not possible to address the > smartphone by its IPv4 address - DNS is required; this makes it > impossible to make a VPN tunnel, or Mobile IP. One can not a deploy > a wireless IPv4 router along the road in a remote area, for example. > > This leads to a situation where the operator requires end user to > switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by another requirement. > This initial requirement would state that _first_, before any v4-v6 > conversion mechanism is considered, both the network and the end > user MUST implement a native IPv4 stack and a native IPv6 stack (not > say 'dual' stack, which is much overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations >> Working Group of the IETF. >> >> Title : An Internet Protocol Version 6 (IPv6) Profile >> for 3GPP Mobile Devices Authors : David Binet Mohamed >> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages >> : 18 Date : 2015-02-12 >> >> Abstract: This document defines a profile that is a superset of >> that of the connection to IPv6 cellular networks defined in the >> IPv6 for Third Generation Partnership Project (3GPP) Cellular >> Hosts document. This document defines an IPv6 profile that a >> number of operators recommend in order to connect 3GPP mobile >> devices to an IPv6-only or dual-stack wireless network (including >> 3GPP cellular network and IEEE 802.11 network) with a special focus >> on IPv4 service continuity features. >> >> Both hosts and devices with capability to share their WAN (Wide >> Area Network) connectivity are in scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >> >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >> >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-17 >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Feb 13 04:52:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD101A6FFA for ; Fri, 13 Feb 2015 04:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij9QgytkIK85 for ; Fri, 13 Feb 2015 04:52:18 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFE81A6F29 for ; Fri, 13 Feb 2015 04:52:17 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DCqEDD012248; Fri, 13 Feb 2015 13:52:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6C9832042F4; Fri, 13 Feb 2015 13:53:10 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5EED8203CE8; Fri, 13 Feb 2015 13:53:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DCqDlx016811; Fri, 13 Feb 2015 13:52:14 +0100 Message-ID: <54DDF37D.1050405@gmail.com> Date: Fri, 13 Feb 2015 13:52:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Heatley, Nick" , "mohamed.boucadair@orange.com" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:52:21 -0000 Le 13/02/2015 11:13, Heatley, Nick a écrit : > A statement such as >> The device should only invoke the CLAT in the absence of a the IPv4 >> AF i.e. when the network does not assign an IPv4 cellular address > could be helpful? > > To go further, and define any additional requirement, then that would > be defining how an Operator could/should manage their remaining IPv4 > public and private addressing. This paper should only focus on the > required device behaviour. > > As an aside 464xlat is a direct replacement for the NAT44 > environments, typical in mobile operators with large consumer bases. Nick, Am I wrong to say that one can not ping 8.8.8.8 from behind a 464xlat, whereas one can ping 8.8.8.8 behind a nat44? If I am not wrong then 464xlat and nat44 are not really equivalent. Alex > Ideal if an operator is exhausting both public and private address > space. If an operator has ample public IPv4 and has consumer products > that are NAT44-free, then they are in a different place (a utopia). > Nick > > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To: > Alexandru Petrescu Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D > Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 > 464XLAT > > Hi Alex, > > The intent of this reco is to address broken IPv4-only applications > over an IPv6-only connectivity. Ideally applications running on the > device should be AF-independent. > > The draft relies on the IPv6 node requirements RFC that mandates the > supports of IPv6. Also, the I-D calls out applications that are > provided by the vendor of the device: > > == APP_REC#2: Applications provided by the mobile device vendor must > be independent of the underlying IP address family. == > > Wouldn't this reco addresses your concern? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : Re: > [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT requirement: >> C_REC#9: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular host should implement >> the Customer Side Translator (CLAT, [RFC6877]) function which is >> compliant with [RFC6052][RFC6145][RFC6146]. >> >> CLAT function in the cellular host allows for IPv4-only application >> and IPv4-referals to work on an IPv6-only connectivity. CLAT >> function requires a NAT64 capability [RFC6146] in the core >> network. >> >> The IPv4 Service Continuity Prefix used by CLAT is defined in >> [RFC7335]. > > I think this requirement leads to a situation where the network > operator deploys IPv6-native-only and IPv4 as an add-on partial > feature. > > On one hand, it is encouraging to see native IPv6 and no IPv4. > > On another hand, _partial_ IPv4 support is a temptation which > deceives in the end - it leads to turn off IPv6 and come back to > good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not offer full IPv4 > connectivity to the smartphone. It is not possible to address the > smartphone by its IPv4 address - DNS is required; this makes it > impossible to make a VPN tunnel, or Mobile IP. One can not a deploy > a wireless IPv4 router along the road in a remote area, for example. > > This leads to a situation where the operator requires end user to > switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by another requirement. > This initial requirement would state that _first_, before any v4-v6 > conversion mechanism is considered, both the network and the end user > MUST implement a native IPv4 stack and a native IPv6 stack (not say > 'dual' stack, which is much overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations >> Working Group of the IETF. >> >> Title : An Internet Protocol Version 6 (IPv6) Profile for >> 3GPP Mobile Devices Authors : David Binet Mohamed >> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename >> : draft-ietf-v6ops-mobile-device-profile-17.txt Pages : >> 18 Date : 2015-02-12 >> >> Abstract: This document defines a profile that is a superset of >> that of the connection to IPv6 cellular networks defined in the >> IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts >> document. This document defines an IPv6 profile that a number of >> operators recommend in order to connect 3GPP mobile devices to an >> IPv6-only or dual-stack wireless network (including 3GPP cellular >> network and IEEE 802.11 network) with a special focus on IPv4 >> service continuity features. >> >> Both hosts and devices with capability to share their WAN (Wide >> Area Network) connectivity are in scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profil >> >> e/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profil >> >> e-17 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > NOTICE AND DISCLAIMER This e-mail (including any attachments) is > intended for the above-named person(s). If you are not the intended > recipient, notify the sender immediately, delete this email from your > system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely affect you. > > EE Limited Registered in England and Wales Company Registered Number: > 02382161 Registered Office Address: Trident Place, Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > From nobody Fri Feb 13 05:00:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66B61A7013 for ; Fri, 13 Feb 2015 05:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMo_YNq3LIPI for ; Fri, 13 Feb 2015 05:00:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC7B1A1B27 for ; Fri, 13 Feb 2015 05:00:38 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DA00722C75E; Fri, 13 Feb 2015 14:00:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B81994C125; Fri, 13 Feb 2015 14:00:36 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 14:00:36 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQR4ubH0P8VsyAQ0msn8bBnn4Z5ZzuiLAg Date: Fri, 13 Feb 2015 13:00:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490ACC7@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF305.8080401@gmail.com> In-Reply-To: <54DDF305.8080401@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.120922 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 13:00:49 -0000 Re-, Please see inline. Cheers, Med -----Message d'origine----- De=A0: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Envoy=E9=A0: vendredi 13 f=E9vrier 2015 13:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: v6ops@ietf.org Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17= .txt - C_REC#9 464XLAT Le 13/02/2015 07:49, mohamed.boucadair@orange.com a =E9crit : > Hi Alex, > > The intent of this reco is to address broken IPv4-only applications > over an IPv6-only connectivity. Ok, makes sense. > Ideally applications running on the device should be AF-independent. That is an ideal, laudable goal. There a number of professional applications that are Address Family=20 dependent, and which do not query DNS to find an address. They may=20 distribute it by SDN. > The draft relies on the IPv6 node requirements RFC that mandates the > supports of IPv6. Also, the I-D calls out applications that are > provided by the vendor of the device: > > =3D=3D APP_REC#2: Applications provided by the mobile device vendor > must be independent of the underlying IP address family. =3D=3D > > Wouldn't this reco addresses your concern? PArtially yes. But is it feasible to recommend something to the 3rd party providers of=20 applications? [Med] FWIW, the wording we had for this reco is among the lines you are hin= ting:=20 " REQ#33: Applications MUST be independent of the underlying IP address family. " but we changed the wording to cover applications that under the responsibil= ity of the device vendor. This change was a result of a comment we received= in the mailing list. That comment was fair IMHO. Is the mobile device vendor realizing that the 3rd party providers may=20 prefer to connect to an IPv4-only APN instead of a 464XLAT APN? [Med] This can be part of the internal validation process of the device ven= dors. I don't think we should interfere with those. Also, applications can = be installed by the user so there is no guarantee those applications will b= ehave well when IPv6 connectivity is provided. FYI, the reason we initially= included this reco is that an app store from a vendor that is known to sup= port IPv6 from a while is broken when an IPv6-only connectivity is in place= . Having APP_REC#2 satisfied is already a high bar. Alex > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoy=E9 : jeudi 12 f=E9vrier 2015 17:27 =C0 : v6ops@ietf.org Objet : Re: > [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT requirement: >> C_REC#9: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular host should implement >> the Customer Side Translator (CLAT, [RFC6877]) function which is >> compliant with [RFC6052][RFC6145][RFC6146]. >> >> CLAT function in the cellular host allows for IPv4-only >> application and IPv4-referals to work on an IPv6-only connectivity. >> CLAT function requires a NAT64 capability [RFC6146] in the core >> network. >> >> The IPv4 Service Continuity Prefix used by CLAT is defined in >> [RFC7335]. > > I think this requirement leads to a situation where the network > operator deploys IPv6-native-only and IPv4 as an add-on partial > feature. > > On one hand, it is encouraging to see native IPv6 and no IPv4. > > On another hand, _partial_ IPv4 support is a temptation which > deceives in the end - it leads to turn off IPv6 and come back to > good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not offer full IPv4 > connectivity to the smartphone. It is not possible to address the > smartphone by its IPv4 address - DNS is required; this makes it > impossible to make a VPN tunnel, or Mobile IP. One can not a deploy > a wireless IPv4 router along the road in a remote area, for example. > > This leads to a situation where the operator requires end user to > switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by another requirement. > This initial requirement would state that _first_, before any v4-v6 > conversion mechanism is considered, both the network and the end > user MUST implement a native IPv4 stack and a native IPv6 stack (not > say 'dual' stack, which is much overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org a =E9crit : >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations >> Working Group of the IETF. >> >> Title : An Internet Protocol Version 6 (IPv6) Profile >> for 3GPP Mobile Devices Authors : David Binet Mohamed >> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages >> : 18 Date : 2015-02-12 >> >> Abstract: This document defines a profile that is a superset of >> that of the connection to IPv6 cellular networks defined in the >> IPv6 for Third Generation Partnership Project (3GPP) Cellular >> Hosts document. This document defines an IPv6 profile that a >> number of operators recommend in order to connect 3GPP mobile >> devices to an IPv6-only or dual-stack wireless network (including >> 3GPP cellular network and IEEE 802.11 network) with a special focus >> on IPv4 service continuity features. >> >> Both hosts and devices with capability to share their WAN (Wide >> Area Network) connectivity are in scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >> >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >> >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profil= e-17 >> >> >> >> >> Please note that it may take a couple of minutes from the time of submissio= n >> until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Feb 13 05:14:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE6D1A7033 for ; Fri, 13 Feb 2015 05:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTKLfbOgxz2P for ; Fri, 13 Feb 2015 05:14:08 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053741A702C for ; Fri, 13 Feb 2015 05:14:07 -0800 (PST) Received: from [85.158.136.3] by server-13.bemta-5.messagelabs.com id 79/D2-02801-E98FDD45; Fri, 13 Feb 2015 13:14:06 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-12.tower-123.messagelabs.com!1423833245!34751363!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23182 invoked from network); 13 Feb 2015 13:14:05 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-12.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 13:14:05 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Fri, 13 Feb 2015 13:13:59 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 13 Feb 2015 13:14:04 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 13:14:04 +0000 From: "Heatley, Nick" To: Alexandru Petrescu , "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZzuJKAAgAA1/FCAAC9ogIAABSbA Date: Fri, 13 Feb 2015 13:14:03 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> In-Reply-To: <54DDF37D.1050405@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 13:14:12 -0000 SGkgQWxleCwNClllcywgdGhhdCBpcyB3cm9uZy4NCllvdSBjYW4gcGluZyBhbnkgSVB2NCBsaXRl cmFsIGZyb20gYSA0NjR4bGF0IGRldmljZS4NCk15IGhhbmRzZXQgb25seSBoYXMgYW4gSVB2NiBh ZGRyZXNzICsgQ0xBVCBhbmQgSSBhbSBwaW5naW5nIDguOC44LjggOi0pKQ0KSW50ZXJuZXQtc2lk ZSBpbml0aWF0ZWQgdHJhZmZpYyB3b3VsZCBiZSBhbiBpc3N1ZSwgc2FtZSBhcyBOQVQ0NCBDR04u DQpOaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kcnUgUGV0 cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSANClNlbnQ6IDEzIEZl YnJ1YXJ5IDIwMTUgMTI6NTINClRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENf UkVDIzkgNDY0WExBVA0KDQpMZSAxMy8wMi8yMDE1IDExOjEzLCBIZWF0bGV5LCBOaWNrIGEgw6lj cml0IDoNCj4gQSBzdGF0ZW1lbnQgc3VjaCBhcw0KPj4gVGhlIGRldmljZSBzaG91bGQgb25seSBp bnZva2UgdGhlIENMQVQgaW4gdGhlIGFic2VuY2Ugb2YgYSB0aGUgSVB2NCANCj4+IEFGIGkuZS4g d2hlbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhc3NpZ24gYW4gSVB2NCBjZWxsdWxhciBhZGRyZXNz DQo+IGNvdWxkIGJlIGhlbHBmdWw/DQo+DQo+IFRvIGdvIGZ1cnRoZXIsIGFuZCBkZWZpbmUgYW55 IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQsIHRoZW4gdGhhdCB3b3VsZCANCj4gYmUgZGVmaW5pbmcg aG93IGFuIE9wZXJhdG9yIGNvdWxkL3Nob3VsZCBtYW5hZ2UgdGhlaXIgcmVtYWluaW5nIElQdjQg DQo+IHB1YmxpYyBhbmQgcHJpdmF0ZSBhZGRyZXNzaW5nLiBUaGlzIHBhcGVyIHNob3VsZCBvbmx5 IGZvY3VzIG9uIHRoZSANCj4gcmVxdWlyZWQgZGV2aWNlIGJlaGF2aW91ci4NCj4NCj4gQXMgYW4g YXNpZGUgNDY0eGxhdCBpcyBhIGRpcmVjdCByZXBsYWNlbWVudCBmb3IgdGhlIE5BVDQ0IA0KPiBl bnZpcm9ubWVudHMsIHR5cGljYWwgaW4gbW9iaWxlIG9wZXJhdG9ycyB3aXRoIGxhcmdlIGNvbnN1 bWVyIGJhc2VzLg0KDQpOaWNrLA0KDQpBbSBJIHdyb25nIHRvIHNheSB0aGF0IG9uZSBjYW4gbm90 IHBpbmcgOC44LjguOCBmcm9tIGJlaGluZCBhIDQ2NHhsYXQsIHdoZXJlYXMgb25lIGNhbiBwaW5n IDguOC44LjggYmVoaW5kIGEgbmF0NDQ/DQoNCklmIEkgYW0gbm90IHdyb25nIHRoZW4gNDY0eGxh dCBhbmQgbmF0NDQgYXJlIG5vdCByZWFsbHkgZXF1aXZhbGVudC4NCg0KQWxleA0KDQo+IElkZWFs IGlmIGFuIG9wZXJhdG9yIGlzIGV4aGF1c3RpbmcgYm90aCBwdWJsaWMgYW5kIHByaXZhdGUgYWRk cmVzcyANCj4gc3BhY2UuIElmIGFuIG9wZXJhdG9yIGhhcyBhbXBsZSBwdWJsaWMgSVB2NCBhbmQg aGFzIGNvbnN1bWVyIHByb2R1Y3RzIA0KPiB0aGF0IGFyZSBOQVQ0NC1mcmVlLCB0aGVuIHRoZXkg YXJlIGluIGEgZGlmZmVyZW50IHBsYWNlIChhIHV0b3BpYSkuDQo+IE5pY2sNCj4NCj4NCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSANCj4gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20g U2VudDogMTMgRmVicnVhcnkgMjAxNSAwNjo0OSANCj4gVG86DQo+IEFsZXhhbmRydSBQZXRyZXNj dSBDYzogdjZvcHNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EDQo+IEFjdGlvbjog ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19SRUMjOSAN Cj4gNDY0WExBVA0KPg0KPiBIaSBBbGV4LA0KPg0KPiBUaGUgaW50ZW50IG9mIHRoaXMgcmVjbyBp cyB0byBhZGRyZXNzIGJyb2tlbiBJUHY0LW9ubHkgYXBwbGljYXRpb25zIA0KPiBvdmVyIGFuIElQ djYtb25seSBjb25uZWN0aXZpdHkuIElkZWFsbHkgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdGhl IA0KPiBkZXZpY2Ugc2hvdWxkIGJlIEFGLWluZGVwZW5kZW50Lg0KPg0KPiBUaGUgZHJhZnQgcmVs aWVzIG9uIHRoZSBJUHY2IG5vZGUgcmVxdWlyZW1lbnRzIFJGQyB0aGF0IG1hbmRhdGVzIHRoZSAN Cj4gc3VwcG9ydHMgb2YgSVB2Ni4gQWxzbywgdGhlIEktRCBjYWxscyBvdXQgYXBwbGljYXRpb25z IHRoYXQgYXJlIA0KPiBwcm92aWRlZCBieSB0aGUgdmVuZG9yIG9mIHRoZSBkZXZpY2U6DQo+DQo+ ID09IEFQUF9SRUMjMjogIEFwcGxpY2F0aW9ucyBwcm92aWRlZCBieSB0aGUgbW9iaWxlIGRldmlj ZSB2ZW5kb3IgbXVzdCANCj4gYmUgaW5kZXBlbmRlbnQgb2YgdGhlIHVuZGVybHlpbmcgSVAgYWRk cmVzcyBmYW1pbHkuID09DQo+DQo+IFdvdWxkbid0IHRoaXMgcmVjbyBhZGRyZXNzZXMgeW91ciBj b25jZXJuPw0KPg0KPiBUaGFuayB5b3UuDQo+DQo+IENoZWVycywgTWVkDQo+DQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLSBEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gDQo+IERlIGxhIHBhcnQgZGUgQWxleGFuZHJ1IFBldHJlc2N1IEVudm95w6kgOiBqZXVk aSAxMiBmw6l2cmllciAyMDE1IDE3OjI3IA0KPiDDgCA6IHY2b3BzQGlldGYub3JnIE9iamV0IDog UmU6DQo+IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNl LXByb2ZpbGUtMTcudHh0IC0NCj4gQ19SRUMjOSA0NjRYTEFUDQo+DQo+IEhlbGxvLA0KPg0KPiBU aGFuayB5b3UgZm9yIHRoaXMgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPg0KPiBJIGhhdmUg YSBkb3VidCB3aXRoIHJlc3BlY3QgdG8gdGhlIDQ2NFhMQVQgcmVxdWlyZW1lbnQ6DQo+PiBDX1JF QyM5OiAgSW4gb3JkZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQ djYtb25seSANCj4+IGRlcGxveW1lbnQgY29udGV4dCwgdGhlIGNlbGx1bGFyIGhvc3Qgc2hvdWxk IGltcGxlbWVudCB0aGUgQ3VzdG9tZXIgDQo+PiBTaWRlIFRyYW5zbGF0b3IgKENMQVQsIFtSRkM2 ODc3XSkgZnVuY3Rpb24gd2hpY2ggaXMgY29tcGxpYW50IHdpdGggDQo+PiBbUkZDNjA1Ml1bUkZD NjE0NV1bUkZDNjE0Nl0uDQo+Pg0KPj4gQ0xBVCBmdW5jdGlvbiBpbiB0aGUgY2VsbHVsYXIgaG9z dCBhbGxvd3MgZm9yIElQdjQtb25seSBhcHBsaWNhdGlvbiANCj4+IGFuZCBJUHY0LXJlZmVyYWxz IHRvIHdvcmsgb24gYW4gSVB2Ni1vbmx5IGNvbm5lY3Rpdml0eS4gIENMQVQgDQo+PiBmdW5jdGlv biByZXF1aXJlcyBhIE5BVDY0IGNhcGFiaWxpdHkgW1JGQzYxNDZdIGluIHRoZSBjb3JlIG5ldHdv cmsuDQo+Pg0KPj4gVGhlIElQdjQgU2VydmljZSBDb250aW51aXR5IFByZWZpeCB1c2VkIGJ5IENM QVQgaXMgZGVmaW5lZCBpbiANCj4+IFtSRkM3MzM1XS4NCj4NCj4gSSB0aGluayB0aGlzIHJlcXVp cmVtZW50IGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBuZXR3b3JrIA0KPiBvcGVyYXRv ciBkZXBsb3lzIElQdjYtbmF0aXZlLW9ubHkgYW5kIElQdjQgYXMgYW4gYWRkLW9uIHBhcnRpYWwg DQo+IGZlYXR1cmUuDQo+DQo+IE9uIG9uZSBoYW5kLCBpdCBpcyBlbmNvdXJhZ2luZyB0byBzZWUg bmF0aXZlIElQdjYgYW5kIG5vIElQdjQuDQo+DQo+IE9uIGFub3RoZXIgaGFuZCwgX3BhcnRpYWxf IElQdjQgc3VwcG9ydCBpcyBhIHRlbXB0YXRpb24gd2hpY2ggZGVjZWl2ZXMgDQo+IGluIHRoZSBl bmQgLSAgaXQgbGVhZHMgdG8gdHVybiBvZmYgSVB2NiBhbmQgY29tZSBiYWNrIHRvIGdvb2Qgb2wn IElQdjQgDQo+IGFuZCBubyBJUHY2Lg0KPg0KPiBUaGUgNDY0WExBVCBpcyBwYXJ0aWFsIElQdjQg c3VwcG9ydDogZG9lcyBub3Qgb2ZmZXIgZnVsbCBJUHY0IA0KPiBjb25uZWN0aXZpdHkgdG8gdGhl IHNtYXJ0cGhvbmUuICBJdCBpcyBub3QgcG9zc2libGUgdG8gYWRkcmVzcyB0aGUgDQo+IHNtYXJ0 cGhvbmUgYnkgaXRzIElQdjQgYWRkcmVzcyAtIEROUyBpcyByZXF1aXJlZDsgdGhpcyBtYWtlcyBp dCANCj4gaW1wb3NzaWJsZSB0byBtYWtlIGEgVlBOIHR1bm5lbCwgb3IgTW9iaWxlIElQLiAgT25l IGNhbiBub3QgYSBkZXBsb3kgYSANCj4gd2lyZWxlc3MgSVB2NCByb3V0ZXIgYWxvbmcgdGhlIHJv YWQgaW4gYSByZW1vdGUgYXJlYSwgZm9yIGV4YW1wbGUuDQo+DQo+IFRoaXMgbGVhZHMgdG8gYSBz aXR1YXRpb24gd2hlcmUgdGhlIG9wZXJhdG9yIHJlcXVpcmVzIGVuZCB1c2VyIHRvIA0KPiBzd2l0 Y2ggdG8gYW5vdGhlciBBUE4gd2hpY2ggaXMgbGVzcyBJUHY2Lg0KPg0KPiBJIHRoaW5rIGl0IGlz IG5vdCBhIGhhcHB5IHNpdHVhdGlvbi4NCj4NCj4gSSB3b3VsZCAgc3VnZ2VzdCB0byBxdWFsaWZ5 IHRoaXMgcmVxdWlyZW1lbnQgYnkgYW5vdGhlciByZXF1aXJlbWVudC4NCj4gVGhpcyBpbml0aWFs IHJlcXVpcmVtZW50IHdvdWxkIHN0YXRlIHRoYXQgX2ZpcnN0XywgYmVmb3JlIGFueSB2NC12NiAN Cj4gY29udmVyc2lvbiBtZWNoYW5pc20gaXMgY29uc2lkZXJlZCwgYm90aCB0aGUgbmV0d29yayBh bmQgdGhlIGVuZCB1c2VyIA0KPiBNVVNUIGltcGxlbWVudCBhIG5hdGl2ZSBJUHY0IHN0YWNrIGFu ZCBhIG5hdGl2ZSBJUHY2IHN0YWNrIChub3Qgc2F5IA0KPiAnZHVhbCcgc3RhY2ssIHdoaWNoIGlz IG11Y2ggb3ZlcmxvYWRlZCkuDQo+DQo+IFdlIGRvbnQgd2FudCB0byBibG9jayBJUHY0IHVzZSB3 aGVuIElQdjYgYXJyaXZlcy4NCj4NCj4gQWxleA0KPg0KPiAxMi8wMi8yMDE1IDEzOjQyLCBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgYSDDqWNyaXQgOg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCj4+IGRp cmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE9wZXJhdGlv bnMgV29ya2luZyANCj4+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4NCj4+IFRpdGxlICAgICAgICAg ICA6IEFuIEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3INCj4+ IDNHUFAgTW9iaWxlIERldmljZXMgQXV0aG9ycyAgICAgICAgIDogRGF2aWQgQmluZXQgTW9oYW1l ZA0KPj4gQm91Y2FkYWlyIEFsZXMgVml6ZGFsIEdhbmcgQ2hlbiBOaWNrIEhlYXRsZXkgUm9zcyBD aGFuZGxlciBGaWxlbmFtZQ0KPj4gOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJv ZmlsZS0xNy50eHQgUGFnZXMgICAgICAgICAgIDoNCj4+IDE4IERhdGUgICAgICAgICAgICA6IDIw MTUtMDItMTINCj4+DQo+PiBBYnN0cmFjdDogVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgcHJvZmls ZSB0aGF0IGlzIGEgc3VwZXJzZXQgb2YgdGhhdCANCj4+IG9mIHRoZSBjb25uZWN0aW9uIHRvIElQ djYgY2VsbHVsYXIgbmV0d29ya3MgZGVmaW5lZCBpbiB0aGUNCj4+IElQdjYgZm9yIFRoaXJkIEdl bmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCkgQ2VsbHVsYXIgSG9zdHMgDQo+PiBk b2N1bWVudC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBJUHY2IHByb2ZpbGUgdGhhdCBhIG51 bWJlciBvZiANCj4+IG9wZXJhdG9ycyByZWNvbW1lbmQgaW4gb3JkZXIgdG8gY29ubmVjdCAzR1BQ IG1vYmlsZSBkZXZpY2VzIHRvIGFuIA0KPj4gSVB2Ni1vbmx5IG9yIGR1YWwtc3RhY2sgd2lyZWxl c3MgbmV0d29yayAoaW5jbHVkaW5nIDNHUFAgY2VsbHVsYXIgDQo+PiBuZXR3b3JrIGFuZCBJRUVF IDgwMi4xMSBuZXR3b3JrKSB3aXRoIGEgc3BlY2lhbCBmb2N1cyBvbiBJUHY0IHNlcnZpY2UgDQo+ PiBjb250aW51aXR5IGZlYXR1cmVzLg0KPj4NCj4+IEJvdGggaG9zdHMgYW5kIGRldmljZXMgd2l0 aCBjYXBhYmlsaXR5IHRvIHNoYXJlIHRoZWlyIFdBTiAoV2lkZSBBcmVhIA0KPj4gTmV0d29yaykg Y29ubmVjdGl2aXR5IGFyZSBpbiBzY29wZS4NCj4+DQo+Pg0KPj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmkNCj4+IGwN Cj4+DQo+Pg0KZS8NCj4+DQo+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMt bW9iaWxlLWRldmljZS1wcm9maWxlLTE3DQo+Pg0KPj4NCj4+DQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmkNCj4+IGwNCj4+ DQo+Pg0KZS0xNw0KPj4NCj4+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4+IHRvb2xzLmll dGYub3JnLg0KPj4NCj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZv cHMgbWFpbGluZyBsaXN0IA0KPj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdCANCj4gdjZv cHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9w cyBtYWlsaW5nIGxpc3QgDQo+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCj4gTk9USUNFIEFORCBESVNDTEFJTUVSIFRoaXMgZS1t YWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyANCj4gaW50ZW5kZWQgZm9yIHRoZSBh Ym92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgDQo+IHJl Y2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWls IGZyb20geW91ciANCj4gc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkg cHVycG9zZS4NCj4NCj4gV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBl bWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgDQo+IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2Vu IHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIA0KPiBhdHRhY2htZW50cyBhcmUg ZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciANCj4gcmVzcG9uc2liaWxp dHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuDQo+ DQo+IEVFIExpbWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBDb21wYW55IFJl Z2lzdGVyZWQgTnVtYmVyOg0KPiAwMjM4MjE2MSBSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBU cmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIA0KPiBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwg QUwxMCA5QlcuDQo+DQoNCg0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVk IHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lz dGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2Ug bWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRo IGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQg dGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBp dCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVu Z2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVn aXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRm aWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcuDQo= From nobody Fri Feb 13 06:05:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605881A7D84 for ; Fri, 13 Feb 2015 06:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM6MIWwFpFMu for ; Fri, 13 Feb 2015 06:05:42 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395581A7D82 for ; Fri, 13 Feb 2015 06:05:41 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 5b40ed45.2b713bc65940.2753160.00-2482.7631775.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 13 Feb 2015 14:05:41 +0000 (UTC) X-MXL-Hash: 54de04b52a0e416e-8887eeca4d6afb2a97fdc8a2e40c787cb1dd52d4 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 3b40ed45.0.2753146.00-2219.7631728.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 13 Feb 2015 14:05:40 +0000 (UTC) X-MXL-Hash: 54de04b448fe7dcf-20d36975c1d86c5a9a412953bf00e85c0e7ecb57 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DE5cmv021019; Fri, 13 Feb 2015 09:05:39 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DE5Wll020952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Feb 2015 09:05:33 -0500 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 13 Feb 2015 14:05:23 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.126]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 09:05:23 -0500 From: "STARK, BARBARA H" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABSNY8AAB3XhwAACIyKIA== Date: Fri, 13 Feb 2015 14:05:23 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> In-Reply-To: <54DDF02C.8020903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ApVZKpBP c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=vKzWRVGcsRAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=SgCuRERWA] X-AnalysisOut: [AAA:8 a=wP04zbwDicQiNb1o5OoA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:05:46 -0000 > When I go through procurements often the vendors ask the RFC list that > need to be there. This criterion - the implemented RFC list - primes ove= r all > others such as software management, dimensions, price tags, electrical, > temperature and noise features. If it were not for these little RFCs the= re > would be no reasonable procurement. >=20 > That said, I also agree with you when you imply that the list of features= in this > draft may be too long, or too hard see coherence. >=20 > If so, then maybe we can try to reduce it a bit? >=20 > Finally, 'profile' is probably not the right title. It should qualify bo= th the end- > user device and the network device. Inside the company I work for, I try to encourage "thoughtful" use of "devi= ce profile" RFCs such as this draft may become. That is, read through the e= ntire RFC, and make sure you want everything that's mandated. If you don't,= pick and choose what makes sense for the product you are procuring. I woul= d definitely not recommend to anyone (inside or outside my company) that th= ey ask for compliance with this document without fully understanding the im= plications of what they are asking for. Basically, I see the items listed i= n the draft as a set of potential items to consider when putting together a= n RFP. As it relates to IPv6 "device profile" documents, I would like to mention t= hat CableLabs has been successful with its eRouter spec, BBF successful wit= h its TR-124, and I'm hoping CEA has impact on the CE industry with its new= CEA2048 publication (which they're offering for free through Feb 28 -- see= http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e8185ea241297a2952= 9). There does seem to be demand for "device profile" documents. I do think= the only reason RFC 7084 (which really is a "device profile" RFC) was done= in IETF was because of the need to identify requirements for CE routers th= at could connect to a variety of access network architecture, and IETF was = "neutral territory". I admit to finding it odd that IETF would be used to p= ublish a device profile that is only for devices connecting to 3GPP access = networks. But I'm not familiar with how 3GPP works, so maybe it wasn't poss= ible to get 3GPP to be willing to create a profile for devices that attach = to their access network. BTW, I'm very concerned about the fact that someone affiliated with a provi= der of an OS found on many 3GPP devices has so many objections to this par= ticular "device profile". Knowing that, I would very, very strongly recomme= nd to people I work with that they be very, very careful about how they use= this particular "device profile" (if at all). I would not suggest includin= g it directly in any RFP. From nobody Fri Feb 13 06:22:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF961A870A for ; Fri, 13 Feb 2015 06:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D3azr1WKJku for ; Fri, 13 Feb 2015 06:22:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6501A8701 for ; Fri, 13 Feb 2015 06:22:07 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7A4C72DC18A; Fri, 13 Feb 2015 15:22:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 564AA4C0FD; Fri, 13 Feb 2015 15:22:06 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 15:22:06 +0100 From: To: "STARK, BARBARA H" , Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852Otdv8/yjdEkq8+myPex9adwBSNY8AAB3XhwAACIyKIAAPg5rw Date: Fri, 13 Feb 2015 14:22:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490AE50@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.120922 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:22:13 -0000 Barbara,=20 FYI as part of the IESF review of this I-D, 3GPP was queried and stated tha= t it had no interest in the document as it categorically doesn't produce do= cuments of the kind. (I understood this from a message from F. Baker). Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA H Envoy=E9=A0: vendredi 13 f=E9vrier 2015 15:05 =C0=A0: Alexandru Petrescu; v6ops@ietf.org Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "ha= rmfully broad"? > When I go through procurements often the vendors ask the RFC list that > need to be there. This criterion - the implemented RFC list - primes ove= r all > others such as software management, dimensions, price tags, electrical, > temperature and noise features. If it were not for these little RFCs the= re > would be no reasonable procurement. >=20 > That said, I also agree with you when you imply that the list of features= in this > draft may be too long, or too hard see coherence. >=20 > If so, then maybe we can try to reduce it a bit? >=20 > Finally, 'profile' is probably not the right title. It should qualify bo= th the end- > user device and the network device. Inside the company I work for, I try to encourage "thoughtful" use of "devi= ce profile" RFCs such as this draft may become. That is, read through the e= ntire RFC, and make sure you want everything that's mandated. If you don't,= pick and choose what makes sense for the product you are procuring. I woul= d definitely not recommend to anyone (inside or outside my company) that th= ey ask for compliance with this document without fully understanding the im= plications of what they are asking for. Basically, I see the items listed i= n the draft as a set of potential items to consider when putting together a= n RFP. As it relates to IPv6 "device profile" documents, I would like to mention t= hat CableLabs has been successful with its eRouter spec, BBF successful wit= h its TR-124, and I'm hoping CEA has impact on the CE industry with its new= CEA2048 publication (which they're offering for free through Feb 28 -- see= http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e8185ea241297a2952= 9). There does seem to be demand for "device profile" documents. I do think= the only reason RFC 7084 (which really is a "device profile" RFC) was done= in IETF was because of the need to identify requirements for CE routers th= at could connect to a variety of access network architecture, and IETF was = "neutral territory". I admit to finding it odd that IETF would be used to p= ublish a device profile that is only for devices connecting to 3GPP access = networks. But I'm not familiar with how 3GPP works, so maybe it wasn't poss= ible to get 3GPP to be willing to create a profile for devices that attach = to their access network . BTW, I'm very concerned about the fact that someone affiliated with a provi= der of an OS found on many 3GPP devices has so many objections to this par= ticular "device profile". Knowing that, I would very, very strongly recomme= nd to people I work with that they be very, very careful about how they use= this particular "device profile" (if at all). I would not suggest includin= g it directly in any RFP. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 13 06:35:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A321A8707 for ; Fri, 13 Feb 2015 06:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVZX8UrEuNxc for ; Fri, 13 Feb 2015 06:35:45 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE3B1A8704 for ; Fri, 13 Feb 2015 06:35:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DEZghF005212; Fri, 13 Feb 2015 15:35:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 269CC20745D; Fri, 13 Feb 2015 15:36:38 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 186EA200CAA; Fri, 13 Feb 2015 15:36:38 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DEZKWc014311; Fri, 13 Feb 2015 15:35:42 +0100 Message-ID: <54DE0BA8.8020908@gmail.com> Date: Fri, 13 Feb 2015 15:35:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Heatley, Nick" , "mohamed.boucadair@orange.com" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:35:49 -0000 Le 13/02/2015 14:14, Heatley, Nick a écrit : > Hi Alex, > Yes, that is wrong. > You can ping any IPv4 literal from a 464xlat device. > My handset only has an IPv6 address + CLAT and I am pinging 8.8.8.8 :-)) Ok, I see. I didnt know CLAT-on-device was required when using v6-only APNs. That means that the device vendors MUST implement CLAT in the smartphones which connect to a v6-only APN. It is a too strong requirement. It is easier for an end user to connect to a pure v4-APN rather than a v6 APN with CLAT. > Internet-side initiated traffic would be an issue, same as NAT44 CGN. YEs, I understand that reachability problem. But here we have a problem with requiring the end user device to run translation just because of IPv6. App writers have already solved the NAT44 reverse reachability problems - they work on non-CLAT devices behind NAT. These apps will no longer work in the v6 world, if CLAT is not added. One would hardly migrate to IPv6 if too much translation is required, be it v4-v6 or v6-v4 translation. Compare this to the v6 migration in the DSL world: no additional CLAT is required on end-user devices. Alex > Nick > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: 13 February 2015 12:52 > To: Heatley, Nick; mohamed.boucadair@orange.com > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 11:13, Heatley, Nick a écrit : >> A statement such as >>> The device should only invoke the CLAT in the absence of a the IPv4 >>> AF i.e. when the network does not assign an IPv4 cellular address >> could be helpful? >> >> To go further, and define any additional requirement, then that would >> be defining how an Operator could/should manage their remaining IPv4 >> public and private addressing. This paper should only focus on the >> required device behaviour. >> >> As an aside 464xlat is a direct replacement for the NAT44 >> environments, typical in mobile operators with large consumer bases. > > Nick, > > Am I wrong to say that one can not ping 8.8.8.8 from behind a 464xlat, whereas one can ping 8.8.8.8 behind a nat44? > > If I am not wrong then 464xlat and nat44 are not really equivalent. > > Alex > >> Ideal if an operator is exhausting both public and private address >> space. If an operator has ample public IPv4 and has consumer products >> that are NAT44-free, then they are in a different place (a utopia). >> Nick >> >> >> -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] >> On Behalf Of mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 >> To: >> Alexandru Petrescu Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D >> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 >> 464XLAT >> >> Hi Alex, >> >> The intent of this reco is to address broken IPv4-only applications >> over an IPv6-only connectivity. Ideally applications running on the >> device should be AF-independent. >> >> The draft relies on the IPv6 node requirements RFC that mandates the >> supports of IPv6. Also, the I-D calls out applications that are >> provided by the vendor of the device: >> >> == APP_REC#2: Applications provided by the mobile device vendor must >> be independent of the underlying IP address family. == >> >> Wouldn't this reco addresses your concern? >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : v6ops [mailto:v6ops-bounces@ietf.org] >> De la part de Alexandru Petrescu Envoyé : jeudi 12 février 2015 17:27 >> À : v6ops@ietf.org Objet : Re: >> [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - >> C_REC#9 464XLAT >> >> Hello, >> >> Thank you for this new version of the draft. >> >> I have a doubt with respect to the 464XLAT requirement: >>> C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only >>> deployment context, the cellular host should implement the Customer >>> Side Translator (CLAT, [RFC6877]) function which is compliant with >>> [RFC6052][RFC6145][RFC6146]. >>> >>> CLAT function in the cellular host allows for IPv4-only application >>> and IPv4-referals to work on an IPv6-only connectivity. CLAT >>> function requires a NAT64 capability [RFC6146] in the core network. >>> >>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>> [RFC7335]. >> >> I think this requirement leads to a situation where the network >> operator deploys IPv6-native-only and IPv4 as an add-on partial >> feature. >> >> On one hand, it is encouraging to see native IPv6 and no IPv4. >> >> On another hand, _partial_ IPv4 support is a temptation which deceives >> in the end - it leads to turn off IPv6 and come back to good ol' IPv4 >> and no IPv6. >> >> The 464XLAT is partial IPv4 support: does not offer full IPv4 >> connectivity to the smartphone. It is not possible to address the >> smartphone by its IPv4 address - DNS is required; this makes it >> impossible to make a VPN tunnel, or Mobile IP. One can not a deploy a >> wireless IPv4 router along the road in a remote area, for example. >> >> This leads to a situation where the operator requires end user to >> switch to another APN which is less IPv6. >> >> I think it is not a happy situation. >> >> I would suggest to qualify this requirement by another requirement. >> This initial requirement would state that _first_, before any v4-v6 >> conversion mechanism is considered, both the network and the end user >> MUST implement a native IPv4 stack and a native IPv6 stack (not say >> 'dual' stack, which is much overloaded). >> >> We dont want to block IPv4 use when IPv6 arrives. >> >> Alex >> >> 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the IPv6 Operations Working >>> Group of the IETF. >>> >>> Title : An Internet Protocol Version 6 (IPv6) Profile for >>> 3GPP Mobile Devices Authors : David Binet Mohamed >>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename >>> : draft-ietf-v6ops-mobile-device-profile-17.txt Pages : >>> 18 Date : 2015-02-12 >>> >>> Abstract: This document defines a profile that is a superset of that >>> of the connection to IPv6 cellular networks defined in the >>> IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts >>> document. This document defines an IPv6 profile that a number of >>> operators recommend in order to connect 3GPP mobile devices to an >>> IPv6-only or dual-stack wireless network (including 3GPP cellular >>> network and IEEE 802.11 network) with a special focus on IPv4 service >>> continuity features. >>> >>> Both hosts and devices with capability to share their WAN (Wide Area >>> Network) connectivity are in scope. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profi >>> l >>> >>> > e/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >>> >>> >>> > A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profi >>> l >>> >>> > e-17 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >> intended for the above-named person(s). If you are not the intended >> recipient, notify the sender immediately, delete this email from your >> system and do not disclose or use for any purpose. >> >> We may monitor all incoming and outgoing emails in line with current >> legislation. We have taken steps to ensure that this email and >> attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely affect you. >> >> EE Limited Registered in England and Wales Company Registered Number: >> 02382161 Registered Office Address: Trident Place, Mosquito Way, >> Hatfield, Hertfordshire, AL10 9BW. >> > > > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. > From nobody Fri Feb 13 07:04:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDC31A86F5 for ; Fri, 13 Feb 2015 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdjUI9bgYZ_3 for ; Fri, 13 Feb 2015 07:04:45 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D371A871E for ; Fri, 13 Feb 2015 07:04:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DF4dGk017341; Fri, 13 Feb 2015 16:04:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0B5CC207503; Fri, 13 Feb 2015 16:05:35 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F1E3B2040B9; Fri, 13 Feb 2015 16:05:34 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DF4KB5013422; Fri, 13 Feb 2015 16:04:38 +0100 Message-ID: <54DE1274.1080609@gmail.com> Date: Fri, 13 Feb 2015 16:04:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF305.8080401@gmail.com> <787AE7BB302AE849A7480A190F8B93300490ACC7@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490ACC7@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 15:04:51 -0000 Hi Med, Le 13/02/2015 14:00, mohamed.boucadair@orange.com a écrit : > Re-, > > Please see inline. > > Cheers, Med > > -----Message d'origine----- De : Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Envoyé : vendredi 13 février > 2015 13:50 À : BOUCADAIR Mohamed IMT/OLN Cc : v6ops@ietf.org Objet : > Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt > - C_REC#9 464XLAT > > Le 13/02/2015 07:49, mohamed.boucadair@orange.com a écrit : >> Hi Alex, >> >> The intent of this reco is to address broken IPv4-only applications >> over an IPv6-only connectivity. > > Ok, makes sense. > >> Ideally applications running on the device should be >> AF-independent. > > That is an ideal, laudable goal. > > There a number of professional applications that are Address Family > dependent, and which do not query DNS to find an address. They may > distribute it by SDN. > >> The draft relies on the IPv6 node requirements RFC that mandates >> the supports of IPv6. Also, the I-D calls out applications that are >> provided by the vendor of the device: >> >> == APP_REC#2: Applications provided by the mobile device vendor >> must be independent of the underlying IP address family. == >> >> Wouldn't this reco addresses your concern? > > PArtially yes. > > But is it feasible to recommend something to the 3rd party providers > of applications? > > [Med] FWIW, the wording we had for this reco is among the lines you > are hinting: > > " REQ#33: Applications MUST be independent of the underlying IP > address family. " Well, it's a good goal. But it is not the way many apps work. We can't delete them with a req in an RFC. > but we changed the wording to cover applications that under the > responsibility of the device vendor. This change was a result of a > comment we received in the mailing list. That comment was fair IMHO. Well, yes, you have made a good distinction. But still there are many address family dependent applications written even by the device vendors in question. > Is the mobile device vendor realizing that the 3rd party providers > may prefer to connect to an IPv4-only APN instead of a 464XLAT APN? > > [Med] This can be part of the internal validation process of the > device vendors. I don't think we should interfere with those. noted. > Also, applications can be installed by the user so there is no > guarantee those applications will behave well when IPv6 connectivity > is provided. YEs. Some will fault writing apps incompatible with a simultaneous v4-v6 access. They should be told to either correct, or maybe use a 464xlat/CLAT feature. All the other apps who support ok simultaneous v4-v6 access should not be imposed to run CLAT/464xlat. > FYI, the reason we initially included this reco is that an app store > from a vendor that is known to support IPv6 from a while is broken > when an IPv6-only connectivity is in place. Noted. But I think it is too early to propose large populations of users v6-only access networks. > Having APP_REC#2 satisfied is already a high bar. YEs, a v6-only access network is a dream for the v6-inclined. But it is too daring. Consider how IPv6 migration happens in DSL networks, like the success at Free. It is the box which does all sorts of translations, 6rd, whatever - this is all invisible to the user device. In the same vein, a cellular network could do all sorts of translation in the Access Router, Base Station, SGSN; and offer native IPv4 and native IPv6 to the end user. The user would switch to IPv6 when s/he feels like, free from translation hurdles. Alex > > Alex > >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : v6ops >> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : Re: >> [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - >> C_REC#9 464XLAT >> >> Hello, >> >> Thank you for this new version of the draft. >> >> I have a doubt with respect to the 464XLAT requirement: >>> C_REC#9: In order to ensure IPv4 service continuity in an >>> IPv6-only deployment context, the cellular host should implement >>> the Customer Side Translator (CLAT, [RFC6877]) function which is >>> compliant with [RFC6052][RFC6145][RFC6146]. >>> >>> CLAT function in the cellular host allows for IPv4-only >>> application and IPv4-referals to work on an IPv6-only >>> connectivity. CLAT function requires a NAT64 capability >>> [RFC6146] in the core network. >>> >>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>> [RFC7335]. >> >> I think this requirement leads to a situation where the network >> operator deploys IPv6-native-only and IPv4 as an add-on partial >> feature. >> >> On one hand, it is encouraging to see native IPv6 and no IPv4. >> >> On another hand, _partial_ IPv4 support is a temptation which >> deceives in the end - it leads to turn off IPv6 and come back to >> good ol' IPv4 and no IPv6. >> >> The 464XLAT is partial IPv4 support: does not offer full IPv4 >> connectivity to the smartphone. It is not possible to address the >> smartphone by its IPv4 address - DNS is required; this makes it >> impossible to make a VPN tunnel, or Mobile IP. One can not a >> deploy a wireless IPv4 router along the road in a remote area, for >> example. >> >> This leads to a situation where the operator requires end user to >> switch to another APN which is less IPv6. >> >> I think it is not a happy situation. >> >> I would suggest to qualify this requirement by another >> requirement. This initial requirement would state that _first_, >> before any v4-v6 conversion mechanism is considered, both the >> network and the end user MUST implement a native IPv4 stack and a >> native IPv6 stack (not say 'dual' stack, which is much >> overloaded). >> >> We dont want to block IPv4 use when IPv6 arrives. >> >> Alex >> >> 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> IPv6 Operations Working Group of the IETF. >>> >>> Title : An Internet Protocol Version 6 (IPv6) Profile >>> for 3GPP Mobile Devices Authors : David Binet Mohamed >>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages : >>> 18 Date : 2015-02-12 >>> >>> Abstract: This document defines a profile that is a superset of >>> that of the connection to IPv6 cellular networks defined in the >>> IPv6 for Third Generation Partnership Project (3GPP) Cellular >>> Hosts document. This document defines an IPv6 profile that a >>> number of operators recommend in order to connect 3GPP mobile >>> devices to an IPv6-only or dual-stack wireless network (including >>> 3GPP cellular network and IEEE 802.11 network) with a special >>> focus on IPv4 service continuity features. >>> >>> Both hosts and devices with capability to share their WAN (Wide >>> Area Network) connectivity are in scope. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >>> >>> >>> >>> > >>> >>> >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >>> >>> >>> >>> > >>> >>> >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-17 >>> >>> >>> >>> >>> > >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > > From nobody Fri Feb 13 07:33:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E611A8748 for ; Fri, 13 Feb 2015 07:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEbiRL3xIoNP for ; Fri, 13 Feb 2015 07:33:30 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508871A873B for ; Fri, 13 Feb 2015 07:33:30 -0800 (PST) Received: from [85.158.136.3] by server-10.bemta-5.messagelabs.com id 65/02-02756-8491ED45; Fri, 13 Feb 2015 15:33:28 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-5.tower-123.messagelabs.com!1423841607!38748163!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13933 invoked from network); 13 Feb 2015 15:33:28 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-5.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 15:33:28 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Fri, 13 Feb 2015 15:33:21 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 13 Feb 2015 15:33:26 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 15:33:23 +0000 From: "Heatley, Nick" To: Alexandru Petrescu , "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZzuJKAAgAA1/FCAAC9ogIAABSbAgAAXqQCAAAP9EA== Date: Fri, 13 Feb 2015 15:33:23 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> In-Reply-To: <54DE0BA8.8020908@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 15:33:34 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3Ug W21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSANClNlbnQ6IDEzIEZlYnJ1YXJ5 IDIwMTUgMTQ6MzUNClRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tDQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENfUkVDIzkg NDY0WExBVA0KDQpMZSAxMy8wMi8yMDE1IDE0OjE0LCBIZWF0bGV5LCBOaWNrIGEgw6ljcml0IDoN Cj4gSGkgQWxleCwNCj4gWWVzLCB0aGF0IGlzIHdyb25nLg0KPiBZb3UgY2FuIHBpbmcgYW55IElQ djQgbGl0ZXJhbCBmcm9tIGEgNDY0eGxhdCBkZXZpY2UuDQo+IE15IGhhbmRzZXQgb25seSBoYXMg YW4gSVB2NiBhZGRyZXNzICsgQ0xBVCBhbmQgSSBhbSBwaW5naW5nIDguOC44LjggDQo+IDotKSkN Cg0KT2ssIEkgc2VlLiAgSSBkaWRudCBrbm93IENMQVQtb24tZGV2aWNlIHdhcyByZXF1aXJlZCB3 aGVuIHVzaW5nIHY2LW9ubHkgQVBOcy4NCg0KW0hlYXRsZXksIE5pY2tdIEZvciBzZXJ2aWNlIGNv bnRpbnVpdHkgd2l0aCBJUHY0LCBvbiBhbiBJUHY2LW9ubHkgYmVhcmVyIHVzZSBDTEFULiBBIHNs aWdodGx5IHBlZGFudGljIG5vdGUsICBpZiB5b3UgaGF2ZSBhICJkdWFsIHN0YWNrIEFQTiIgYnV0 IHRoZSBkZXZpY2Ugb25seSByZXF1ZXN0cyBJUHY2IHRoZW4gdGhlIGRldmljZSB3aWxsIHJlY2Vp dmUgYW4gSVB2NiBiZWFyZXIgYW5kIHJlcXVpcmVzIENMQVQuIFlvdSB3aWxsIGhlYXIgZnJvbSBS b3NzIGFuZCBtZSB0YWxraW5nIGFib3V0IGhhdmluZyBhIHNpbmdsZSBBUE4gc3VwcG9ydGluZyBh bGwgbW9kZXMsIElQdjQsIElQdjR2NiBhbmQgSVB2NiBiZWFyZXJzLiBUaGVyZSBtYXkgYmUgYnVz aW5lc3MgcmVhc29ucyBmb3IgdGhpcywgYXMgd2VsbCBhcyBhdm9pZGluZyBjb25zdW1lcnMgaGF2 aW5nIHRvIGNoYW5nZSBBUE5zLg0KDQpUaGF0IG1lYW5zIHRoYXQgdGhlIGRldmljZSB2ZW5kb3Jz IE1VU1QgaW1wbGVtZW50IENMQVQgaW4gdGhlIHNtYXJ0cGhvbmVzIHdoaWNoIGNvbm5lY3QgdG8g YSB2Ni1vbmx5IEFQTi4gIEl0IGlzIGEgdG9vIHN0cm9uZyByZXF1aXJlbWVudC4NCg0KW0hlYXRs ZXksIE5pY2tdIFRvZGF5J3MgcmVhbGl0eSBpcyB0aGF0IG9wZXJhdG9ycyBjYW5ub3QgdGFrZSBk ZXZpY2VzIHRvIElQdjYtb25seSBtb2RlIG9mIG9wZXJhdGlvbiB3aXRob3V0IENMQVQuIEluIHRo ZSBmdXR1cmUgd2lsbCBvdGhlciBhbHRlcm5hdGl2ZXMgYXBwZWFyPw0KDQpJdCBpcyBlYXNpZXIg Zm9yIGFuIGVuZCB1c2VyIHRvIGNvbm5lY3QgdG8gYSBwdXJlIHY0LUFQTiByYXRoZXIgdGhhbiBh DQp2NiBBUE4gd2l0aCBDTEFULg0KDQpbSGVhdGxleSwgTmlja10gSWYgdGhleSBoYXZlIHRoZSBj aG9pY2UuLi4ud2hlbiB0aGUgZWxlbWVudCBvZiBjaG9pY2UgaXMgdGFrZW4gYXdheSwgdGhlIG9w ZXJhdG9yIG11c3QgbWFrZSB0aGVpciBuZXR3b3JrIGJ1bGxldCBwcm9vZiBmb3IgYWxsIGRldmlj ZXMgc3VwcG9ydGVkLg0KDQo+IEludGVybmV0LXNpZGUgaW5pdGlhdGVkIHRyYWZmaWMgd291bGQg YmUgYW4gaXNzdWUsIHNhbWUgYXMgTkFUNDQgQ0dOLg0KDQpZRXMsIEkgdW5kZXJzdGFuZCB0aGF0 IHJlYWNoYWJpbGl0eSBwcm9ibGVtLg0KDQpCdXQgaGVyZSB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRo IHJlcXVpcmluZyB0aGUgZW5kIHVzZXIgZGV2aWNlIHRvIHJ1biB0cmFuc2xhdGlvbiBqdXN0IGJl Y2F1c2Ugb2YgSVB2Ni4NCg0KQXBwIHdyaXRlcnMgaGF2ZSBhbHJlYWR5IHNvbHZlZCB0aGUgTkFU NDQgcmV2ZXJzZSByZWFjaGFiaWxpdHkgcHJvYmxlbXMNCi0gdGhleSB3b3JrIG9uIG5vbi1DTEFU IGRldmljZXMgYmVoaW5kIE5BVC4gIFRoZXNlIGFwcHMgd2lsbCBubyBsb25nZXIgd29yayBpbiB0 aGUgdjYgd29ybGQsIGlmIENMQVQgaXMgbm90IGFkZGVkLg0KDQpPbmUgd291bGQgaGFyZGx5IG1p Z3JhdGUgdG8gSVB2NiBpZiB0b28gbXVjaCB0cmFuc2xhdGlvbiBpcyByZXF1aXJlZCwgYmUgaXQg djQtdjYgb3IgdjYtdjQgdHJhbnNsYXRpb24uDQoNCkNvbXBhcmUgdGhpcyB0byB0aGUgdjYgbWln cmF0aW9uIGluIHRoZSBEU0wgd29ybGQ6IG5vIGFkZGl0aW9uYWwgQ0xBVCBpcyByZXF1aXJlZCBv biBlbmQtdXNlciBkZXZpY2VzLg0KDQpBbGV4DQoNCj4gTmljaw0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5k cnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50OiAxMyBGZWJydWFyeSAyMDE1IDEyOjUyDQo+ IFRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IENjOiB2 Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiANCj4gZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19SRUMjOSA0NjRY TEFUDQo+DQo+IExlIDEzLzAyLzIwMTUgMTE6MTMsIEhlYXRsZXksIE5pY2sgYSDDqWNyaXQgOg0K Pj4gQSBzdGF0ZW1lbnQgc3VjaCBhcw0KPj4+IFRoZSBkZXZpY2Ugc2hvdWxkIG9ubHkgaW52b2tl IHRoZSBDTEFUIGluIHRoZSBhYnNlbmNlIG9mIGEgdGhlIElQdjQgDQo+Pj4gQUYgaS5lLiB3aGVu IHRoZSBuZXR3b3JrIGRvZXMgbm90IGFzc2lnbiBhbiBJUHY0IGNlbGx1bGFyIGFkZHJlc3MNCj4+ IGNvdWxkIGJlIGhlbHBmdWw/DQo+Pg0KPj4gVG8gZ28gZnVydGhlciwgYW5kIGRlZmluZSBhbnkg YWRkaXRpb25hbCByZXF1aXJlbWVudCwgdGhlbiB0aGF0IHdvdWxkIA0KPj4gYmUgZGVmaW5pbmcg aG93IGFuIE9wZXJhdG9yIGNvdWxkL3Nob3VsZCBtYW5hZ2UgdGhlaXIgcmVtYWluaW5nIElQdjQg DQo+PiBwdWJsaWMgYW5kIHByaXZhdGUgYWRkcmVzc2luZy4gVGhpcyBwYXBlciBzaG91bGQgb25s eSBmb2N1cyBvbiB0aGUgDQo+PiByZXF1aXJlZCBkZXZpY2UgYmVoYXZpb3VyLg0KPj4NCj4+IEFz IGFuIGFzaWRlIDQ2NHhsYXQgaXMgYSBkaXJlY3QgcmVwbGFjZW1lbnQgZm9yIHRoZSBOQVQ0NCAN Cj4+IGVudmlyb25tZW50cywgdHlwaWNhbCBpbiBtb2JpbGUgb3BlcmF0b3JzIHdpdGggbGFyZ2Ug Y29uc3VtZXIgYmFzZXMuDQo+DQo+IE5pY2ssDQo+DQo+IEFtIEkgd3JvbmcgdG8gc2F5IHRoYXQg b25lIGNhbiBub3QgcGluZyA4LjguOC44IGZyb20gYmVoaW5kIGEgNDY0eGxhdCwgd2hlcmVhcyBv bmUgY2FuIHBpbmcgOC44LjguOCBiZWhpbmQgYSBuYXQ0ND8NCj4NCj4gSWYgSSBhbSBub3Qgd3Jv bmcgdGhlbiA0NjR4bGF0IGFuZCBuYXQ0NCBhcmUgbm90IHJlYWxseSBlcXVpdmFsZW50Lg0KPg0K PiBBbGV4DQo+DQo+PiBJZGVhbCBpZiBhbiBvcGVyYXRvciBpcyBleGhhdXN0aW5nIGJvdGggcHVi bGljIGFuZCBwcml2YXRlIGFkZHJlc3MgDQo+PiBzcGFjZS4gSWYgYW4gb3BlcmF0b3IgaGFzIGFt cGxlIHB1YmxpYyBJUHY0IGFuZCBoYXMgY29uc3VtZXIgcHJvZHVjdHMgDQo+PiB0aGF0IGFyZSBO QVQ0NC1mcmVlLCB0aGVuIHRoZXkgYXJlIGluIGEgZGlmZmVyZW50IHBsYWNlIChhIHV0b3BpYSku DQo+PiBOaWNrDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHY2 b3BzIA0KPj4gW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+ PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIFNlbnQ6IDEzIEZlYnJ1YXJ5IDIwMTUgMDY6 NDkNCj4+IFRvOg0KPj4gQWxleGFuZHJ1IFBldHJlc2N1IENjOiB2Nm9wc0BpZXRmLm9yZyBTdWJq ZWN0OiBSZTogW3Y2b3BzXSBJLUQNCj4+IEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUt ZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19SRUMjOSANCj4+IDQ2NFhMQVQNCj4+DQo+PiBIaSBB bGV4LA0KPj4NCj4+IFRoZSBpbnRlbnQgb2YgdGhpcyByZWNvIGlzIHRvIGFkZHJlc3MgYnJva2Vu IElQdjQtb25seSBhcHBsaWNhdGlvbnMgDQo+PiBvdmVyIGFuIElQdjYtb25seSBjb25uZWN0aXZp dHkuIElkZWFsbHkgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdGhlIA0KPj4gZGV2aWNlIHNob3Vs ZCBiZSBBRi1pbmRlcGVuZGVudC4NCj4+DQo+PiBUaGUgZHJhZnQgcmVsaWVzIG9uIHRoZSBJUHY2 IG5vZGUgcmVxdWlyZW1lbnRzIFJGQyB0aGF0IG1hbmRhdGVzIHRoZSANCj4+IHN1cHBvcnRzIG9m IElQdjYuIEFsc28sIHRoZSBJLUQgY2FsbHMgb3V0IGFwcGxpY2F0aW9ucyB0aGF0IGFyZSANCj4+ IHByb3ZpZGVkIGJ5IHRoZSB2ZW5kb3Igb2YgdGhlIGRldmljZToNCj4+DQo+PiA9PSBBUFBfUkVD IzI6ICBBcHBsaWNhdGlvbnMgcHJvdmlkZWQgYnkgdGhlIG1vYmlsZSBkZXZpY2UgdmVuZG9yIG11 c3QgDQo+PiBiZSBpbmRlcGVuZGVudCBvZiB0aGUgdW5kZXJseWluZyBJUCBhZGRyZXNzIGZhbWls eS4gPT0NCj4+DQo+PiBXb3VsZG4ndCB0aGlzIHJlY28gYWRkcmVzc2VzIHlvdXIgY29uY2Vybj8N Cj4+DQo+PiBUaGFuayB5b3UuDQo+Pg0KPj4gQ2hlZXJzLCBNZWQNCj4+DQo+PiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0gRGUgOiB2Nm9wcyANCj4+IFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBBbGV4YW5kcnUgUGV0cmVzY3UgDQo+PiBFbnZvecOpIDog amV1ZGkgMTIgZsOpdnJpZXIgMjAxNSAxNzoyNyDDgCA6IHY2b3BzQGlldGYub3JnIE9iamV0IDog UmU6DQo+PiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlLTE3LnR4dCAtDQo+PiBDX1JFQyM5IDQ2NFhMQVQNCj4+DQo+PiBIZWxsbywNCj4+ DQo+PiBUaGFuayB5b3UgZm9yIHRoaXMgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPj4NCj4+ IEkgaGF2ZSBhIGRvdWJ0IHdpdGggcmVzcGVjdCB0byB0aGUgNDY0WExBVCByZXF1aXJlbWVudDoN Cj4+PiBDX1JFQyM5OiAgSW4gb3JkZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5 IGluIGFuIElQdjYtb25seSANCj4+PiBkZXBsb3ltZW50IGNvbnRleHQsIHRoZSBjZWxsdWxhciBo b3N0IHNob3VsZCBpbXBsZW1lbnQgdGhlIEN1c3RvbWVyIA0KPj4+IFNpZGUgVHJhbnNsYXRvciAo Q0xBVCwgW1JGQzY4NzddKSBmdW5jdGlvbiB3aGljaCBpcyBjb21wbGlhbnQgd2l0aCANCj4+PiBb UkZDNjA1Ml1bUkZDNjE0NV1bUkZDNjE0Nl0uDQo+Pj4NCj4+PiBDTEFUIGZ1bmN0aW9uIGluIHRo ZSBjZWxsdWxhciBob3N0IGFsbG93cyBmb3IgSVB2NC1vbmx5IGFwcGxpY2F0aW9uIA0KPj4+IGFu ZCBJUHY0LXJlZmVyYWxzIHRvIHdvcmsgb24gYW4gSVB2Ni1vbmx5IGNvbm5lY3Rpdml0eS4gIENM QVQgDQo+Pj4gZnVuY3Rpb24gcmVxdWlyZXMgYSBOQVQ2NCBjYXBhYmlsaXR5IFtSRkM2MTQ2XSBp biB0aGUgY29yZSBuZXR3b3JrLg0KPj4+DQo+Pj4gVGhlIElQdjQgU2VydmljZSBDb250aW51aXR5 IFByZWZpeCB1c2VkIGJ5IENMQVQgaXMgZGVmaW5lZCBpbiANCj4+PiBbUkZDNzMzNV0uDQo+Pg0K Pj4gSSB0aGluayB0aGlzIHJlcXVpcmVtZW50IGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRo ZSBuZXR3b3JrIA0KPj4gb3BlcmF0b3IgZGVwbG95cyBJUHY2LW5hdGl2ZS1vbmx5IGFuZCBJUHY0 IGFzIGFuIGFkZC1vbiBwYXJ0aWFsIA0KPj4gZmVhdHVyZS4NCj4+DQo+PiBPbiBvbmUgaGFuZCwg aXQgaXMgZW5jb3VyYWdpbmcgdG8gc2VlIG5hdGl2ZSBJUHY2IGFuZCBubyBJUHY0Lg0KPj4NCj4+ IE9uIGFub3RoZXIgaGFuZCwgX3BhcnRpYWxfIElQdjQgc3VwcG9ydCBpcyBhIHRlbXB0YXRpb24g d2hpY2ggDQo+PiBkZWNlaXZlcyBpbiB0aGUgZW5kIC0gIGl0IGxlYWRzIHRvIHR1cm4gb2ZmIElQ djYgYW5kIGNvbWUgYmFjayB0byANCj4+IGdvb2Qgb2wnIElQdjQgYW5kIG5vIElQdjYuDQo+Pg0K Pj4gVGhlIDQ2NFhMQVQgaXMgcGFydGlhbCBJUHY0IHN1cHBvcnQ6IGRvZXMgbm90IG9mZmVyIGZ1 bGwgSVB2NCANCj4+IGNvbm5lY3Rpdml0eSB0byB0aGUgc21hcnRwaG9uZS4gIEl0IGlzIG5vdCBw b3NzaWJsZSB0byBhZGRyZXNzIHRoZSANCj4+IHNtYXJ0cGhvbmUgYnkgaXRzIElQdjQgYWRkcmVz cyAtIEROUyBpcyByZXF1aXJlZDsgdGhpcyBtYWtlcyBpdCANCj4+IGltcG9zc2libGUgdG8gbWFr ZSBhIFZQTiB0dW5uZWwsIG9yIE1vYmlsZSBJUC4gIE9uZSBjYW4gbm90IGEgZGVwbG95IA0KPj4g YSB3aXJlbGVzcyBJUHY0IHJvdXRlciBhbG9uZyB0aGUgcm9hZCBpbiBhIHJlbW90ZSBhcmVhLCBm b3IgZXhhbXBsZS4NCj4+DQo+PiBUaGlzIGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBv cGVyYXRvciByZXF1aXJlcyBlbmQgdXNlciB0byANCj4+IHN3aXRjaCB0byBhbm90aGVyIEFQTiB3 aGljaCBpcyBsZXNzIElQdjYuDQo+Pg0KPj4gSSB0aGluayBpdCBpcyBub3QgYSBoYXBweSBzaXR1 YXRpb24uDQo+Pg0KPj4gSSB3b3VsZCAgc3VnZ2VzdCB0byBxdWFsaWZ5IHRoaXMgcmVxdWlyZW1l bnQgYnkgYW5vdGhlciByZXF1aXJlbWVudC4NCj4+IFRoaXMgaW5pdGlhbCByZXF1aXJlbWVudCB3 b3VsZCBzdGF0ZSB0aGF0IF9maXJzdF8sIGJlZm9yZSBhbnkgdjQtdjYgDQo+PiBjb252ZXJzaW9u IG1lY2hhbmlzbSBpcyBjb25zaWRlcmVkLCBib3RoIHRoZSBuZXR3b3JrIGFuZCB0aGUgZW5kIHVz ZXIgDQo+PiBNVVNUIGltcGxlbWVudCBhIG5hdGl2ZSBJUHY0IHN0YWNrIGFuZCBhIG5hdGl2ZSBJ UHY2IHN0YWNrIChub3Qgc2F5IA0KPj4gJ2R1YWwnIHN0YWNrLCB3aGljaCBpcyBtdWNoIG92ZXJs b2FkZWQpLg0KPj4NCj4+IFdlIGRvbnQgd2FudCB0byBibG9jayBJUHY0IHVzZSB3aGVuIElQdjYg YXJyaXZlcy4NCj4+DQo+PiBBbGV4DQo+Pg0KPj4gMTIvMDIvMjAxNSAxMzo0MiwgaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIGEgw6ljcml0IDoNCj4+Pg0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCj4+PiBkaXJl Y3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25z IA0KPj4+IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4NCj4+PiBUaXRsZSAgICAgICAg ICAgOiBBbiBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgKElQdjYpIFByb2ZpbGUgZm9yDQo+ Pj4gM0dQUCBNb2JpbGUgRGV2aWNlcyBBdXRob3JzICAgICAgICAgOiBEYXZpZCBCaW5ldCBNb2hh bWVkDQo+Pj4gQm91Y2FkYWlyIEFsZXMgVml6ZGFsIEdhbmcgQ2hlbiBOaWNrIEhlYXRsZXkgUm9z cyBDaGFuZGxlciBGaWxlbmFtZQ0KPj4+IDogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNl LXByb2ZpbGUtMTcudHh0IFBhZ2VzICAgICAgICAgICA6DQo+Pj4gMTggRGF0ZSAgICAgICAgICAg IDogMjAxNS0wMi0xMg0KPj4+DQo+Pj4gQWJzdHJhY3Q6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IHByb2ZpbGUgdGhhdCBpcyBhIHN1cGVyc2V0IG9mIHRoYXQgDQo+Pj4gb2YgdGhlIGNvbm5lY3Rp b24gdG8gSVB2NiBjZWxsdWxhciBuZXR3b3JrcyBkZWZpbmVkIGluIHRoZQ0KPj4+IElQdjYgZm9y IFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCkgQ2VsbHVsYXIgSG9z dHMgDQo+Pj4gZG9jdW1lbnQuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gSVB2NiBwcm9maWxl IHRoYXQgYSBudW1iZXIgb2YgDQo+Pj4gb3BlcmF0b3JzIHJlY29tbWVuZCBpbiBvcmRlciB0byBj b25uZWN0IDNHUFAgbW9iaWxlIGRldmljZXMgdG8gYW4gDQo+Pj4gSVB2Ni1vbmx5IG9yIGR1YWwt c3RhY2sgd2lyZWxlc3MgbmV0d29yayAoaW5jbHVkaW5nIDNHUFAgY2VsbHVsYXIgDQo+Pj4gbmV0 d29yayBhbmQgSUVFRSA4MDIuMTEgbmV0d29yaykgd2l0aCBhIHNwZWNpYWwgZm9jdXMgb24gSVB2 NCANCj4+PiBzZXJ2aWNlIGNvbnRpbnVpdHkgZmVhdHVyZXMuDQo+Pj4NCj4+PiBCb3RoIGhvc3Rz IGFuZCBkZXZpY2VzIHdpdGggY2FwYWJpbGl0eSB0byBzaGFyZSB0aGVpciBXQU4gKFdpZGUgQXJl YQ0KPj4+IE5ldHdvcmspIGNvbm5lY3Rpdml0eSBhcmUgaW4gc2NvcGUuDQo+Pj4NCj4+Pg0KPj4+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxl LWRldmljZS1wcm9mDQo+Pj4gaQ0KPj4+IGwNCj4+Pg0KPj4+DQo+IGUvDQo+Pj4NCj4+PiBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0x Nw0KPj4+DQo+Pj4NCj4+Pg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2YNCj4+PiBpDQo+Pj4gbA0KPj4+DQo+Pj4NCj4g ZS0xNw0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgDQo+Pj4gdG9vbHMuaWV0 Zi5vcmcuDQo+Pj4NCj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IHY2b3BzIG1haWxpbmcgbGlzdCANCj4+PiB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pj4NCj4+Pg0KPj4NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxp c3QgDQo+PiB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0IA0KPj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4+IE5PVElDRSBBTkQgRElT Q0xBSU1FUiBUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgDQo+PiBp bnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCANCj4+IHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHks IGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciANCj4+IHN5c3RlbSBhbmQgZG8gbm90IGRpc2Ns b3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuDQo+Pg0KPj4gV2UgbWF5IG1vbml0b3IgYWxsIGlu Y29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgDQo+PiBsZWdp c2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFu ZCANCj4+IGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlu cyB5b3VyIA0KPj4gcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3Qg YWR2ZXJzZWx5IGFmZmVjdCB5b3UuDQo+Pg0KPj4gRUUgTGltaXRlZCBSZWdpc3RlcmVkIGluIEVu Z2xhbmQgYW5kIFdhbGVzIENvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6DQo+PiAwMjM4MjE2MSBS ZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIA0K Pj4gSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXLg0KPj4NCj4NCj4NCj4NCj4gTk9U SUNFIEFORCBESVNDTEFJTUVSDQo+IFRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xv c2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4NCj4NCj4gV2UgbWF5IG1vbml0b3IgYWxsIGluY29t aW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24u IFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNo bWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9u c2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5 b3UuDQo+DQo+IEVFIExpbWl0ZWQNCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0K PiBDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KPiBSZWdpc3RlcmVkIE9mZmlj ZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9y ZHNoaXJlLCBBTDEwIDlCVy4NCj4NCg0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBl LW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJv dmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20g eW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiAg DQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBs aW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1 cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1 cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1 c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgy MTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBX YXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== From nobody Fri Feb 13 07:33:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0F1A8742 for ; Fri, 13 Feb 2015 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4R87ge8Lza7 for ; Fri, 13 Feb 2015 07:33:39 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D041A8750 for ; Fri, 13 Feb 2015 07:33:37 -0800 (PST) Received: from [85.158.136.35] by server-2.bemta-5.messagelabs.com id 96/A9-03511-0591ED45; Fri, 13 Feb 2015 15:33:36 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-125.messagelabs.com!1423841355!8168409!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26905 invoked from network); 13 Feb 2015 15:29:16 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 15:29:16 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Fri, 13 Feb 2015 15:29:09 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 13 Feb 2015 15:29:15 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 15:29:15 +0000 From: "Heatley, Nick" To: "STARK, BARBARA H" , "IPv6 Ops WG (v6ops@ietf.org)" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQ Date: Fri, 13 Feb 2015 15:29:15 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 15:33:43 -0000 I find your comments very well considered, thank you. Barbara, ultimately the question remains, will your people be better off = having read a document, with all the appropriate contextual warnings (i.e= . it is not a standard), than if the paper did not exist? (Do you expect = them to read all RFCs?) To use an analogy I am not the "specialist surgeon", but a GP* wondering= =20what to vaccinate my patients with. I don't wish to know, or understand, every new breakthrough in every dise= ase. I wish the specialists to agree what is ready for patients. With approaching 10k of RFCs, and given I would hope to fully read 20 a y= ear, I have little chance of keeping up. My devices team, well, If I can get them to read one paper. (What else ca= n I do, tell them to a RFC search on "mobile"?) So I'd like the specialists to distill there wisdom into a useable form t= o take to the front line. That is why I need a profile paper. Lorenzo, I feel you are like the specialist surgeon berating the GPs for = not knowing every RFC in its pure form. We have a difficult job dealing with the front line here. If terminal folks really don't need to know about some of these items, le= ts remove them. Perhaps the IETF leads should think about a class of document for exactly= =20this need.=20 It is not a pure standards paper, and should not be judged as so. It could have all the health warnings that Barbara et al would like to se= e. Better to have it than not - that is my view. I only see these becoming more prevalent, we are no longer in an industry= =20where a handful of IP vendors roll out the latest RFCs into code. Soon every electronic device will have an IP stack, IP features and more.= =20IP Developers will soon be like GPs, not specialists! Help them out. Nick * I don't know if GP is an international term - General Practitioner mean= s local doctor who sees patients in the surgery! -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BARBARA H= Sent: 13 February 2015 14:05 To: Alexandru Petrescu; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "h= armfully broad"? > When I go through procurements often the vendors ask the RFC list that = > need to be there. This criterion - the implemented RFC list - primes=20 > over all others such as software management, dimensions, price tags,=20 > electrical, temperature and noise features. If it were not for these=20 > little RFCs there would be no reasonable procurement. >=20 > That said, I also agree with you when you imply that the list of=20 > features in this draft may be too long, or too hard see coherence. >=20 > If so, then maybe we can try to reduce it a bit? >=20 > Finally, 'profile' is probably not the right title. It should qualify = > both the end- user device and the network device. Inside the company I work for, I try to encourage "thoughtful" use of "de= vice profile" RFCs such as this draft may become. That is, read through t= he entire RFC, and make sure you want everything that's mandated. If you = don't, pick and choose what makes sense for the product you are procuring= . I would definitely not recommend to anyone (inside or outside my compan= y) that they ask for compliance with this document without fully understa= nding the implications of what they are asking for. Basically, I see the = items listed in the draft as a set of potential items to consider when pu= tting together an RFP. As it relates to IPv6 "device profile" documents, I would like to mention= =20that CableLabs has been successful with its eRouter spec, BBF successf= ul with its TR-124, and I'm hoping CEA has impact on the CE industry with= =20its new CEA2048 publication (which they're offering for free through F= eb 28 -- see http://www2.ce.org/webmail/26962/296407969/c0b6a64961882e818= 5ea241297a29529). There does seem to be demand for "device profile" docum= ents. I do think the only reason RFC 7084 (which really is a "device prof= ile" RFC) was done in IETF was because of the need to identify requiremen= ts for CE routers that could connect to a variety of access network archi= tecture, and IETF was "neutral territory". I admit to finding it odd that= =20IETF would be used to publish a device profile that is only for device= s connecting to 3GPP access networks. But I'm not familiar with how 3GPP = works, so maybe it wasn't possible to get 3GPP to be willing to create a = profile for devices that attach to their access network . BTW, I'm very concerned about the fact that someone affiliated with a pro= vider of an OS found on many 3GPP devices has so many objections to this= =20particular "device profile". Knowing that, I would very, very strongly= =20recommend to people I work with that they be very, very careful about = how they use this particular "device profile" (if at all). I would not su= ggest including it directly in any RFP. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Fri Feb 13 07:35:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911881A874A for ; Fri, 13 Feb 2015 07:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-Kqar_lZG_T for ; Fri, 13 Feb 2015 07:34:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494AC1A8718 for ; Fri, 13 Feb 2015 07:34:54 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 62B9D3B4217; Fri, 13 Feb 2015 16:34:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2F62A3840A1; Fri, 13 Feb 2015 16:34:52 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 16:34:52 +0100 From: To: Alexandru Petrescu , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQR5pKH0P8VsyAQ0msn8bBnn4Z5Zzur24Q Date: Fri, 13 Feb 2015 15:34:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> In-Reply-To: <54DE0BA8.8020908@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.133920 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 15:34:58 -0000 UmUtLA0KDQpDTEFUIGlzIG5vdCBhIE1VU1QsIGl0IGlzIGxpc3RlZCBhcyBhICJzaG91bGQiLiBU aGUgbWFpbiBtb3RpdmF0aW9uIGZvciBpdCBpcyB0byBmaXggdGhlICJyZW1haW5pbmciIGFwcGxp Y2F0aW9ucyB0aGF0IGFyZSBicm9rZW4gaWYgSVB2Ni1vbmx5IG1vZGUgaXMgZW5hYmxlZDogSVB2 NC1vbmx5IGFwcGxpY2F0aW9ucyBvciB0aG9zZSB1c2luZyBJUHY0IHJlZmVycmFscyAoZS5nLiwg c2t5cGUgaXMgdXN1YWxseSBwcmVzZW50ZWQgYXMgYW4gZXhhbXBsZSBvZiBzdWNoIGFwcGxpY2F0 aW9ucykuIA0KDQpTb21lIG9wZXJhdG9ycyBhcmUgc2VlaW5nIENMQVQgYXMgY3JpdGljYWwgYmVj YXVzZSB0aGV5IGRvbid0IHdhbnQgdG8gaGF2ZSBhIHNlcnZpY2UgZGlzcnVwdGlvbiBjb21wYXJl ZCB0byBJUHY0IHdoZW4gSVB2Ni1vbmx5IGNvbm5lY3Rpdml0eSBpcyBwcm92aWRlZCB0byB0aGVp ciBjdXN0b21lcnMuIA0KDQpUaGUgY29tcGFyaXNvbiB3aXRoIHRoZSBEU0wgd29ybGQgaXMgbm90 IGFjY3VyYXRlIElNSE8gYmVjYXVzZSBlbmNhcHN1bGF0aW9uIHNjaGVtZXMgYXJlIHRoZSBydWxl IGluIGZpeGVkIGVudmlyb25tZW50cyAoZS5nLiwgRFMtbGl0ZSwgTUFQLCBsdzRvdmVyNiwgZXRj LikgZXZlbiBpZiB0aGVyZSBhcmUgcmVjZW50bHkgc29tZSBwcm9wb3NhbHMgcmVseWluZyBvbiBk b3VibGUgdHJhbnNsYXRpb24gKGUuZy4sIE1BUC1UKS4gDQoNCkluIHRoZSBtb2JpbGUgd29ybGQs IE5BVDY0IGlzIHRoZSBydWxlLg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQpEZcKgOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0 cmVzY3VAZ21haWwuY29tXSANCkVudm95w6nCoDogdmVuZHJlZGkgMTMgZsOpdnJpZXIgMjAxNSAx NTozNQ0Kw4DCoDogSGVhdGxleSwgTmljazsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2PC oDogdjZvcHNAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENfUkVDIzkgNDY0WExB VA0KDQpMZSAxMy8wMi8yMDE1IDE0OjE0LCBIZWF0bGV5LCBOaWNrIGEgw6ljcml0IDoNCj4gSGkg QWxleCwNCj4gWWVzLCB0aGF0IGlzIHdyb25nLg0KPiBZb3UgY2FuIHBpbmcgYW55IElQdjQgbGl0 ZXJhbCBmcm9tIGEgNDY0eGxhdCBkZXZpY2UuDQo+IE15IGhhbmRzZXQgb25seSBoYXMgYW4gSVB2 NiBhZGRyZXNzICsgQ0xBVCBhbmQgSSBhbSBwaW5naW5nIDguOC44LjggOi0pKQ0KDQpPaywgSSBz ZWUuICBJIGRpZG50IGtub3cgQ0xBVC1vbi1kZXZpY2Ugd2FzIHJlcXVpcmVkIHdoZW4gdXNpbmcg djYtb25seSANCkFQTnMuDQoNClRoYXQgbWVhbnMgdGhhdCB0aGUgZGV2aWNlIHZlbmRvcnMgTVVT VCBpbXBsZW1lbnQgQ0xBVCBpbiB0aGUgDQpzbWFydHBob25lcyB3aGljaCBjb25uZWN0IHRvIGEg djYtb25seSBBUE4uICBJdCBpcyBhIHRvbyBzdHJvbmcgcmVxdWlyZW1lbnQuDQoNCkl0IGlzIGVh c2llciBmb3IgYW4gZW5kIHVzZXIgdG8gY29ubmVjdCB0byBhIHB1cmUgdjQtQVBOIHJhdGhlciB0 aGFuIGEgDQp2NiBBUE4gd2l0aCBDTEFULg0KDQo+IEludGVybmV0LXNpZGUgaW5pdGlhdGVkIHRy YWZmaWMgd291bGQgYmUgYW4gaXNzdWUsIHNhbWUgYXMgTkFUNDQgQ0dOLg0KDQpZRXMsIEkgdW5k ZXJzdGFuZCB0aGF0IHJlYWNoYWJpbGl0eSBwcm9ibGVtLg0KDQpCdXQgaGVyZSB3ZSBoYXZlIGEg cHJvYmxlbSB3aXRoIHJlcXVpcmluZyB0aGUgZW5kIHVzZXIgZGV2aWNlIHRvIHJ1biANCnRyYW5z bGF0aW9uIGp1c3QgYmVjYXVzZSBvZiBJUHY2Lg0KDQpBcHAgd3JpdGVycyBoYXZlIGFscmVhZHkg c29sdmVkIHRoZSBOQVQ0NCByZXZlcnNlIHJlYWNoYWJpbGl0eSBwcm9ibGVtcyANCi0gdGhleSB3 b3JrIG9uIG5vbi1DTEFUIGRldmljZXMgYmVoaW5kIE5BVC4gIFRoZXNlIGFwcHMgd2lsbCBubyBs b25nZXIgDQp3b3JrIGluIHRoZSB2NiB3b3JsZCwgaWYgQ0xBVCBpcyBub3QgYWRkZWQuDQoNCk9u ZSB3b3VsZCBoYXJkbHkgbWlncmF0ZSB0byBJUHY2IGlmIHRvbyBtdWNoIHRyYW5zbGF0aW9uIGlz IHJlcXVpcmVkLCBiZSANCml0IHY0LXY2IG9yIHY2LXY0IHRyYW5zbGF0aW9uLg0KDQpDb21wYXJl IHRoaXMgdG8gdGhlIHY2IG1pZ3JhdGlvbiBpbiB0aGUgRFNMIHdvcmxkOiBubyBhZGRpdGlvbmFs IENMQVQgaXMgDQpyZXF1aXJlZCBvbiBlbmQtdXNlciBkZXZpY2VzLg0KDQpBbGV4DQoNCj4gTmlj aw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5kcnUgUGV0 cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50OiAxMyBG ZWJydWFyeSAyMDE1IDEyOjUyDQo+IFRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNy50 eHQgLSBDX1JFQyM5IDQ2NFhMQVQNCj4NCj4gTGUgMTMvMDIvMjAxNSAxMToxMywgSGVhdGxleSwg TmljayBhIMOpY3JpdCA6DQo+PiBBIHN0YXRlbWVudCBzdWNoIGFzDQo+Pj4gVGhlIGRldmljZSBz aG91bGQgb25seSBpbnZva2UgdGhlIENMQVQgaW4gdGhlIGFic2VuY2Ugb2YgYSB0aGUgSVB2NA0K Pj4+IEFGIGkuZS4gd2hlbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhc3NpZ24gYW4gSVB2NCBjZWxs dWxhciBhZGRyZXNzDQo+PiBjb3VsZCBiZSBoZWxwZnVsPw0KPj4NCj4+IFRvIGdvIGZ1cnRoZXIs IGFuZCBkZWZpbmUgYW55IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQsIHRoZW4gdGhhdCB3b3VsZA0K Pj4gYmUgZGVmaW5pbmcgaG93IGFuIE9wZXJhdG9yIGNvdWxkL3Nob3VsZCBtYW5hZ2UgdGhlaXIg cmVtYWluaW5nIElQdjQNCj4+IHB1YmxpYyBhbmQgcHJpdmF0ZSBhZGRyZXNzaW5nLiBUaGlzIHBh cGVyIHNob3VsZCBvbmx5IGZvY3VzIG9uIHRoZQ0KPj4gcmVxdWlyZWQgZGV2aWNlIGJlaGF2aW91 ci4NCj4+DQo+PiBBcyBhbiBhc2lkZSA0NjR4bGF0IGlzIGEgZGlyZWN0IHJlcGxhY2VtZW50IGZv ciB0aGUgTkFUNDQNCj4+IGVudmlyb25tZW50cywgdHlwaWNhbCBpbiBtb2JpbGUgb3BlcmF0b3Jz IHdpdGggbGFyZ2UgY29uc3VtZXIgYmFzZXMuDQo+DQo+IE5pY2ssDQo+DQo+IEFtIEkgd3Jvbmcg dG8gc2F5IHRoYXQgb25lIGNhbiBub3QgcGluZyA4LjguOC44IGZyb20gYmVoaW5kIGEgNDY0eGxh dCwgd2hlcmVhcyBvbmUgY2FuIHBpbmcgOC44LjguOCBiZWhpbmQgYSBuYXQ0ND8NCj4NCj4gSWYg SSBhbSBub3Qgd3JvbmcgdGhlbiA0NjR4bGF0IGFuZCBuYXQ0NCBhcmUgbm90IHJlYWxseSBlcXVp dmFsZW50Lg0KPg0KPiBBbGV4DQo+DQo+PiBJZGVhbCBpZiBhbiBvcGVyYXRvciBpcyBleGhhdXN0 aW5nIGJvdGggcHVibGljIGFuZCBwcml2YXRlIGFkZHJlc3MNCj4+IHNwYWNlLiBJZiBhbiBvcGVy YXRvciBoYXMgYW1wbGUgcHVibGljIElQdjQgYW5kIGhhcyBjb25zdW1lciBwcm9kdWN0cw0KPj4g dGhhdCBhcmUgTkFUNDQtZnJlZSwgdGhlbiB0aGV5IGFyZSBpbiBhIGRpZmZlcmVudCBwbGFjZSAo YSB1dG9waWEpLg0KPj4gTmljaw0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo+PiBPbiBCZWhh bGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBTZW50OiAxMyBGZWJydWFyeSAyMDE1 IDA2OjQ5DQo+PiBUbzoNCj4+IEFsZXhhbmRydSBQZXRyZXNjdSBDYzogdjZvcHNAaWV0Zi5vcmcg U3ViamVjdDogUmU6IFt2Nm9wc10gSS1EDQo+PiBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtbW9i aWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENfUkVDIzkNCj4+IDQ2NFhMQVQNCj4+DQo+PiBI aSBBbGV4LA0KPj4NCj4+IFRoZSBpbnRlbnQgb2YgdGhpcyByZWNvIGlzIHRvIGFkZHJlc3MgYnJv a2VuIElQdjQtb25seSBhcHBsaWNhdGlvbnMNCj4+IG92ZXIgYW4gSVB2Ni1vbmx5IGNvbm5lY3Rp dml0eS4gSWRlYWxseSBhcHBsaWNhdGlvbnMgcnVubmluZyBvbiB0aGUNCj4+IGRldmljZSBzaG91 bGQgYmUgQUYtaW5kZXBlbmRlbnQuDQo+Pg0KPj4gVGhlIGRyYWZ0IHJlbGllcyBvbiB0aGUgSVB2 NiBub2RlIHJlcXVpcmVtZW50cyBSRkMgdGhhdCBtYW5kYXRlcyB0aGUNCj4+IHN1cHBvcnRzIG9m IElQdjYuIEFsc28sIHRoZSBJLUQgY2FsbHMgb3V0IGFwcGxpY2F0aW9ucyB0aGF0IGFyZQ0KPj4g cHJvdmlkZWQgYnkgdGhlIHZlbmRvciBvZiB0aGUgZGV2aWNlOg0KPj4NCj4+ID09IEFQUF9SRUMj MjogIEFwcGxpY2F0aW9ucyBwcm92aWRlZCBieSB0aGUgbW9iaWxlIGRldmljZSB2ZW5kb3IgbXVz dA0KPj4gYmUgaW5kZXBlbmRlbnQgb2YgdGhlIHVuZGVybHlpbmcgSVAgYWRkcmVzcyBmYW1pbHku ID09DQo+Pg0KPj4gV291bGRuJ3QgdGhpcyByZWNvIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm4/DQo+ Pg0KPj4gVGhhbmsgeW91Lg0KPj4NCj4+IENoZWVycywgTWVkDQo+Pg0KPj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tIERlIDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XQ0KPj4gRGUgbGEgcGFydCBkZSBBbGV4YW5kcnUgUGV0cmVzY3UgRW52b3nDqSA6IGpldWRpIDEy IGbDqXZyaWVyIDIwMTUgMTc6MjcNCj4+IMOAIDogdjZvcHNAaWV0Zi5vcmcgT2JqZXQgOiBSZToN Cj4+IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUtMTcudHh0IC0NCj4+IENfUkVDIzkgNDY0WExBVA0KPj4NCj4+IEhlbGxvLA0KPj4NCj4+ IFRoYW5rIHlvdSBmb3IgdGhpcyBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+Pg0KPj4gSSBo YXZlIGEgZG91YnQgd2l0aCByZXNwZWN0IHRvIHRoZSA0NjRYTEFUIHJlcXVpcmVtZW50Og0KPj4+ IENfUkVDIzk6ICBJbiBvcmRlciB0byBlbnN1cmUgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkgaW4g YW4gSVB2Ni1vbmx5DQo+Pj4gZGVwbG95bWVudCBjb250ZXh0LCB0aGUgY2VsbHVsYXIgaG9zdCBz aG91bGQgaW1wbGVtZW50IHRoZSBDdXN0b21lcg0KPj4+IFNpZGUgVHJhbnNsYXRvciAoQ0xBVCwg W1JGQzY4NzddKSBmdW5jdGlvbiB3aGljaCBpcyBjb21wbGlhbnQgd2l0aA0KPj4+IFtSRkM2MDUy XVtSRkM2MTQ1XVtSRkM2MTQ2XS4NCj4+Pg0KPj4+IENMQVQgZnVuY3Rpb24gaW4gdGhlIGNlbGx1 bGFyIGhvc3QgYWxsb3dzIGZvciBJUHY0LW9ubHkgYXBwbGljYXRpb24NCj4+PiBhbmQgSVB2NC1y ZWZlcmFscyB0byB3b3JrIG9uIGFuIElQdjYtb25seSBjb25uZWN0aXZpdHkuICBDTEFUDQo+Pj4g ZnVuY3Rpb24gcmVxdWlyZXMgYSBOQVQ2NCBjYXBhYmlsaXR5IFtSRkM2MTQ2XSBpbiB0aGUgY29y ZSBuZXR3b3JrLg0KPj4+DQo+Pj4gVGhlIElQdjQgU2VydmljZSBDb250aW51aXR5IFByZWZpeCB1 c2VkIGJ5IENMQVQgaXMgZGVmaW5lZCBpbg0KPj4+IFtSRkM3MzM1XS4NCj4+DQo+PiBJIHRoaW5r IHRoaXMgcmVxdWlyZW1lbnQgbGVhZHMgdG8gYSBzaXR1YXRpb24gd2hlcmUgdGhlIG5ldHdvcmsN Cj4+IG9wZXJhdG9yIGRlcGxveXMgSVB2Ni1uYXRpdmUtb25seSBhbmQgSVB2NCBhcyBhbiBhZGQt b24gcGFydGlhbA0KPj4gZmVhdHVyZS4NCj4+DQo+PiBPbiBvbmUgaGFuZCwgaXQgaXMgZW5jb3Vy YWdpbmcgdG8gc2VlIG5hdGl2ZSBJUHY2IGFuZCBubyBJUHY0Lg0KPj4NCj4+IE9uIGFub3RoZXIg aGFuZCwgX3BhcnRpYWxfIElQdjQgc3VwcG9ydCBpcyBhIHRlbXB0YXRpb24gd2hpY2ggZGVjZWl2 ZXMNCj4+IGluIHRoZSBlbmQgLSAgaXQgbGVhZHMgdG8gdHVybiBvZmYgSVB2NiBhbmQgY29tZSBi YWNrIHRvIGdvb2Qgb2wnIElQdjQNCj4+IGFuZCBubyBJUHY2Lg0KPj4NCj4+IFRoZSA0NjRYTEFU IGlzIHBhcnRpYWwgSVB2NCBzdXBwb3J0OiBkb2VzIG5vdCBvZmZlciBmdWxsIElQdjQNCj4+IGNv bm5lY3Rpdml0eSB0byB0aGUgc21hcnRwaG9uZS4gIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBhZGRy ZXNzIHRoZQ0KPj4gc21hcnRwaG9uZSBieSBpdHMgSVB2NCBhZGRyZXNzIC0gRE5TIGlzIHJlcXVp cmVkOyB0aGlzIG1ha2VzIGl0DQo+PiBpbXBvc3NpYmxlIHRvIG1ha2UgYSBWUE4gdHVubmVsLCBv ciBNb2JpbGUgSVAuICBPbmUgY2FuIG5vdCBhIGRlcGxveSBhDQo+PiB3aXJlbGVzcyBJUHY0IHJv dXRlciBhbG9uZyB0aGUgcm9hZCBpbiBhIHJlbW90ZSBhcmVhLCBmb3IgZXhhbXBsZS4NCj4+DQo+ PiBUaGlzIGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBvcGVyYXRvciByZXF1aXJlcyBl bmQgdXNlciB0bw0KPj4gc3dpdGNoIHRvIGFub3RoZXIgQVBOIHdoaWNoIGlzIGxlc3MgSVB2Ni4N Cj4+DQo+PiBJIHRoaW5rIGl0IGlzIG5vdCBhIGhhcHB5IHNpdHVhdGlvbi4NCj4+DQo+PiBJIHdv dWxkICBzdWdnZXN0IHRvIHF1YWxpZnkgdGhpcyByZXF1aXJlbWVudCBieSBhbm90aGVyIHJlcXVp cmVtZW50Lg0KPj4gVGhpcyBpbml0aWFsIHJlcXVpcmVtZW50IHdvdWxkIHN0YXRlIHRoYXQgX2Zp cnN0XywgYmVmb3JlIGFueSB2NC12Ng0KPj4gY29udmVyc2lvbiBtZWNoYW5pc20gaXMgY29uc2lk ZXJlZCwgYm90aCB0aGUgbmV0d29yayBhbmQgdGhlIGVuZCB1c2VyDQo+PiBNVVNUIGltcGxlbWVu dCBhIG5hdGl2ZSBJUHY0IHN0YWNrIGFuZCBhIG5hdGl2ZSBJUHY2IHN0YWNrIChub3Qgc2F5DQo+ PiAnZHVhbCcgc3RhY2ssIHdoaWNoIGlzIG11Y2ggb3ZlcmxvYWRlZCkuDQo+Pg0KPj4gV2UgZG9u dCB3YW50IHRvIGJsb2NrIElQdjQgdXNlIHdoZW4gSVB2NiBhcnJpdmVzLg0KPj4NCj4+IEFsZXgN Cj4+DQo+PiAxMi8wMi8yMDE1IDEzOjQyLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgYSDDqWNy aXQgOg0KPj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj4gZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nDQo+Pj4gR3JvdXAgb2Yg dGhlIElFVEYuDQo+Pj4NCj4+PiBUaXRsZSAgICAgICAgICAgOiBBbiBJbnRlcm5ldCBQcm90b2Nv bCBWZXJzaW9uIDYgKElQdjYpIFByb2ZpbGUgZm9yDQo+Pj4gM0dQUCBNb2JpbGUgRGV2aWNlcyBB dXRob3JzICAgICAgICAgOiBEYXZpZCBCaW5ldCBNb2hhbWVkDQo+Pj4gQm91Y2FkYWlyIEFsZXMg Vml6ZGFsIEdhbmcgQ2hlbiBOaWNrIEhlYXRsZXkgUm9zcyBDaGFuZGxlciBGaWxlbmFtZQ0KPj4+ IDogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IFBhZ2VzICAg ICAgICAgICA6DQo+Pj4gMTggRGF0ZSAgICAgICAgICAgIDogMjAxNS0wMi0xMg0KPj4+DQo+Pj4g QWJzdHJhY3Q6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHByb2ZpbGUgdGhhdCBpcyBhIHN1cGVy c2V0IG9mIHRoYXQNCj4+PiBvZiB0aGUgY29ubmVjdGlvbiB0byBJUHY2IGNlbGx1bGFyIG5ldHdv cmtzIGRlZmluZWQgaW4gdGhlDQo+Pj4gSVB2NiBmb3IgVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVy c2hpcCBQcm9qZWN0ICgzR1BQKSBDZWxsdWxhciBIb3N0cw0KPj4+IGRvY3VtZW50LiAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGFuIElQdjYgcHJvZmlsZSB0aGF0IGEgbnVtYmVyIG9mDQo+Pj4gb3Bl cmF0b3JzIHJlY29tbWVuZCBpbiBvcmRlciB0byBjb25uZWN0IDNHUFAgbW9iaWxlIGRldmljZXMg dG8gYW4NCj4+PiBJUHY2LW9ubHkgb3IgZHVhbC1zdGFjayB3aXJlbGVzcyBuZXR3b3JrIChpbmNs dWRpbmcgM0dQUCBjZWxsdWxhcg0KPj4+IG5ldHdvcmsgYW5kIElFRUUgODAyLjExIG5ldHdvcmsp IHdpdGggYSBzcGVjaWFsIGZvY3VzIG9uIElQdjQgc2VydmljZQ0KPj4+IGNvbnRpbnVpdHkgZmVh dHVyZXMuDQo+Pj4NCj4+PiBCb3RoIGhvc3RzIGFuZCBkZXZpY2VzIHdpdGggY2FwYWJpbGl0eSB0 byBzaGFyZSB0aGVpciBXQU4gKFdpZGUgQXJlYQ0KPj4+IE5ldHdvcmspIGNvbm5lY3Rpdml0eSBh cmUgaW4gc2NvcGUuDQo+Pj4NCj4+Pg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maQ0KPj4+IGwNCj4+Pg0KPj4+ DQo+IGUvDQo+Pj4NCj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJs ZSBhdDoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW1v YmlsZS1kZXZpY2UtcHJvZmlsZS0xNw0KPj4+DQo+Pj4NCj4+Pg0KPiBBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpDQo+Pj4g bA0KPj4+DQo+Pj4NCj4gZS0xNw0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0K Pj4+IHRvb2xzLmlldGYub3JnLg0KPj4+DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+PiB2Nm9wc0BpZXRmLm9yZyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pj4NCj4+Pg0KPj4NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3Jn IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+PiBOT1RJ Q0UgQU5EIERJU0NMQUlNRVIgVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMp IGlzDQo+PiBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyDQo+PiBzeXN0ZW0gYW5kIGRvIG5v dCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLg0KPj4NCj4+IFdlIG1heSBtb25pdG9y IGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50DQo+ PiBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVt YWlsIGFuZA0KPj4gYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCBy ZW1haW5zIHlvdXINCj4+IHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8g bm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KPj4NCj4+IEVFIExpbWl0ZWQgUmVnaXN0ZXJlZCBp biBFbmdsYW5kIGFuZCBXYWxlcyBDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOg0KPj4gMDIzODIx NjEgUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5 LA0KPj4gSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXLg0KPj4NCj4NCj4NCj4NCj4g Tk9USUNFIEFORCBESVNDTEFJTUVSDQo+IFRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlz Y2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4NCj4NCj4gV2UgbWF5IG1vbml0b3IgYWxsIGlu Y29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRp b24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0 YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVz cG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVj dCB5b3UuDQo+DQo+IEVFIExpbWl0ZWQNCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxl cw0KPiBDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KPiBSZWdpc3RlcmVkIE9m ZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0 Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCj4NCg0KDQo= From nobody Fri Feb 13 08:14:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43AC1A8755 for ; Fri, 13 Feb 2015 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdDXx5O3NC16 for ; Fri, 13 Feb 2015 08:13:41 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BCC1A8762 for ; Fri, 13 Feb 2015 08:13:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DGD0Nt031065; Fri, 13 Feb 2015 17:13:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 61E432075BD; Fri, 13 Feb 2015 17:13:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53F572074DE; Fri, 13 Feb 2015 17:13:56 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DGCjTJ010425; Fri, 13 Feb 2015 17:13:00 +0100 Message-ID: <54DE227D.9050303@gmail.com> Date: Fri, 13 Feb 2015 17:12:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Heatley, Nick" , "mohamed.boucadair@orange.com" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:13:56 -0000 Le 13/02/2015 16:33, Heatley, Nick a écrit : > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35 > To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 14:14, Heatley, Nick a écrit : >> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a >> 464xlat device. My handset only has an IPv6 address + CLAT and I am >> pinging 8.8.8.8 :-)) > > Ok, I see. I didnt know CLAT-on-device was required when using > v6-only APNs. > > [Heatley, Nick] For service continuity with IPv4, on an IPv6-only > bearer use CLAT. A slightly pedantic note, if you have a "dual stack > APN" but the device only requests IPv6 then the device will receive > an IPv6 bearer and requires CLAT. You will hear from Ross and me > talking about having a single APN supporting all modes, IPv4, IPv4v6 > and IPv6 bearers. There may be business reasons for this, as well as > avoiding consumers having to change APNs. In my understanding 464xlat/clat are trials these days. They could be improved before going live. If the 464xlat/clat happened elsewhere than on the user terminal (e.g. BAse Station) I think more of these terminals could be accommodated, more business. > That means that the device vendors MUST implement CLAT in the > smartphones which connect to a v6-only APN. It is a too strong > requirement. > > [Heatley, Nick] Today's reality is that operators cannot take devices > to IPv6-only mode of operation without CLAT. In the future will other > alternatives appear? Alternatives there are very many. E.g. 464lat/clat to run on an operator-controlled network device, not on end-user terminal. E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device. 3GPP also designed a DS-MIPv6, not sure whether you are aware of it. It had the same goal of terminal on v6-only link. It's hard to justify requiring just one of them on all end-user terminals because it will surely affect the other. > It is easier for an end user to connect to a pure v4-APN rather than > a v6 APN with CLAT. > > [Heatley, Nick] If they have the choice....when the element of choice > is taken away, the operator must make their network bullet proof for > all devices supported. Well, historic operators, MVNOs? Historic operators today no longer 'own' the device as in the recent past. Yes, they have contracts with well-funded manufacturers, but they also accept any other device to connect to their networks. They sell SIM cards with DATA plans regardless of the device in which this SIM card ends: they must offer unlocking codes of all devices they sell. Finally they must accept phone number portability for free. If this 464xlat/clat requirement is between a Historic operator and an MVNOs, then it may make sense. But one can not require the end-user to run CLAT translation. Alex >> Internet-side initiated traffic would be an issue, same as NAT44 >> CGN. > > YEs, I understand that reachability problem. > > But here we have a problem with requiring the end user device to run > translation just because of IPv6. > > App writers have already solved the NAT44 reverse reachability > problems - they work on non-CLAT devices behind NAT. These apps will > no longer work in the v6 world, if CLAT is not added. > > One would hardly migrate to IPv6 if too much translation is required, > be it v4-v6 or v6-v4 translation. > > Compare this to the v6 migration in the DSL world: no additional CLAT > is required on end-user devices. > > Alex > >> Nick >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 12:52 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Le 13/02/2015 11:13, Heatley, Nick a écrit : >>> A statement such as >>>> The device should only invoke the CLAT in the absence of a the >>>> IPv4 AF i.e. when the network does not assign an IPv4 cellular >>>> address >>> could be helpful? >>> >>> To go further, and define any additional requirement, then that >>> would be defining how an Operator could/should manage their >>> remaining IPv4 public and private addressing. This paper should >>> only focus on the required device behaviour. >>> >>> As an aside 464xlat is a direct replacement for the NAT44 >>> environments, typical in mobile operators with large consumer >>> bases. >> >> Nick, >> >> Am I wrong to say that one can not ping 8.8.8.8 from behind a >> 464xlat, whereas one can ping 8.8.8.8 behind a nat44? >> >> If I am not wrong then 464xlat and nat44 are not really >> equivalent. >> >> Alex >> >>> Ideal if an operator is exhausting both public and private >>> address space. If an operator has ample public IPv4 and has >>> consumer products that are NAT44-free, then they are in a >>> different place (a utopia). Nick >>> >>> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To: >>> Alexandru Petrescu Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D >>> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 >>> 464XLAT >>> >>> Hi Alex, >>> >>> The intent of this reco is to address broken IPv4-only >>> applications over an IPv6-only connectivity. Ideally applications >>> running on the device should be AF-independent. >>> >>> The draft relies on the IPv6 node requirements RFC that mandates >>> the supports of IPv6. Also, the I-D calls out applications that >>> are provided by the vendor of the device: >>> >>> == APP_REC#2: Applications provided by the mobile device vendor >>> must be independent of the underlying IP address family. == >>> >>> Wouldn't this reco addresses your concern? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : v6ops >>> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >>> Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : >>> Re: [v6ops] I-D Action: >>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >>> >>> Hello, >>> >>> Thank you for this new version of the draft. >>> >>> I have a doubt with respect to the 464XLAT requirement: >>>> C_REC#9: In order to ensure IPv4 service continuity in an >>>> IPv6-only deployment context, the cellular host should >>>> implement the Customer Side Translator (CLAT, [RFC6877]) >>>> function which is compliant with [RFC6052][RFC6145][RFC6146]. >>>> >>>> CLAT function in the cellular host allows for IPv4-only >>>> application and IPv4-referals to work on an IPv6-only >>>> connectivity. CLAT function requires a NAT64 capability >>>> [RFC6146] in the core network. >>>> >>>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>>> [RFC7335]. >>> >>> I think this requirement leads to a situation where the network >>> operator deploys IPv6-native-only and IPv4 as an add-on partial >>> feature. >>> >>> On one hand, it is encouraging to see native IPv6 and no IPv4. >>> >>> On another hand, _partial_ IPv4 support is a temptation which >>> deceives in the end - it leads to turn off IPv6 and come back >>> to good ol' IPv4 and no IPv6. >>> >>> The 464XLAT is partial IPv4 support: does not offer full IPv4 >>> connectivity to the smartphone. It is not possible to address >>> the smartphone by its IPv4 address - DNS is required; this makes >>> it impossible to make a VPN tunnel, or Mobile IP. One can not a >>> deploy a wireless IPv4 router along the road in a remote area, >>> for example. >>> >>> This leads to a situation where the operator requires end user >>> to switch to another APN which is less IPv6. >>> >>> I think it is not a happy situation. >>> >>> I would suggest to qualify this requirement by another >>> requirement. This initial requirement would state that _first_, >>> before any v4-v6 conversion mechanism is considered, both the >>> network and the end user MUST implement a native IPv4 stack and a >>> native IPv6 stack (not say 'dual' stack, which is much >>> overloaded). >>> >>> We dont want to block IPv4 use when IPv6 arrives. >>> >>> Alex >>> >>> 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> IPv6 Operations Working Group of the IETF. >>>> >>>> Title : An Internet Protocol Version 6 (IPv6) Profile >>>> for 3GPP Mobile Devices Authors : David Binet Mohamed >>>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >>>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages >>>> : 18 Date : 2015-02-12 >>>> >>>> Abstract: This document defines a profile that is a superset of >>>> that of the connection to IPv6 cellular networks defined in >>>> the IPv6 for Third Generation Partnership Project (3GPP) >>>> Cellular Hosts document. This document defines an IPv6 profile >>>> that a number of operators recommend in order to connect 3GPP >>>> mobile devices to an IPv6-only or dual-stack wireless network >>>> (including 3GPP cellular network and IEEE 802.11 network) with >>>> a special focus on IPv4 service continuity features. >>>> >>>> Both hosts and devices with capability to share their WAN (Wide >>>> Area Network) connectivity are in scope. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-prof >>>> >>>> i >>>> l >>>> >>>> >> e/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >>>> >>>> >>>> >> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-prof >>>> >>>> i >>>> l >>>> >>>> >> e-17 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time >>>> of submission until the htmlized version and diff are available >>>> at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >>> intended for the above-named person(s). If you are not the >>> intended recipient, notify the sender immediately, delete this >>> email from your system and do not disclose or use for any >>> purpose. >>> >>> We may monitor all incoming and outgoing emails in line with >>> current legislation. We have taken steps to ensure that this >>> email and attachments are free from any virus, but it remains >>> your responsibility to ensure that viruses do not adversely >>> affect you. >>> >>> EE Limited Registered in England and Wales Company Registered >>> Number: 02382161 Registered Office Address: Trident Place, >>> Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. >>> >> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >> intended for the above-named person(s). If you are not the >> intended recipient, notify the sender immediately, delete this >> email from your system and do not disclose or use for any purpose. >> >> We may monitor all incoming and outgoing emails in line with >> current legislation. We have taken steps to ensure that this email >> and attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely affect you. >> >> EE Limited Registered in England and Wales Company Registered >> Number: 02382161 Registered Office Address: Trident Place, Mosquito >> Way, Hatfield, Hertfordshire, AL10 9BW. >> > > > > NOTICE AND DISCLAIMER This e-mail (including any attachments) is > intended for the above-named person(s). If you are not the intended > recipient, notify the sender immediately, delete this email from your > system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely affect you. > > EE Limited Registered in England and Wales Company Registered Number: > 02382161 Registered Office Address: Trident Place, Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > From nobody Fri Feb 13 08:59:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD61A8781 for ; Fri, 13 Feb 2015 08:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU1dLKgeR126 for ; Fri, 13 Feb 2015 08:59:03 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A911A000D for ; Fri, 13 Feb 2015 08:59:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DGwwGL000445; Fri, 13 Feb 2015 17:58:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ABF5D207634; Fri, 13 Feb 2015 17:59:54 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E0B52074E8; Fri, 13 Feb 2015 17:59:54 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DGweTC013288; Fri, 13 Feb 2015 17:58:58 +0100 Message-ID: <54DE2D40.50908@gmail.com> Date: Fri, 13 Feb 2015 17:58:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:59:07 -0000 Le 13/02/2015 16:34, mohamed.boucadair@orange.com a écrit : > Re-, > > CLAT is not a MUST, it is listed as a "should". I think CLAT should be a MAY, for those who need it. I think the operator should offer a high level of simultaneous IPv4 and IPv6 access even though the end user forgets to run CLAT. > The main motivation for it is to fix the "remaining" applications > that are broken if IPv6-only mode is enabled: IPv4-only applications > or those using IPv4 referrals (e.g., skype is usually presented as > an example of such applications). One wouldn't fix applications by improving routing, no. One could develop a CLAT checkbox in the skype Options menu. But one would not require all other IPv4 apps in the Host to go through the CLAT daemon. > Some operators are seeing CLAT as critical because they don't want to > have a service disruption compared to IPv4 when IPv6-only > connectivity is provided to their customers. I agree about the criticality of IPv4 apps when IPv6-only connectivity is in place. But why should there be IPv6-only connectivity in place today for the masses? Nobody but some ultra-geek do this IPv6-only today. Even if the operator's network is IPv6 only, it should have means to translate between v4 and v6 at its edges, such as to show pure IPv4 and pure IPv6 to end user. > The comparison with the DSL world is not accurate IMHO because > encapsulation schemes are the rule in fixed environments (e.g., > DS-lite, MAP, lw4over6, etc.) even if there are recently some > proposals relying on double translation (e.g., MAP-T). Yes, in the DSL world encapsulations schemes are used. But they don't touch the end users. I think even with 464xlat/clat there is some encapsulation, although much of it is probably address or header rewriting. An end-user wouldnt normally care how much of this is translation, address rewriting, packet-in-packet encapsulation. But would be surprised to be imposed to do it. Because it interacts with other networking software like VPN, Mobile IP and has additional software requirements. > In the mobile world, NAT64 is the rule. Well, IMHO it's delicate to attach importance to something having NAT and IPv6 in a same term. Yours, Alex > > Cheers, Med > > -----Message d'origine----- De : Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Envoyé : vendredi 13 février > 2015 15:35 À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc : > v6ops@ietf.org Objet : Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 14:14, Heatley, Nick a écrit : >> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a >> 464xlat device. My handset only has an IPv6 address + CLAT and I am >> pinging 8.8.8.8 :-)) > > Ok, I see. I didnt know CLAT-on-device was required when using > v6-only APNs. > > That means that the device vendors MUST implement CLAT in the > smartphones which connect to a v6-only APN. It is a too strong > requirement. > > It is easier for an end user to connect to a pure v4-APN rather than > a v6 APN with CLAT. > >> Internet-side initiated traffic would be an issue, same as NAT44 >> CGN. > > YEs, I understand that reachability problem. > > But here we have a problem with requiring the end user device to run > translation just because of IPv6. > > App writers have already solved the NAT44 reverse reachability > problems - they work on non-CLAT devices behind NAT. These apps will > no longer work in the v6 world, if CLAT is not added. > > One would hardly migrate to IPv6 if too much translation is required, > be it v4-v6 or v6-v4 translation. > > Compare this to the v6 migration in the DSL world: no additional CLAT > is required on end-user devices. > > Alex > >> Nick >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 12:52 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Le 13/02/2015 11:13, Heatley, Nick a écrit : >>> A statement such as >>>> The device should only invoke the CLAT in the absence of a the >>>> IPv4 AF i.e. when the network does not assign an IPv4 cellular >>>> address >>> could be helpful? >>> >>> To go further, and define any additional requirement, then that >>> would be defining how an Operator could/should manage their >>> remaining IPv4 public and private addressing. This paper should >>> only focus on the required device behaviour. >>> >>> As an aside 464xlat is a direct replacement for the NAT44 >>> environments, typical in mobile operators with large consumer >>> bases. >> >> Nick, >> >> Am I wrong to say that one can not ping 8.8.8.8 from behind a >> 464xlat, whereas one can ping 8.8.8.8 behind a nat44? >> >> If I am not wrong then 464xlat and nat44 are not really >> equivalent. >> >> Alex >> >>> Ideal if an operator is exhausting both public and private >>> address space. If an operator has ample public IPv4 and has >>> consumer products that are NAT44-free, then they are in a >>> different place (a utopia). Nick >>> >>> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To: >>> Alexandru Petrescu Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D >>> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 >>> 464XLAT >>> >>> Hi Alex, >>> >>> The intent of this reco is to address broken IPv4-only >>> applications over an IPv6-only connectivity. Ideally applications >>> running on the device should be AF-independent. >>> >>> The draft relies on the IPv6 node requirements RFC that mandates >>> the supports of IPv6. Also, the I-D calls out applications that >>> are provided by the vendor of the device: >>> >>> == APP_REC#2: Applications provided by the mobile device vendor >>> must be independent of the underlying IP address family. == >>> >>> Wouldn't this reco addresses your concern? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : v6ops >>> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >>> Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : >>> Re: [v6ops] I-D Action: >>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >>> >>> Hello, >>> >>> Thank you for this new version of the draft. >>> >>> I have a doubt with respect to the 464XLAT requirement: >>>> C_REC#9: In order to ensure IPv4 service continuity in an >>>> IPv6-only deployment context, the cellular host should >>>> implement the Customer Side Translator (CLAT, [RFC6877]) >>>> function which is compliant with [RFC6052][RFC6145][RFC6146]. >>>> >>>> CLAT function in the cellular host allows for IPv4-only >>>> application and IPv4-referals to work on an IPv6-only >>>> connectivity. CLAT function requires a NAT64 capability >>>> [RFC6146] in the core network. >>>> >>>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>>> [RFC7335]. >>> >>> I think this requirement leads to a situation where the network >>> operator deploys IPv6-native-only and IPv4 as an add-on partial >>> feature. >>> >>> On one hand, it is encouraging to see native IPv6 and no IPv4. >>> >>> On another hand, _partial_ IPv4 support is a temptation which >>> deceives in the end - it leads to turn off IPv6 and come back to >>> good ol' IPv4 and no IPv6. >>> >>> The 464XLAT is partial IPv4 support: does not offer full IPv4 >>> connectivity to the smartphone. It is not possible to address >>> the smartphone by its IPv4 address - DNS is required; this makes >>> it impossible to make a VPN tunnel, or Mobile IP. One can not a >>> deploy a wireless IPv4 router along the road in a remote area, >>> for example. >>> >>> This leads to a situation where the operator requires end user >>> to switch to another APN which is less IPv6. >>> >>> I think it is not a happy situation. >>> >>> I would suggest to qualify this requirement by another >>> requirement. This initial requirement would state that _first_, >>> before any v4-v6 conversion mechanism is considered, both the >>> network and the end user MUST implement a native IPv4 stack and a >>> native IPv6 stack (not say 'dual' stack, which is much >>> overloaded). >>> >>> We dont want to block IPv4 use when IPv6 arrives. >>> >>> Alex >>> >>> 12/02/2015 13:42, internet-drafts@ietf.org a écrit : >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> IPv6 Operations Working Group of the IETF. >>>> >>>> Title : An Internet Protocol Version 6 (IPv6) Profile >>>> for 3GPP Mobile Devices Authors : David Binet Mohamed >>>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >>>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages >>>> : 18 Date : 2015-02-12 >>>> >>>> Abstract: This document defines a profile that is a superset of >>>> that of the connection to IPv6 cellular networks defined in the >>>> IPv6 for Third Generation Partnership Project (3GPP) Cellular >>>> Hosts document. This document defines an IPv6 profile that a >>>> number of operators recommend in order to connect 3GPP mobile >>>> devices to an IPv6-only or dual-stack wireless network >>>> (including 3GPP cellular network and IEEE 802.11 network) with >>>> a special focus on IPv4 service continuity features. >>>> >>>> Both hosts and devices with capability to share their WAN (Wide >>>> Area Network) connectivity are in scope. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profi >>>> >>>> >>>> >>>> l >>>> >>>> >> e/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >>>> >>>> >>>> >> >>>> >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profi >>>> >>>> >>>> >>>> l >>>> >>>> >> e-17 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time >>>> of submission until the htmlized version and diff are >>>> available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >>> intended for the above-named person(s). If you are not the >>> intended recipient, notify the sender immediately, delete this >>> email from your system and do not disclose or use for any >>> purpose. >>> >>> We may monitor all incoming and outgoing emails in line with >>> current legislation. We have taken steps to ensure that this >>> email and attachments are free from any virus, but it remains >>> your responsibility to ensure that viruses do not adversely >>> affect you. >>> >>> EE Limited Registered in England and Wales Company Registered >>> Number: 02382161 Registered Office Address: Trident Place, >>> Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. >>> >> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >> intended for the above-named person(s). If you are not the >> intended recipient, notify the sender immediately, delete this >> email from your system and do not disclose or use for any purpose. >> >> We may monitor all incoming and outgoing emails in line with >> current legislation. We have taken steps to ensure that this email >> and attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely affect you. >> >> EE Limited Registered in England and Wales Company Registered >> Number: 02382161 Registered Office Address: Trident Place, Mosquito >> Way, Hatfield, Hertfordshire, AL10 9BW. >> > > From nobody Fri Feb 13 09:11:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BB21A0065 for ; Fri, 13 Feb 2015 09:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxazeNVzd7iv for ; Fri, 13 Feb 2015 09:11:19 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59121A0097 for ; Fri, 13 Feb 2015 09:11:13 -0800 (PST) Received: from [85.158.136.3] by server-8.bemta-5.messagelabs.com id 91/79-03712-0303ED45; Fri, 13 Feb 2015 17:11:12 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-123.messagelabs.com!1423847471!43111424!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8831 invoked from network); 13 Feb 2015 17:11:11 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 17:11:11 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Fri, 13 Feb 2015 17:11:04 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 13 Feb 2015 17:11:11 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 17:11:10 +0000 From: "Heatley, Nick" To: Alexandru Petrescu , "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZzuJKAAgAA1/FCAAC9ogIAABSbAgAAXqQCAAAP9EIAAFzuAgAAMlVA= Date: Fri, 13 Feb 2015 17:11:09 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303DEA862@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> In-Reply-To: <54DE227D.9050303@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:11:21 -0000 PklmIHRoZSA0NjR4bGF0L2NsYXQgaGFwcGVuZWQgZWxzZXdoZXJlIHRoYW4gb24gdGhlIHVzZXIg dGVybWluYWwgKGUuZy4gQkFzZSBTdGF0aW9uKSBJIHRoaW5rIG1vcmUgb2YgdGhlc2UgdGVybWlu YWxzIGNvdWxkIGJlIGFjY29tbW9kYXRlZCwgbW9yZSBidXNpbmVzcy4NCg0KTm90IHBvc3NpYmxl IGluIG1vYmlsZSBhcmNoaXRlY3R1cmUuDQpUaGUgbW9iaWxlIGJlYXJlciAoYSB0dW5uZWwpIGlz IGJldHdlZW4gZGV2aWNlLCBhbmQgUEdXIGluIHRoZSBjb3JlIG5ldHdvcmssIGJlY2F1c2UgaXQg aXMgdGhlIGRldmljZSB0aGF0IGlzIG1vYmlsZS4NClBHVyBhc3NpZ25zIElQIGFkZHJlc3MgdG8g ZGV2aWNlLCBiYXNlIHN0YXRpb24gaXMganVzdCBhIHJlbGF5Lg0KRm9yIGJhc2Ugc3RhdGlvbiB0 byB0YWtlIHRoZSByb2xlIG9mIENMQVQgbWVhbnMgbm8gc2VhbWxlc3MgbW9iaWxpdHkuIA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21h aWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSANClNlbnQ6IDEzIEZlYnJ1YXJ5IDIw MTUgMTY6MTMNClRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENfUkVDIzkgNDY0 WExBVA0KDQpMZSAxMy8wMi8yMDE1IDE2OjMzLCBIZWF0bGV5LCBOaWNrIGEgw6ljcml0IDoNCj4N Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogQWxleGFuZHJ1IFBldHJlc2N1 IA0KPiBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb21dIFNlbnQ6IDEzIEZlYnJ1 YXJ5IDIwMTUgMTQ6MzUNCj4gVG86IEhlYXRsZXksIE5pY2s7IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246DQo+IGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAt IENfUkVDIzkgNDY0WExBVA0KPg0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1h aWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUt bmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91 ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiAgDQog DQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5l IHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUg dGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywg YnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2Vz IGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYx DQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXks IEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== From nobody Fri Feb 13 09:39:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC58E1A006F for ; Fri, 13 Feb 2015 09:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acy6AanVIN3X for ; Fri, 13 Feb 2015 09:38:59 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222BC1A0060 for ; Fri, 13 Feb 2015 09:37:37 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id k48so18001489wev.3 for ; Fri, 13 Feb 2015 09:37:35 -0800 (PST) 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=OjzEJC8tu5wgNDHR9YyX9L+3u1IPC7RDDz4jbBrVZlU=; b=U4VkRiec9k9QwhThDHUL7VnO9LDTIp/zdV64NaF3xat/WnrnsSZQhJdAcvIi3F3Uo9 fCCIy1q8hQTKLSWatIv2w5Yz1bBpnp3vl/Nc0Qw4y8PP9tE4jCoZY8N/ac+D4MorbAhi b1xdV/JqB67DzTaw6MyzzWLpil5mhhF8eAWfHPA8VJqVFNti55xZvJhzG/zCN/YR7gyk odJKm7lXU4aNTUtsBSYYqW88YbnVGnCG8wxpdEC01Mbf3omnKFx8z2fY0yVMvwdpAqrI 7xiTzSheK4S9/3Un1ieNxGYv1LNTFmrg42IvHj/8f9CcPYe1FmIRItxMP7P8x1ocAf1J UnoA== MIME-Version: 1.0 X-Received: by 10.194.2.43 with SMTP id 11mr9390520wjr.104.1423849054222; Fri, 13 Feb 2015 09:37:34 -0800 (PST) Received: by 10.216.107.198 with HTTP; Fri, 13 Feb 2015 09:37:34 -0800 (PST) In-Reply-To: <54DE227D.9050303@gmail.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> Date: Fri, 13 Feb 2015 09:37:34 -0800 Message-ID: From: Ca By To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b3a82b2173e8e050efbb1ac Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:39:08 -0000 --047d7b3a82b2173e8e050efbb1ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 13/02/2015 16:33, Heatley, Nick a =C3=A9crit : > >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Le 13/02/2015 14:14, Heatley, Nick a =C3=A9crit : >> >>> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a >>> 464xlat device. My handset only has an IPv6 address + CLAT and I am >>> pinging 8.8.8.8 :-)) >>> >> >> Ok, I see. I didnt know CLAT-on-device was required when using >> v6-only APNs. >> >> [Heatley, Nick] For service continuity with IPv4, on an IPv6-only >> bearer use CLAT. A slightly pedantic note, if you have a "dual stack >> APN" but the device only requests IPv6 then the device will receive >> an IPv6 bearer and requires CLAT. You will hear from Ross and me >> talking about having a single APN supporting all modes, IPv4, IPv4v6 >> and IPv6 bearers. There may be business reasons for this, as well as >> avoiding consumers having to change APNs. >> > > In my understanding 464xlat/clat are trials these days. They could be > improved before going live. If the 464xlat/clat happened elsewhere than = on > the user terminal (e.g. BAse Station) I think more of these terminals cou= ld > be accommodated, more business. Hi, T-Mobile US's IPv6 deployment is 100% 464XLAT. According to measurements, 49% of connections to major internet content is over IPv6 from T-Mobile US http://www.worldipv6launch.org/measurements/ According to public statement, T-Mobile US has 50+ million subscribers in q3 2014 So, 49% of 50 Million -- i do not think it is fair to characterize 464XLAT as only being a trial. Regards, Cameron > > > That means that the device vendors MUST implement CLAT in the >> smartphones which connect to a v6-only APN. It is a too strong >> requirement. >> >> [Heatley, Nick] Today's reality is that operators cannot take devices >> to IPv6-only mode of operation without CLAT. In the future will other >> alternatives appear? >> > > Alternatives there are very many. > > E.g. 464lat/clat to run on an operator-controlled network device, not on > end-user terminal. > > E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device. > > 3GPP also designed a DS-MIPv6, not sure whether you are aware of it. It > had the same goal of terminal on v6-only link. > > It's hard to justify requiring just one of them on all end-user terminals > because it will surely affect the other. > > It is easier for an end user to connect to a pure v4-APN rather than >> a v6 APN with CLAT. >> >> [Heatley, Nick] If they have the choice....when the element of choice >> is taken away, the operator must make their network bullet proof for >> all devices supported. >> > > Well, historic operators, MVNOs? > > Historic operators today no longer 'own' the device as in the recent > past. Yes, they have contracts with well-funded manufacturers, but they > also accept any other device to connect to their networks. They sell SIM > cards with DATA plans regardless of the device in which this SIM card end= s: > they must offer unlocking codes of all devices they sell. Finally they mu= st > accept phone number portability for free. > > If this 464xlat/clat requirement is between a Historic operator and an > MVNOs, then it may make sense. > > But one can not require the end-user to run CLAT translation. > > Alex > > > Internet-side initiated traffic would be an issue, same as NAT44 >>> CGN. >>> >> >> YEs, I understand that reachability problem. >> >> But here we have a problem with requiring the end user device to run >> translation just because of IPv6. >> >> App writers have already solved the NAT44 reverse reachability >> problems - they work on non-CLAT devices behind NAT. These apps will >> no longer work in the v6 world, if CLAT is not added. >> >> One would hardly migrate to IPv6 if too much translation is required, >> be it v4-v6 or v6-v4 translation. >> >> Compare this to the v6 migration in the DSL world: no additional CLAT >> is required on end-user devices. >> >> Alex >> >> Nick >>> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 12:52 >>> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] I-D Action: >>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >>> >>> Le 13/02/2015 11:13, Heatley, Nick a =C3=A9crit : >>> >>>> A statement such as >>>> >>>>> The device should only invoke the CLAT in the absence of a the >>>>> IPv4 AF i.e. when the network does not assign an IPv4 cellular >>>>> address >>>>> >>>> could be helpful? >>>> >>>> To go further, and define any additional requirement, then that >>>> would be defining how an Operator could/should manage their >>>> remaining IPv4 public and private addressing. This paper should >>>> only focus on the required device behaviour. >>>> >>>> As an aside 464xlat is a direct replacement for the NAT44 >>>> environments, typical in mobile operators with large consumer >>>> bases. >>>> >>> >>> Nick, >>> >>> Am I wrong to say that one can not ping 8.8.8.8 from behind a >>> 464xlat, whereas one can ping 8.8.8.8 behind a nat44? >>> >>> If I am not wrong then 464xlat and nat44 are not really >>> equivalent. >>> >>> Alex >>> >>> Ideal if an operator is exhausting both public and private >>>> address space. If an operator has ample public IPv4 and has >>>> consumer products that are NAT44-free, then they are in a >>>> different place (a utopia). Nick >>>> >>>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To: >>>> Alexandru Petrescu Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D >>>> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 >>>> 464XLAT >>>> >>>> Hi Alex, >>>> >>>> The intent of this reco is to address broken IPv4-only >>>> applications over an IPv6-only connectivity. Ideally applications >>>> running on the device should be AF-independent. >>>> >>>> The draft relies on the IPv6 node requirements RFC that mandates >>>> the supports of IPv6. Also, the I-D calls out applications that >>>> are provided by the vendor of the device: >>>> >>>> =3D=3D APP_REC#2: Applications provided by the mobile device vendor >>>> must be independent of the underlying IP address family. =3D=3D >>>> >>>> Wouldn't this reco addresses your concern? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>> -----Message d'origine----- De : v6ops >>>> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >>>> Envoy=C3=A9 : jeudi 12 f=C3=A9vrier 2015 17:27 =C3=80 : v6ops@ietf.org= Objet : >>>> Re: [v6ops] I-D Action: >>>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >>>> >>>> Hello, >>>> >>>> Thank you for this new version of the draft. >>>> >>>> I have a doubt with respect to the 464XLAT requirement: >>>> >>>>> C_REC#9: In order to ensure IPv4 service continuity in an >>>>> IPv6-only deployment context, the cellular host should >>>>> implement the Customer Side Translator (CLAT, [RFC6877]) >>>>> function which is compliant with [RFC6052][RFC6145][RFC6146]. >>>>> >>>>> CLAT function in the cellular host allows for IPv4-only >>>>> application and IPv4-referals to work on an IPv6-only >>>>> connectivity. CLAT function requires a NAT64 capability >>>>> [RFC6146] in the core network. >>>>> >>>>> The IPv4 Service Continuity Prefix used by CLAT is defined in >>>>> [RFC7335]. >>>>> >>>> >>>> I think this requirement leads to a situation where the network >>>> operator deploys IPv6-native-only and IPv4 as an add-on partial >>>> feature. >>>> >>>> On one hand, it is encouraging to see native IPv6 and no IPv4. >>>> >>>> On another hand, _partial_ IPv4 support is a temptation which >>>> deceives in the end - it leads to turn off IPv6 and come back >>>> to good ol' IPv4 and no IPv6. >>>> >>>> The 464XLAT is partial IPv4 support: does not offer full IPv4 >>>> connectivity to the smartphone. It is not possible to address >>>> the smartphone by its IPv4 address - DNS is required; this makes >>>> it impossible to make a VPN tunnel, or Mobile IP. One can not a >>>> deploy a wireless IPv4 router along the road in a remote area, >>>> for example. >>>> >>>> This leads to a situation where the operator requires end user >>>> to switch to another APN which is less IPv6. >>>> >>>> I think it is not a happy situation. >>>> >>>> I would suggest to qualify this requirement by another >>>> requirement. This initial requirement would state that _first_, >>>> before any v4-v6 conversion mechanism is considered, both the >>>> network and the end user MUST implement a native IPv4 stack and a >>>> native IPv6 stack (not say 'dual' stack, which is much >>>> overloaded). >>>> >>>> We dont want to block IPv4 use when IPv6 arrives. >>>> >>>> Alex >>>> >>>> 12/02/2015 13:42, internet-drafts@ietf.org a =C3=A9crit : >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. This draft is a work item of the >>>>> IPv6 Operations Working Group of the IETF. >>>>> >>>>> Title : An Internet Protocol Version 6 (IPv6) Profile >>>>> for 3GPP Mobile Devices Authors : David Binet Mohamed >>>>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler >>>>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages >>>>> : 18 Date : 2015-02-12 >>>>> >>>>> Abstract: This document defines a profile that is a superset of >>>>> that of the connection to IPv6 cellular networks defined in >>>>> the IPv6 for Third Generation Partnership Project (3GPP) >>>>> Cellular Hosts document. This document defines an IPv6 profile >>>>> that a number of operators recommend in order to connect 3GPP >>>>> mobile devices to an IPv6-only or dual-stack wireless network >>>>> (including 3GPP cellular network and IEEE 802.11 network) with >>>>> a special focus on IPv4 service continuity features. >>>>> >>>>> Both hosts and devices with capability to share their WAN (Wide >>>>> Area Network) connectivity are in scope. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-prof >>>>> >>>>> >>>>> i > >> l >>>>> >>>>> >>>>> e/ >>> >>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17 >>>>> >>>>> >>>>> >>>>> >>> >>>>> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-prof >>>>> >>>>> >>>>> i > >> l >>>>> >>>>> >>>>> e-17 >>> >>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time >>>>> of submission until the htmlized version and diff are available >>>>> at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >>>> intended for the above-named person(s). If you are not the >>>> intended recipient, notify the sender immediately, delete this >>>> email from your system and do not disclose or use for any >>>> purpose. >>>> >>>> We may monitor all incoming and outgoing emails in line with >>>> current legislation. We have taken steps to ensure that this >>>> email and attachments are free from any virus, but it remains >>>> your responsibility to ensure that viruses do not adversely >>>> affect you. >>>> >>>> EE Limited Registered in England and Wales Company Registered >>>> Number: 02382161 Registered Office Address: Trident Place, >>>> Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. >>>> >>>> >>> >>> >>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >>> intended for the above-named person(s). If you are not the >>> intended recipient, notify the sender immediately, delete this >>> email from your system and do not disclose or use for any purpose. >>> >>> We may monitor all incoming and outgoing emails in line with >>> current legislation. We have taken steps to ensure that this email >>> and attachments are free from any virus, but it remains your >>> responsibility to ensure that viruses do not adversely affect you. >>> >>> EE Limited Registered in England and Wales Company Registered >>> Number: 02382161 Registered Office Address: Trident Place, Mosquito >>> Way, Hatfield, Hertfordshire, AL10 9BW. >>> >>> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >> intended for the above-named person(s). If you are not the intended >> recipient, notify the sender immediately, delete this email from your >> system and do not disclose or use for any purpose. >> >> We may monitor all incoming and outgoing emails in line with current >> legislation. We have taken steps to ensure that this email and >> attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely affect you. >> >> EE Limited Registered in England and Wales Company Registered Number: >> 02382161 Registered Office Address: Trident Place, Mosquito Way, >> Hatfield, Hertfordshire, AL10 9BW. >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b3a82b2173e8e050efbb1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu &= lt;alexan= dru.petrescu@gmail.com> wrote:
Le 13/02/2= 015 16:33, Heatley, Nick a =C3=A9crit :


-----Original Message----- From: Alexandru Petrescu
[mailto:a= lexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35
To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action:
draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Le 13/02/2015 14:14, Heatley, Nick a =C3=A9crit :
Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a
464xlat device. My handset only has an IPv6 address + CLAT and I am
pinging 8.8.8.8 :-))

Ok, I see.=C2=A0 I didnt know CLAT-on-device was required when using
v6-only APNs.

[Heatley, Nick] For service continuity with IPv4, on an IPv6-only
bearer use CLAT. A slightly pedantic note,=C2=A0 if you have a "dual s= tack
APN" but the device only requests IPv6 then the device will receive an IPv6 bearer and requires CLAT. You will hear from Ross and me
talking about having a single APN supporting all modes, IPv4, IPv4v6
and IPv6 bearers. There may be business reasons for this, as well as
avoiding consumers having to change APNs.

 In my understanding 464xlat/clat are trials these days.=C2=A0 They could be= improved before going live.=C2=A0 If the 464xlat/clat happened elsewhere t= han on the user terminal (e.g. BAse Station) I think more of these terminal= s could be accommodated, more business.

Hi,=

T-Mobile US's IPv6 deployment is 100% 464XLAT= .

According to measurements, 49% of connections to= major internet content is over IPv6 from T-Mobile US

<= div>http://www.wor= ldipv6launch.org/measurements/

According to pu= blic statement, T-Mobile US has 50+ million subscribers in q3 2014

So, 49% of 50 Million -- i do not think it is fair to char= acterize 464XLAT as only being a trial.

Regards,

Cameron
=C2=A0


That means that the device vendors MUST implement CLAT in the
smartphones which connect to a v6-only APN.=C2=A0 It is a too strong
requirement.

[Heatley, Nick] Today's reality is that operators cannot take devices to IPv6-only mode of operation without CLAT. In the future will other
alternatives appear?

 Alternatives there are very many.

E.g. 464lat/clat to run on an operator-controlled network device, not on en= d-user terminal.

E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device.

3GPP also designed a DS-MIPv6, not sure whether you are aware of it.=C2=A0 = It had the same goal of terminal on v6-only link.

It's hard to justify requiring just one of them on all end-user termina= ls because it will surely affect the other.

It is easier for an end user to connect to a pure v4-APN rather than
a v6 APN with CLAT.

[Heatley, Nick] If they have the choice....when the element of choice
is taken away, the operator must make their network bullet proof for
all devices supported.

 Well, historic operators, MVNOs?

Historic operators today no longer 'own' the device as in the recen= t past.=C2=A0 Yes, they have contracts with well-funded manufacturers, but = they also accept any other device to connect to their networks.=C2=A0 They = sell SIM cards with DATA plans regardless of the device in which this SIM c= ard ends: they must offer unlocking codes of all devices they sell. Finally= they must accept phone number portability for free.

If this 464xlat/clat requirement is between a Historic operator and an MVNO= s, then it may make sense.

But one can not require the end-user to run CLAT translation.

Alex


Internet-side initiated traffic would be an issue, same as NAT44
CGN.

YEs, I understand that reachability problem.

But here we have a problem with requiring the end user device to run
translation just because of IPv6.

App writers have already solved the NAT44 reverse reachability
problems - they work on non-CLAT devices behind NAT.=C2=A0 These apps will<= br> no longer work in the v6 world, if CLAT is not added.

One would hardly migrate to IPv6 if too much translation is required,
be it v4-v6 or v6-v4 translation.

Compare this to the v6 migration in the DSL world: no additional CLAT
is required on end-user devices.

Alex

Nick

-----Original Message----- From: Alexandru Petrescu
[mailto:a= lexandru.petrescu@gmail.com] Sent: 13 February 2015 12:52
To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action:
draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Le 13/02/2015 11:13, Heatley, Nick a =C3=A9crit :
A statement such as
The device should only invoke the CLAT in the absence of a the
IPv4 AF i.e. when the network does not assign an IPv4 cellular
address
could be helpful?

To go further, and define any additional requirement, then that
would be defining how an Operator could/should manage their
remaining IPv4 public and private addressing. This paper should
only focus on the required device behaviour.

As an aside 464xlat is a direct replacement for the NAT44
environments, typical in mobile operators with large consumer
bases.

Nick,

Am I wrong to say that one can not ping 8.8.8.8 from behind a
464xlat, whereas one can ping 8.8.8.8 behind a nat44?

If I am not wrong then 464xlat and nat44 are not really
equivalent.

Alex

Ideal if an operator is exhausting both public and private
address space. If an operator has ample public IPv4 and has
consumer products that are NAT44-free, then they are in a
different place (a utopia). Nick


-----Original Message----- From: v6ops
[mailto:v6ops-b= ounces@ietf.org] On Behalf Of
mohamed.b= oucadair@orange.com Sent: 13 February 2015 06:49 To:
Alexandru Petrescu Cc: = v6ops@ietf.org Subject: Re: [v6ops] I-D
Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9
464XLAT

Hi Alex,

The intent of this reco is to address broken IPv4-only
applications over an IPv6-only connectivity. Ideally applications
running on the device should be AF-independent.

The draft relies on the IPv6 node requirements RFC that mandates
the supports of IPv6. Also, the I-D calls out applications that
are provided by the vendor of the device:

=3D=3D APP_REC#2:=C2=A0 Applications provided by the mobile device vendor must be independent of the underlying IP address family. =3D=3D

Wouldn't this reco addresses your concern?

Thank you.

Cheers, Med

-----Message d'origine----- De : v6ops
[mailto:v6ops-b= ounces@ietf.org] De la part de Alexandru Petrescu
Envoy=C3=A9 : jeudi 12 f=C3=A9vrier 2015 17:27 =C3=80 : v6ops@ietf.org Objet :
Re: [v6ops] I-D Action:
draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Hello,

Thank you for this new version of the draft.

I have a doubt with respect to the 464XLAT requirement:
C_REC#9:=C2=A0 In order to ensure IPv4 service continuity in an
IPv6-only deployment context, the cellular host should
implement the Customer Side Translator (CLAT, [RFC6877])
function which is compliant with [RFC6052][RFC6145][RFC6146].

CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only
connectivity.=C2=A0 CLAT function requires a NAT64 capability
[RFC6146] in the core network.

The IPv4 Service Continuity Prefix used by CLAT is defined in
[RFC7335].

I think this requirement leads to a situation where the network
operator deploys IPv6-native-only and IPv4 as an add-on partial
feature.

On one hand, it is encouraging to see native IPv6 and no IPv4.

On another hand, _partial_ IPv4 support is a temptation which
deceives in the end -=C2=A0 it leads to turn off IPv6 and come back
to good ol' IPv4 and no IPv6.

The 464XLAT is partial IPv4 support: does not offer full IPv4
connectivity to the smartphone.=C2=A0 It is not possible to address
the smartphone by its IPv4 address - DNS is required; this makes
it impossible to make a VPN tunnel, or Mobile IP.=C2=A0 One can not a
deploy a wireless IPv4 router along the road in a remote area,
for example.

This leads to a situation where the operator requires end user
to switch to another APN which is less IPv6.

I think it is not a happy situation.

I would=C2=A0 suggest to qualify this requirement by another
requirement. This initial requirement would state that _first_,
before any v4-v6 conversion mechanism is considered, both the
network and the end user MUST implement a native IPv4 stack and a
native IPv6 stack (not say 'dual' stack, which is much
overloaded).

We dont want to block IPv4 use when IPv6 arrives.

Alex

12/02/2015 13:42, internet-drafts@ietf.org a =C3=A9crit :

A New Internet-Draft is available from the on-line
Internet-Drafts directories. This draft is a work item of the
IPv6 Operations Working Group of the IETF.

Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Internet Protocol Versio= n 6 (IPv6) Profile
for 3GPP Mobile Devices Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: David Bi= net Mohamed
Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler
Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages
: 18 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-02-12

Abstract: This document defines a profile that is a superset of
that of the connection to IPv6 cellular networks defined in
the IPv6 for Third Generation Partnership Project (3GPP)
Cellular Hosts document.=C2=A0 This document defines an IPv6 profile
that a number of operators recommend in order to connect 3GPP
mobile devices to an IPv6-only or dual-stack wireless network
(including 3GPP cellular network and IEEE 802.11 network) with
a special focus on IPv4 service continuity features.

Both hosts and devices with capability to share their WAN (Wide
Area Network) connectivity are in scope.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= v6ops-mobile-device-prof


i
l


e/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-= mobile-device-profile-17





A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-v6ops-mobile-device-prof


i
l


e-17


Please note that it may take a couple of minutes from the time
of submission until the htmlized version and diff are available
at tools.ietf.org.<= br>
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________ v6ops mailing
list v6ops@ietf.org=
h= ttps://www.ietf.org/mailman/listinfo/v6ops




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

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

NOTICE AND DISCLAIMER This e-mail (including any attachments) is
intended for the above-named person(s).=C2=A0 If you are not the
intended recipient, notify the sender immediately, delete this
email from your system and do not disclose or use for any
purpose.

We may monitor all incoming and outgoing emails in line with
current legislation. We have taken steps to ensure that this
email and attachments are free from any virus, but it remains
your responsibility to ensure that viruses do not adversely
affect you.

EE Limited Registered in England and Wales Company Registered
Number: 02382161 Registered Office Address: Trident Place,
Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.




NOTICE AND DISCLAIMER This e-mail (including any attachments) is
intended for the above-named person(s).=C2=A0 If you are not the
intended recipient, notify the sender immediately, delete this
email from your system and do not disclose or use for any purpose.

We may monitor all incoming and outgoing emails in line with
current legislation. We have taken steps to ensure that this email
and attachments are free from any virus, but it remains your
responsibility to ensure that viruses do not adversely affect you.

EE Limited Registered in England and Wales Company Registered
Number: 02382161 Registered Office Address: Trident Place, Mosquito
Way, Hatfield, Hertfordshire, AL10 9BW.




NOTICE AND DISCLAIMER This e-mail (including any attachments) is
intended for the above-named person(s).=C2=A0 If you are not the intended recipient, notify the sender immediately, delete this email from your
system and do not disclose or use for any purpose.

We may monitor all incoming and outgoing emails in line with current
legislation. We have taken steps to ensure that this email and
attachments are free from any virus, but it remains your
responsibility to ensure that viruses do not adversely affect you.

EE Limited Registered in England and Wales Company Registered Number:
02382161 Registered Office Address: Trident Place, Mosquito Way,
Hatfield, Hertfordshire, AL10 9BW.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b3a82b2173e8e050efbb1ac-- From nobody Fri Feb 13 09:40:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206611A005F for ; Fri, 13 Feb 2015 09:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jURh_2zODVra for ; Fri, 13 Feb 2015 09:39:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739C01A0060 for ; Fri, 13 Feb 2015 09:39:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DHdcEQ024210; Fri, 13 Feb 2015 18:39:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CAF6A207623; Fri, 13 Feb 2015 18:40:34 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BDA89207598; Fri, 13 Feb 2015 18:40:34 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DHdPYo010286; Fri, 13 Feb 2015 18:39:38 +0100 Message-ID: <54DE36CD.20203@gmail.com> Date: Fri, 13 Feb 2015 18:39:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Heatley, Nick" , "mohamed.boucadair@orange.com" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA862@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303DEA862@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:39:53 -0000 Le 13/02/2015 18:11, Heatley, Nick a écrit : >> If the 464xlat/clat happened elsewhere than on the user terminal >> (e.g. BAse Station) I think more of these terminals could be >> accommodated, more business. > > Not possible in mobile architecture. If it is not possible to have v4-v6 translation in the Base Station, then it should be in the entity before it. 'PGW' mentioned? > The mobile bearer (a tunnel) is between device, and PGW in the core > network, because it is the device that is mobile. PGW assigns IP > address to device, base station is just a relay. In this case PGW (not the base station) should do translation. I said 'base station' to refer to the cheap stations for femto-cell. These run IP between an Ethernet cable and a 4G radio interface. They're basically PCs easy to deploy. It is easy to have many v4-v6 translation mechanisms on these PCs. > For base station to take the role of CLAT means no seamless > mobility. Well, by deduction this implies that seamless mobility is possible only if the end user implements CLAT. On another hand, seamless mobility is also achieved by something else which is called Mobile IP. The end user in some cases prefers this protocol over CLAT. This Mobile IP protocol works fine when the cellular access is v4-only. Also, the Mobile IPv6 protocol works fine when the cellular access is v6 only. Finally, Mobile IPv4 and Mobile IPv6 implementations work fine when the access is simultaneous v4 and v6. There are a number of access networks (beyond cellular) which work fine when the end user is Mobile IP. This stops working fine when the access is v6-only with CLAT. Alex > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 16:13 > To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 16:33, Heatley, Nick a écrit : >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> > > > NOTICE AND DISCLAIMER This e-mail (including any attachments) is > intended for the above-named person(s). If you are not the intended > recipient, notify the sender immediately, delete this email from > your system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely affect you. > > EE Limited Registered in England and Wales Company Registered Number: > 02382161 Registered Office Address: Trident Place, Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > From nobody Fri Feb 13 10:03:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD90D1A005F for ; Fri, 13 Feb 2015 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WrkVx04ITpv for ; Fri, 13 Feb 2015 10:03:01 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B85F1A0162 for ; Fri, 13 Feb 2015 10:03:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1DI2uHt029928; Fri, 13 Feb 2015 19:02:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6A14320766C; Fri, 13 Feb 2015 19:03:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 593BB2074E8; Fri, 13 Feb 2015 19:03:52 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1DI2jsc003044; Fri, 13 Feb 2015 19:02:56 +0100 Message-ID: <54DE3C45.9080806@gmail.com> Date: Fri, 13 Feb 2015 19:02:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ca By References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:03:05 -0000 Le 13/02/2015 18:37, Ca By a écrit : > > > On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu > > wrote: > > Le 13/02/2015 16:33, Heatley, Nick a écrit : > > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@__gmail.com > ] Sent: 13 February 2015 14:35 > To: Heatley, Nick; mohamed.boucadair@orange.com > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 14:14, Heatley, Nick a écrit : > > Hi Alex, Yes, that is wrong. You can ping any IPv4 literal > from a > 464xlat device. My handset only has an IPv6 address + CLAT > and I am > pinging 8.8.8.8 :-)) > > > Ok, I see. I didnt know CLAT-on-device was required when using > v6-only APNs. > > [Heatley, Nick] For service continuity with IPv4, on an IPv6-only > bearer use CLAT. A slightly pedantic note, if you have a "dual > stack > APN" but the device only requests IPv6 then the device will receive > an IPv6 bearer and requires CLAT. You will hear from Ross and me > talking about having a single APN supporting all modes, IPv4, IPv4v6 > and IPv6 bearers. There may be business reasons for this, as well as > avoiding consumers having to change APNs. > > > In my understanding 464xlat/clat are trials these days. They could > be improved before going live. If the 464xlat/clat happened > elsewhere than on the user terminal (e.g. BAse Station) I think more > of these terminals could be accommodated, more business. > > > Hi, > > T-Mobile US's IPv6 deployment is 100% 464XLAT. > > According to measurements, 49% of connections to major internet content > is over IPv6 from T-Mobile US > > http://www.worldipv6launch.org/measurements/ > > According to public statement, T-Mobile US has 50+ million subscribers > in q3 2014 > > So, 49% of 50 Million -- i do not think it is fair to characterize > 464XLAT as only being a trial. Hi Cameron, I am impressed by the figures, it's good for IPv6 in general. In other places 464xlat is still a trial. In these trials, my suggestion is to not make CLAT mandatory on the device, and still offer native IPv4 and native IPv6 to the end user. If this is realized (avoid CLAT), do you think T-Mobile subscribers would talk easier to subscribers of these networks currently trialled? Or is it that subscribers of other networks MUST have CLAT in their phones in order to talk to CLAT phones of T-Mobile? Alex > > Regards, > > Cameron > > > > That means that the device vendors MUST implement CLAT in the > smartphones which connect to a v6-only APN. It is a too strong > requirement. > > [Heatley, Nick] Today's reality is that operators cannot take > devices > to IPv6-only mode of operation without CLAT. In the future will > other > alternatives appear? > > > Alternatives there are very many. > > E.g. 464lat/clat to run on an operator-controlled network device, > not on end-user terminal. > > E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device. > > 3GPP also designed a DS-MIPv6, not sure whether you are aware of > it. It had the same goal of terminal on v6-only link. > > It's hard to justify requiring just one of them on all end-user > terminals because it will surely affect the other. > > It is easier for an end user to connect to a pure v4-APN rather than > a v6 APN with CLAT. > > [Heatley, Nick] If they have the choice....when the element of > choice > is taken away, the operator must make their network bullet proof for > all devices supported. > > > Well, historic operators, MVNOs? > > Historic operators today no longer 'own' the device as in the recent > past. Yes, they have contracts with well-funded manufacturers, but > they also accept any other device to connect to their networks. > They sell SIM cards with DATA plans regardless of the device in > which this SIM card ends: they must offer unlocking codes of all > devices they sell. Finally they must accept phone number portability > for free. > > If this 464xlat/clat requirement is between a Historic operator and > an MVNOs, then it may make sense. > > But one can not require the end-user to run CLAT translation. > > Alex > > > Internet-side initiated traffic would be an issue, same as NAT44 > CGN. > > > YEs, I understand that reachability problem. > > But here we have a problem with requiring the end user device to run > translation just because of IPv6. > > App writers have already solved the NAT44 reverse reachability > problems - they work on non-CLAT devices behind NAT. These apps > will > no longer work in the v6 world, if CLAT is not added. > > One would hardly migrate to IPv6 if too much translation is > required, > be it v4-v6 or v6-v4 translation. > > Compare this to the v6 migration in the DSL world: no additional > CLAT > is required on end-user devices. > > Alex > > Nick > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@__gmail.com > ] Sent: 13 February > 2015 12:52 > To: Heatley, Nick; mohamed.boucadair@orange.com > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9 > 464XLAT > > Le 13/02/2015 11:13, Heatley, Nick a écrit : > > A statement such as > > The device should only invoke the CLAT in the > absence of a the > IPv4 AF i.e. when the network does not assign an > IPv4 cellular > address > > could be helpful? > > To go further, and define any additional requirement, > then that > would be defining how an Operator could/should manage their > remaining IPv4 public and private addressing. This paper > should > only focus on the required device behaviour. > > As an aside 464xlat is a direct replacement for the NAT44 > environments, typical in mobile operators with large > consumer > bases. > > > Nick, > > Am I wrong to say that one can not ping 8.8.8.8 from behind a > 464xlat, whereas one can ping 8.8.8.8 behind a nat44? > > If I am not wrong then 464xlat and nat44 are not really > equivalent. > > Alex > > Ideal if an operator is exhausting both public and private > address space. If an operator has ample public IPv4 and has > consumer products that are NAT44-free, then they are in a > different place (a utopia). Nick > > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org > __] On Behalf Of > mohamed.boucadair@orange.com > Sent: 13 February > 2015 06:49 To: > Alexandru Petrescu Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D > Action: draft-ietf-v6ops-mobile-__device-profile-17.txt > - C_REC#9 > 464XLAT > > Hi Alex, > > The intent of this reco is to address broken IPv4-only > applications over an IPv6-only connectivity. Ideally > applications > running on the device should be AF-independent. > > The draft relies on the IPv6 node requirements RFC that > mandates > the supports of IPv6. Also, the I-D calls out > applications that > are provided by the vendor of the device: > > == APP_REC#2: Applications provided by the mobile > device vendor > must be independent of the underlying IP address family. == > > Wouldn't this reco addresses your concern? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org > __] De la part de > Alexandru Petrescu > Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org > Objet : > Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-__device-profile-17.txt - > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT requirement: > > C_REC#9: In order to ensure IPv4 service continuity > in an > IPv6-only deployment context, the cellular host should > implement the Customer Side Translator (CLAT, [RFC6877]) > function which is compliant with > [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows for IPv4-only > application and IPv4-referals to work on an IPv6-only > connectivity. CLAT function requires a NAT64 capability > [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by CLAT is > defined in > [RFC7335]. > > > I think this requirement leads to a situation where the > network > operator deploys IPv6-native-only and IPv4 as an add-on > partial > feature. > > On one hand, it is encouraging to see native IPv6 and no > IPv4. > > On another hand, _partial_ IPv4 support is a temptation > which > deceives in the end - it leads to turn off IPv6 and > come back > to good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not offer full > IPv4 > connectivity to the smartphone. It is not possible to > address > the smartphone by its IPv4 address - DNS is required; > this makes > it impossible to make a VPN tunnel, or Mobile IP. One > can not a > deploy a wireless IPv4 router along the road in a remote > area, > for example. > > This leads to a situation where the operator requires > end user > to switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by another > requirement. This initial requirement would state that > _first_, > before any v4-v6 conversion mechanism is considered, > both the > network and the end user MUST implement a native IPv4 > stack and a > native IPv6 stack (not say 'dual' stack, which is much > overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org > a écrit : > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work > item of the > IPv6 Operations Working Group of the IETF. > > Title : An Internet Protocol Version 6 > (IPv6) Profile > for 3GPP Mobile Devices Authors : David > Binet Mohamed > Boucadair Ales Vizdal Gang Chen Nick Heatley Ross > Chandler > Filename : > draft-ietf-v6ops-mobile-__device-profile-17.txt Pages > : 18 Date : 2015-02-12 > > Abstract: This document defines a profile that is a > superset of > that of the connection to IPv6 cellular networks > defined in > the IPv6 for Third Generation Partnership Project (3GPP) > Cellular Hosts document. This document defines an > IPv6 profile > that a number of operators recommend in order to > connect 3GPP > mobile devices to an IPv6-only or dual-stack > wireless network > (including 3GPP cellular network and IEEE 802.11 > network) with > a special focus on IPv4 service continuity features. > > Both hosts and devices with capability to share > their WAN (Wide > Area Network) connectivity are in scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/__doc/draft-ietf-v6ops-mobile-__device-prof > > > > i > > l > > > e/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17 > > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?__url2=draft-ietf-v6ops-mobile-__device-prof > > > > i > > l > > > e-17 > > > > Please note that it may take a couple of minutes > from the time > of submission until the htmlized version and diff > are available > at tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-__drafts/ > > > _________________________________________________ > v6ops mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > > > > _________________________________________________ v6ops > mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > _________________________________________________ v6ops > mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you are not the > intended recipient, notify the sender immediately, > delete this > email from your system and do not disclose or use for any > purpose. > > We may monitor all incoming and outgoing emails in line with > current legislation. We have taken steps to ensure that this > email and attachments are free from any virus, but it > remains > your responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: 02382161 Registered Office Address: Trident Place, > Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any attachments) is > intended for the above-named person(s). If you are not the > intended recipient, notify the sender immediately, delete this > email from your system and do not disclose or use for any > purpose. > > We may monitor all incoming and outgoing emails in line with > current legislation. We have taken steps to ensure that this > email > and attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company Registered > Number: 02382161 Registered Office Address: Trident Place, > Mosquito > Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any attachments) is > intended for the above-named person(s). If you are not the intended > recipient, notify the sender immediately, delete this email from > your > system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely affect you. > > EE Limited Registered in England and Wales Company Registered > Number: > 02382161 Registered Office Address: Trident Place, Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > > > > _________________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > From nobody Fri Feb 13 11:19:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892911A001C for ; Fri, 13 Feb 2015 11:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZrmZrWvq438 for ; Fri, 13 Feb 2015 11:19:07 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D051A0072 for ; Fri, 13 Feb 2015 11:19:06 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w55so18482480wes.4 for ; Fri, 13 Feb 2015 11:19:05 -0800 (PST) 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=6aKtV5WfA0cFlsAKRSgW91Z50U4OTiRtlyIMOJ2KwkI=; b=ukP1x2DmuxMyW3Di0ko0fiRkC56H1hv0/49d9ppjqCBEN1F08hibjV/XnOLYY9cqAV aRWvdInm+3iQOjj/lFz16uHgWjuKKST/lxb/pnhO8Ss2kDZ3ooOSOXB9lgjo55HfqGbW xkc+6WMjYNw1f7lF1GUZiq2w/ngJOHtog86wxDt5T99HkvTtiU24KZ6vJ3Ey3vdcaVYm uwLhv4yng0gBhxuLJrrZ675N1y1ujYjjDJ6bgjaTZmboSrdnc8lY2os/jkN8zpyxJmVO S4/Y5CGY3Qn9dHdBfmr4gSXupMY0ZABWNkBrnZFp2U7mEODxSqQ1NwkeXccqMOvcZmsQ LDSg== MIME-Version: 1.0 X-Received: by 10.180.39.72 with SMTP id n8mr19323894wik.59.1423855141475; Fri, 13 Feb 2015 11:19:01 -0800 (PST) Received: by 10.216.107.198 with HTTP; Fri, 13 Feb 2015 11:19:01 -0800 (PST) In-Reply-To: <54DE3C45.9080806@gmail.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <54DE3C45.9080806@gmail.com> Date: Fri, 13 Feb 2015 11:19:01 -0800 Message-ID: From: Ca By To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a1135e5d0eb5a99050efd1b7c Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 19:19:13 -0000 --001a1135e5d0eb5a99050efd1b7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 13/02/2015 18:37, Ca By a =C3=A9crit : > >> >> >> On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu >> > >> wrote: >> >> Le 13/02/2015 16:33, Heatley, Nick a =C3=A9crit : >> >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@__gmail.com >> ] Sent: 13 February 2015 >> 14:35 >> To: Heatley, Nick; mohamed.boucadair@orange.com >> Cc: v6ops@ietf.org >> >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9 464XLA= T >> >> >> Le 13/02/2015 14:14, Heatley, Nick a =C3=A9crit : >> >> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal >> from a >> 464xlat device. My handset only has an IPv6 address + CLAT >> and I am >> pinging 8.8.8.8 :-)) >> >> >> Ok, I see. I didnt know CLAT-on-device was required when using >> v6-only APNs. >> >> [Heatley, Nick] For service continuity with IPv4, on an IPv6-onl= y >> bearer use CLAT. A slightly pedantic note, if you have a "dual >> stack >> APN" but the device only requests IPv6 then the device will >> receive >> an IPv6 bearer and requires CLAT. You will hear from Ross and me >> talking about having a single APN supporting all modes, IPv4, >> IPv4v6 >> and IPv6 bearers. There may be business reasons for this, as wel= l >> as >> avoiding consumers having to change APNs. >> >> >> In my understanding 464xlat/clat are trials these days. They could >> be improved before going live. If the 464xlat/clat happened >> elsewhere than on the user terminal (e.g. BAse Station) I think more >> of these terminals could be accommodated, more business. >> >> >> Hi, >> >> T-Mobile US's IPv6 deployment is 100% 464XLAT. >> >> According to measurements, 49% of connections to major internet content >> is over IPv6 from T-Mobile US >> >> http://www.worldipv6launch.org/measurements/ >> >> According to public statement, T-Mobile US has 50+ million subscribers >> in q3 2014 >> >> So, 49% of 50 Million -- i do not think it is fair to characterize >> 464XLAT as only being a trial. >> > > Hi Cameron, > > I am impressed by the figures, it's good for IPv6 in general. > > In other places 464xlat is still a trial. In these trials, my suggestion > is to not make CLAT mandatory on the device, and still offer native IPv4 > and native IPv6 to the end user. > > Offering native IPv4 is not an option due to IPv4 address exhaustion. > If this is realized (avoid CLAT), do you think T-Mobile subscribers > would talk easier to subscribers of these networks currently trialled? > > Or is it that subscribers of other networks MUST have CLAT in their > phones in order to talk to CLAT phones of T-Mobile? > > Alex > > It is my recommendations that networks and service use IPv6 to avoid any undue complications related to CGN / NAT44 / NAT64 / MAP and so on. IPv4 is fundamentally problematic in any network that exceeds 4 billion nodes in size. I do not recommend using IPv4 on the Internet. Regards, Cameron > >> Regards, >> >> Cameron >> >> >> >> That means that the device vendors MUST implement CLAT in the >> smartphones which connect to a v6-only APN. It is a too strong >> requirement. >> >> [Heatley, Nick] Today's reality is that operators cannot take >> devices >> to IPv6-only mode of operation without CLAT. In the future will >> other >> alternatives appear? >> >> >> Alternatives there are very many. >> >> E.g. 464lat/clat to run on an operator-controlled network device, >> not on end-user terminal. >> >> E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device. >> >> 3GPP also designed a DS-MIPv6, not sure whether you are aware of >> it. It had the same goal of terminal on v6-only link. >> >> It's hard to justify requiring just one of them on all end-user >> terminals because it will surely affect the other. >> >> It is easier for an end user to connect to a pure v4-APN rather >> than >> a v6 APN with CLAT. >> >> [Heatley, Nick] If they have the choice....when the element of >> choice >> is taken away, the operator must make their network bullet proof >> for >> all devices supported. >> >> >> Well, historic operators, MVNOs? >> >> Historic operators today no longer 'own' the device as in the recent >> past. Yes, they have contracts with well-funded manufacturers, but >> they also accept any other device to connect to their networks. >> They sell SIM cards with DATA plans regardless of the device in >> which this SIM card ends: they must offer unlocking codes of all >> devices they sell. Finally they must accept phone number portability >> for free. >> >> If this 464xlat/clat requirement is between a Historic operator and >> an MVNOs, then it may make sense. >> >> But one can not require the end-user to run CLAT translation. >> >> Alex >> >> >> Internet-side initiated traffic would be an issue, same as >> NAT44 >> CGN. >> >> >> YEs, I understand that reachability problem. >> >> But here we have a problem with requiring the end user device to >> run >> translation just because of IPv6. >> >> App writers have already solved the NAT44 reverse reachability >> problems - they work on non-CLAT devices behind NAT. These apps >> will >> no longer work in the v6 world, if CLAT is not added. >> >> One would hardly migrate to IPv6 if too much translation is >> required, >> be it v4-v6 or v6-v4 translation. >> >> Compare this to the v6 migration in the DSL world: no additional >> CLAT >> is required on end-user devices. >> >> Alex >> >> Nick >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@__gmail.com >> ] Sent: 13 February >> 2015 12:52 >> To: Heatley, Nick; mohamed.boucadair@orange.com >> Cc: v6ops@ietf.org >> >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9 >> >> 464XLAT >> >> Le 13/02/2015 11:13, Heatley, Nick a =C3=A9crit : >> >> A statement such as >> >> The device should only invoke the CLAT in the >> absence of a the >> IPv4 AF i.e. when the network does not assign an >> IPv4 cellular >> address >> >> could be helpful? >> >> To go further, and define any additional requirement, >> then that >> would be defining how an Operator could/should manage >> their >> remaining IPv4 public and private addressing. This paper >> should >> only focus on the required device behaviour. >> >> As an aside 464xlat is a direct replacement for the NAT4= 4 >> environments, typical in mobile operators with large >> consumer >> bases. >> >> >> Nick, >> >> Am I wrong to say that one can not ping 8.8.8.8 from behind = a >> 464xlat, whereas one can ping 8.8.8.8 behind a nat44? >> >> If I am not wrong then 464xlat and nat44 are not really >> equivalent. >> >> Alex >> >> Ideal if an operator is exhausting both public and priva= te >> address space. If an operator has ample public IPv4 and >> has >> consumer products that are NAT44-free, then they are in = a >> different place (a utopia). Nick >> >> >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org >> __] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: 13 February >> 2015 06:49 To: >> Alexandru Petrescu Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D >> Action: draft-ietf-v6ops-mobile-__device-profile-17.txt >> - C_REC#9 >> 464XLAT >> >> Hi Alex, >> >> The intent of this reco is to address broken IPv4-only >> applications over an IPv6-only connectivity. Ideally >> applications >> running on the device should be AF-independent. >> >> The draft relies on the IPv6 node requirements RFC that >> mandates >> the supports of IPv6. Also, the I-D calls out >> applications that >> are provided by the vendor of the device: >> >> =3D=3D APP_REC#2: Applications provided by the mobile >> device vendor >> must be independent of the underlying IP address family. >> =3D=3D >> >> Wouldn't this reco addresses your concern? >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : v6ops >> [mailto:v6ops-bounces@ietf.org >> __] De la part de >> Alexandru Petrescu >> Envoy=C3=A9 : jeudi 12 f=C3=A9vrier 2015 17:27 =C3=80 : = v6ops@ietf.org >> Objet : >> Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-__device-profile-17.txt - >> >> C_REC#9 464XLAT >> >> Hello, >> >> Thank you for this new version of the draft. >> >> I have a doubt with respect to the 464XLAT requirement: >> >> C_REC#9: In order to ensure IPv4 service continuity >> in an >> IPv6-only deployment context, the cellular host shou= ld >> implement the Customer Side Translator (CLAT, >> [RFC6877]) >> function which is compliant with >> [RFC6052][RFC6145][RFC6146]. >> >> CLAT function in the cellular host allows for >> IPv4-only >> application and IPv4-referals to work on an IPv6-onl= y >> connectivity. CLAT function requires a NAT64 >> capability >> [RFC6146] in the core network. >> >> The IPv4 Service Continuity Prefix used by CLAT is >> defined in >> [RFC7335]. >> >> >> I think this requirement leads to a situation where the >> network >> operator deploys IPv6-native-only and IPv4 as an add-on >> partial >> feature. >> >> On one hand, it is encouraging to see native IPv6 and no >> IPv4. >> >> On another hand, _partial_ IPv4 support is a temptation >> which >> deceives in the end - it leads to turn off IPv6 and >> come back >> to good ol' IPv4 and no IPv6. >> >> The 464XLAT is partial IPv4 support: does not offer full >> IPv4 >> connectivity to the smartphone. It is not possible to >> address >> the smartphone by its IPv4 address - DNS is required; >> this makes >> it impossible to make a VPN tunnel, or Mobile IP. One >> can not a >> deploy a wireless IPv4 router along the road in a remote >> area, >> for example. >> >> This leads to a situation where the operator requires >> end user >> to switch to another APN which is less IPv6. >> >> I think it is not a happy situation. >> >> I would suggest to qualify this requirement by another >> requirement. This initial requirement would state that >> _first_, >> before any v4-v6 conversion mechanism is considered, >> both the >> network and the end user MUST implement a native IPv4 >> stack and a >> native IPv6 stack (not say 'dual' stack, which is much >> overloaded). >> >> We dont want to block IPv4 use when IPv6 arrives. >> >> Alex >> >> 12/02/2015 13:42, internet-drafts@ietf.org >> a =C3=A9crit : >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work >> item of the >> IPv6 Operations Working Group of the IETF. >> >> Title : An Internet Protocol Version 6 >> (IPv6) Profile >> for 3GPP Mobile Devices Authors : David >> Binet Mohamed >> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross >> Chandler >> Filename : >> draft-ietf-v6ops-mobile-__device-profile-17.txt Page= s >> : 18 Date : 2015-02-12 >> >> Abstract: This document defines a profile that is a >> superset of >> that of the connection to IPv6 cellular networks >> defined in >> the IPv6 for Third Generation Partnership Project >> (3GPP) >> Cellular Hosts document. This document defines an >> IPv6 profile >> that a number of operators recommend in order to >> connect 3GPP >> mobile devices to an IPv6-only or dual-stack >> wireless network >> (including 3GPP cellular network and IEEE 802.11 >> network) with >> a special focus on IPv4 service continuity features. >> >> Both hosts and devices with capability to share >> their WAN (Wide >> Area Network) connectivity are in scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/_ >> _doc/draft-ietf-v6ops-mobile-__device-prof >> > doc/draft-ietf-v6ops-mobile-device-prof> >> >> >> i >> >> l >> >> >> e/ >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/__ >> draft-ietf-v6ops-mobile-__device-profile-17 >> > device-profile-17> >> >> >> >> >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?__ >> url2=3Ddraft-ietf-v6ops-mobile-__device-prof >> > url2=3Ddraft-ietf-v6ops-mobile-device-prof> >> >> >> i >> >> l >> >> >> e-17 >> >> >> >> Please note that it may take a couple of minutes >> from the time >> of submission until the htmlized version and diff >> are available >> at tools.ietf.org . >> >> Internet-Drafts are also available by anonymous FTP >> at: >> ftp://ftp.ietf.org/internet-__drafts/ >> >> >> _________________________________________________ >> v6ops mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/__listinfo/v6ops >> >> >> >> >> >> _________________________________________________ v6ops >> mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/__listinfo/v6ops >> >> >> _________________________________________________ v6ops >> mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/__listinfo/v6ops >> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any >> attachments) is >> intended for the above-named person(s). If you are not >> the >> intended recipient, notify the sender immediately, >> delete this >> email from your system and do not disclose or use for an= y >> purpose. >> >> We may monitor all incoming and outgoing emails in line >> with >> current legislation. We have taken steps to ensure that >> this >> email and attachments are free from any virus, but it >> remains >> your responsibility to ensure that viruses do not >> adversely >> affect you. >> >> EE Limited Registered in England and Wales Company >> Registered >> Number: 02382161 Registered Office Address: Trident Plac= e, >> Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. >> >> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments= ) >> is >> intended for the above-named person(s). If you are not the >> intended recipient, notify the sender immediately, delete th= is >> email from your system and do not disclose or use for any >> purpose. >> >> We may monitor all incoming and outgoing emails in line with >> current legislation. We have taken steps to ensure that this >> email >> and attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely >> affect you. >> >> EE Limited Registered in England and Wales Company Registere= d >> Number: 02382161 Registered Office Address: Trident Place, >> Mosquito >> Way, Hatfield, Hertfordshire, AL10 9BW. >> >> >> >> >> NOTICE AND DISCLAIMER This e-mail (including any attachments) is >> intended for the above-named person(s). If you are not the >> intended >> recipient, notify the sender immediately, delete this email from >> your >> system and do not disclose or use for any purpose. >> >> We may monitor all incoming and outgoing emails in line with >> current >> legislation. We have taken steps to ensure that this email and >> attachments are free from any virus, but it remains your >> responsibility to ensure that viruses do not adversely affect yo= u. >> >> EE Limited Registered in England and Wales Company Registered >> Number: >> 02382161 Registered Office Address: Trident Place, Mosquito Way, >> Hatfield, Hertfordshire, AL10 9BW. >> >> >> >> _________________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/__listinfo/v6ops >> >> >> >> > > --001a1135e5d0eb5a99050efd1b7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu = <alexa= ndru.petrescu@gmail.com> wrote:
Le 13/02/2015 18:37, Ca By a =C3=A9crit :


On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu
 <alexa= ndru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>&g= t; wrote:

=C2=A0 =C2=A0 Le 13/02/2015 16:33, Heatley, Nick a =C3=A9crit :



=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- From: Alexandru Petr= escu
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:alexandru.petrescu@__gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandru.petrescu@gmail.com>] = Sent: 13 February 2015 14:35
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Heatley, Nick; mohamed.boucadair@orange.com
<= /span> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mohamed.boucadair@orange.com> C= c: v6ops@ietf.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [v6ops] I-D Action:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-v6ops-mobile-__device-profile= -17.txt - C_REC#9 464XLAT


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 13/02/2015 14:14, Heatley, Nick a =C3=A9crit= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alex, Yes, that is wrong. You = can ping any IPv4 literal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 464xlat device. My handset only h= as an IPv6 address + CLAT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and I am
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pinging 8.8.8.8 :-))


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ok, I see.=C2=A0 I didnt know CLAT-on-device wa= s required when using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6-only APNs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Heatley, Nick] For service continuity with IPv= 4, on an IPv6-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bearer use CLAT. A slightly pedantic note,=C2= =A0 if you have a "dual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stack
=C2=A0 =C2=A0 =C2=A0 =C2=A0 APN" but the device only requests IPv6 the= n the device will receive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an IPv6 bearer and requires CLAT. You will hear= from Ross and me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 talking about having a single APN supporting al= l modes, IPv4, IPv4v6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and IPv6 bearers. There may be business reasons= for this, as well as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 avoiding consumers having to change APNs.


=C2=A0 =C2=A0 In my understanding 464xlat/clat are trials these days.=C2=A0= They could
=C2=A0 =C2=A0 be improved before going live.=C2=A0 If the 464xlat/clat happ= ened
=C2=A0 =C2=A0 elsewhere than on the user terminal (e.g. BAse Station) I thi= nk more
=C2=A0 =C2=A0 of these terminals could be accommodated, more business.


Hi,

T-Mobile US's IPv6 deployment is 100% 464XLAT.

According to measurements, 49% of connections to major internet content
is over IPv6 from T-Mobile US

= http://www.worldipv6launch.org/measurements/

According to public statement, T-Mobile US has 50+ million subscribers
in q3 2014

So, 49% of 50 Million -- i do not think it is fair to characterize
464XLAT as only being a trial.

Hi Cameron,

I am impressed by the figures, it's good for IPv6 in general.

In other places 464xlat is still a trial. In these trials, my suggestion is to not make CLAT mandatory on the device, and still offer native IPv4
and native IPv6 to the end user.


Offering native IPv4 is not an = option due to IPv4 address exhaustion.
=C2=A0
If this is realized (avoid CLAT), do you think T-Mobile subscribers
would talk easier to subscribers of these networks currently trialled?

Or is it that subscribers of other networks MUST have CLAT in their
phones in order to talk to CLAT phones of T-Mobile?

Alex


It is my recommendations that networks= and service use IPv6 to avoid any undue complications related to CGN / NAT= 44 / NAT64 / MAP and so on.

IPv4 is fundamentally = problematic =C2=A0in any network that exceeds 4 billion nodes in size. I do= not recommend using IPv4 on the Internet. =C2=A0

= Regards,

Cameron
=C2=A0

Regards,

Cameron



=C2=A0 =C2=A0 =C2=A0 =C2=A0 That means that the device vendors MUST impleme= nt CLAT in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 smartphones which connect to a v6-only APN.=C2= =A0 It is a too strong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Heatley, Nick] Today's reality is that ope= rators cannot take
=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to IPv6-only mode of operation without CLAT. In= the future will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 alternatives appear?


=C2=A0 =C2=A0 Alternatives there are very many.

=C2=A0 =C2=A0 E.g. 464lat/clat to run on an operator-controlled network dev= ice,
=C2=A0 =C2=A0 not on end-user terminal.

=C2=A0 =C2=A0 E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user = device.

=C2=A0 =C2=A0 3GPP also designed a DS-MIPv6, not sure whether you are aware= of
=C2=A0 =C2=A0 it.=C2=A0 It had the same goal of terminal on v6-only link.
=C2=A0 =C2=A0 It's hard to justify requiring just one of them on all en= d-user
=C2=A0 =C2=A0 terminals because it will surely affect the other.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It is easier for an end user to connect to a pu= re v4-APN rather than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a v6 APN with CLAT.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Heatley, Nick] If they have the choice....when= the element of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 choice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is taken away, the operator must make their net= work bullet proof for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 all devices supported.


=C2=A0 =C2=A0 Well, historic operators, MVNOs?

=C2=A0 =C2=A0 Historic operators today no longer 'own' the device a= s in the recent
=C2=A0 =C2=A0 past.=C2=A0 Yes, they have contracts with well-funded manufac= turers, but
=C2=A0 =C2=A0 they also accept any other device to connect to their network= s.
=C2=A0 =C2=A0 They sell SIM cards with DATA plans regardless of the device = in
=C2=A0 =C2=A0 which this SIM card ends: they must offer unlocking codes of = all
=C2=A0 =C2=A0 devices they sell. Finally they must accept phone number port= ability
=C2=A0 =C2=A0 for free.

=C2=A0 =C2=A0 If this 464xlat/clat requirement is between a Historic operat= or and
=C2=A0 =C2=A0 an MVNOs, then it may make sense.

=C2=A0 =C2=A0 But one can not require the end-user to run CLAT translation.=

=C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Internet-side initiated traffic w= ould be an issue, same as NAT44
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CGN.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 YEs, I understand that reachability problem.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 But here we have a problem with requiring the e= nd user device to run
=C2=A0 =C2=A0 =C2=A0 =C2=A0 translation just because of IPv6.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 App writers have already solved the NAT44 rever= se reachability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 problems - they work on non-CLAT devices behind= NAT.=C2=A0 These apps
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 no longer work in the v6 world, if CLAT is not = added.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 One would hardly migrate to IPv6 if too much tr= anslation is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be it v4-v6 or v6-v4 translation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Compare this to the v6 migration in the DSL wor= ld: no additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CLAT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is required on end-user devices.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nick

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- From: = Alexandru Petrescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:alexandru.petrescu@__gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandru.petrescu@gmail= .com>] Sent: 13 February
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2015 12:52
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Heatley, Nick; mohamed.boucadair@orang= e.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mohamed.boucadair@orange= .com> Cc: v6ops@= ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [v6ops] I-D Action:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-v6ops-mobile-__= device-profile-17.txt - C_REC#9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 464XLAT

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 13/02/2015 11:13, Heatley, Nic= k a =C3=A9crit :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A statement such as=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The d= evice should only invoke the CLAT in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 absen= ce of a the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv4 = AF i.e. when the network does not assign an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv4 = cellular
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addre= ss

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be helpful?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To go further, and = define any additional requirement,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would be defining h= ow an Operator could/should manage their
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 remaining IPv4 publ= ic and private addressing. This paper
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only focus on the r= equired device behaviour.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As an aside 464xlat= is a direct replacement for the NAT44
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 environments, typic= al in mobile operators with large
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consumer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bases.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nick,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Am I wrong to say that one can no= t ping 8.8.8.8 from behind a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 464xlat, whereas one can ping 8.8= .8.8 behind a nat44?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If I am not wrong then 464xlat an= d nat44 are not really
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equivalent.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ideal if an operato= r is exhausting both public and private
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address space. If a= n operator has ample public IPv4 and has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consumer products t= hat are NAT44-free, then they are in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 different place (a = utopia). Nick


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Messa= ge----- From: v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:v6ops-bounces@ietf.org=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops-bounces@ietf.org= >__] On Behalf Of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mohamed.boucadair@orange.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mohamed.boucadai= r@orange.com> Sent: 13 February
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2015 06:49 To:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexandru Petrescu = Cc: v6ops@ietf.org<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops@ietf.org> Subject= : Re: [v6ops] I-D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Action: draft-ietf-= v6ops-mobile-__device-profile-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - C_REC#9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 464XLAT

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alex,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The intent of this = reco is to address broken IPv4-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications over a= n IPv6-only connectivity. Ideally
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 running on the devi= ce should be AF-independent.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The draft relies on= the IPv6 node requirements RFC that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the supports of IPv= 6. Also, the I-D calls out
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications that =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are provided by the= vendor of the device:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D APP_REC#2:= =C2=A0 Applications provided by the mobile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 device vendor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 must be independent= of the underlying IP address family. =3D=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wouldn't this r= eco addresses your concern?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, Med

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Message d'= origine----- De : v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:v6ops-bounces@ietf.org=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops-bounces@ietf.org= >__] De la part de
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexandru Petrescu<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Envoy=C3=A9 : jeudi= 12 f=C3=A9vrier 2015 17:27 =C3=80 : v6ops@ietf.org
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:v6ops@ietf.org> Objet :=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Re: [v6ops] I-D Act= ion:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-v6ops-mo= bile-__device-profile-17.txt -

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C_REC#9 464XLAT

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for this = new version of the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I have a doubt with= respect to the 464XLAT requirement:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C_REC= #9:=C2=A0 In order to ensure IPv4 service continuity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in an=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-= only deployment context, the cellular host should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 imple= ment the Customer Side Translator (CLAT, [RFC6877])
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 funct= ion which is compliant with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC6= 052][RFC6145][RFC6146].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CLAT = function in the cellular host allows for IPv4-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appli= cation and IPv4-referals to work on an IPv6-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conne= ctivity.=C2=A0 CLAT function requires a NAT64 capability
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC6= 146] in the core network.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The I= Pv4 Service Continuity Prefix used by CLAT is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= ed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7= 335].


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think this requir= ement leads to a situation where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operator deploys IP= v6-native-only and IPv4 as an add-on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 partial
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 feature.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On one hand, it is = encouraging to see native IPv6 and no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv4.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On another hand, _p= artial_ IPv4 support is a temptation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deceives in the end= -=C2=A0 it leads to turn off IPv6 and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 come back
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to good ol' IPv= 4 and no IPv6.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The 464XLAT is part= ial IPv4 support: does not offer full
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connectivity to the= smartphone.=C2=A0 It is not possible to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the smartphone by i= ts IPv4 address - DNS is required;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this makes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it impossible to ma= ke a VPN tunnel, or Mobile IP.=C2=A0 One
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can not a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deploy a wireless I= Pv4 router along the road in a remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 area,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for example.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This leads to a sit= uation where the operator requires
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 end user
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to switch to anothe= r APN which is less IPv6.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think it is not a= happy situation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would=C2=A0 sugge= st to qualify this requirement by another
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement. This i= nitial requirement would state that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _first_,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 before any v4-v6 co= nversion mechanism is considered,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 both the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network and the end= user MUST implement a native IPv4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stack and a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 native IPv6 stack (= not say 'dual' stack, which is much
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 overloaded).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We dont want to blo= ck IPv4 use when IPv6 arrives.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12/02/2015 13:42, <= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:internet-drafts@ietf= .org> a =C3=A9crit :


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A New= Internet-Draft is available from the on-line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Inter= net-Drafts directories. This draft is a work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 item = of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 = Operations Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Internet Protocol Version 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (IPv6= ) Profile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for 3= GPP Mobile Devices Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: David
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Binet= Mohamed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bouca= dair Ales Vizdal Gang Chen Nick Heatley Ross
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chand= ler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filen= ame :
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= -ietf-v6ops-mobile-__device-profile-17.txt Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 18 = Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-02-12

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstr= act: This document defines a profile that is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 super= set of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that = of the connection to IPv6 cellular networks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= ed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the I= Pv6 for Third Generation Partnership Project (3GPP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cellu= lar Hosts document.=C2=A0 This document defines an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 = profile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that = a number of operators recommend in order to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conne= ct 3GPP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mobil= e devices to an IPv6-only or dual-stack
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wirel= ess network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (incl= uding 3GPP cellular network and IEEE 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 netwo= rk) with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a spe= cial focus on IPv4 service continuity features.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Both = hosts and devices with capability to share
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 their= WAN (Wide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Area = Network) connectivity are in scope.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The I= ETF datatracker status page for this draft is:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/__doc/draft-ietf= -v6ops-mobile-__device-prof
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-p= rof" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-v= 6ops-mobile-device-prof>


=C2=A0 =C2=A0 i

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e/


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There= 's also a htmlized version available at:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/__draft-ietf-v6ops= -mobile-__device-profile-17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile= -17" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-v6ops-m= obile-device-profile-17>





=C2=A0 =C2=A0 A diff from the previous version is available at:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/rfcdiff?__url2=3Ddraft-= ietf-v6ops-mobile-__device-prof
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device= -prof" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-v6ops-mobile-device-prof>


=C2=A0 =C2=A0 i

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e-17



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pleas= e note that it may take a couple of minutes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from = the time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of su= bmission until the htmlized version and diff
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are a= vailable
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at tools.ietf.org <http://tools.ietf.org= >.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Inter= net-Drafts are also available by anonymous FTP at:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ftp://ftp.ie= tf.org/internet-__drafts/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp.= ietf.org/internet-drafts/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= ____________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops= mailing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list = v6ops@ietf.org <= mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= s://www.ietf.org/mailman/__listinfo/v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/v6ops>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ______________________________ v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/__listinfo/v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf= .org/mailman/listinfo/v6ops>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ______________________________ v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/__listinfo/v6ops

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf= .org/mailman/listinfo/v6ops>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOTICE AND DISCLAIM= ER This e-mail (including any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attachments) is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended for the ab= ove-named person(s).=C2=A0 If you are not the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended recipient,= notify the sender immediately,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 delete this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email from your sys= tem and do not disclose or use for any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 purpose.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We may monitor all = incoming and outgoing emails in line with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current legislation= . We have taken steps to ensure that this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email and attachmen= ts are free from any virus, but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 remains
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 your responsibility= to ensure that viruses do not adversely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 affect you.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EE Limited Register= ed in England and Wales Company
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Registered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Number: 02382161 Re= gistered Office Address: Trident Place,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mosquito Way, Hatfi= eld, Hertfordshire, AL10 9BW.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOTICE AND DISCLAIMER This e-mail= (including any attachments) is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended for the above-named pers= on(s).=C2=A0 If you are not the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended recipient, notify the se= nder immediately, delete this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email from your system and do not= disclose or use for any
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 purpose.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We may monitor all incoming and o= utgoing emails in line with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current legislation. We have take= n steps to ensure that this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and attachments are free from any= virus, but it remains your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 responsibility to ensure that vir= uses do not adversely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 affect you.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EE Limited Registered in England = and Wales Company Registered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Number: 02382161 Registered Offic= e Address: Trident Place,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mosquito
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Way, Hatfield, Hertfordshire, AL1= 0 9BW.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 NOTICE AND DISCLAIMER This e-mail (including an= y attachments) is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 intended for the above-named person(s).=C2=A0 I= f you are not the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 recipient, notify the sender immediately, delet= e this email from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 system and do not disclose or use for any purpo= se.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We may monitor all incoming and outgoing emails= in line with current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legislation. We have taken steps to ensure that= this email and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attachments are free from any virus, but it rem= ains your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 responsibility to ensure that viruses do not ad= versely affect you.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 EE Limited Registered in England and Wales Comp= any Registered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Number:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 02382161 Registered Office Address: Trident Pla= ce, Mosquito Way,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hatfield, Hertfordshire, AL10 9BW.



=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org <mailto:v6= ops@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/v6ops
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/v6ops>=





--001a1135e5d0eb5a99050efd1b7c-- From nobody Fri Feb 13 12:44:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69CF1A038B for ; Fri, 13 Feb 2015 12:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdqqAtJKZh1j for ; Fri, 13 Feb 2015 12:44:24 -0800 (PST) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id 3FE151A026F for ; Fri, 13 Feb 2015 12:44:23 -0800 (PST) Received: (qmail 34439 messnum 320540 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 13 Feb 2015 20:44:19 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail19.svc.cra.dublin.eircom.net (qp 34439) with SMTP; 13 Feb 2015 20:44:19 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id rwkG1p00R4BK5ly01wkKqn; Fri, 13 Feb 2015 20:44:19 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: <54DDEDB8.90001@gmail.com> Date: Fri, 13 Feb 2015 20:44:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 20:44:26 -0000 > On 13 Feb 2015, at 12:27, Alexandru Petrescu = wrote: >=20 > Le 12/02/2015 20:39, Ross Chandler a =E9crit : >>=20 >> Perhaps it could be clarified in C_REC#9 that the IPv6-only >> deployment context refers to the 3GPP device? The data APN it >> accesses could support IPv4, IPv6 and dual-stack IPv4v6 PDP/PDNs. >=20 > I think the current deployments of 464XLAT use the same APN for both = 3GPP and data services. I mean the APN configuration on the provider GGSN/PGW can simultaneously = accept separate PDP/PDN connections of multiple types. e.g The current APN name can be kept by the provider. Their old devices = use IPv4 with the APN and the newer devices use IPv6. =20 Ross From nobody Fri Feb 13 13:37:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0171A1AC6 for ; Fri, 13 Feb 2015 13:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p7XZAvgt1-v for ; Fri, 13 Feb 2015 13:37:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716811A1A8F for ; Fri, 13 Feb 2015 13:37:05 -0800 (PST) Received: from CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) by CO2PR04MB716.namprd04.prod.outlook.com (10.141.229.156) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 13 Feb 2015 21:36:45 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 13 Feb 2015 21:36:44 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0081.018; Fri, 13 Feb 2015 21:36:44 +0000 From: "Metzler, Dan J" To: Alexandru Petrescu , "mohamed.boucadair@orange.com" , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDwg1fzpxhvcUOCHDFyDxLETJzuJKAAgAA4+wCAACxpgIAABhmAgAAWtgCAABChgIAAF2sAgAA2ZOA= Date: Fri, 13 Feb 2015 21:36:44 +0000 Message-ID: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> In-Reply-To: <54DE2D40.50908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.55.230.66] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(13464003)(377454003)(54356999)(66066001)(89122001)(19580405001)(76576001)(50986999)(76176999)(93886004)(86362001)(74316001)(46102003)(106116001)(77156002)(88552001)(2501002)(230783001)(75432002)(92566002)(2900100001)(102836002)(2950100001)(15975445007)(122556002)(40100003)(77096005)(99286002)(90282001)(87936001)(33656002)(2656002)(19580395003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2015 21:36:44.4379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB716; X-OriginatorOrg: uiowa.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 21:37:12 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJ1IFBldHJlc2N1 DQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTMsIDIwMTUgMTA6NTkgQU0NCj4gVG86IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEhlYXRsZXksIE5pY2sNCj4gQ2M6IHY2b3BzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMt bW9iaWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtDQo+IENfUkVDIzkgNDY0WExBVA0KPiANCjxz bmlwLz4NCj4gDQo+ID4gU29tZSBvcGVyYXRvcnMgYXJlIHNlZWluZyBDTEFUIGFzIGNyaXRpY2Fs IGJlY2F1c2UgdGhleSBkb24ndCB3YW50IHRvDQo+ID4gaGF2ZSBhIHNlcnZpY2UgZGlzcnVwdGlv biBjb21wYXJlZCB0byBJUHY0IHdoZW4gSVB2Ni1vbmx5IGNvbm5lY3Rpdml0eQ0KPiA+IGlzIHBy b3ZpZGVkIHRvIHRoZWlyIGN1c3RvbWVycy4NCj4gDQo+IEkgYWdyZWUgYWJvdXQgdGhlIGNyaXRp Y2FsaXR5IG9mIElQdjQgYXBwcyB3aGVuIElQdjYtb25seSBjb25uZWN0aXZpdHkgaXMgaW4NCj4g cGxhY2UuDQo+IA0KPiBCdXQgd2h5IHNob3VsZCB0aGVyZSBiZSBJUHY2LW9ubHkgY29ubmVjdGl2 aXR5IGluIHBsYWNlIHRvZGF5IGZvciB0aGUgbWFzc2VzPw0KDQpCZWNhdXNlIHdoZXRoZXIgaXQg ZXhpc3RzIHRvZGF5LCBvciBub3QsIHRoYXQncyB0aGUgZ29hbCB3ZSBhcmUgd29ya2luZyB0b3dh cmQuICBJdCdzIGZhciB0b28gbGF0ZSB0byBiZSBkZXNpZ25pbmcgdGhpbmdzIGJhc2VkIG9uIHNv bWUgYXNzdW1wdGlvbiB0aGF0IElQdjYtb25seSBjb25uZWN0aXZpdHkgZG9lc24ndCBoYXZlIHRv IGFjdHVhbGx5IHdvcmsgYW55d2F5LiAgVGhlIHVsdGltYXRlIGdvYWwgaXMgSVB2Ni1vbmx5IGNv bm5lY3Rpdml0eSBmb3IgdGhlIG1hc3NlcywgYW5kIGlmIHdlIG1ha2Ugbm8gb3RoZXIgYXNzdW1w dGlvbnMsIHdlIG91Z2h0IHRvIGJlIGFibGUgdG8gc3RhcnQgd2l0aCB0aGUgYXNzdW1wdGlvbiB0 aGF0IGF0IGxlYXN0IHdvcmtzIHRvIGFsbCBpbnRlcm5ldCBjb25uZWN0ZWQgSVB2NiBlbmRwb2lu dHMuDQoNCj4gDQo+IE5vYm9keSBidXQgc29tZSB1bHRyYS1nZWVrIGRvIHRoaXMgSVB2Ni1vbmx5 IHRvZGF5Lg0KDQpPdWNoIQ0KDQo+IA0KPiBFdmVuIGlmIHRoZSBvcGVyYXRvcidzIG5ldHdvcmsg aXMgSVB2NiBvbmx5LCBpdCBzaG91bGQgaGF2ZSBtZWFucyB0byB0cmFuc2xhdGUNCj4gYmV0d2Vl biB2NCBhbmQgdjYgYXQgaXRzIGVkZ2VzLCBzdWNoIGFzIHRvIHNob3cgcHVyZSBJUHY0IGFuZCBw dXJlIElQdjYgdA0KPiB1c2VyLg0KPiANCg0KSSB0aGluayB3ZSBzaG91bGQgc3RheSBhd2F5IGZy b20gYXNzdW1wdGlvbnMgbGlrZSB0aGlzLiAgSWYgbm8gb25lIGlzIGdvaW5nIHRvIG1hbmRhdGUg dGhhdCBhbGwgSVNQcyBNVVNUIHByb3ZpZGUgSVB2NiBjb25uZWN0aXZpdHksIChhbmQgdGhhdCBo YXNuJ3QgaGFwcGVuZWQgeWV0KSwgdGhlbiBpdCBkb2Vzbid0IHNlZW0gbGlrZSB3ZSBjYW4gbWFr ZSBhc3N1bXB0aW9ucyBhYm91dCB3aGVyZSB0aGUgdHJhbnNsYXRpb24gbmVlZHMgdG8gaGFwcGVu Lg0KDQo8c25pcC8+DQoNClRoYW5rcywNCg0KLSBEYW4gKHBhcnQgdGltZSB1bHRyYS1nZWVrIEkg Z3Vlc3MpDQoNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Fri Feb 13 17:31:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9561A1A7E for ; Fri, 13 Feb 2015 17:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR7Q6TIDa495 for ; Fri, 13 Feb 2015 17:31:53 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF391A1A78 for ; Fri, 13 Feb 2015 17:31:53 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so14226169igb.2 for ; Fri, 13 Feb 2015 17:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q4Jii/3Z7UNQEkBgOVuNwY7zwq5K4jpuEc1o59lKaMA=; b=V38DmJ2WLfuMohswYU/a0QMGGfvSTTJfvy3x0gdZF7A6T/FXAar8KouJbh6C0QN/gP +72Ql03gs/bh+7tpHw/RRSXLg6zCUoMkRkPezSneskX3stLoDB3vHw8kaJBXOZQ7hlu3 PloDZwcNyaZVMc/Go3TfiJGl8CFkLfBgZEJIYlbP5tzLby6mjIK3vqvnCTmTLRdT0Tjz Wm8OPgRuVUPfE1sb0VZWo4fLRFkW9TsHpLKNNZ0+3pbgsTrGspGKH9pF9pYkQrp5Lkcb +uC2K8jNgJZxnZFtCd2Lf6mmZqCNoW6erlrtzzj9AUTkpvGljWJSXDuOh2MmjdLt6Ib9 fd0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=q4Jii/3Z7UNQEkBgOVuNwY7zwq5K4jpuEc1o59lKaMA=; b=H07OkiZWr6yEGMU03ebfAcZ1AdrSpy/T6NyjWSqGk+5UKSf0eTjeMYkf29yIozBM/5 W0PSBtNy7U4XBOxScNihJAuy/86OeHFq4ytiHlQP9pG99qi4LnppQKbSO4gQPd0VZz+G fkL10/pfA4xYw4dLK1+15hc8eqXZ52rSMvlURJQ1OQuiN5unzZk1D2rMZelPSCLhn8+C D6wZRoBJesumxJO6SYeRCeZtEDFZF/sdXSIGXdzrzl8PL+l1T7gqYbxvynsHqiz6Z4zN 953hgBNWxru4nwepx4qwxrKAoojs3LGcEDZFAI4t0d2DSx4+6p4VThpYUOrmlhex1KYM bguQ== X-Gm-Message-State: ALoCoQlXCN8KPMD93o01FzhKpErhd/vIEOS1SuuRZbUa2L8wV6iYhAVJtFIXFZGDzG1b7Xn562ym X-Received: by 10.107.25.135 with SMTP id 129mr16288562ioz.44.1423877512683; Fri, 13 Feb 2015 17:31:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Fri, 13 Feb 2015 17:31:32 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Fri, 13 Feb 2015 17:31:32 -0800 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=001a113fd5e4590afa050f025118 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 01:31:55 -0000 --001a113fd5e4590afa050f025118 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick wrote: > Lorenzo, I feel you are like the specialist surgeon berating the GPs for > not knowing every RFC in its pure form. > No, I am berating the authors of this draft for writing a document that makes GPs (=device manufacturers, other network operators) believe that they have to prepare loads of unnecessary medical machinery (=the many recommendations that this draft makes) before they can open a small GP surgery (=deploy IPv6), without bothering to tell them why they need all that machinery and what they're supposed to do with it. --001a113fd5e4590afa050f025118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 13, 2015 at 7:29 AM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:
Lorenzo, I feel you are= like the specialist surgeon berating the GPs for not knowing every RFC in = its pure form.

No, I am berating the au= thors of this draft for writing a document that makes GPs (=3Ddevice manufa= cturers, other network operators) believe that they have to prepare loads o= f unnecessary medical machinery (=3Dthe many recommendations that this draf= t makes) before they can open a small GP surgery (=3Ddeploy IPv6), without = bothering to tell them why they need all that machinery and what they'r= e supposed to do with it.
--001a113fd5e4590afa050f025118-- From nobody Sat Feb 14 04:25:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABD81A1C04 for ; Sat, 14 Feb 2015 04:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxYK_Mt2kpIK for ; Sat, 14 Feb 2015 04:25:21 -0800 (PST) Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by ietfa.amsl.com (Postfix) with SMTP id BA0D21A1C00 for ; Sat, 14 Feb 2015 04:25:20 -0800 (PST) Received: (qmail 61925 messnum 6674032 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 14 Feb 2015 12:25:18 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail11.svc.cra.dublin.eircom.net (qp 61925) with SMTP; 14 Feb 2015 12:25:18 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id sCRE1p00b4BK5ly01CRJ0W; Sat, 14 Feb 2015 12:25:18 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_88B85873-9475-46DF-91F4-A02CED3DAD37" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: Date: Sat, 14 Feb 2015 12:25:14 +0000 Message-Id: <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 12:25:23 -0000 --Apple-Mail=_88B85873-9475-46DF-91F4-A02CED3DAD37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Feb 2015, at 01:31, Lorenzo Colitti wrote: >=20 > On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick > wrote: > Lorenzo, I feel you are like the specialist surgeon berating the GPs = for not knowing every RFC in its pure form. >=20 > No, I am berating the authors of this draft for writing a document = that makes GPs (=3Ddevice manufacturers, other network operators) = believe that they have to prepare loads of unnecessary medical machinery = (=3Dthe many recommendations that this draft makes) before they can open = a small GP surgery (=3Ddeploy IPv6), without bothering to tell them why = they need all that machinery and what they=E2=80=99re supposed to do = with it. In this particular analogy I classify the device manufacturers as = members of Big Pharma, not as GPs. The small country GPs are faced with = buying equipment/features (dual-stack vaccination) to compensate for = deficiencies between network+devices they get from their vendors. Until = some paying customer demand arises that gets the GP=E2=80=99s Bank = Manager interested in helping to push through the development to = production services the GP has little incentive to try to move forward = (got a works order for that? no didn=E2=80=99t think so) unless he also = happens to be an IPv6 =E2=80=9Cultra-geek=E2=80=9D. =20 A lot of specific input has been taken on board. The list of = recommendations has been paired right back and they are in order of = priority and there are explanations in the document.=20 Ross --Apple-Mail=_88B85873-9475-46DF-91F4-A02CED3DAD37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 14 Feb 2015, at 01:31, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick = <nick.heatley@ee.co.uk> = wrote:
Lorenzo, I feel = you are like the specialist surgeon berating the GPs for not knowing = every RFC in its pure form.
No, I am berating the authors of this = draft for writing a document that makes GPs (=3Ddevice manufacturers, = other network operators) believe that they have to prepare loads of = unnecessary medical machinery (=3Dthe many recommendations that this = draft makes) before they can open a small GP surgery (=3Ddeploy IPv6), = without bothering to tell them why they need all that machinery and what = they=E2=80=99re supposed to do with = it.

In= this particular analogy I classify the device manufacturers as members = of Big Pharma, not as GPs.  The small country GPs are faced with = buying equipment/features (dual-stack vaccination) to compensate for = deficiencies between network+devices they get from their vendors. Until = some paying customer demand arises that gets the GP=E2=80=99s Bank = Manager interested in helping to push through the development to = production services the GP has little incentive to try to move forward = (got a works order for that? no didn=E2=80=99t think so) unless he also = happens to be an  IPv6 =E2=80=9Cultra-geek=E2=80=9D. =  

A lot of specific input has = been taken on board. The list of recommendations has been paired right = back and they are in order of priority and there are explanations in the = document. 


Ross





= --Apple-Mail=_88B85873-9475-46DF-91F4-A02CED3DAD37-- From nobody Sat Feb 14 11:47:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04B1A00B8 for ; Sat, 14 Feb 2015 11:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtdRT-E8LuMc for ; Sat, 14 Feb 2015 11:47:03 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24061A0089 for ; Sat, 14 Feb 2015 11:47:01 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B25E760134 for ; Sat, 14 Feb 2015 20:46:58 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6C18960736 for ; Sat, 14 Feb 2015 20:46:58 +0100 (CET) Received: (qmail 75635 invoked by uid 1007); 14 Feb 2015 20:46:58 +0100 Date: Sat, 14 Feb 2015 20:46:58 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150214194658.GI34798@Space.Net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DDF37D.1050405@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 19:47:05 -0000 Hi, On Fri, Feb 13, 2015 at 01:52:13PM +0100, Alexandru Petrescu wrote: > Am I wrong to say that one can not ping 8.8.8.8 from behind a 464xlat, > whereas one can ping 8.8.8.8 behind a nat44? Yes, you are. That is the whole point of a 464xlat: give applications that insist on talking to numeric IPv4 addresses a way to do so. Applications that use DNS and modern socket APIs do not need 464xlat, because NAT64/DNS64 will already solve their needs. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat Feb 14 11:49:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE851A001B for ; Sat, 14 Feb 2015 11:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbj0cEBdIzVE for ; Sat, 14 Feb 2015 11:49:09 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC20B1A017D for ; Sat, 14 Feb 2015 11:49:02 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 100B060736 for ; Sat, 14 Feb 2015 20:49:01 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C4C7A602FF for ; Sat, 14 Feb 2015 20:49:00 +0100 (CET) Received: (qmail 75690 invoked by uid 1007); 14 Feb 2015 20:49:00 +0100 Date: Sat, 14 Feb 2015 20:49:00 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150214194900.GJ34798@Space.Net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DE0BA8.8020908@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 19:49:10 -0000 Hi, On Fri, Feb 13, 2015 at 03:35:20PM +0100, Alexandru Petrescu wrote: > That means that the device vendors MUST implement CLAT in the > smartphones which connect to a v6-only APN. It is a too strong requirement. It's not exactly hard. > It is easier for an end user to connect to a pure v4-APN rather than a > v6 APN with CLAT. Why should the end user have to know? This is completely transparent - and available today: Android devices on T-Mobile USA's IPv6-only APN. [..] > Compare this to the v6 migration in the DSL world: no additional CLAT is > required on end-user devices. That's because there is still IPv4. If you remove that from the DSL world, and people want to keep using Skype, they need a CLAT. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sun Feb 15 09:08:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED81A0218 for ; Sun, 15 Feb 2015 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEeuy3DqjWr5 for ; Sun, 15 Feb 2015 09:08:34 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD0A1A1B2F for ; Sun, 15 Feb 2015 09:08:31 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sun, 15 Feb 2015 09:08:28 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Sun, 15 Feb 2015 09:08:28 -0800 From: Edward Lewis To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSUIEjnmiENkrAUKRqDIUqGF8vg== Date: Sun, 15 Feb 2015 17:08:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3506846905_1019284" MIME-Version: 1.0 Archived-At: Subject: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 17:08:41 -0000 --B_3506846905_1019284 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If it pleases the chairs . . . (I thought I sent this earlier but I don=E2=80=99t see it in the archives. If it did go out, please forgive the repeat.) Below is an announcement for yet-another--00 that I=E2=80=99d like to get some feed back on. From reading the charter to see if it would be appropriate to mention the draft, I believe it is appropriate. (Mindful that I=E2=80=99ve been wrong before.) Whether or not it is a candidate for WG adoption is another matter. For now, I=E2=80=99d appreciate thoughts on whether this is a =E2=80=98good idea=E2=80=99 to deve= lop or not. Ed Lewis On 2/12/15, 14:26, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ipversion6-loopback-prefix-00.txt >has been successfully submitted by Edward Lewis and posted to the >IETF repository. > >Name: draft-ipversion6-loopback-prefix >Revision: 00 >Title: Loopback Prefix for IPv6 >Document date: 2015-02-12 >Group: Individual Submission >Pages: 3 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ipversion6-loopback-prefix-00.tx >t >Status: =20 >https://datatracker.ietf.org/doc/draft-ipversion6-loopback-prefix/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00 > > >Abstract: > The IPv6 address range of 0::/64 is reserved for loopback addresses. > This expands from the single loophack address already defined for >IPv6, > ::1, to allow for a set of addresses to be used when packets are >intended > to stay within a host system. Multiple loopback addresses allow for > simultaneous varied uses of the loopback addresses as has proven, >albeit > in limited ways, in IPv4. And exception is made to accomodate the > ::0/128, already defined as The Unspecified Address. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > --B_3506846905_1019284 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQEC4swFX6Xcl28OM2H qiT1RUvooDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAy MTUxNzA4MjVaMA0GCSqGSIb3DQEBAQUABIIBAIQQ0SUfbb7/7QOqQRt6tyvuYHB92vfwJ4Km RZjRVH+dqeUYWN8NykdtKd1JV21AHfiNn6chkIt5FOdnzYB1MYGhJKQBqWGEXERSNfEdU/d0 hUR9pcDvGaeRmfaCBP7s708hlgi55CvoQdv2a2qHxJe8F66IVk8i/i+PJ0VVjAMNVwTzyfcI tiJ6NiyoC7MKP5zAU6Tzb9sjUa91+CtaSBOdSaL0gMndc5pddRjJt0g4wgAKbcnoGkyLU9ku JIVJMt7aPe9ZM65yeb/yhnFmnc45/9NnLdvXbgsKL1kxVkI8mtEw5ffjEva7uYCWZm+LeFo4 HvhEpafQSK9NefeFBVo= --B_3506846905_1019284-- From nobody Sun Feb 15 11:47:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901881A00E7 for ; Sun, 15 Feb 2015 11:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.717 X-Spam-Level: ** X-Spam-Status: No, score=2.717 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9UgZSFDNtXE for ; Sun, 15 Feb 2015 11:47:19 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DFA1A00E5 for ; Sun, 15 Feb 2015 11:47:19 -0800 (PST) Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7B3FA4C8089; Sun, 15 Feb 2015 20:47:05 +0100 (CET) Message-ID: <54E0F7C3.3050500@gmail.com> Date: Sun, 15 Feb 2015 20:47:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ca By References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <54DE3C45.9080806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150215-0, 15/02/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 19:47:23 -0000 On 13/02/2015 20:19, Ca By wrote: > > > On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu > > wrote: > > Le 13/02/2015 18:37, Ca By a écrit : > > > > On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu > > >> wrote: > > Le 13/02/2015 16:33, Heatley, Nick a écrit : > > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@ > __g__mail.com > >] Sent: 13 February 2015 14:35 > To: Heatley, Nick; mohamed.boucadair@orange.com > > > Cc: v6ops@ietf.org > > > > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > C_REC#9 464XLAT > > > Le 13/02/2015 14:14, Heatley, Nick a écrit : > > Hi Alex, Yes, that is wrong. You can ping any IPv4 > literal > from a > 464xlat device. My handset only has an IPv6 address > + CLAT > and I am > pinging 8.8.8.8 :-)) > > > Ok, I see. I didnt know CLAT-on-device was required > when using > v6-only APNs. > > [Heatley, Nick] For service continuity with IPv4, on an > IPv6-only > bearer use CLAT. A slightly pedantic note, if you have > a "dual > stack > APN" but the device only requests IPv6 then the device > will receive > an IPv6 bearer and requires CLAT. You will hear from > Ross and me > talking about having a single APN supporting all modes, > IPv4, IPv4v6 > and IPv6 bearers. There may be business reasons for > this, as well as > avoiding consumers having to change APNs. > > > In my understanding 464xlat/clat are trials these days. > They could > be improved before going live. If the 464xlat/clat happened > elsewhere than on the user terminal (e.g. BAse Station) I > think more > of these terminals could be accommodated, more business. > > > Hi, > > T-Mobile US's IPv6 deployment is 100% 464XLAT. > > According to measurements, 49% of connections to major internet > content > is over IPv6 from T-Mobile US > > http://www.worldipv6launch.__org/measurements/ > > > According to public statement, T-Mobile US has 50+ million > subscribers > in q3 2014 > > So, 49% of 50 Million -- i do not think it is fair to characterize > 464XLAT as only being a trial. > > > Hi Cameron, > > I am impressed by the figures, it's good for IPv6 in general. > > In other places 464xlat is still a trial. In these trials, my suggestion > is to not make CLAT mandatory on the device, and still offer native IPv4 > and native IPv6 to the end user. > > > Offering native IPv4 is not an option due to IPv4 address exhaustion. > > If this is realized (avoid CLAT), do you think T-Mobile subscribers > would talk easier to subscribers of these networks currently trialled? > > Or is it that subscribers of other networks MUST have CLAT in their > phones in order to talk to CLAT phones of T-Mobile? > > Alex > > > It is my recommendations that networks and service use IPv6 to avoid any > undue complications related to CGN / NAT44 / NAT64 / MAP and so on. > > IPv4 is fundamentally problematic in any network that exceeds 4 billion > nodes in size. Numerous networks are not that large. IPv4 deserves more consideration than what it seems to be implied above. T-Mobile is not the only network out there. If your goal is to present it as an example, I can agree with you - it's a good example, in one particular sense. Alex > I do not recommend using IPv4 on the Internet. > > Regards, > > Cameron > > > Regards, > > Cameron > > > > That means that the device vendors MUST implement CLAT > in the > smartphones which connect to a v6-only APN. It is a > too strong > requirement. > > [Heatley, Nick] Today's reality is that operators > cannot take > devices > to IPv6-only mode of operation without CLAT. In the > future will > other > alternatives appear? > > > Alternatives there are very many. > > E.g. 464lat/clat to run on an operator-controlled network > device, > not on end-user terminal. > > E.g. use a v4-APN and v6-in-v4 encapsulation on the > end-user device. > > 3GPP also designed a DS-MIPv6, not sure whether you are > aware of > it. It had the same goal of terminal on v6-only link. > > It's hard to justify requiring just one of them on all end-user > terminals because it will surely affect the other. > > It is easier for an end user to connect to a pure > v4-APN rather than > a v6 APN with CLAT. > > [Heatley, Nick] If they have the choice....when the > element of > choice > is taken away, the operator must make their network > bullet proof for > all devices supported. > > > Well, historic operators, MVNOs? > > Historic operators today no longer 'own' the device as in > the recent > past. Yes, they have contracts with well-funded > manufacturers, but > they also accept any other device to connect to their networks. > They sell SIM cards with DATA plans regardless of the device in > which this SIM card ends: they must offer unlocking codes > of all > devices they sell. Finally they must accept phone number > portability > for free. > > If this 464xlat/clat requirement is between a Historic > operator and > an MVNOs, then it may make sense. > > But one can not require the end-user to run CLAT translation. > > Alex > > > Internet-side initiated traffic would be an issue, > same as NAT44 > CGN. > > > YEs, I understand that reachability problem. > > But here we have a problem with requiring the end user > device to run > translation just because of IPv6. > > App writers have already solved the NAT44 reverse > reachability > problems - they work on non-CLAT devices behind NAT. > These apps > will > no longer work in the v6 world, if CLAT is not added. > > One would hardly migrate to IPv6 if too much translation is > required, > be it v4-v6 or v6-v4 translation. > > Compare this to the v6 migration in the DSL world: no > additional > CLAT > is required on end-user devices. > > Alex > > Nick > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@ > __g__mail.com > >] Sent: 13 February > 2015 12:52 > To: Heatley, Nick; mohamed.boucadair@orange.com > > > Cc: v6ops@ietf.org > > > > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > C_REC#9 > > 464XLAT > > Le 13/02/2015 11:13, Heatley, Nick a écrit : > > A statement such as > > The device should only invoke the CLAT in the > absence of a the > IPv4 AF i.e. when the network does not > assign an > IPv4 cellular > address > > could be helpful? > > To go further, and define any additional > requirement, > then that > would be defining how an Operator could/should > manage their > remaining IPv4 public and private addressing. > This paper > should > only focus on the required device behaviour. > > As an aside 464xlat is a direct replacement for > the NAT44 > environments, typical in mobile operators with > large > consumer > bases. > > > Nick, > > Am I wrong to say that one can not ping 8.8.8.8 > from behind a > 464xlat, whereas one can ping 8.8.8.8 behind a nat44? > > If I am not wrong then 464xlat and nat44 are not really > equivalent. > > Alex > > Ideal if an operator is exhausting both public > and private > address space. If an operator has ample public > IPv4 and has > consumer products that are NAT44-free, then > they are in a > different place (a utopia). Nick > > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org > > __>__] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 13 February > 2015 06:49 To: > Alexandru Petrescu Cc: v6ops@ietf.org > > > > Subject: Re: [v6ops] I-D > Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt > - C_REC#9 > 464XLAT > > Hi Alex, > > The intent of this reco is to address broken > IPv4-only > applications over an IPv6-only connectivity. > Ideally > applications > running on the device should be AF-independent. > > The draft relies on the IPv6 node requirements > RFC that > mandates > the supports of IPv6. Also, the I-D calls out > applications that > are provided by the vendor of the device: > > == APP_REC#2: Applications provided by the mobile > device vendor > must be independent of the underlying IP > address family. == > > Wouldn't this reco addresses your concern? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org > > __>__] De la part de > Alexandru Petrescu > Envoyé : jeudi 12 février 2015 17:27 À : > v6ops@ietf.org > > > Objet : > Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT > requirement: > > C_REC#9: In order to ensure IPv4 service > continuity > in an > IPv6-only deployment context, the cellular > host should > implement the Customer Side Translator > (CLAT, [RFC6877]) > function which is compliant with > [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows > for IPv4-only > application and IPv4-referals to work on an > IPv6-only > connectivity. CLAT function requires a > NAT64 capability > [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by > CLAT is > defined in > [RFC7335]. > > > I think this requirement leads to a situation > where the > network > operator deploys IPv6-native-only and IPv4 as > an add-on > partial > feature. > > On one hand, it is encouraging to see native > IPv6 and no > IPv4. > > On another hand, _partial_ IPv4 support is a > temptation > which > deceives in the end - it leads to turn off > IPv6 and > come back > to good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not > offer full > IPv4 > connectivity to the smartphone. It is not > possible to > address > the smartphone by its IPv4 address - DNS is > required; > this makes > it impossible to make a VPN tunnel, or Mobile > IP. One > can not a > deploy a wireless IPv4 router along the road in > a remote > area, > for example. > > This leads to a situation where the operator > requires > end user > to switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by > another > requirement. This initial requirement would > state that > _first_, > before any v4-v6 conversion mechanism is > considered, > both the > network and the end user MUST implement a > native IPv4 > stack and a > native IPv6 stack (not say 'dual' stack, which > is much > overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org > > > a écrit : > > > A New Internet-Draft is available from the > on-line > Internet-Drafts directories. This draft is > a work > item of the > IPv6 Operations Working Group of the IETF. > > Title : An Internet Protocol > Version 6 > (IPv6) Profile > for 3GPP Mobile Devices Authors : David > Binet Mohamed > Boucadair Ales Vizdal Gang Chen Nick > Heatley Ross > Chandler > Filename : > > draft-ietf-v6ops-mobile-____device-profile-17.txt Pages > : 18 Date : 2015-02-12 > > Abstract: This document defines a profile > that is a > superset of > that of the connection to IPv6 cellular > networks > defined in > the IPv6 for Third Generation Partnership > Project (3GPP) > Cellular Hosts document. This document > defines an > IPv6 profile > that a number of operators recommend in > order to > connect 3GPP > mobile devices to an IPv6-only or dual-stack > wireless network > (including 3GPP cellular network and IEEE > 802.11 > network) with > a special focus on IPv4 service continuity > features. > > Both hosts and devices with capability to share > their WAN (Wide > Area Network) connectivity are in scope. > > > The IETF datatracker status page for this > draft is: > https://datatracker.ietf.org/____doc/draft-ietf-v6ops-mobile-____device-prof > > > > > > > i > > l > > > e/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/____draft-ietf-v6ops-mobile-____device-profile-17 > > > > > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?____url2=draft-ietf-v6ops-mobile-____device-prof > > > > > > > i > > l > > > e-17 > > > > Please note that it may take a couple of > minutes > from the time > of submission until the htmlized version > and diff > are available > at tools.ietf.org > . > > Internet-Drafts are also available by > anonymous FTP at: > ftp://ftp.ietf.org/internet-____drafts/ > > > > > > ___________________________________________________ > v6ops mailing > list v6ops@ietf.org > > > https://www.ietf.org/mailman/____listinfo/v6ops > > > > > > > > > > ___________________________________________________ v6ops > mailing > list v6ops@ietf.org > > > https://www.ietf.org/mailman/____listinfo/v6ops > > > > > > ___________________________________________________ v6ops > mailing > list v6ops@ietf.org > > > https://www.ietf.org/mailman/____listinfo/v6ops > > > > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you > are not the > intended recipient, notify the sender immediately, > delete this > email from your system and do not disclose or > use for any > purpose. > > We may monitor all incoming and outgoing emails > in line with > current legislation. We have taken steps to > ensure that this > email and attachments are free from any virus, > but it > remains > your responsibility to ensure that viruses do > not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: 02382161 Registered Office Address: > Trident Place, > Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you are > not the > intended recipient, notify the sender immediately, > delete this > email from your system and do not disclose or use > for any > purpose. > > We may monitor all incoming and outgoing emails in > line with > current legislation. We have taken steps to ensure > that this > email > and attachments are free from any virus, but it > remains your > responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: 02382161 Registered Office Address: Trident > Place, > Mosquito > Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you are not > the intended > recipient, notify the sender immediately, delete this > email from > your > system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line > with current > legislation. We have taken steps to ensure that this > email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: > 02382161 Registered Office Address: Trident Place, > Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > > > > ___________________________________________________ > v6ops mailing list > v6ops@ietf.org > > https://www.ietf.org/mailman/____listinfo/v6ops > > > > > > > > --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com From nobody Sun Feb 15 11:49:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3671A013B for ; Sun, 15 Feb 2015 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.916 X-Spam-Level: * X-Spam-Status: No, score=1.916 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo9oXcawvhQO for ; Sun, 15 Feb 2015 11:49:22 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1551A0067 for ; Sun, 15 Feb 2015 11:49:21 -0800 (PST) Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 6459C4C80E5; Sun, 15 Feb 2015 20:49:10 +0100 (CET) Message-ID: <54E0F83F.3020403@gmail.com> Date: Sun, 15 Feb 2015 20:49:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ross Chandler References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150215-1, 15/02/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 19:49:23 -0000 On 13/02/2015 21:44, Ross Chandler wrote: > >> On 13 Feb 2015, at 12:27, Alexandru Petrescu >> wrote: >> >> Le 12/02/2015 20:39, Ross Chandler a écrit : >>> >>> Perhaps it could be clarified in C_REC#9 that the IPv6-only >>> deployment context refers to the 3GPP device? The data APN it >>> accesses could support IPv4, IPv6 and dual-stack IPv4v6 >>> PDP/PDNs. >> >> I think the current deployments of 464XLAT use the same APN for >> both 3GPP and data services. > > I mean the APN configuration on the provider GGSN/PGW can > simultaneously accept separate PDP/PDN connections of multiple > types. e.g The current APN name can be kept by the provider. Their > old devices use IPv4 with the APN and the newer devices use IPv6. YEs, the APN type can be "IPv4IPv6", or something named like that. Except that the 464xlat networks I am aware of to only "IPv6" kind of APN. In the past some of these networks were IPv4IPv6, but now they move to IPv6-only kind of type, and 464xlat/clat is given as reason why. I disagree with that reason. Alex > > Ross > > > --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com From nobody Sun Feb 15 11:56:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFBB1A00E9 for ; Sun, 15 Feb 2015 11:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.717 X-Spam-Level: ** X-Spam-Status: No, score=2.717 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwTkyBaOo6hw for ; Sun, 15 Feb 2015 11:56:22 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCC41A00B6 for ; Sun, 15 Feb 2015 11:56:22 -0800 (PST) Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id EBB354C80D2; Sun, 15 Feb 2015 20:56:09 +0100 (CET) Message-ID: <54E0F9E3.8000802@gmail.com> Date: Sun, 15 Feb 2015 20:56:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Metzler, Dan J" , "mohamed.boucadair@orange.com" , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150215-1, 15/02/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 19:56:24 -0000 On 13/02/2015 22:36, Metzler, Dan J wrote: > Hi, > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, February 13, 2015 10:59 AM To: >> mohamed.boucadair@orange.com; Heatley, Nick Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> > >> >>> Some operators are seeing CLAT as critical because they don't >>> want to have a service disruption compared to IPv4 when >>> IPv6-only connectivity is provided to their customers. >> >> I agree about the criticality of IPv4 apps when IPv6-only >> connectivity is in place. >> >> But why should there be IPv6-only connectivity in place today for >> the masses? > > Because whether it exists today, or not, that's the goal we are > working toward. It's far too late to be designing things based on > some assumption that IPv6-only connectivity doesn't have to actually > work anyway. The ultimate goal is IPv6-only connectivity for the > masses, and if we make no other assumptions, we ought to be able to > start with the assumption that at least works to all internet > connected IPv6 endpoints. Yes, I agree with the goal. But I think it is too early to think IPv6-only for the masses. I talk to a number of professional deployers and the majority is still questioning the necessity of IPv6. >> Nobody but some ultra-geek do this IPv6-only today. > > Ouch! Sorry, didnt mean to hurt anyone's feelings. Geek is said with respect. One must be ultra-geek to turn off her IPv4 stack. Have you tried? >> Even if the operator's network is IPv6 only, it should have means >> to translate between v4 and v6 at its edges, such as to show pure >> IPv4 and pure IPv6 t user. >> > > I think we should stay away from assumptions like this. But 464xlat/clat is already doing translation. Except that it does translation only on one edge and on the terminal. It should have done translation on both edges and let the terminal free of not implementing CLAT. > If no one is going to mandate that all ISPs MUST provide IPv6 > connectivity, (and that hasn't happened yet), then it doesn't seem > like we can make assumptions about where the translation needs to > happen. I agree with you, IPv6 must be recommended. But there several types in which to bring IPv6 in. Some are smoother than others. In the case I struggle with, in the current situation (CLAT required on the terminal), I will be forced to recommend and use an IPv4-only APN type, and leave IPv6 for a few years later. The end users will not even have a chance to see an RA coming from the network and their Windows end-systems naturally self-configure an address. The end user does not want IPv6, the backend system does not want to provide IPv6. Only the cellular system imposes IPv6. Alex > > > > Thanks, > > - Dan (part time ultra-geek I guess) > >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. http://www.avast.com From nobody Sun Feb 15 12:02:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389F71A0154 for ; Sun, 15 Feb 2015 12:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.717 X-Spam-Level: ** X-Spam-Status: No, score=2.717 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoDK2sIQnxps for ; Sun, 15 Feb 2015 12:02:02 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9EE1A00E7 for ; Sun, 15 Feb 2015 12:02:02 -0800 (PST) Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 671D54C80D7; Sun, 15 Feb 2015 21:01:50 +0100 (CET) Message-ID: <54E0FB37.9090800@gmail.com> Date: Sun, 15 Feb 2015 21:01:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gert Doering References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <20150214194658.GI34798@Space.Net> In-Reply-To: <20150214194658.GI34798@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 150215-1, 15/02/2015), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 20:02:04 -0000 On 14/02/2015 20:46, Gert Doering wrote: > Hi, > > On Fri, Feb 13, 2015 at 01:52:13PM +0100, Alexandru Petrescu wrote: >> Am I wrong to say that one can not ping 8.8.8.8 from behind a 464xlat, >> whereas one can ping 8.8.8.8 behind a nat44? > > Yes, you are. > > That is the whole point of a 464xlat: give applications that insist on > talking to numeric IPv4 addresses a way to do so. Yes, I realized that, thanks for noting. Except that it seems not only 464xlat is required in the network, but also CLAT (TAYGA daemon?) is required on the end user terminal for ping v4-literal to work. This CLAT is conflicting with other requirements. In an IPv4-only world CLAT does not exist. > Applications that use DNS and modern socket APIs do not need 464xlat, Yes. But there are apps that dont rely on DNS and no modern socket APIs. This functionality is replaced by SDN if you wish. The apps I talk about are largely deployed. They won't migrate to IPv6 soon, it's not on the immediate product roadmap. The hurdles are with making the app work, dont need additional burden of IPv4-or-IPv6 debates. The network should be smooth in this respect. Alex > because NAT64/DNS64 will already solve their needs. > > Gert Doering > -- NetMaster > --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. http://www.avast.com From nobody Sun Feb 15 13:06:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5BD1A0154 for ; Sun, 15 Feb 2015 13:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjYI0tuH36pb for ; Sun, 15 Feb 2015 13:05:59 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E971A6EFE for ; Sun, 15 Feb 2015 13:05:58 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 2823525CA253; Sun, 15 Feb 2015 21:05:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45FwFjI-EjAg; Sun, 15 Feb 2015 22:05:54 +0100 (CET) Received: from kopoli (p5DCC7BCB.dip0.t-ipconnect.de [93.204.123.203]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1657525CA072; Sun, 15 Feb 2015 22:05:54 +0100 (CET) From: "Hosnieh Rafiee" To: "'Edward Lewis'" References: In-Reply-To: Date: Sun, 15 Feb 2015 22:05:52 +0100 Message-ID: <000d01d04963$2ec35e90$8c4a1bb0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKBcjE0VatzMzRdx7CgEbL5BHhkapuP1j3w Content-Language: en-us Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 21:06:02 -0000 Hi Edward, I reviewed your draft. You defined two use cases. I think in testing = purposes, usually there is one target service (right?) and It is likely = that only one loopback address is enough (there are many ports = available) Is there a use case that in IPv4 more than one loopback = addresses were in use concurrently to test the communication of a = service? For DNS purpose, I am not sure how this process is useful. Why to = redirect the error messages to xx loopback address and then store = somewhere for operators? How this process help the debugging of a = service like DNS that is application? I think that now one can easily = log the sender, receiver and the whole error message. I still do not = understand the purpose... , Best, Hosnieh > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Edward Lewis > Sent: Sunday, February 15, 2015 6:08 PM > To: v6ops@ietf.org > Subject: [v6ops] FW: New Version Notification for = draft-ipversion6-loopback- > prefix-00.txt >=20 > If it pleases the chairs . . . >=20 > (I thought I sent this earlier but I don=E2=80=99t see it in the = archives. > If it did go out, please forgive the repeat.) >=20 > Below is an announcement for yet-another--00 that I=E2=80=99d like to = get some > feed back on. From reading the charter to see if it would be = appropriate > to mention the draft, I believe it is appropriate. (Mindful that = I=E2=80=99ve been wrong > before.) >=20 > Whether or not it is a candidate for WG adoption is another matter. = For now, > I=E2=80=99d appreciate thoughts on whether this is a =E2=80=98good = idea=E2=80=99 to develop or not. >=20 > Ed Lewis >=20 > On 2/12/15, 14:26, "internet-drafts@ietf.org" = > wrote: >=20 > > > >A new version of I-D, draft-ipversion6-loopback-prefix-00.txt > >has been successfully submitted by Edward Lewis and posted to the = IETF > >repository. > > > >Name: draft-ipversion6-loopback-prefix > >Revision: 00 > >Title: Loopback Prefix for IPv6 > >Document date: 2015-02-12 > >Group: Individual Submission > >Pages: 3 > >URL: > = >http://www.ietf.org/internet-drafts/draft-ipversion6-loopback-prefix-00 > >.tx > >t > >Status: > >https://datatracker.ietf.org/doc/draft-ipversion6-loopback-prefix/ > >Htmlized: > >http://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00 > > > > > >Abstract: > > The IPv6 address range of 0::/64 is reserved for loopback = addresses. > > This expands from the single loophack address already defined for > >IPv6, > > ::1, to allow for a set of addresses to be used when packets are > >intended > > to stay within a host system. Multiple loopback addresses allow = for > > simultaneous varied uses of the loopback addresses as has proven, > >albeit > > in limited ways, in IPv4. And exception is made to accomodate = the > > ::0/128, already defined as The Unspecified Address. > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >The IETF Secretariat > > From nobody Sun Feb 15 19:50:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5333E1A8735 for ; Sun, 15 Feb 2015 19:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFWNF0xIcTaf for ; Sun, 15 Feb 2015 19:50:04 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F371A8734 for ; Sun, 15 Feb 2015 19:50:04 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id p6so22426470qcv.9 for ; Sun, 15 Feb 2015 19:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=/7TTV986mMyTGVmqhkZrp9pR7FqQaAHrDoVUesGSpNQ=; b=UdT8GTG+f6+Pk6LBy0C+ZHv8FEU6EJURmzMGkEGj0gmHrsWZYv00T8XqwglAErR/10 K+y27+GcGNVKjaut2m9P12s95FA/XYMqWPKV7mtJf4QoMyn9mZ2hanR15JPOkgg6UAaP iH+i5rXYv0c8yE5u0UMeXJO61Qt+SuCdhvWW8R0qb0lcQYw1wbgaVWZd5ABVzdJqcnC/ s0+2hbBvS5aajplEDRy8ZBiI+iZWyw8/YDNNlhQb2L9yoAbwp3liAh2ycz7AO1D8BPZm qjOOA9EIV/iV0Q6NCN4SFqN4VcQJ/2At1ZO8tGmUk9amESyb941fVh4duJpPWi+ObWEU aTmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=/7TTV986mMyTGVmqhkZrp9pR7FqQaAHrDoVUesGSpNQ=; b=SmjMSUR971nSq9PmhfDNqW5XeW7C6b3P0KlyLG5IEpXfKuJe+lt+upCPEfEoiIkoCx Lkr49kkTmNCgW+qSZtLoY6Ewhru1sB9hM72Gn/XMAohcm/Hpkd8IA9IjPYo6qB/nQiri X1f3nUY30DFEsqeJcZIBWTTjUSfvUPtuUa0r7jhq0FbkmB6Yab40NlVfqyReXlYBvHBJ c0fc/k8euVL+kIk9EUuBwv2t3s5gAjCV9w4pLR680NFFH8N1PExAmZQyz9MxrjF22jMj DcycOks8W7Wb+J/fV+0AI3ViIfcwfmhBqsIf+1XyIcF1fiudeD/nK8zv8CyrE0KDaKPw hJ6Q== X-Gm-Message-State: ALoCoQm7jX9aURVMi0mTBjs6v/DeneflvvGV6r5WMW35+m1rju779GR9/wbiqt4VlGEoz/nHrnRv X-Received: by 10.140.20.23 with SMTP id 23mr210924qgi.40.1424058603072; Sun, 15 Feb 2015 19:50:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.2 with HTTP; Sun, 15 Feb 2015 19:49:42 -0800 (PST) In-Reply-To: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> From: Erik Kline Date: Mon, 16 Feb 2015 12:49:42 +0900 Message-ID: To: "v6ops@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 03:50:06 -0000 Overall, I think what this document wants is to become an update to something like https://www.ripe.net/ripe/docs/ripe-554 (or similar). I don't think this is really an IETF operational document--mostly it strikes me as fairly weak tea. ----- * I really don't see that section 2.1 has any business being in this document, and I would strike it altogether. * Section 3, A_REC#2: I personally don't see any justification for PCP support as pertains to IPv6. The documented justification seems to be about power savings w.r.t. NAT--not a v6ops thing, as far as I can see. Even if the document means to say that mobile nodes doing NAT64 need to support PCP for IPv4 communications, well I still don't see the point of that. I would remove this part. * Section 3, A_REC#3: I think this should have been be phrased more like "mobile nodes that perform DNSSEC validation AND perform some kind of NAT64 must are advised to...", if it weren't for that fact that it then falls into the "generally obvious" category. I'd remove it. * Section 3, A_REC#4 seems to take RFC 6555 section 5.2 "MAY" behaviour and tries to make it "should". It also specifies some "must" behaviour for DNS recursion libraries that I don't think we've seen before, that I suspect DNS folks should review, and that I don't think we really need. I'd strike this section altogether too. * Section 3, L_REC#1,#2,#3,#4: All of these seem to be just "deployments of type A must implement RFCs that specify type A protocols/operations". These seem obvious, don't add anything new or useful, and I would strike them all. I think by the time you remove all the non-useful sections there won't be much left. From nobody Sun Feb 15 22:11:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2221A873D for ; Sun, 15 Feb 2015 22:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.062 X-Spam-Level: **** X-Spam-Status: No, score=4.062 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_GET_MEDS=2.75, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJYoFuU09747 for ; Sun, 15 Feb 2015 22:11:29 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E3B1A8739 for ; Sun, 15 Feb 2015 22:11:28 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so21755708igq.0 for ; Sun, 15 Feb 2015 22:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XYHCmoFpkPfkQkXqvhyAelfDGN+NcW32qTzexLA6bAE=; b=hegbvihSxFiUJSyj8lvffhB2Zki3v+cP/q3IrLRQpif/AzNp/WmgmAuGHg3JhOZ0K9 ZfNcZX3E0F7XluS12ImLuOQivATXh9CIzbuHHT7cw0qCAlAxSOUeB4/at10B0nH3wEXG dbLERYKa8sg0DRCPt0EvVy20SuXevpOInlsLMNpGmH0TCZoyIUgJgVGDQ/LYjXxCmaka YJTpDX2wd+VxZAXlFtQAiMF81A/k9jbbK/6Q9XMCSuIpZQ1lR8mS7a7UcRQw06s3HtpX zORzVPWOlBn6UKX8XJJaFjcpTiE9sGZ+RNw9T+SDuPAlkibe/vlpDqN4nAZ0z0dLPs/p DaTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XYHCmoFpkPfkQkXqvhyAelfDGN+NcW32qTzexLA6bAE=; b=gjuIxdTKCxHVDuoxjn20X8iSNUNgZeCYd7e+AoSkDfdcmXKTOc1RuR3TE1Cz7sgpbp /CxDW99UvO7da4BDwmcodRUhqn95NZ7r4NifLIgne7NicldiXwlCt+N5MLkAk9732c1g BjgBWcgbHzQ4NkKGD4dkLeUBzKTXUKJA111cbPRKsgeWOR74S29Q8WFiHTO3WbdWNUIP uKf+82aQyLYnOt+HsrLhnEyOJ+YLqcpGZRVJ0LnofzXW8kGihlUd3yu+spTASGYuJM3f FOGhToQq95UUiF4eyG2okArhQIUsSpWVWNf1SsKBRX/Iw3kEBI7zJObTaE0kDgSlg3Gr Y7fA== X-Gm-Message-State: ALoCoQnV5z6IhbbzJZ1vxVMQDCti9aYSdY+0AWYFtV8nCC9XmyZETDgfjuZ50SB2kqWq2izwFegs X-Received: by 10.50.1.48 with SMTP id 16mr19779413igj.45.1424067087999; Sun, 15 Feb 2015 22:11:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Sun, 15 Feb 2015 22:11:07 -0800 (PST) In-Reply-To: <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> From: Lorenzo Colitti Date: Sun, 15 Feb 2015 22:11:07 -0800 Message-ID: To: Ross Chandler Content-Type: multipart/alternative; boundary=047d7bdc12b0eac269050f2e74f0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 06:11:31 -0000 --047d7bdc12b0eac269050f2e74f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, and to continue the analogy, the proposed solution to convince Big Pharma to do what the GPs need is to get a medical standards organization (not even a GP consortium!) to publish an informational document says "this document is not a standard, and compliance with this document is not required, but if you haven't yet stopped reading, here's a profile 30 features long that you might want to implement if you feel like it". I don't see how that will help at all. The way I see it, the only important issues here are a) absent strong operator requirements, device manufacturers do not always implement IPv6 in all products on all regions, and b) iOS does not implement 464xlat. If you want to effect meaningful change, I'd suggest focusing on those issues instead. On Sat, Feb 14, 2015 at 4:25 AM, Ross Chandler wrote: > > On 14 Feb 2015, at 01:31, Lorenzo Colitti wrote: > > On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick > wrote: > >> Lorenzo, I feel you are like the specialist surgeon berating the GPs for >> not knowing every RFC in its pure form. >> > > No, I am berating the authors of this draft for writing a document that > makes GPs (=3Ddevice manufacturers, other network operators) believe that > they have to prepare loads of unnecessary medical machinery (=3Dthe many > recommendations that this draft makes) before they can open a small GP > surgery (=3Ddeploy IPv6), without bothering to tell them why they need al= l > that machinery and what they=E2=80=99re supposed to do with it. > > > In this particular analogy I classify the device manufacturers as members > of Big Pharma, not as GPs. The small country GPs are faced with buying > equipment/features (dual-stack vaccination) to compensate for deficiencie= s > between network+devices they get from their vendors. Until some paying > customer demand arises that gets the GP=E2=80=99s Bank Manager interested= in > helping to push through the development to production services the GP has > little incentive to try to move forward (got a works order for that? no > didn=E2=80=99t think so) unless he also happens to be an IPv6 =E2=80=9Cu= ltra-geek=E2=80=9D. > > A lot of specific input has been taken on board. The list of > recommendations has been paired right back and they are in order of > priority and there are explanations in the document. > > > Ross > > > > > > --047d7bdc12b0eac269050f2e74f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, and to continue the analogy, the proposed solutio= n to convince Big Pharma to do what the GPs need is to get a medical standa= rds organization (not even a GP consortium!) to publish an informational do= cument says "this document is not a standard, and compliance with this= document is not required, but if you haven't yet stopped reading, here= 's a profile 30 features long that you might want to implement if you f= eel like it". I don't see how that will help at all.
The way I see it, the only important issues here are a) absent = strong operator requirements, device manufacturers do not always implement = IPv6 in all products on all regions, and b) iOS does not implement 464xlat.=

If you want to effect meaningful change, I'd = suggest focusing on those issues instead.

On Sat, Feb 14, 2015 at 4:25 AM, Ross C= handler <ross@eircom.net> wrote:

On 14 Feb 2015, at 01:31, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:

On Fri, Feb 13, 2015 at 7:29 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:
Lorenzo, I feel you are like the specialist surgeon berating the GPs = for not knowing every RFC in its pure form.

=
No, I am berating the authors of this draft for writing a document tha= t makes GPs (=3Ddevice manufacturers, other network operators) believe that= they have to prepare loads of unnecessary medical machinery (=3Dthe many r= ecommendations that this draft makes) before they can open a small GP surge= ry (=3Ddeploy IPv6), without bothering to tell them why they need all that = machinery and what they=E2=80=99re supposed to do with it.

In this particular ana= logy I classify the device manufacturers as members of Big Pharma, not as G= Ps.=C2=A0 The small country GPs are faced with buying equipment/features (d= ual-stack vaccination) to compensate for deficiencies between network+devic= es they get from their vendors. Until some paying customer demand arises th= at gets the GP=E2=80=99s Bank Manager interested in helping to push through= the development to production services the GP has little incentive to try = to move forward (got a works order for that? no didn=E2=80=99t think so) un= less he also happens to be an =C2=A0IPv6 =E2=80=9Cultra-geek=E2=80=9D. =C2= =A0

A lot of specific input has been taken on boar= d. The list of recommendations has been paired right back and they are in o= rder of priority and there are explanations in the document.=C2=A0


<= div>Ross




<= br>
--047d7bdc12b0eac269050f2e74f0-- From nobody Sun Feb 15 22:30:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC8D1A874B for ; Sun, 15 Feb 2015 22:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYgw2eWnWYPh for ; Sun, 15 Feb 2015 22:30:18 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2F61A873D for ; Sun, 15 Feb 2015 22:30:18 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so21743469igb.3 for ; Sun, 15 Feb 2015 22:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E9gV+odhfRkK10Vlz/z9LeJHouRkYDt512UXoR11Lcw=; b=jHIFYa5l5a0O+ooMTkZp4DAWi3Of71svH8t8gbCQI8qfha6eRcA4fzfT0yd2lV4SDT QmHXPTJzsvoKp2DQ+2cp4U77HAtrEUBkcetpEjSEEiTio9EQx9Gpc139meZHk9cUcYZK zZAH42WBewvbMyFXkLtBbIWC5cERieZgHl8HU8wcrvzaezZRNnpv7sfCR3volucDmn8o UmPtKdLPtF3uh8XJRmP0Qilm4adNTyObFEnUSMKRAW+knlB9tqjxZYPP8IkmIqG7sBsK 51+hIcf/bNdTk6/mko0q9mhLoYHyNXhCa5odJi5hPC7KAjnv9/vqj5LERdQccLt/8axA TU3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E9gV+odhfRkK10Vlz/z9LeJHouRkYDt512UXoR11Lcw=; b=K9HVE29aIWa34992Faw2SEPl7kroR+xsZo3ElO7zzTM7DVPBfqvz6XUP2/Lrd2D+X4 bMUceO5NzQVkw4G076u2t97jnJRs3OsoRIOxqbumAwPO1zOWVP77mf8EU4py+yrM8w/d razwG9fpyogm3Od6YmLJ8aqbx9hYegcs62L/IQ0axDxdbsXAWKalAoh9hQepTpTkaDrY HrTJVpCYXuweM0CjOD1NLoBbX1tHbHMVIbMCzBqECi/XNCnjUit8n+w3Or7+0A5J404E 5PycnxSEF3tQG6Y6G+IWDEbOTiow2fmHtWBt2naIbxyIWwAI1niMNiGiRLszoGgo7pf5 jS6w== X-Gm-Message-State: ALoCoQlFWiX36aLupcVmGroaTHX+4ElUjfv1xVH4kAJCdFXoi5nlBl4LPKidICg2TsYnnS3SK+vw X-Received: by 10.42.58.139 with SMTP id i11mr21056585ich.68.1424068217505; Sun, 15 Feb 2015 22:30:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Sun, 15 Feb 2015 22:29:57 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Sun, 15 Feb 2015 22:29:57 -0800 Message-ID: To: Edward Lewis Content-Type: multipart/alternative; boundary=20cf30334b6f3db0a8050f2eb8f2 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 06:30:19 -0000 --20cf30334b6f3db0a8050f2eb8f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Feb 15, 2015 at 9:08 AM, Edward Lewis wrote: > Whether or not it is a candidate for WG adoption is another matter. For > now, I=E2=80=99d appreciate thoughts on whether this is a =E2=80=98good i= dea=E2=80=99 to develop > or not. > IIRC this idea has come up at least once before, and maybe more (not sure where - perhaps in v6ops?). I don't oppose it - in fact, I think it's a good idea - but since the previous attempt(s) never came to anything, I assume there was no consensus that this is useful. If you choose ::/64 as your loopback prefix, then you're specifiying a range that includes all IPv4-compatible addresses (::192.0.2.1) and all IPv4-mapped addresses (::ffff:192.0.2.1) in addition to ::/128 (unspecified) and ::1/128 (loopback). --20cf30334b6f3db0a8050f2eb8f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113ece62965f1c050f3f7d8f-- From nobody Mon Feb 16 18:33:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55C1A802C for ; Mon, 16 Feb 2015 18:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35soMJOuNRqX for ; Mon, 16 Feb 2015 18:33:30 -0800 (PST) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0F81A8029 for ; Mon, 16 Feb 2015 18:33:30 -0800 (PST) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 0D9E313F41AE; Mon, 16 Feb 2015 19:33:29 -0700 (MST) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id A30B614FA039; Mon, 16 Feb 2015 19:33:28 -0700 (MST) Message-ID: <54E2A879.2010201@iridiumlinux.org> Date: Mon, 16 Feb 2015 19:33:29 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020200050901010604070702" Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:33:32 -0000 This is a cryptographically signed message in MIME format. --------------ms020200050901010604070702 Content-Type: multipart/alternative; boundary="------------080002010006020405050107" This is a multi-part message in MIME format. --------------080002010006020405050107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/02/2015 19:30, Lorenzo Colitti wrote: > On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot > > wrote: > >> That doesn't make sense. A /64 *is* a large swath of IPv6 address >> space. And there are lots of them. > > The point is that they're addresses, not tags. Why would you > allocate addresses that have absolutely no purpose in relation to > routing? > > > That's what we did in IPv4 with 127.0.0.0/8 . As a > proportion to the size of the IPv4 address pool, that's way more space > than we're talking about here. > =20 > > If a use case (involving routing) for multiple loopback addresses > is evident, I'd say this makes sense, but I just don't see it.=20 > DNS RBL tagging is not such a use case. > > > Pointing network at addresses inside 127.0.0.0/8 > is a very reliable way to cause said applications to fail fast without > emitting any packets. We don't have a way to do that in IPv6 except > pointing them at ::1. How about discard, 0100::/64 as per RFC6666? This seems rather more explicit than using loopback as discard. --------------080002010006020405050107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 16/02/2015 19:30, Lorenzo Colitti wrote:
On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot <falcon@iridiumlinux.org> wrote:
That doesn't make sense. A /64 *is* a large swath of IPv6 address space. And there are lots of them.

The point is that they're addresses, not tags.=C2=A0 Why would you allocate addresses that have absolutely no purpose in relation to routing?

That's what we did in IPv4 with 127.= 0.0.0/8. As a proportion to the size of the IPv4 address pool, that's way more space than we're talking about here.
=C2=A0
If a use case (involving routing) for multiple loopback addresses is evident, I'd say this makes sense, but I just don't see it.=C2=A0 DNS RBL tagging is not such a use case.

Pointing network =C2=A0at addresses inside 127.= 0.0.0/8 is a very reliable way to cause said applications to fail fast without emitting any packets. We don't have a way to do that in IPv6 except pointing them at ::1.

How about discard, 0100::/64 as per RFC6666?=C2=A0 This seems rather = more explicit than using loopback as discard.
--------------080002010006020405050107-- --------------ms020200050901010604070702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTcwMjMz MjlaMCMGCSqGSIb3DQEJBDEWBBTJX5ZHY8e8tNLCuQXJwbNFOcarODBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBADompG2IgzubzrLqLpOyTxMKvbzQc+mPP2KzO045fhaFy6AI Fkg+zKG5N8o/xcMVrqnGndIdhsA00TaIV7bzF24Iz3MGIRxSDPyb1xBTlqh1Kgg/DqzVABlj Vp6nO7w1YrOf1f/4mWxKE5b38UoDmPJ0kIf21Geo++5wmMhylrliIrAHra/5Ipx+OSw/JXRh ZmtInMTNOcPytFJNNcraJDIz45wCMzvifVgXOhn7wYsspMRHgsLQP1qob2zFo9tbhP8jyPJw PdSbsMow2YVUDkHgHrg4ZuIKXXzM0Yisex1pefDWIJOJxcFs/abvY2fwaMKPKZpGAwS/OG9P mHDkK+cAAAAAAAA= --------------ms020200050901010604070702-- From nobody Mon Feb 16 18:36:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231DE1A7034 for ; Mon, 16 Feb 2015 18:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkMgUgQBjlmE for ; Mon, 16 Feb 2015 18:36:42 -0800 (PST) Received: from nm35-vm3.bullet.mail.bf1.yahoo.com (nm35-vm3.bullet.mail.bf1.yahoo.com [72.30.238.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD511A802F for ; Mon, 16 Feb 2015 18:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424140601; bh=TKp4f6PFY705CM57L7swYNmMPmJhF4ENj5moLfID+ss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=flBGOmXjL/TLgQJMhz/QL1uiq5pumD6gIA9pwopSl4xjqnftLqoQAyX7EHIJBy7t6UrH+7cjDaV9IlFsqtNU+Jk0gRkJ52JNWI9boCWMqPovoR3uZ2tTRj9uSGzxpoIu0bfOpbr6aWLwHzpsp5MnisxxuLBDE6xX0z9HYxBBAR8YD0DPmmKdYnN4JjD7Tgm86PvJslU+pzQSLbu90Dc5RJsnQ6dCRCq0IttBfMc+H3Le1dVc9BRRW0VWDnnL7dS68iueo7tyMq5mqlhkGxfghRW6IVSdLW4ctFTSMgCdLGHQx8nVC2JTPcjQuwRU1Byw9yUC1mEDCKVaz1+9dk1iGA== Received: from [98.139.215.141] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:36:41 -0000 Received: from [98.139.212.229] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:36:41 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:36:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 602793.82792.bm@omp1038.mail.bf1.yahoo.com X-YMail-OSG: kwrqYZwVM1lB9pGxpGDh2F0JNLi8zcpAqfDYE9GbCbw0kEaSVDGTvKiAo1doGDI zqCG3SCi3Iei30Bg5dVScvcBLUlscuyEKiiGw2a6mv0.vueiysKosKHKDqxCDYR5dqTRBGm79jZS q1BeJOYJRVuhb6bQqj7eZVyyV9hauheMFOyi006hZw2_1VV2SO_vyGzLe562SeeQns6ASF.aUeIU TU2jGOEdBSpL_wciBA0RzQptCPISQEM1jmNEKzt8.yEsMImsUKrngrJOAHjVKvrOTulbHhjGhqFP I6VlsVC.RtfYDinmjf5e.UWQZd6Is63_Hr8jbz5n8.Ez_Ya.l1pcijAV9.hwLyxg0vQ.tjw2Ctuf 7aeSbv4YnsPSN6OKfMxiWrHYy0VEHsTd9Bk_kPg0wfcKfkGhmPx9M_b4xnrEyrZ7.Ows8Jt2wB4_ qEQAgeQ3Gn_IB6hNqEMbxYSJJPGeUw.3zNvWhECIM4UdyW4u1ih6eHp43usUEFe9Jz1r2ir1HCrw mGI4ShzOzti8iI2EqbMR2PkJhvgtQLqnol1dpmoKH1ip4Wu8.hWSMDXWYaDKD0NFapy8GfblyLLd TK8b3ZyljnhQq_tlWhbzYPG.ISWMqZwsN1DyiYOZpYtRsmu712CRAFptleO.MdGyKQRK2tfq02dp AW4LExs5FkFAAib8zCDTZ01V4dxUOCo4V1NPb_MDX5_gAripv1a8yeii_BmklcbFqjEMswV1N8d6 xPrZLKldnqlg- Received: by 66.196.81.110; Tue, 17 Feb 2015 02:36:39 +0000 Date: Tue, 17 Feb 2015 02:36:34 +0000 (UTC) From: Mark ZZZ Smith To: Mark Andrews Message-ID: <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150217012326.698E829A71C4@rock.dv.isc.org> References: <20150217012326.698E829A71C4@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:36:44 -0000 ________________________________ From: Mark Andrews To: Mark ZZZ Smith Cc: David Conrad ; "v6ops@ietf.org" Sent: Tuesday, 17 February 2015, 12:23 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt The fundemental reason for 127.0.0.0/8 was to give each node a addresses block they could use. 127.0.0.1 evolved as the "standard" loopback address over time. / Actually, 4.2BSD made added the '.1' as the default address, as the '0' they'd originally chosen was the BSD broadcast address: http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_loop.c For the most part no one uses the rest of 127.0.0.0/8 but it is useful to have available. / I'm not sure I completely agree with the idea, however the NTP reference clock drivers use 127.127/16 addresses to make them available to the ntp daemon. I think this use is a bit different to what ICANN specified, as those addresses only have local significance on the host that both the ntp daemon and the reference clocks are attached to. Outside of that host they're unreachable and have no meaning. Fortunately with millions of other addresses within 127/8 there are plenty of others to use for other purposes on the host. That said any use of the rest of 127.0.0.0/8 has to be negotiated between the users. You can't just grab 127.0.0.2 and hope that no one else is using it for IP traffic. / I'm a bit confused by this. 127.0.0.2 traffic should not be leaking outside of the host, as that is contrary to RFC990/RFC1122 rules. So the only risk of collision is two users on the same host. That is of course possible, however the great thing is that there are millions of other loopback addresses available on the host that the users can choose from, and the ones in use can be viewed with 'netstat -a -4 -n' or similar. Hosts have become pretty much single user too these days. / ::1/128 is pretty much single user use. In IPv6 we had both link local and site local addresses from the get go. These gave the operator addresses they could use. They were also slightly more complicated than a GUA as you needed to specify scope. We now have ULA addresses which gets rid of the need to specify scope. Just like with 127.0.0.2 you need to negotiate the use of a address. Reserving a new block of addressing in IPv6 will not stop the need to negotiate address use. If you need truly automatic assignment you need to go to IANA or a RIR (e.g. ARIN and 100.64/10) and request a block for a specific purpose. There is no other way to do truly automatic. / From my draft: "9. IANA Considerations IANA is requested to allocate 0001::/32 from within 0000::/8 of the Internet Protocol Version 6 Address Space, for use as a larger loopback prefix for IPv6, as detailed in this memo, and to record it in the [IANA-IPV6REG]." Mark In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, Mar k ZZZ Smith writes: > So the fundamental problem is 'configured like this'. It's a manual operation > to generate and apply a ULA. ULAs on loopbacks aren't going to well known or > ubiquitous. > > If you want something to be used you need to make it easy, and the best way t > o make something easy is to make it automatic. > > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or wo > uld be automatically configured by the OS, with operator intervention. It's a > lways there, and always available to use. The 4.1c/2.9BSD people though there > was value in automatic configuration of the loopback address on a loopback i > nterface, way back in 1982/1983: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop.c > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.c > > > > ----- Original Message ----- > From: Mark Andrews > To: David Conrad > Cc: Mark ZZZ Smith ; "v6ops@ietf.org" org> > Sent: Tuesday, 17 February 2015, 10:22 > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p > refix-00.txt > > > We don't need *more* reserved address for this. This is from my > laptop and it has been configured like this for years. > > Yes, I have a ULA site on my loopback interface. If your loopback > interface does not support this it is broken. > > > Mark > > lo0: flags=8049 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet 10.53.0.1 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::1 prefixlen 64 > inet 10.53.0.2 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::2 prefixlen 64 > inet 10.53.0.3 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::3 prefixlen 64 > inet 10.53.0.4 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::4 prefixlen 64 > inet 10.53.0.5 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::5 prefixlen 64 > inet 10.53.0.6 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::6 prefixlen 64 > inet 10.53.0.7 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > inet 10.53.0.8 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::8 prefixlen 64 > inet 10.53.0.9 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::9 prefixlen 64 > inet 10.53.0.10 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::10 prefixlen 64 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 16 18:41:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDA1A8983 for ; Mon, 16 Feb 2015 18:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIctOsnv58XI for ; Mon, 16 Feb 2015 18:41:56 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3B61A86EE for ; Mon, 16 Feb 2015 18:41:40 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so27079727igj.4 for ; Mon, 16 Feb 2015 18:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t6IMLzuGOjpKWOSd/1UdvNYeX4KZlbebN9lq84cmJOY=; b=pcIveRK702W0f6JVo6bquwrRgcaodrRUrSLoM3WHyGrjVKUem2Uus7JkhnpAKJzPaO YNdel2Qul5s1AlOcRzz7NJ9PJC2RfEmdwezlNVV2OkYjPaRc2/llSR3gHiQ1YgAtGVbE O7NYbb/jmVV7ubOi8swVlrhuJHG+8WanE43OqcCGNJgHBu+FCwBka6RGj/f47a4Ipbt1 Cwrx8uofcMAM70bkdxMxLA8W3Pmpw6XgEWAnR9VFFAI3ouf+FrvNHPLi5hv4lb4etFiZ bbA4DOloPaahmtD43czFHiO2B8j191KhEbazR9t5jjMBjxkgf9kyfGH48o94cEhzCkTJ TJNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t6IMLzuGOjpKWOSd/1UdvNYeX4KZlbebN9lq84cmJOY=; b=G1GT2O6A6Ag+Vs6zCSMTuWHJPrVUOFMiMPnXPW6UsL9jHgGrVZjKJRK7L+qeSUc0zM qmvywL312LXCIx3Cc6DBSGTdzO6I7xFuPoG7EFA3l9I+t7qwdtHQwwqE+yXjjkXgWOHs qmSMckW2FmhOcsrwGtcbvgNxdThfFOcHSQ9taim9kF/dnP1Hm7ARvrcdFIroMO+Dj0cn HRYnW8mueQVBtCWkKiI7+shO5Mw8078skbnD0eS8pXF38Tsfo88yav9v/stELHux7g3C gAsH2g1wLFVcE1AP9vbL0L/50O4oZpE42Mtl+CQ+1vybhh91Kk1AAGY2q3N9CVv/mYbi KiOw== X-Gm-Message-State: ALoCoQmfrE/ZufkLC6zdttt5NrmNaiM7LWXtGpj+yOFWXv0C2jPsEHCvc7GzhBSQS1xoMv+u0Osy X-Received: by 10.107.170.220 with SMTP id g89mr32808593ioj.31.1424140900200; Mon, 16 Feb 2015 18:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 18:41:19 -0800 (PST) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 11:41:19 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=001a114159b87794e6050f3fa46d Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:41:57 -0000 --001a114159b87794e6050f3fa46d Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti wrote: > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and > give the OEMs a credible signal that from date X onwards, you *will* fail > TA on every device that doesn't implement IPv6, and you *will not* waive > the requirement. That's what Verizon and T-Mobile did, and it worked for > them. > Also: if you think that this strategy is not feasible because you do not have an IPv6 network yet, then yes, that's true - you can't make IPv6 a device requirement until you have an IPv6 network. But I think the key point here is that apart from the lack of 464xlat on iOS, the mobile operating systems are a lot more ready for IPv6 than you might think they are. Once the network is complete, I think turning on IPv6 in the devices does work. Orange Poland, Telenor, and SK Telecom should be able to confirm. --001a114159b87794e6050f3fa46d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <lorenzo@google.com>= wrote:
Yes. Make IPv6* (see belo= w) a requirement for carrier-branded devices, and give the OEMs a credible = signal that from date X onwards, you *will* fail TA on every device that do= esn't implement IPv6, and you *will not* waive the requirement. That= 9;s what Verizon and T-Mobile did, and it worked for them.

Also: if you think that this strate= gy is not feasible because you do not have an IPv6 network yet, then yes, t= hat's true - you can't make IPv6 a device requirement until you hav= e an IPv6 network.

But I think the key point here = is that apart from the lack of 464xlat on iOS, the mobile operating systems= are a lot more ready for IPv6 than you might think they are. Once the netw= ork is complete, I think turning on IPv6 in the devices does work. Orange P= oland, Telenor, and SK Telecom should be able to confirm.
--001a114159b87794e6050f3fa46d-- From nobody Mon Feb 16 19:20:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FD81A014D for ; Mon, 16 Feb 2015 19:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i1xpt3Gx_aU for ; Mon, 16 Feb 2015 19:20:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32C11A0145 for ; Mon, 16 Feb 2015 19:20:40 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id E65163493CE; Tue, 17 Feb 2015 03:20:37 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B47D160060; Tue, 17 Feb 2015 03:27:29 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id AA91D16004C; Tue, 17 Feb 2015 03:27:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 87BA329A857B; Tue, 17 Feb 2015 14:20:29 +1100 (EST) To: Mark ZZZ Smith From: Mark Andrews References: <20150217012326.698E829A71C4@rock.dv.isc.org> <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com> In-reply-to: Your message of "Tue, 17 Feb 2015 02:36:34 -0000." <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Feb 2015 14:20:28 +1100 Message-Id: <20150217032029.87BA329A857B@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 03:20:43 -0000 In message <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com>, Ma rk ZZZ Smith writes: > > > > > ________________________________ > From: Mark Andrews > To: Mark ZZZ Smith > Cc: David Conrad ; "v6ops@ietf.org" > Sent: Tuesday, 17 February 2015, 12:23 > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p > refix-00.txt > > > > The fundemental reason for 127.0.0.0/8 was to give each node a > addresses block they could use. 127.0.0.1 evolved as the "standard" > loopback address over time. > > / Actually, 4.2BSD made added the '.1' as the default address, as the '0' the > y'd originally chosen was the BSD broadcast address: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_lo > op.c Yes, BSD squatted on the address. I was well aware of the history. > For the most part no one uses the rest > of 127.0.0.0/8 but it is useful to have available. > > / I'm not sure I completely agree with the idea, however the NTP reference cl > ock drivers use 127.127/16 addresses to make them available to the ntp daemon > . I think this use is a bit different to what ICANN specified, as those addre > sses only have local significance on the host that both the ntp daemon and th > e reference clocks are attached to. Outside of that host they're unreachable > and have no meaning. Fortunately with millions of other addresses within 127/ > 8 there are plenty of others to use for other purposes on the host. Yes, they have squatted on these address for internal uses. The only reason this doesn't cause issues is that for the most part 127.0.0.0/8 is not used. > That said any > use of the rest of 127.0.0.0/8 has to be negotiated between the > users. You can't just grab 127.0.0.2 and hope that no one else is > using it for IP traffic. > > > / I'm a bit confused by this. 127.0.0.2 traffic should not be leaking outside > of the host, as that is contrary to RFC990/RFC1122 rules. So the only risk o > f collision is two users on the same host. That is of course possible, howeve > r the great thing is that there are millions of other loopback addresses avai > lable on the host that the users can choose from, and the ones in use can be > viewed with 'netstat -a -4 -n' or similar. Hosts have become pretty much sing > le user too these days. I have two different applications which have hard coded 127.0.0.2 port 2356 as the way to connect to them. Which one gets to use 127.0.0.2 port 2356? As I said the use of the rest of 127.0.0.0/8 needs to be negotiated. No one and "rights" on any part of it. > / ::1/128 is pretty much single user use. > > In IPv6 we had both link local and site local addresses from the > get go. These gave the operator addresses they could use. They > were also slightly more complicated than a GUA as you needed to > specify scope. We now have ULA addresses which gets rid of the > need to specify scope. Just like with 127.0.0.2 you need to negotiate > the use of a address. > > Reserving a new block of addressing in IPv6 will not stop the need > to negotiate address use. > > If you need truly automatic assignment you need to go to IANA or a > RIR (e.g. ARIN and 100.64/10) and request a block for a specific > > purpose. There is no other way to do truly automatic. > > / From my draft: > > "9. IANA Considerations > > IANA is requested to allocate 0001::/32 from within 0000::/8 of the > Internet Protocol Version 6 Address Space, for use as a larger > loopback prefix for IPv6, as detailed in this memo, and to record it > in the [IANA-IPV6REG]." And 1::1 will have what automatic meaning? Which application get *exclusive* use of 1::1? 1::/32 would be scratch space. We already have enough mechanisms to create scatch space. If you need a /32 then you can get one from ULA space. There are 16M /32's ULA blocks for local assignment. If a application needs reserved address space that will never collide with anyone else then the vendor should request it from the RIR's for the use of the application. Even if 1::/32 is allocated it is useless for that purpose. Mark > Mark > > In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, M > ar > k ZZZ Smith writes: > > So the fundamental problem is 'configured like this'. It's a manual operati > on > > to generate and apply a ULA. ULAs on loopbacks aren't going to well known > or > > ubiquitous. > > > > If you want something to be used you need to make it easy, and the best way > t > > o make something easy is to make it automatic. > > > > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or > wo > > uld be automatically configured by the OS, with operator intervention. It's > a > > lways there, and always available to use. The 4.1c/2.9BSD people though the > re > > was value in automatic configuration of the loopback address on a loopback > i > > nterface, way back in 1982/1983: > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop > .c > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop. > c > > > > > > > > ----- Original Message ----- > > From: Mark Andrews > > To: David Conrad > > Cc: Mark ZZZ Smith ; "v6ops@ietf.org" f. > > org> > > Sent: Tuesday, 17 February 2015, 10:22 > > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback > -p > > refix-00.txt > > > > > > We don't need *more* reserved address for this. This is from my > > laptop and it has been configured like this for years. > > > > Yes, I have a ULA site on my loopback interface. If your loopback > > interface does not support this it is broken. > > > > > > Mark > > > > lo0: flags=8049 mtu 16384 > > options=3 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > > inet 127.0.0.1 netmask 0xff000000 > > inet6 ::1 prefixlen 128 > > inet 10.53.0.1 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::1 prefixlen 64 > > inet 10.53.0.2 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::2 prefixlen 64 > > inet 10.53.0.3 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::3 prefixlen 64 > > inet 10.53.0.4 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::4 prefixlen 64 > > inet 10.53.0.5 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::5 prefixlen 64 > > inet 10.53.0.6 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::6 prefixlen 64 > > inet 10.53.0.7 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > > inet 10.53.0.8 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::8 prefixlen 64 > > inet 10.53.0.9 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::9 prefixlen 64 > > inet 10.53.0.10 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::10 prefixlen 64 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 17 02:31:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8879F1A8785 for ; Tue, 17 Feb 2015 02:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC-_Ta22qOoo for ; Tue, 17 Feb 2015 02:31:22 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEC71A8783 for ; Tue, 17 Feb 2015 02:31:22 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id CE12B1FCC83; Tue, 17 Feb 2015 10:31:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 97373160064; Tue, 17 Feb 2015 10:38:10 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 44AFD160069; Tue, 17 Feb 2015 10:38:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E5A9629A8B49; Tue, 17 Feb 2015 15:39:12 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> In-reply-to: Your message of "Tue, 17 Feb 2015 11:30:27 +0900." Date: Tue, 17 Feb 2015 15:39:12 +1100 Message-Id: <20150217043912.E5A9629A8B49@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:31:23 -0000 In message , Lorenzo Colitti writes: > Pointing network at addresses inside 127.0.0.0/8 is a very reliable way to > cause said applications to fail fast without emitting any packets. We don't > have a way to do that in IPv6 except pointing them at ::1. Packets to from fe80::1%lo0 only go over the loopback interface. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 17 02:31:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049181A879B for ; Tue, 17 Feb 2015 02:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzDNgbBzYTFX for ; Tue, 17 Feb 2015 02:31:26 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE6C1A879D for ; Tue, 17 Feb 2015 02:31:26 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 5D7431FCAC7; Tue, 17 Feb 2015 10:31:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 28495160067; Tue, 17 Feb 2015 10:38:14 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 6145A160064; Tue, 17 Feb 2015 10:38:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A045F29A87F6; Tue, 17 Feb 2015 15:29:11 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> In-reply-to: Your message of "Tue, 17 Feb 2015 10:26:49 +0900." Date: Tue, 17 Feb 2015 15:29:11 +1100 Message-Id: <20150217042911.A045F29A87F6@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:31:31 -0000 In message , Lorenzo Colitti writes: > On Tue, Feb 17, 2015 at 10:23 AM, Mark Andrews wrote: > > > If you need truly automatic assignment you need to go to IANA or a > > RIR (e.g. ARIN and 100.64/10) and request a block for a specific > > purpose. There is no other way to do truly automatic. > > There is. Just make the block big enough and pick addresses out of it at > random. And you still need to have a strategy to deal with collisions. You also need to be able to communicate the resulting address to all components that need to know it. I still see no benefit between picking a random block in 1::/32 vs picking a random block in fd00::/8. In both cases you have to deal with collisions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 17 02:36:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDFA1A8785 for ; Tue, 17 Feb 2015 02:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r80GhLxlEKj for ; Tue, 17 Feb 2015 02:35:58 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50881A1A94 for ; Tue, 17 Feb 2015 02:35:57 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so28776454igj.4 for ; Tue, 17 Feb 2015 02:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=44QeakrllHnZlnaPCrl+KtGjgo1Uih81FoNeIy8L6EI=; b=cOuEd+4t9EiXco9JctO55QyNlmX2u2Hc75nPs+gYQPNUsAYAvg5aaPJIuliPcwLKdw PnKyt78zD+icbB27BjGHUXE9sMrBC5eEWGGgYS6SonZh1GpDWDnP5Zhyy/T+gJ5yVSsg edRrXQvNTod+qm1uEOQvXxyjPS/FEYuUl/Sq/sqzw5c8dehqYbsOOGr1wIqRMWU2EnVE Q8gQ0LeFU9mr/nYDkD5PBrxc9SIHDx6NswIrCvtegnsaBNoeqMfTjNyKHNZ7IcY9XHAH kZrLbrqYEmMeZHiH7AGbJSOufls2FiXfWOKl3r5nmoMgb0rEU02yH/9Xp26Hjdl/KzCW fQDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=44QeakrllHnZlnaPCrl+KtGjgo1Uih81FoNeIy8L6EI=; b=Hvn/G6nhZTzlBZLOsY61ChsRYJVNb1X9DGAhSmQpLBcE11OK+2/Q1mqPQyrqTGGU1v 0bvhkchFkjavw9oYKawebl2eFpui1pZc1dab5kBk4VKlt+HGauluFBW3rz8mm2+nmyTE QbMTKlTLhxjALNda6+XfStvcsfwZdILw8NvyosGZXobQwIM+qsphwsqL0KqT8LJtH3Zb u9Biz/LDbGLYew5AUNfshEaPvJ5MTHmyLcesvFIaPCqERebjxG3s47T4O4F//5wfkdZp GrArycImNCCogVPkHnS7fJwAy81+9dcYp6qfZfpFaTpGa0XNivQbjsfWqWW2NKR+GREB Fnmg== X-Gm-Message-State: ALoCoQnxT9pQ8C3GIfk66BZf69C1KOj8/on7ySxWRCSwW5KUPRFU6Aq0/qXk5GCchDIr4LOWChe7 X-Received: by 10.42.172.136 with SMTP id n8mr33904382icz.85.1424169356974; Tue, 17 Feb 2015 02:35:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 02:35:36 -0800 (PST) In-Reply-To: <20150217043912.E5A9629A8B49@rock.dv.isc.org> References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> <20150217043912.E5A9629A8B49@rock.dv.isc.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 19:35:36 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=90e6ba6e81989f9043050f464482 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:36:01 -0000 --90e6ba6e81989f9043050f464482 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 1:39 PM, Mark Andrews wrote: > > Pointing network at addresses inside 127.0.0.0/8 is a very reliable > way to > > cause said applications to fail fast without emitting any packets. We > don't > > have a way to do that in IPv6 except pointing them at ::1. > > Packets to from fe80::1%lo0 only go over the loopback interface. > But fe80::1%lo0 doesn't work on my machine because my loopback interface is called lo, not lo0. And you can't put fe80::1%lo0 in DNS, either. 127.x.y.z doesn't have those problems. --90e6ba6e81989f9043050f464482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 1:39 PM, Mark Andrews <marka@isc.org> wrote:=
> Pointing network=C2=A0 at addres= ses inside 127.0.0.0/8= is a very reliable way to
> cause said applications to fail fast without emitting any packets. We = don't
> have a way to do that in IPv6 except pointing them at ::1.

Packets to from fe80::1%lo0 only go over the loopback interface.
=

But fe80::1%lo0 doesn't work on my mac= hine because my loopback interface is called lo, not lo0. And you can't= put fe80::1%lo0 in DNS, either. 127.x.y.z doesn't have those problems.=
--90e6ba6e81989f9043050f464482-- From nobody Tue Feb 17 02:40:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148021A87CA for ; Tue, 17 Feb 2015 02:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFddx_iASydy for ; Tue, 17 Feb 2015 02:40:06 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9271A87C9 for ; Tue, 17 Feb 2015 02:40:06 -0800 (PST) Received: by iecat20 with SMTP id at20so39941110iec.12 for ; Tue, 17 Feb 2015 02:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=laoF/c9hmms7O6BZ7riApNLU7pWzf2kJDBTk+wINGR0=; b=C56NybIN9q+FM81PVFgLa6z9VNvFLxPozrVGfrjdhK872Sq1yaMDRjepPuvgMivohA CIabLE2MH10Qb3bOxWzJTkzRwzVsGb5OK0lzF0vD2JokLXAL44ay+lJvz2yvpVRLhSZ/ gOlAEZJ4/5VOb3/4v5i7NwT7C0TceEgRBr1t+kwW1/EpzZdxtaQkDfrJ2eojY4Ahl8kw Hs2Dq41OilCCnvwakdEa6Xl1ptwKOv/CCyRT09ztLT1kDn5mWi+Xz8asUzTuS0MHTtcO 5/8czYmUxoFZDCC0W6ssYc0sFGaSjN8WVrTR8APLpl/z/bjf1l5NUaGAjZw/Ge2cpw97 Zy0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=laoF/c9hmms7O6BZ7riApNLU7pWzf2kJDBTk+wINGR0=; b=R5S3dOwbF5yE90oe+5ygIfSP1umC0MtctWoHzNxtLAEWha1Dw1F7Hjv5rh0EGKJs3U imRE2AdG7t596ahx2Yw2FrG4FOvtd1qHJKybaU6Ei0nJCXI9SSD8tixJkjUSrAWwbQBk entfcDuAs/yEAePeAZbjxW0rhzIiBJ+9YsVcF7Xne/hbgTp4n24qwzJaXpl1s/PwSeJe 4M8tivV2LIT8IT8+cr+QtUkdRGhxqA3RzurXLMjY0r0MBnSGuP5S7zfh9qgn/3Gn09yd dZywuJu6Weo/9mTN96f3ScpxmTFiF1F+aJwNZDe1A/EuPcu3nAQAJf+QDzEpzHt96MzW 1Arw== X-Gm-Message-State: ALoCoQnZaN8UDuka4yluA2Tl3gM+VHR1EQ4nQc/cctDNs9uGf6Pzi10wg0e4fA/Fmkxzg585PADH X-Received: by 10.107.170.220 with SMTP id g89mr34510790ioj.31.1424169605514; Tue, 17 Feb 2015 02:40:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 02:39:45 -0800 (PST) In-Reply-To: <20150217042911.A045F29A87F6@rock.dv.isc.org> References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> <20150217042911.A045F29A87F6@rock.dv.isc.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 19:39:45 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a114159b86fec90050f4653b2 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 10:40:08 -0000 --001a114159b86fec90050f4653b2 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 1:29 PM, Mark Andrews wrote: > And you still need to have a strategy to deal with collisions. bind() and EADDRINUSE? > You also need to be able to communicate the resulting address to all > components that need to know it. > 127.0.0.0/8 has that problem too, but people seem to find it useful. > I still see no benefit between picking a random block in 1::/32 vs > picking a random block in fd00::/8. But while a ULA block only works on the machine where it's configured, 127.0.0.0/8 is present on every machine. > In both cases you have to deal with collisions. > With a decent random number generator, the probability of a collision is infinitesimally low unless you start generating millions of them. --001a114159b86fec90050f4653b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 1:29 PM, Mark Andrews <marka@isc.org> wrote:=
And you still need to have a strategy to= deal with collisions.

bind() and EADDRINUS= E?
=C2=A0
You=C2=A0also need = to be able to communicate the resulting address to all
components that need to know it.

127.0.0.0/8 has that problem too, but people s= eem to find it useful.
=C2=A0
I still see no benefit between picking a random block in 1::/32 vs
picking a random block in fd00::/8.

But whi= le a ULA block only works on the machine where it's configured, 127.0.0.0/8 is present on every machine.
<= div>=C2=A0
In both cases you have to de= al=C2=A0with collisions.

With a decent = random number generator, the probability of a collision is infinitesimally = low unless you start generating millions of them.
--001a114159b86fec90050f4653b2-- From nobody Tue Feb 17 03:31:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB561A876E for ; Tue, 17 Feb 2015 03:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwaQHIvB8RPe for ; Tue, 17 Feb 2015 03:31:34 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF6D1A8840 for ; Tue, 17 Feb 2015 03:31:33 -0800 (PST) Received: from [85.158.136.35] by server-10.bemta-5.messagelabs.com id 67/35-02756-39623E45; Tue, 17 Feb 2015 11:31:31 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-125.messagelabs.com!1424172690!36183826!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9940 invoked from network); 17 Feb 2015 11:31:31 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-16.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Feb 2015 11:31:31 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Tue, 17 Feb 2015 11:31:27 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Tue, 17 Feb 2015 11:31:30 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 11:31:30 +0000 From: "Heatley, Nick" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAFtSIAABXhFiAAAXD/SAAI6wAAAABhtuAABDDgdA= Date: Tue, 17 Feb 2015 11:31:29 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E088AEUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 11:31:36 -0000 --_000_6536E263028723489CCD5B6821D4B21303E088AEUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFwcHJvYWNoLCBJIGhhdmUgbm8gZG91YnQgaXQg d29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUgdG8gYWxsIG1vYmlsZSBvcGVyYXRvcnM/DQpGb3Ig bWUsIGl0IGhhcyBzb21lIGxpbWl0YXRpb25zOg0KDQotICAgICAgICAgIFRoZSBvcGVyYXRvciBt dXN0IGhhdmUgdG9wIGRvd24gYmFja2luZyBmb3IgYSB0ZXJtaW5hbCBwb2xpY3kgb2Yg4oCcSVB2 NiBvciB5b3UgYXJlIG91dOKAnSAobm93IHRoYXQgaXMgYSB3aWxkY2FyZCBjb25kaXRpb24gaW4g aXRzZWxmKTsgaXQgbWF5IGNvbXByb21pc2UgcmVsYXRpb25zaGlwcyBpbiBhIHZhbHVhYmxlIGVj b3N5c3RlbQ0KDQotICAgICAgICAgIFdoZXJlIHRoZSBvcGVyYXRvciBoYXMgaGlnaCBtYWpvciBt YXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1hcmtldHMgaGF2ZSBhIG51bWJlciBvZiBwbGF5ZXJz IHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2FtZSwgdGhlcmUgaXMgYW4gYWR2YW50YWdlLiBPdGhl cndpc2UgdGhlIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUgYW5kIGNvbnF1ZXIN Cg0KLSAgICAgICAgICBDdXJyZW50bHkgaXQgdGVuZHMgdG8gcGxheSBvdXQgYXMgYSB0aGUgc2lt cGxlc3Qgc2V0IG9mIHJlcXVpcmVtZW50cy4gV2hpY2ggYWxzbyBtZWFucyBzaW1wbGVzdCBzZXQg b2YgbmV0d29yayBjYXBhYmlsaXRpZXMuIFNvbWV0aW1lcyB0aGVzZSBzaW1wbGVzdCBzZXQgb2Yg bmV0d29yayBjYXBhYmlsaXRpZXMgYXJlIGF0IG9kZHMgd2l0aCB0aGUgYnVzaW5lc3MgcHJpb3Jp dGllcyBvZiB0aGUgb3BlcmF0b3IgKGNsZWFyIGV4YW1wbGVzIGFyZTogQVBOIHN0cmF0ZWd5LCB0 ZXRoZXJpbmcgYXBwcm9hY2gsIHJvYW1pbmcgYXBwcm9hY2gsIHN1YnNpZGlzZWQgaGFuZHNldCB2 cyDigJxTSU0tb25seeKAnSkNCihOb3QgaGF2aW5nIGFuIElQdjYgY2FwYWJsZSBuZXR3b3JrIGlz IGEgbXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQgb3BlcmF0b3Igdmlld3MsIGl0 IGlzIGEgcmVkIGhlcnJpbmcg4oCTIGFueSBvcGVyYXRvciBzcGVjaWZ5aW5nICphbnkqIElQdjYg cmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhpcyBjYXBhYmlsaXR5IHRvIHZh bGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5IGNob29zZS4pDQoNCkkgY2Fu IHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIG9mIHY2IHJl cXVpcmVtZW50cy4NCkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3JrIGFjcm9z cyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLg0KVGhlIG90aGVyIGFw cHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFuZCB0cnlpbmcgdG8gc2V0 IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9uYWwgcmVxdWly ZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICDigJxoYXJtZnVsbHkgYnJv YWTigJ0uDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUu Y29tXQ0KU2VudDogMTcgRmVicnVhcnkgMjAxNSAwMjo0MQ0KVG86IEhlYXRsZXksIE5pY2sNCkNj OiBSb3NzIENoYW5kbGVyOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNh bGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUdWUsIEZlYiAxNywgMjAxNSBhdCAxMDo1NyBB TSwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbT4+IHdyb3RlOg0KWWVzLiBNYWtlIElQdjYqIChzZWUgYmVsb3cpIGEgcmVxdWlyZW1l bnQgZm9yIGNhcnJpZXItYnJhbmRlZCBkZXZpY2VzLCBhbmQgZ2l2ZSB0aGUgT0VNcyBhIGNyZWRp YmxlIHNpZ25hbCB0aGF0IGZyb20gZGF0ZSBYIG9ud2FyZHMsIHlvdSAqd2lsbCogZmFpbCBUQSBv biBldmVyeSBkZXZpY2UgdGhhdCBkb2Vzbid0IGltcGxlbWVudCBJUHY2LCBhbmQgeW91ICp3aWxs IG5vdCogd2FpdmUgdGhlIHJlcXVpcmVtZW50LiBUaGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBULU1v YmlsZSBkaWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRoZW0uDQoNCkFsc286IGlmIHlvdSB0aGluayB0 aGF0IHRoaXMgc3RyYXRlZ3kgaXMgbm90IGZlYXNpYmxlIGJlY2F1c2UgeW91IGRvIG5vdCBoYXZl IGFuIElQdjYgbmV0d29yayB5ZXQsIHRoZW4geWVzLCB0aGF0J3MgdHJ1ZSAtIHlvdSBjYW4ndCBt YWtlIElQdjYgYSBkZXZpY2UgcmVxdWlyZW1lbnQgdW50aWwgeW91IGhhdmUgYW4gSVB2NiBuZXR3 b3JrLg0KDQpCdXQgSSB0aGluayB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCBhcGFydCBmcm9t IHRoZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0aGUgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1z IGFyZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2IHRoYW4geW91IG1pZ2h0IHRoaW5rIHRoZXkg YXJlLiBPbmNlIHRoZSBuZXR3b3JrIGlzIGNvbXBsZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2 NiBpbiB0aGUgZGV2aWNlcyBkb2VzIHdvcmsuIE9yYW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBT SyBUZWxlY29tIHNob3VsZCBiZSBhYmxlIHRvIGNvbmZpcm0uDQoNCk5PVElDRSBBTkQgRElTQ0xB SU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVk IGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlz IGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFu eSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5n IGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBz dGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBm cm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1 cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0 ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBO dW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNl LCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== --_000_6536E263028723489CCD5B6821D4B21303E088AEUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjczODY3NDg4MzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTk5NDUwOTY2IDUzNTA4ODc1MiAxMzQ4MDc1NTUg MTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1 NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgdGhlIGdh bWUgb2YgY2hpY2tlbiBhcHByb2FjaCwgSSBoYXZlIG5vIGRvdWJ0IGl0IHdvcmtzLCBidXQgaXMg aXQgaW5jbHVzaXZlIHRvIGFsbCBtb2JpbGUgb3BlcmF0b3JzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Gb3IgbWUsIGl0IGhhcyBzb21lIGxpbWl0YXRpb25zOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3BlcmF0b3IgbXVzdCBoYXZlIHRvcCBkb3du IGJhY2tpbmcgZm9yIGEgdGVybWluYWwgcG9saWN5IG9mIOKAnElQdjYgb3IgeW91IGFyZSBvdXTi gJ0gKG5vdyB0aGF0IGlzIGEgd2lsZGNhcmQgY29uZGl0aW9uIGluIGl0c2VsZik7IGl0IG1heSBj b21wcm9taXNlDQogcmVsYXRpb25zaGlwcyBpbiBhIHZhbHVhYmxlIGVjb3N5c3RlbTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVyZSB0aGUgb3BlcmF0b3IgaGFzIGhp Z2ggbWFqb3IgbWFya2V0IHBvd2VyIGhlbHBzLiBXaGVyZSBtYXJrZXRzIGhhdmUgYSBudW1iZXIg b2YgcGxheWVycyByZWFkeSB0byBwbGF5IHRoZSBJUHY2IGdhbWUsIHRoZXJlIGlzIGFuIGFkdmFu dGFnZS4gT3RoZXJ3aXNlDQogdGhlIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUg YW5kIGNvbnF1ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3VycmVu dGx5IGl0IHRlbmRzIHRvIHBsYXkgb3V0IGFzIGEgdGhlIHNpbXBsZXN0IHNldCBvZiByZXF1aXJl bWVudHMuIFdoaWNoIGFsc28gbWVhbnMgc2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsgY2FwYWJpbGl0 aWVzLiBTb21ldGltZXMgdGhlc2Ugc2ltcGxlc3QNCiBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRp ZXMgYXJlIGF0IG9kZHMgd2l0aCB0aGUgYnVzaW5lc3MgcHJpb3JpdGllcyBvZiB0aGUgb3BlcmF0 b3IgKGNsZWFyIGV4YW1wbGVzIGFyZTogQVBOIHN0cmF0ZWd5LCB0ZXRoZXJpbmcgYXBwcm9hY2gs IHJvYW1pbmcgYXBwcm9hY2gsIHN1YnNpZGlzZWQgaGFuZHNldCB2cyDigJxTSU0tb25seeKAnSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KE5vdCBoYXZpbmcgYW4gSVB2NiBjYXBhYmxl IG5ldHdvcmsgaXMgYSBteXRoIHlvdSBhcmUgcHJvbW90aW5nIHRvIGRpc2NyZWRpdCBvcGVyYXRv ciB2aWV3cywgaXQgaXMgYSByZWQgaGVycmluZyDigJMgYW55IG9wZXJhdG9yIHNwZWNpZnlpbmcg KjxiPmFueTwvYj4qIElQdjYNCiByZXF1aXJlbWVudHMgd2lsbCB2ZXJ5IHF1aWNrbHkgbmVlZCB0 aGlzIGNhcGFiaWxpdHkgdG8gdmFsaWRhdGUgdGVybWluYWxzIHdoYXRldmVyIHRoZSBwYXRoIHRo ZXkgY2hvb3NlLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3Qg Y29tbW9uIGRlbm9taW5hdG9yIG9mIHY2IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB0aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3Nz IHRoZSBib2FyZCBpcyDigJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBvdGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBk aWZmZXJlbmNlcyBhbmQgdHJ5aW5nIHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlciBiYXIgdGhhdCBo aWdobGlnaHRzIGNvbmRpdGlvbmFsIHJlcXVpcmVtZW50cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hh dA0KIHlvdSBjYWxsICZuYnNwO+KAnGhhcm1mdWxseSBicm9hZOKAnS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNyBGZWJydWFyeSAyMDE1 IDAyOjQxPGJyPg0KPGI+VG86PC9iPiBIZWF0bGV5LCBOaWNrPGJyPg0KPGI+Q2M6PC9iPiBSb3Nz IENoYW5kbGVyOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxh c3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQg MTA6NTcgQU0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlllcy4gTWFrZSBJUHY2KiAoc2VlIGJlbG93KSBhIHJlcXVpcmVtZW50IGZvciBj YXJyaWVyLWJyYW5kZWQgZGV2aWNlcywgYW5kIGdpdmUgdGhlIE9FTXMgYSBjcmVkaWJsZSBzaWdu YWwgdGhhdCBmcm9tIGRhdGUgWCBvbndhcmRzLCB5b3UgKndpbGwqIGZhaWwgVEEgb24gZXZlcnkg ZGV2aWNlIHRoYXQgZG9lc24ndCBpbXBsZW1lbnQgSVB2NiwgYW5kIHlvdSAqd2lsbCBub3QqIHdh aXZlIHRoZSByZXF1aXJlbWVudC4NCiBUaGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBULU1vYmlsZSBk aWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc286IGlm IHlvdSB0aGluayB0aGF0IHRoaXMgc3RyYXRlZ3kgaXMgbm90IGZlYXNpYmxlIGJlY2F1c2UgeW91 IGRvIG5vdCBoYXZlIGFuIElQdjYgbmV0d29yayB5ZXQsIHRoZW4geWVzLCB0aGF0J3MgdHJ1ZSAt IHlvdSBjYW4ndCBtYWtlIElQdjYgYSBkZXZpY2UgcmVxdWlyZW1lbnQgdW50aWwgeW91IGhhdmUg YW4gSVB2NiBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CdXQgSSB0aGluayB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCBhcGFy dCBmcm9tIHRoZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0aGUgbW9iaWxlIG9wZXJhdGluZyBz eXN0ZW1zIGFyZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2IHRoYW4geW91IG1pZ2h0IHRoaW5r IHRoZXkgYXJlLiBPbmNlIHRoZSBuZXR3b3JrIGlzIGNvbXBsZXRlLCBJIHRoaW5rIHR1cm5pbmcg b24gSVB2NiBpbiB0aGUgZGV2aWNlcw0KIGRvZXMgd29yay4gT3JhbmdlIFBvbGFuZCwgVGVsZW5v ciwgYW5kIFNLIFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29uZmlybS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCjxQPk5PVElDRSBB TkQgRElTQ0xBSU1FUjxCUj5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykg aXMgaW50ZW5kZWQgDQpmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4mbmJzcDsgSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgDQpub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IA0K ZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4mbmJzcDsgPEJSPiZuYnNwOzxCUj5XZSBt YXkgbW9uaXRvciBhbGwgaW5jb21pbmcgDQphbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0 aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIA0KZW5zdXJlIHRo YXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1 dCBpdCByZW1haW5zIA0KeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2Vz IGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gPC9QPg0KPFA+RUUgTGltaXRlZDxCUj5SZWdp c3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzPEJSPkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6 IA0KMDIzODIxNjE8QlI+UmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwg TW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgDQpIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVzwvUD4NCjxQ PiZuYnNwOzwvUD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6536E263028723489CCD5B6821D4B21303E088AEUK30S005EXS06EE_-- From nobody Tue Feb 17 04:43:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CEA1A890D for ; Tue, 17 Feb 2015 04:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VLi7YALAnnt for ; Tue, 17 Feb 2015 04:43:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875101A1AB0 for ; Tue, 17 Feb 2015 04:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3424; q=dns/txt; s=iport; t=1424177016; x=1425386616; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fl+F/vA7Qc7EnwP9RvdZ+CQTn9ZdzAKfUs+jK9CLxAY=; b=At6KXac9PFFH5BLAWbfnf//+/wtCNYrCuWvArIuoYWnQWDQovMBe9usw lYsNqahvEOJtmBfUOZ/dXmtYNtI/cROPI9MZeV7SQeudJP/GsXNOBpYn5 36Np4oEnG63aSel3qgT+d7Ub6sK16IGfZaAdNcy/GOUnBb78y7QVCQNAq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B1BQAnN+NU/4sNJK1bgkNDgSwEgn/FOQIcdkMBAQEBAQF8hA0BAQQjVAIQAgEIBBABKgMCAgIwFBECBAENBYgvt2mXbwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLD4RdEQeCaIFCAQSPOIk3kw0igjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,594,1418083200"; d="scan'208,217";a="396759659" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 17 Feb 2015 12:43:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1HChTAr029197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 12:43:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 06:43:29 -0600 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , Mark Andrews Thread-Topic: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSjzmQb36b/Nq8kSi62lmwwt4/Zzz6mXrgACCWYCAANLHgA== Date: Tue, 17 Feb 2015 12:43:28 +0000 Message-ID: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> <20150216232213.3123C29A61F1@rock.dv.isc.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.73] Content-Type: multipart/alternative; boundary="_000_D108F59A3D33Bevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:43:38 -0000 --_000_D108F59A3D33Bevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbT4+DQpEYXRlOiBtYXJkaSAxNyBmw6l2cmllciAyMDE1IDAyOjA5DQpUaGUgdmFs dWUgb2YgdGhlIGxvb3BiYWNrIHByZWZpeCBpcyBub3QgdGhhdCBpdCdzIHJvdXRlZCB0byBsb29w YmFjay4gSXQncyB0aGF0ICpldmVyeWJvZHkga25vd3MqIGl0J3MgYWx3YXlzIHJvdXRlZCB0byBs b29wYmFjay4NCg0KSW5kZWVkLiBDbGFyaXR5IGFsd2F5cyB3aW5zLCB0aGlzIGlzIHdoeSBJIHRl bmQgdG8gbGlrZSB0aGlzIEktRCAoYWxiZWl0IGl0IHNob3VsZCBiZSByZXdyaXR0ZW4pLg0KDQpC VFcsIHRoZSBjaG9pY2Ugb2YgOjovNjQgaXMgcHJvYmFibHkgbm90IHRoZSBiZXN0IGNob2ljZSBh cyBpdCBpbmNsdWRlcyB0aGUgZGVwcmVjYXRlZCA6Oi85NiBmb3IgSVB2NC1jb21wYXRpYmxlIElQ djYgYWRkcmVzcy4NCg0KLcOpcmljDQo= --_000_D108F59A3D33Bevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7573AE3F8ED4F047B3E1A16D3FF65814@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC13ZWlnaHQ6IGJv bGQ7Ij5Gcm9tOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9u dC1zaXplOiAxMXB0OyI+TG9yZW56byBDb2xpdHRpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyBmb250LXNp emU6IDExcHQ7Ij5sb3JlbnpvQGdvb2dsZS5jb208L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpOyBmb250LXNpemU6IDExcHQ7Ij4mZ3Q7PC9zcGFuPjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9Q OiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1U T1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPm1h cmRpIDE3IGbDqXZyaWVyIDIwMTUgMDI6MDk8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+VGhlIHZhbHVlIG9mIHRoZSBsb29wYmFjayBwcmVm aXggaXMgbm90IHRoYXQgaXQncyByb3V0ZWQgdG8gbG9vcGJhY2suIEl0J3MgdGhhdCAqZXZlcnli b2R5IGtub3dzKiBpdCdzIGFsd2F5cyByb3V0ZWQgdG8gbG9vcGJhY2suPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW5kZWVkLiBDbGFyaXR5IGFsd2F5cyB3aW5zLCB0aGlz IGlzIHdoeSBJIHRlbmQgdG8gbGlrZSB0aGlzIEktRCAoYWxiZWl0IGl0IHNob3VsZCBiZSByZXdy aXR0ZW4pLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QlRXLCB0aGUgY2hvaWNlIG9m IDo6LzY0IGlzIHByb2JhYmx5IG5vdCB0aGUgYmVzdCBjaG9pY2UgYXMgaXQgaW5jbHVkZXMgdGhl IGRlcHJlY2F0ZWQgOjovOTYgZm9yIElQdjQtY29tcGF0aWJsZSBJUHY2IGFkZHJlc3MuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tw6lyaWM8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D108F59A3D33Bevynckeciscocom_-- From nobody Tue Feb 17 04:48:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359CE1A8857 for ; Tue, 17 Feb 2015 04:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRdpROwlspKa for ; Tue, 17 Feb 2015 04:48:51 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93FE1A8854 for ; Tue, 17 Feb 2015 04:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1424177331; x=1425386931; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3gL5S2hA0irWNYKk0su5LmdXx17rP35dR+u0ne8CJXE=; b=Rs5jA/SpAmEQm7FDsD8Gotjyx9MV+NN2HcT7cvLba95LB99Mh/gaTyqv jmE/SlNT5RLm5JSzCwuUJkTm3g//qrwKq0BYBGmr0rQoQz7NLwGJyLsEB 300kmHeX1g2FiyjhP+fkwhDJu4nIhoJXKKIW+GDkASTCnV1aLwjSL2zeC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B1BQBJOONU/4gNJK1bgkNDgSwEgn/FOQIcdkMBAQEBAQF8hAwBAQEEI1QCEAIBCAQBDwEqAwICAjAUCAkCBAENBYgvt3GXbgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLD4RdEQeCaIFCAQSPOIk3kw0igjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,594,1418083200"; d="scan'208,217";a="124324267" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 17 Feb 2015 12:48:50 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1HCmo90028542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 12:48:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 06:48:49 -0600 From: "Eric Vyncke (evyncke)" To: Falcon Darkstar Momot , Lorenzo Colitti Thread-Topic: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSUIEjnmiENkrAUKRqDIUqGF8vpzzNgiAgAAK6wCAACcnAIAAb4sAgAB3uICAADH9AIAAAkeAgAABEICAAADBgIAAANmAgAC8rgA= Date: Tue, 17 Feb 2015 12:48:49 +0000 Message-ID: References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> <54E2A879.2010201@iridiumlinux.org> In-Reply-To: <54E2A879.2010201@iridiumlinux.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.73] Content-Type: multipart/alternative; boundary="_000_D108F7053D345evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:48:55 -0000 --_000_D108F7053D345evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBGYWxjb24gRGFya3N0YXIgTW9tb3QgPGZhbGNvbkBpcmlkaXVtbGludXgub3JnPG1h aWx0bzpmYWxjb25AaXJpZGl1bWxpbnV4Lm9yZz4+DQpEYXRlOiBtYXJkaSAxNyBmw6l2cmllciAy MDE1IDAzOjMzDQoNCkhvdyBhYm91dCBkaXNjYXJkLCAwMTAwOjovNjQgYXMgcGVyIFJGQzY2NjY/ ICBUaGlzIHNlZW1zIHJhdGhlciBtb3JlIGV4cGxpY2l0IHRoYW4gdXNpbmcgbG9vcGJhY2sgYXMg ZGlzY2FyZC4NCg0KRVY+IHRoZW4gd2hhdCBhYm91dCBub2RlcyBoYXZpbmcgcm91dGVzIGZvciAx MDA6Oi82NCB0byAvZGV2L251bGw/IFN1Y2ggYXMgcGVlcmluZyByb3V0ZXJzPyA6LSkNCg0KLcOp cmljDQoNCg0K --_000_D108F7053D345evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5GYWxjb24gRGFya3N0YXIgTW9tb3QgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWxj b25AaXJpZGl1bWxpbnV4Lm9yZyI+ZmFsY29uQGlyaWRpdW1saW51eC5vcmc8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+bWFyZGkgMTcgZsOp dnJpZXIgMjAxNSAwMzozMzwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SG93IGFib3V0IGRpc2NhcmQsIDAxMDA6Oi82NCBhcyBwZXIgUkZDNjY2Nj8mbmJzcDsgVGhpcyBz ZWVtcyByYXRoZXIgbW9yZSBleHBsaWNpdCB0aGFuIHVzaW5nIGxvb3BiYWNrIGFzIGRpc2NhcmQu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5FViZndDsgdGhlbiB3aGF0IGFib3V0IG5v ZGVzIGhhdmluZyByb3V0ZXMgZm9yIDEwMDo6LzY0IHRvIC9kZXYvbnVsbD8gU3VjaCBhcyBwZWVy aW5nIHJvdXRlcnM/IDotKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LcOpcmljPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D108F7053D345evynckeciscocom_-- From nobody Tue Feb 17 06:33:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4D1A8996 for ; Tue, 17 Feb 2015 06:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVCM-yXZCqCq for ; Tue, 17 Feb 2015 06:33:31 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C001A8999 for ; Tue, 17 Feb 2015 06:33:31 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 17 Feb 2015 06:33:29 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 17 Feb 2015 06:33:29 -0800 From: Edward Lewis To: Falcon Darkstar Momot , Lorenzo Colitti Thread-Topic: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSUIEjnmiENkrAUKRqDIUqGF8vpzzV4+AgAAK6wCAACcnAIAAG7gAgADLi4CAADH9AIAAAkeAgAABEICAAADBgIAAANmAgAB1VQA= Date: Tue, 17 Feb 2015 14:33:29 +0000 Message-ID: References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> <54E2A879.2010201@iridiumlinux.org> In-Reply-To: <54E2A879.2010201@iridiumlinux.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3507010407_3241943" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:33:35 -0000 --B_3507010407_3241943 Content-type: multipart/alternative; boundary="B_3507010406_3248707" --B_3507010406_3248707 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/16/15, 21:33, "Falcon Darkstar Momot" wrote: > On 16/02/2015 19:30, Lorenzo Colitti wrote: >> On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot >> wrote: >>> The point is that they're addresses, not tags. Why would you allocate >>> addresses that have absolutely no purpose in relation to routing? >>=20 >> Pointing network at addresses inside 127.0.0.0/8 = is a >> very reliable way to cause said applications to fail fast without emitti= ng >> any packets. We don't have a way to do that in IPv6 except pointing them= at >> ::1. > How about discard, 0100::/64 as per RFC6666? This seems rather more expl= icit > than using loopback as discard. I=E2=80=99ve carved up this thread a bit because it contains a case of protocol engineering vs. protocol operations conflict. Yes, architecturally, I find the use of encoding messages in addresses rather appalling. What I called =E2=80=9Covert covert=E2=80=9D channels are cute trick= s that are just that, tricks. The more of these one tries to support in an architecture, the more difficult it is to fully exercise innovation in the architecture. (My background is tied to DNS, and this is pretty evident there.) OTOH, operationally, the Internet Protocol stack is a challenge to manage. The basic definition of Internet Protocols haven=E2=80=99t left a lot of hooks fo= r management and operations, having been born in the days before there was a lot of experience upon which to draw lessons and thus requirements. (Again= , very evident in DNS.) Operators have over time had to work with what they have, some of their choices present challenges to architectural models. I=E2=80=99d be out of my depth to rationalize why DNSBL=E2=80=99s do what they do. I c= an imagine a few reasons (or excuses depending on one=E2=80=99s perspective) and I a= m tempted to add some conjecture. But that would be wrong on the list. For controlled interruption, the uphill battle was passively coercing the installed base to be caught in the trap (as systems errantly sending unintended queries). The way to do this is to tap into the address record lookups. The backchannel is the operations use of logs - where the =E2=80=98connection to 127.0.53.53 failed=E2=80=99 would appear. Controlled interrupti= on includes other record types, including a TXT record which has a short message. The goal is two fold. One is to get a message back. Two is to have the node not leak anymore than it already has. (IMHO, the idea of wanting a loopback is a bit overreaching, the goal is not to have the node successfully send anything within itself.) Way back (1998+/-) when DNSSEC was being developed, I wanted to =E2=80=98get a message back=E2=80=99 and thought I=E2=80=99d be able to depend on SNMP - a nice architectural thing to, but that wasn=E2=80=99t achievable. (There=E2=80=99s no real g= ood back channel for DNSSEC detection of failures - it=E2=80=99s still actively discussed on mailing lists.) That=E2=80=99s just an example of the challenge of getting =E2=80=98a message back.=E2=80=99 (The analogy here is a bit weak, DNSSEC want= ed to reach the administrator of the node with the failure, for controlled interruption and DNSBL=E2=80=99s have different relationships.) The suggestion to use the discard block is an interesting one, but it doesn=E2=80=99t quite attain the goal of preventing leakage. The goal is to have the node not even generate the datagram, as opposed to having a recipient know to discard it. It=E2=80=99s not a bad suggestion, but the mere fact the act= ion is taken at the recipient means there=E2=80=99s that much leakage. (Of course, I don=E2=80=99t know what existing implementations would do with the address block I=E2=80=99ll propose to mean =E2=80=98don=E2=80=99t even make this datagram=E2=80=99.) --B_3507010406_3248707 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
On 2/16/15, 21:33, "Falcon Da= rkstar Momot" <falcon@iridiumlin= ux.org> wrote:

On 16/02/2015 19:30, Lorenzo Colitti wrote:<= br>
<= div class=3D"gmail_quote">On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Mo= mot <falcon@iridiumlinux.org> wrote:
The point is that they're addresses, not tags.&nb= sp; Why would you allocate addresses that have absolutely no purpose in rela= tion to routing?

Pointing network =  at addresses inside 127.0.0.0/8 is a very reliable way to cause said applications to fail f= ast without emitting any packets. We don't have a way to do that in IPv6 exc= ept pointing them at ::1.
How about disc= ard, 0100::/64 as per RFC6666?  This seems rather more explicit than us= ing loopback as discard.

= I’ve carved up this thread a bit because it contains a case of protoco= l engineering vs. protocol operations conflict.

Yes= , architecturally, I find the use of encoding messages in addresses rather a= ppalling.  What I called “overt covert” channels are cute t= ricks that are just that, tricks.  The more of these one tries to suppo= rt in an architecture, the more difficult it is to fully exercise innovation= in the architecture.  (My background is tied to DNS, and this is prett= y evident there.)

OTOH, operationally, the Internet= Protocol stack is a challenge to manage.  The basic definition of Inte= rnet Protocols haven’t left a lot of hooks for management and operatio= ns, having been born in the days before there was a lot of experience upon w= hich to draw lessons and thus requirements.  (Again, very evident in DN= S.)  Operators have over time had to work with what they have, some of = their choices present challenges to architectural models.

I’d be out of my depth to rationalize why DNSBL’s do what= they do.  I can imagine a few reasons (or excuses depending on oneR= 17;s perspective) and I am tempted to add some conjecture.  But that wo= uld be wrong on the list.

For controlled interrupti= on, the uphill battle was passively coercing the installed base to be caught= in the trap (as systems errantly sending unintended queries).  The way= to do this is to tap into the address record lookups.  The backchannel= is the operations use of logs - where the ‘connection to 127.0.53.53 = failed’ would appear.  Controlled interruption includes other rec= ord types, including a TXT record which has a short message.

<= /div>
The goal is two fold.  One is to get a message back.  Tw= o is to have the node not leak anymore than it already has.  (IMHO, the= idea of wanting a loopback is a bit overreaching, the goal is not to have t= he node successfully send anything within itself.)

= Way back (1998+/-) when DNSSEC was being developed, I wanted to ‘get a= message back’ and thought I’d be able to depend on SNMP - a nic= e architectural thing to, but that wasn’t achievable.  (ThereR= 17;s no real good back channel for DNSSEC detection of failures - it’s= still actively discussed on mailing lists.)  That’s just an exam= ple of the challenge of getting ‘a message back.’  (The ana= logy here is a bit weak, DNSSEC wanted to reach the administrator of the nod= e with the failure, for controlled interruption and DNSBL’s have diffe= rent relationships.)

The suggestion to use the disc= ard block is an interesting one, but it doesn’t quite attain the goal = of preventing leakage.  The goal is to have the node not even generate = the datagram, as opposed to having a recipient know to discard it.  It&= #8217;s not a bad suggestion, but the mere fact the action is taken at the r= ecipient means there’s that much leakage.  (Of course, I don̵= 7;t know what existing implementations would do with the address block IR= 17;ll propose to mean ‘don’t even make this datagram’.)

--B_3507010406_3248707-- --B_3507010407_3241943 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTsjuhwaXPIKaNxsZij TBYZ53ykFTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAy MTcxNDMzMjZaMA0GCSqGSIb3DQEBAQUABIIBALgC9qGni1Zq3qiaGaA8JoKXR56zVX1H1YeD WP0WN9cGfvlt5wVMjy2hbT8p36rnPNjKj7bcHO3rmwtjv+TwT4U99lBU9u7Gc0QukXnfyihs uJ5J85uO+UTzXuPszlvQ6Uu55kIWCm/RPDFGemiqJKk+G9PiflHaeyd9i1Adu8KyFM3mniU0 D7ux6GtfjnUyJCqRdiRTxwAcYnxLqfuOqEHCBxLh9RJuKB0LeA6NM7jTOAhyK5RtRjtoNRm5 8H02AUziiFf9PAMuOZgAY3SvQSbKCzff9G9WdeYtM0Ra2QcdsA7Pd3PELTnt7Sg33JsngAh/ AxGVhGGkoCPUkNX7tFM= --B_3507010407_3241943-- From nobody Tue Feb 17 06:55:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B581A89B9 for ; Tue, 17 Feb 2015 06:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1hQDZobD4BI for ; Tue, 17 Feb 2015 06:55:44 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D181A89A8 for ; Tue, 17 Feb 2015 06:55:43 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 17 Feb 2015 06:55:41 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 17 Feb 2015 06:55:41 -0800 From: Edward Lewis To: "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSjztJ6swZqCeP0+nVrp9tTPzApzz6nQYgACj0YCAAMIFAP//0RsA Date: Tue, 17 Feb 2015 14:55:41 +0000 Message-ID: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> <20150216232213.3123C29A61F1@rock.dv.isc.org> 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.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3507011738_3312294" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:55:46 -0000 --B_3507011738_3312294 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 2/17/15, 7:43, "Eric Vyncke (evyncke)" wrote: >Indeed. Clarity always wins, this is why I tend to like this I-D (albeit >it should be rewritten). > >BTW, the choice of ::/64 is probably not the best choice as it includes >the deprecated ::/96 for IPv4-compatible IPv6 address. I agree on both counts (needs rewriting and a different block is needed). What I=E2=80=99m thinking of writing is a draft to set aside 7F::/64 (because 0x7= F is 127 in decimal) and set: Source - - - - - - - - False Destination - - - - - False Forwardable - - - - - False Global - - - - - - - - False Reserved-by-Protocol - True These are the same values as for 127.0.0.0/8 in RFC 6890. The question remains for me, whether the Protocol should make this a loopback or refuse to create the datagram. By =E2=80=9Cmake this a loopback=E2=80=9D I mean specify that one of the addresses should by default be =E2=80=98ifconfiged=E2=80= =99 to the loopback interface and the -prefixlen 64 route be added too. --B_3507011738_3312294 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSXJdxChYYFa+we5I6r yGepNskbMTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAy MTcxNDU1MzhaMA0GCSqGSIb3DQEBAQUABIIBALp7TkSveeXDjEBlyyKfv6WZjr1+t7YBKtGd /3GlvDfMtFfDUnz0dNKJlUW4GDBWLwD9F9OXFZVEx8BkFRYKzcHxUptRMIdw5UZSUk+QJNCz ongctOTNnAiozL92C02ugeVTx1lNgvMg+LazFdR3hzpjeXe7viX9iYUGNh5SzPbhlYM2CmE7 Xlq+YdtfZUFv0/T61amuuI2iqMjtXnEpTG/aoHqHwX72Mn1AUaKUP70CtxugbLEOsYF47G1j I4UVoGzab8uefS3c4Yleb4KBQx5zkhwHnVVfvzP5LOOWuTBGpVVfZ3mdU3suG5VQrrd4uSzt xHvADtjAB/KgXmlzwiM= --B_3507011738_3312294-- From nobody Tue Feb 17 07:06:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD75C1A89B9 for ; Tue, 17 Feb 2015 07:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqjvxgXzgc-l for ; Tue, 17 Feb 2015 07:06:22 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 79BB81A89C5 for ; Tue, 17 Feb 2015 07:06:13 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 17 Feb 2015 09:06:11 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f169.google.com with SMTP id hl2so42745196igb.0 for ; Tue, 17 Feb 2015 07:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=WUW0kHC0FbBgA1piU084BZxDCb6WdXCnvY5CNhVoXrk=; b=l6saoq15p3tdh2usv/01OD64kZURbQ5A9egoVSPvWjt9jLu4cJY83lNFiH5LiV3Rht /HtypIpAkl0hTZ+uXgZn2oVLmYdpVJsC4W88772DmACCYeuzh1cTnol2uuUU1imfTTxe GmqdzaY0ZauvDHO/zyHH28U96DMbMSwHwqd/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=WUW0kHC0FbBgA1piU084BZxDCb6WdXCnvY5CNhVoXrk=; b=CNa/SFYO7WBQdaVPK85cbQ3am+9RhGXlUIYFL7bzJ1/fE9VrnrkEA1uQIyNkt9h/ca 52ybMZOzf9qSlu386I9xs5xuFCFnS+Sm2PpOXB/lEcKkgtDeJ1gilVcUUIehDtVEd9qk t0fOmuw20Jlk/lQ1ICcsGIllpVOO1tir1m3UjinmDAcKgN2akrDuSNLxYJ/tHHd1c2N8 Qvh6+8klm+W/FTvMla+nc34KvEZCG1TRKW2B6hS853qwRymSg5vEQbU9IofJ1vErM7wu Mr4DeguItib2bisyFxmTozXAQ0LaE2QuYGOOzlxG0qCtVU2JnmXbIgp5H/OZtmQiXQh6 bpYw== X-Gm-Message-State: ALoCoQlGoD/Cl9ghPuapVspwURAPBv64WpP5J4Z7RfURRb+rRDtd4Nz4Khdxv8ESBiWb087K7/rQQ4YKNX2uARN1wI1tlHqVJH3MBP2HyUwwBsHRrKrlhaeggD4A6Td3loAuBeNf5qHU X-Received: by 10.107.15.96 with SMTP id x93mr36505330ioi.75.1424185571422; Tue, 17 Feb 2015 07:06:11 -0800 (PST) X-Received: by 10.107.15.96 with SMTP id x93mr36505312ioi.75.1424185571236; Tue, 17 Feb 2015 07:06:11 -0800 (PST) Received: from [10.0.0.16] (c-75-73-121-154.hsd1.mn.comcast.net. [75.73.121.154]) by mx.google.com with ESMTPSA id b1sm10217744igl.7.2015.02.17.07.06.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 07:06:10 -0800 (PST) References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-01696D7B-2582-4E94-9678-AA56F9910BF4 Message-Id: <12A09714-DA9D-4A75-8281-6D79437D3155@umn.edu> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (12B466) From: David Farmer Date: Tue, 17 Feb 2015 09:06:08 -0600 To: David Conrad Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:06:24 -0000 --Apple-Mail-01696D7B-2582-4E94-9678-AA56F9910BF4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Feb 16, 2015, at 17:04, David Conrad wrote: >=20 > Mark, >=20 >> Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 sp= ecial address registry. It should be, >=20 > Could you explain why? >=20 > A number of RBLs use localhost addresses as flags to designate different f= orms of block lists (e.g., https://www.spamhaus.org/zen/). Do you believe th= ose should be registered in the IANA IPv4 special address registry? No, but nothing says I have to use any of those RBLs either, their use is co= mpletely voluntary, I locally choose to use those semantics or not. As long= as I don't query those RBLs I can ignore those semantics. And, there at le= ast is an informational RFC discussing this use too, RFC5782.=20 However, the very name given to the technique "controlled interruption", mak= es it quite clear there is nothing voluntary about it. ICANN is applying th= is semantics to me and everyone else. Now I'll admit, if I'm getting this I= chose to locally use a unassigned TLD. While I personally think that is an= extremely bad idea, nothing explicitly said it was invalid either. Person= ally I think the old saying, "two wrongs don't make a right", applies to thi= s one. But that's mostly spilt milk, maybe slightly sour spilt milk, but sp= ilt none the less. :) On the other hand, the way this address talked about on ICANN's website "Spe= cial IP Address (127.0.53.53)" at the very least sure sounds a lot like it b= elongs in the registry discussed above, even if it probably doesn't. Maybe a= disclaimer saying that is just a loopback address like any other in 127.0.0= .0/8 and that it may have other legitimate local uses too, would be in order= . =20 >> If ICANN want to do the above for IPv6, they should instead reserve a new= IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefi= x. >=20 > OK. However, for clarity, this isn't specifically about "Controlled Inter= ruption" or what ICANN "wants". It is about trying to have the same sort of f= acility that is available in IPv4 for IPv6. >=20 > Is there some reason I'm unaware of why IPv6 does not have a loopback pref= ix that allows a network of more than one host like IPv4? Yea, there is a reason, we couldn't develop consensus for it. And, from wha= t I've heard on this thread so far, I don't think that has really changed. H= owever, I personally support working on this, for the little that's probably= worth. As a tactical response, any reason you couldn't use the IPv6 address ::FFFF:= 7900:3535 (::FFFF:127.0.53.53) or generate a ULA prefix for IPv6 "controlled= interruption"? You've already spilt the milk anyway. :) > Thanks, > -drc > (ICANN CTO, but speaking only for myself) --=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 David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-01696D7B-2582-4E94-9678-AA56F9910BF4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Feb 16, 2015, at 17:04, David Conrad &= lt;drc@virtualized.org> wrote:=

Mark,

Note that the above 127.0.53.53 addr= ess is not reserved in IANA's IPv4 special address registry. It should be,

Could you explain why?
A number of RBLs use localhost addresses as flags t= o designate different forms of block lists (e.g., https://www.spamhaus.org/zen/). Do you believe those sho= uld be registered in the IANA IPv4 special address registry?

No, but nothing says I have to use any of t= hose RBLs either, their use is completely voluntary, I locally choose to use= those semantics or not.  As long as I don't query those RBLs I can ign= ore those semantics.  And, there at least is an informational RFC discu= ssing this use too, RFC5782. 

However, the ver= y name given to the technique "controlled interruption", makes it quite clear ther= e is nothing voluntary about it.  ICANN is applying this semantics to m= e and everyone else.  Now I'll admit, if I'm getting this I chose to lo= cally use a unassigned TLD.  While I personally think that is an extrem= ely bad idea, nothing explicitly said it was invalid either.   Personal= ly I think the old saying, "two wrongs don't make a right", applies to this o= ne.  But that= 's mostly spilt milk, maybe slightly sour spilt milk, but spilt none the les= s. :)

On the other hand, the way this addres= s talked about on ICANN's website "Special  Address (127.0.53.53)" at the very least sure sounds a lot= like it belongs in the registry discussed above, even if it probably doesn'= t.  Maybe a disclaimer saying that is just a loopback address like any o= ther in 127.0.0.0/8 and that it may have other legitimate local uses too, wo= uld be in order.   

If ICANN want to do the above for IPv6, the= y should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a= special purpose discard prefix.

OK.  However, for clarity, this isn't specifically about "Controlled= Interruption" or what ICANN "wants". It is about trying to have the same so= rt of facility that is available in IPv4 for IPv6.
Is there some reason I'm unaware of why IPv6 does not have a loopbac= k prefix that allows a network of more than one host like IPv4?

Yea, there is a reason, we couldn't develop c= onsensus for it.  And, from what I've heard on this thread so far, I do= n't think that has really changed.  However, I personally support worki= ng on this, for the little that's probably worth.

As a ta= ctical response, any reason you couldn't use the IPv6 address ::FFFF:7900:35= 35 (::FFFF:127.0.53.53) or generate a ULA prefix for IPv6 "controlled interruption"?  = ;You've already spilt the milk anyway. :)

Thanks,
-drc<= br>(ICANN CTO, but speaking only for myself)

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer             &nbs= p;            Email: farmer@umn.edu
Office of Information Technology
=
University of Minnesota    
2218 University Ave SE &= nbsp;       Phone: +1-612-626-0815
Minneapolis, MN 5= 5414-3029   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


= --Apple-Mail-01696D7B-2582-4E94-9678-AA56F9910BF4-- From nobody Tue Feb 17 08:44:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6511A700A for ; Tue, 17 Feb 2015 08:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJMM-Bg3mnIp for ; Tue, 17 Feb 2015 08:43:57 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE111A1EF3 for ; Tue, 17 Feb 2015 08:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3544; q=dns/txt; s=iport; t=1424191436; x=1425401036; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jYVvkiQv+Xt8ftykNKALhs4kj2O0UENzgltMEF4wjbw=; b=iVqQ2r4dodGG5tmie97zs4VRILJFNitEGruSNYJk4b/7CdiwPFAfya3y hSk1gWhdthmPEHltdxjleZ7AVYVpndfFdX3CPCO0qJPZEM79SioE8LJxk RrgfTCKQ1q6TXy2OmspGH2zvYcpu3DD5+4Mznu8Zyyt6JlSoAlOm4x9X5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBwBxb+NU/5xdJa1bgkNDUloEgn+9JDyBboVxAhx5QwEBAQEBAXyEDQEBBCNUAhACAQgEOwMCAgIwFBECBA4FiC8NuT+XcAEBAQEBAQEBAgEBAQEBAQEBAQEBF4sPhG4HgmgugRQFjziDV4VggVCRPSKCMoE8bwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208,217";a="124319589" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 17 Feb 2015 16:43:56 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1HGhugf025371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 16:43:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 10:43:55 -0600 From: "Carlos Pignataro (cpignata)" To: Lorenzo Colitti Thread-Topic: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSjzmjePUrZUB9Eib5lFaIWQ/lJzz6mWEgACCWYCAAQUyAA== Date: Tue, 17 Feb 2015 16:43:55 +0000 Message-ID: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> <20150216232213.3123C29A61F1@rock.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.61] Content-Type: multipart/alternative; boundary="_000_CD85542A7EC344719F49A38B6A17F67Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:43:58 -0000 --_000_CD85542A7EC344719F49A38B6A17F67Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMTYsIDIwMTUsIGF0IDg6MDkgUE0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bn b29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KVGhlIHZhbHVl IG9mIHRoZSBsb29wYmFjayBwcmVmaXggaXMgbm90IHRoYXQgaXQncyByb3V0ZWQgdG8gbG9vcGJh Y2suIEl0J3MgdGhhdCAqZXZlcnlib2R5IGtub3dzKiBpdCdzIGFsd2F5cyByb3V0ZWQgdG8gbG9v cGJhY2suDQoNCg0KKzEuDQoNCkJ5IHRoZSB3YXksIGFub3RoZXIgdXNlIGNhc2UgZm9yIGEgbG9v cGJhY2sgYmxvY2sgaXMgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQzOSNzZWN0 aW9uLTMuNC4yDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg== --_000_CD85542A7EC344719F49A38B6A17F67Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <63C9B7ADFB6809458F92FF9915CCBCFF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIg MTYsIDIwMTUsIGF0IDg6MDkgUE0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbSIgY2xhc3M9IiI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPlRoZSB2YWx1ZSBvZiB0aGUgbG9vcGJhY2sgcHJlZml4 IGlzIG5vdCB0aGF0IGl0J3Mgcm91dGVkIHRvIGxvb3BiYWNrLiBJdCdzIHRoYXQgKmV2ZXJ5Ym9k eSBrbm93cyogaXQncyBhbHdheXMgcm91dGVkIHRvIGxvb3BiYWNrLjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjwvc3Bhbj48YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+JiM0MzsxLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnkgdGhlIHdh eSwgYW5vdGhlciB1c2UgY2FzZSBmb3IgYSBsb29wYmFjayBibG9jayBpcyBpbiZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Mzkjc2VjdGlvbi0zLjQuMiIgY2xh c3M9IiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQzOSNzZWN0aW9uLTMuNC4yPC9h PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CD85542A7EC344719F49A38B6A17F67Cciscocom_-- From nobody Tue Feb 17 08:52:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D91A88E2 for ; Tue, 17 Feb 2015 08:51:59 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YooAVvGGYgsD for ; Tue, 17 Feb 2015 08:51:57 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDBC1A8AEE for ; Tue, 17 Feb 2015 08:51:53 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i13so27036762qae.10 for ; Tue, 17 Feb 2015 08:51:52 -0800 (PST) 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=mdXIHNs5ug9hMh4mSk+lJeBhXHzt5kWB3vWQBAV03YE=; b=QvKsAWfHzn9tPWQXSFA1Hd4+u7R9DHrh6PjN6+4d8kzt5BaURu3bzJKshANsTg59Mc w2aDBTt/sa6kF9atebwzNcpYoUPwcFzUMR3IB87FxWjYxsSyr33HCXHuXo2uNHXszhUX kRAG/sIty2ACNy/3cJvGNpxuGHuquqY8ulWsfTrnDo5yBq6SDqVNOGb9+PjwBScz+lMV Y5+YrzhLHa0YcUmkflCrqAQJ76imgjyIz/tZFXDiT8+yVL2LSN3hz2FBN4c93YjDWUSt WJzxY+fctgOTcKT9USKPYagMki1254iaAQqNfWt3MSBVspQ0fZziIEE0wuRDoQuAWT2N N6og== MIME-Version: 1.0 X-Received: by 10.140.38.197 with SMTP id t63mr422755qgt.61.1424191912243; Tue, 17 Feb 2015 08:51:52 -0800 (PST) Received: by 10.140.84.133 with HTTP; Tue, 17 Feb 2015 08:51:52 -0800 (PST) In-Reply-To: References: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Feb 2015 17:51:52 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Erik Kline Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:52:00 -0000 On 2/17/15, Erik Kline wrote: > I was wondering about maybe an update/doc that merged this use case? > > I was in favor of your loopback prefix, as I recall (it would be > especially handy if any application should implicitly bind to > 1::${RAND96} /without/ any special permissions), but I can't recall > the opposition at the time. > > /me re-reads/ > > Ah, yeah it turns out the use cases I wanted it for are exactly the > ones that were opposed by others at the time (the implicit delivery of > all packets to destinations in this prefix is /technically/ new > behaviour). Sad panda. Would borrowing a /64 out of fe80::/10 work ? fe80:dead:dead:dead::/64 ? Given the special status of fe80::/10 at least there is a high chance that the packets would not randomly leak into the wire from the "legacy" hosts. And most of the unmodified stacks will even reject attempts to assign an address from such prefix, which will take care of potential overlap. --a > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Feb 17 09:27:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF73D1A1BBB for ; Tue, 17 Feb 2015 09:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9NLBRrhLxBZ for ; Tue, 17 Feb 2015 09:27:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CD81A1B56 for ; Tue, 17 Feb 2015 09:27:02 -0800 (PST) Received: from mb-aye.local (64.125.197.170.IPYX-102339-ZYO.zip.zayo.com [64.125.197.170] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1HHOxNR080091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Feb 2015 17:24:59 GMT (envelope-from joelja@bogus.com) Message-ID: <54E37964.1090705@bogus.com> Date: Tue, 17 Feb 2015 09:24:52 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Edward Lewis , "v6ops@ietf.org" References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> <20150216232213.3123C29A61F1@rock.dv.isc.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P5U3AMlhOIElXug6jn6hIQs7Ti4CuLJ3f" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:27:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P5U3AMlhOIElXug6jn6hIQs7Ti4CuLJ3f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not going to comment on the merits of this spefic proposal at this time. one thing catches my however which is that mappings between v4 and v6 addresses used for the same purpose make very a little sense 7f:: doesn't have a meaning becasue of some magical congruence with 127 decimal and makes no particular sense in the absence of v4. although this draft contends with a particular aspect of mapping between v4 and v6 and is sadly expired I think it's instructive as to intuiting meaning from equivalence: https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 Beyond that in general we should leave the actual assignment of special use-prefixes to iana as stewards, we request that they be allocated. they assign them. On 2/17/15 6:55 AM, Edward Lewis wrote: > On 2/17/15, 7:43, "Eric Vyncke (evyncke)" wrote: >=20 >> Indeed. Clarity always wins, this is why I tend to like this I-D (albe= it >> it should be rewritten). >> >> BTW, the choice of ::/64 is probably not the best choice as it include= s >> the deprecated ::/96 for IPv4-compatible IPv6 address. >=20 > I agree on both counts (needs rewriting and a different block is needed= ). >=20 > What I=92m thinking of writing is a draft to set aside 7F::/64 (because= 0x7F > is 127 in decimal) and set: >=20 > Source - - - - - - - - False > Destination - - - - - False > Forwardable - - - - - False > Global - - - - - - - - False > Reserved-by-Protocol - True >=20 >=20 > These are the same values as for 127.0.0.0/8 in RFC 6890. >=20 > The question remains for me, whether the Protocol should make this a > loopback or refuse to create the datagram. By =93make this a loopback=94= I > mean specify that one of the addresses should by default be =91ifconfig= ed=92 > to the loopback interface and the -prefixlen 64 route be added too. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --P5U3AMlhOIElXug6jn6hIQs7Ti4CuLJ3f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTjeWUACgkQ8AA1q7Z/VrI6HACeN6qyIKubCbmxWxFd6mSJDk07 ptIAn0TLuzmb1x8f3lrAlhvw/mgKRaFX =TlHM -----END PGP SIGNATURE----- --P5U3AMlhOIElXug6jn6hIQs7Ti4CuLJ3f-- From nobody Tue Feb 17 16:33:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB91A8867 for ; Tue, 17 Feb 2015 16:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPvVuzhjymWf for ; Tue, 17 Feb 2015 16:33:16 -0800 (PST) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2381A1B0A for ; Tue, 17 Feb 2015 16:33:16 -0800 (PST) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id E725613F41FD; Tue, 17 Feb 2015 17:33:15 -0700 (MST) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 3F85C13F41F8 for ; Tue, 17 Feb 2015 17:33:14 -0700 (MST) Message-ID: <54E3DDC7.7070806@iridiumlinux.org> Date: Tue, 17 Feb 2015 17:33:11 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> <54E2A879.2010201@iridiumlinux.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050309090707010402080901" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:33:22 -0000 This is a multi-part message in MIME format. --------------050309090707010402080901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =20 On 17/02/2015 07:33, Edward Lewis wrote: > On 2/16/15, 21:33, "Falcon Darkstar Momot" > wrote: > > On 16/02/2015 19:30, Lorenzo Colitti wrote: >> On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot > wrote: >> >> The point is that they're addresses, not tags. Why would you allocate addresses that have absolutely no purpose in relation to routing= ? >> >> >> Pointing network at addresses inside 127.0.0.0/8 is a very reliable way to cause said applications to fail fast without emitting any packets. We don't have a way to do that in IPv6 except pointing them at ::1. > How about discard, 0100::/64 as per RFC6666? This seems rather more explicit than using loopback as discard. > > > I=E2=80=99ve carved up this thread a bit because it contains a case of protocol engineering vs. protocol operations conflict. > > Yes, architecturally, I find the use of encoding messages in addresses rather appalling. What I called =E2=80=9Covert covert=E2=80=9D channels = are cute tricks that are just that, tricks. The more of these one tries to support in an architecture, the more difficult it is to fully exercise innovation in the architecture. (My background is tied to DNS, and this is pretty evident there.) > > OTOH, operationally, the Internet Protocol stack is a challenge to manage. The basic definition of Internet Protocols haven=E2=80=99t left = a lot of hooks for management and operations, having been born in the days before there was a lot of experience upon which to draw lessons and thus requirements. (Again, very evident in DNS.) Operators have over time had to work with what they have, some of their choices present challenges to architectural models. > > I=E2=80=99d be out of my depth to rationalize why DNSBL=E2=80=99s do wh= at they do. I can imagine a few reasons (or excuses depending on one=E2=80=99s perspect= ive) and I am tempted to add some conjecture. But that would be wrong on the list. > > For controlled interruption, the uphill battle was passively coercing the installed base to be caught in the trap (as systems errantly sending unintended queries). The way to do this is to tap into the address record lookups. The backchannel is the operations use of logs - where the =E2=80=98connection to 127.0.53.53 failed=E2=80=99 would appear. Con= trolled interruption includes other record types, including a TXT record which has a short message. > > The goal is two fold. One is to get a message back. Two is to have the node not leak anymore than it already has. (IMHO, the idea of wanting a loopback is a bit overreaching, the goal is not to have the node successfully send anything within itself.) > > Way back (1998+/-) when DNSSEC was being developed, I wanted to =E2=80=98= get a message back=E2=80=99 and thought I=E2=80=99d be able to depend on SNMP -= a nice architectural thing to, but that wasn=E2=80=99t achievable. (There=E2=80= =99s no real good back channel for DNSSEC detection of failures - it=E2=80=99s still a= ctively discussed on mailing lists.) That=E2=80=99s just an example of the chall= enge of getting =E2=80=98a message back.=E2=80=99 (The analogy here is a bit wea= k, DNSSEC wanted to reach the administrator of the node with the failure, for controlled interruption and DNSBL=E2=80=99s have different relationships.= ) > > The suggestion to use the discard block is an interesting one, but it doesn=E2=80=99t quite attain the goal of preventing leakage. The goal is= to have the node not even generate the datagram, as opposed to having a recipient know to discard it. It=E2=80=99s not a bad suggestion, but the= mere fact the action is taken at the recipient means there=E2=80=99s that much= leakage. (Of course, I don=E2=80=99t know what existing implementations = would do with the address block I=E2=80=99ll propose to mean =E2=80=98don=E2=80= =99t even make this datagram=E2=80=99.) > While it is possible to envision a DNSBL being queried for relay addresses to use internally to a host as part of mail routing, what I understand is that the DNSBL is not necessarily dispositive (in spamassassin it certainly isn't), and so the MTA or its spam filter makes the query but processes the returned A record as a tag in nearly every case. Certainly, using a DNSBL to get a next hop is operationally disadvantageous if the DNSBL is not working correctly, and could even be used to man-in-the-middle mails. So, while someone might be using DNSBL queries to route mail, it doesn't seem like either the normal or correct thing to do. It would be interesting to hear from a DNSBL operator on this topic, if for no other reason than to ask why they do as they do with 127.0.0.0/8 addresses. This quandary is not illuminated in RFC5782, the DNSBL RFC. However, we do there specify (perhaps inelegantly) in section 2.4 that DNSBLs are to return A records for queries against IPv6 addresses just as they would for IPv4. The TXT record is used only for a comment (perhaps this is why it is not used as a tag). Why a new RRtype is not requested I could not say. On a different topic, I may have misspoke when recommending ipv6 discard for this purpose - since it is intended for RTBH, it doesn't prevent leakage at all (quite the opposite). Nor does link-local, since the traffic may be leaked across a link. The documentation prefix would, but it is not appropriate to apply non-documentation semantics to documentation addresses. Loopback does not prevent leakage. A local listener could still receive the traffic, and that local process may be running with whatever credentials. It is as weak for this purpose as link-local. ::/128 would definitely prevent leakage. This is only one address, and it does have the meaning "unspecified" if memory serves, which seems exactly what one might want if they would rather the packet not even be generated. If someone needs a set of addresses, we'd need to assign a prefix (perhaps 100:1::/64?) for that, since nothing else fills that role, but it's difficult to find a use case that isn't architecturally abhorrent.=20 Then again, if that is what it takes to prevent people from using other things (such as loopback) for this purpose, that's exactly what we should do. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) =20 iQIcBAEBAgAGBQJU493GAAoJEM2g2ken2JPs5pEQAJdze1aEKvdPJC95lCYAZfZl 24uvM/6aAsX86A14vmPR59OIhH6d8B+732QSOBGrITfEDGMRrcMHDNUXaPqK0S3O GnbbHnaHB+dy4ZI/am24SFnBGpj55Vw+NmB2akVmpIJQcYuP5aMCURWpSVv3ogny 78zutlmXODGcZ785YKkebs86uTMWK0AE12Gil/PCJNAKG8lbx///+RO1SZOX9+wS nzkrnHBpvOy3rk56ppBa9xWBnnoWMj/qMmFxTRT1Z75VAWgO489QECSOI8uSJ7JO MndJ4Dq4dVTyeEBD+ppHmMfHj4Sv9NlWoodxmPphjEWhDjxCYQMan2OuF/Gt1LEd YEdDRPeAd945XHfcb/UZCfIJp+e8+zBEGr3l5qd25knIVY9G1eCAS9DrSixdVqO/ RL9L3nqzMFlTBAwcObHDh4hEafk/lroD+vdV8pEeOTFjUlqlQp2gAteSKisspYIQ uEJvNsVaPnuQFxw0mtOQ5qii8R6/qRWCQri7MPnHLL09cNE+CMxHvYn8puq7C9XE XMAfkrR6oPPqxUt0DqjAMu3A1bNzPNgB9bjbaE6bJGwG39jnUovET/vzyaFV6Z4G wOXs/6oWJcvX3XXPHMPiXR/PqCaYPqukNV5ygyIrjphRNEx4SUyXGwoK2JQzC1xb Sv7FcDFH9flG1tTb9VGc =3DNqlh -----END PGP SIGNATURE----- --------------050309090707010402080901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 17/02/2015 07:33, Edward Lewis wrote:
> On 2/16/15, 21:33, "Falcon Darkstar Momot" <falcon@iridiumlinux.org <mailto:falcon@iridiumlinux.org>> wrote:
>
>     On 16/02/2015 19:30, Lorenzo Colitti wrote:
>>     On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot <falcon@iridiumlinux.org <mailto:falcon@iridiumlinux.org>> wrote:
>>
>>         The point is that they're addresses, not tags.  Why would you allocate addresses that have absolutely no purpose in relation to routing?
>>
>>
>>     Pointing network  at addresses inside 127.0.0.0/8 <http://127.0.0.0/8> is a very reliable way to cause said applications to fail fast without emitting any packets. We don't have a way to do that in IPv6 except pointing them at ::1.
>     How about discard, 0100::/64 as per RFC6666?  This seems rather more explicit than using loopback as discard.
>
>
> I’ve carved up this thread a bit because it contains a case of protocol engineering vs. protocol operations conflict.
>
> Yes, architecturally, I find the use of encoding messages in addresses rather appalling.  What I called “overt covert†channels are cute tricks that are just that, tricks.  The more of these one tries to support in an architecture, the more difficult it is to fully exercise innovation in the architecture.  (My background is tied to DNS, and this is pretty evident there.)
>
> OTOH, operationally, the Internet Protocol stack is a challenge to manage.  The basic definition of Internet Protocols haven’t left a lot of hooks for management and operations, having been born in the days before there was a lot of experience upon which to draw lessons and thus requirements.  (Again, very evident in DNS.)  Operators have over time had to work with what they have, some of their choices present challenges to architectural models.
>
> I’d be out of my depth to rationalize why DNSBL’s do what they do.  I can imagine a few reasons (or excuses depending on one’s perspective) and I am tempted to add some conjecture.  But that would be wrong on the list.
>
> For controlled interruption, the uphill battle was passively coercing the installed base to be caught in the trap (as systems errantly sending unintended queries).  The way to do this is to tap into the address record lookups.  The backchannel is the operations use of logs - where the ‘connection to 127.0.53.53 failed’ would appear.  Controlled interruption includes other record types, including a TXT record which has a short message.
>
> The goal is two fold.  One is to get a message back.  Two is to have the node not leak anymore than it already has.  (IMHO, the idea of wanting a loopback is a bit overreaching, the goal is not to have the node successfully send anything within itself.)
>
> Way back (1998+/-) when DNSSEC was being developed, I wanted to ‘get a message back’ and thought I’d be able to depend on SNMP - a nice architectural thing to, but that wasn’t achievable.  (There’s no real good back channel for DNSSEC detection of failures - it’s still actively discussed on mailing lists.)  That’s just an example of the challenge of getting ‘a message back.’  (The analogy here is a bit weak, DNSSEC wanted to reach the administrator of the node with the failure, for controlled interruption and DNSBL’s have different relationships.)
>
> The suggestion to use the discard block is an interesting one, but it doesn’t quite attain the goal of preventing leakage.  The goal is to have the node not even generate the datagram, as opposed to having a recipient know to discard it.  It’s not a bad suggestion, but the mere fact the action is taken at the recipient means there’s that much leakage.  (Of course, I don’t know what existing implementations would do with the address block I’ll propose to mean ‘don’t even make this datagram’.)
>

While it is possible to envision a DNSBL being queried for relay addresses to use internally to a host as part of mail routing, what I understand is that the DNSBL is not necessarily dispositive (in spamassassin it certainly isn't), and so the MTA or its spam filter makes the query but processes the returned A record as a tag in nearly every case.  Certainly, using a DNSBL to get a next hop is operationally disadvantageous if the DNSBL is not working correctly, and could even be used to man-in-the-middle mails.

So, while someone might be using DNSBL queries to route mail, it doesn't seem like either the normal or correct thing to do.  It would be interesting to hear from a DNSBL operator on this topic, if for no other reason than to ask why they do as they do with 127.0.0.0/8 addresses.

This quandary is not illuminated in RFC5782, the DNSBL RFC.  However, we do there specify (perhaps inelegantly) in section 2.4 that DNSBLs are to return A records for queries against IPv6 addresses just as they would for IPv4.  The TXT record is used only for a comment (perhaps this is why it is not used as a tag).  Why a new RRtype is not requested I could not say.

On a different topic, I may have misspoke when recommending ipv6 discard for this purpose - since it is intended for RTBH, it doesn't prevent leakage at all (quite the opposite).  Nor does link-local, since the traffic may be leaked across a link.  The documentation prefix would, but it is not appropriate to apply non-documentation semantics to documentation addresses.

Loopback does not prevent leakage.  A local listener could still receive the traffic, and that local process may be running with whatever credentials.  It is as weak for this purpose as link-local.

::/128 would definitely prevent leakage.  This is only one address, and it does have the meaning "unspecified" if memory serves, which seems exactly what one might want if they would rather the packet not even be generated.

If someone needs a set of addresses, we'd need to assign a prefix (perhaps 100:1::/64?) for that, since nothing else fills that role, but it's difficult to find a use case that isn't architecturally abhorrent.  Then again, if that is what it takes to prevent people from using other things (such as loopback) for this purpose, that's exactly what we should do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
 
iQIcBAEBAgAGBQJU493GAAoJEM2g2ken2JPs5pEQAJdze1aEKvdPJC95lCYAZfZl
24uvM/6aAsX86A14vmPR59OIhH6d8B+732QSOBGrITfEDGMRrcMHDNUXaPqK0S3O
GnbbHnaHB+dy4ZI/am24SFnBGpj55Vw+NmB2akVmpIJQcYuP5aMCURWpSVv3ogny
78zutlmXODGcZ785YKkebs86uTMWK0AE12Gil/PCJNAKG8lbx///+RO1SZOX9+wS
nzkrnHBpvOy3rk56ppBa9xWBnnoWMj/qMmFxTRT1Z75VAWgO489QECSOI8uSJ7JO
MndJ4Dq4dVTyeEBD+ppHmMfHj4Sv9NlWoodxmPphjEWhDjxCYQMan2OuF/Gt1LEd
YEdDRPeAd945XHfcb/UZCfIJp+e8+zBEGr3l5qd25knIVY9G1eCAS9DrSixdVqO/
RL9L3nqzMFlTBAwcObHDh4hEafk/lroD+vdV8pEeOTFjUlqlQp2gAteSKisspYIQ
uEJvNsVaPnuQFxw0mtOQ5qii8R6/qRWCQri7MPnHLL09cNE+CMxHvYn8puq7C9XE
XMAfkrR6oPPqxUt0DqjAMu3A1bNzPNgB9bjbaE6bJGwG39jnUovET/vzyaFV6Z4G
wOXs/6oWJcvX3XXPHMPiXR/PqCaYPqukNV5ygyIrjphRNEx4SUyXGwoK2JQzC1xb
Sv7FcDFH9flG1tTb9VGc
=Nqlh
-----END PGP SIGNATURE-----

--------------050309090707010402080901-- From nobody Tue Feb 17 16:49:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162C61A8846 for ; Tue, 17 Feb 2015 16:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.135 X-Spam-Level: **** X-Spam-Status: No, score=4.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICNuyegYzFmT for ; Tue, 17 Feb 2015 16:49:52 -0800 (PST) Received: from nm41-vm10.bullet.mail.gq1.yahoo.com (nm41-vm10.bullet.mail.gq1.yahoo.com [67.195.87.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F64C1A90E5 for ; Tue, 17 Feb 2015 16:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424220590; bh=IGUeHcjEw1ofNj5q0BGSgnU9iu9iTgdfwrkgiPL6Y2E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JTFBVBnBSvsLXw+x/Lop3gyJUtChwNbD/YimhV18Pue2aCW81XdB/FHUrgMDapdqmTGH8REFP3ya0gJ7djy3UUXsohLZikUMhyJDp+PcTYFsINY3RD2JMll0rjBPI7QSNUIj9002cO7u6gJ0AdTyvz99gNjjp4AnzgM0CveSS4PY4whGCCNrSqBmzlmgEanSn/qCfsDeKgjeQU84Ew8ag06Y/DgOpdZf0IArtujOLTKkEUORt+2W7RU6Jlmk0G2dvnZEMfJM5fB4u+LJmHJStgvnhvs/T1BDokWdS7lnL/QL9NsLLyGeag6Gak00efyGZ9TcTGDCLzbSCPIxE2eU5Q== Received: from [127.0.0.1] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:49:50 -0000 Received: from [216.39.60.181] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:46:51 -0000 Received: from [66.196.81.170] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000 Received: from [98.139.212.199] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 642602.55517.bm@omp1008.mail.bf1.yahoo.com X-YMail-OSG: 2VgUp.gVM1mbFGZp5aC2svUOM1ZxIDhoS694gmK6WBsyaEp7Qh1p848ERTHvY9z N01YtXXjxPNH7LmZWmamVfFgalO7vXQynoJ_fDk3gudOv8VPgEc6KI3jci40uo5a5IVZIaJunvuA fLPu_P2U1.VGO.h1qkO5QHWBTv5eQhu7c0Jx2mLObxbG0xVTx2tr8kNlfClfKumpAmcfi25rd3rW ShGWNLb3Ib.xK_i0BnZwfbxTytwsN6g5fgS1qSBJZgKgX7BiChJAGbtfuGC8XFm5rdpquvQobFJs nHDbWepm38s5ocyl7LgLrhaa8GFCSHBWCeBafxTsAUGI.CZ.QDesk6C_rfbJ3rIpvckOiEfIQqfw I5eeY5u_o.t14y4dV.g3x8Ex05aQ4YkGLe31ylgy_qoPiFzuw6FFbqeN8ej6WNKmWtC8BJhLiQd2 oI9HG_2MRP3TgtwcW5SIupTQa5WvI7z8IX4GC1fQ7KcqJxGPgtRa..eo8p7I0czRhnGrPSReZS4a VpB6NkS8IITiMpkbjveAUsWBEhp7XVcLIfpzgpvdXTouY4QmzRljLTYkbsMU7HQwnrPXXtJ4K21Z 8iZ50Wajo_lomRKqfEXYVtAU.j4_REwNSTQWw4A3sKlYkRqCxQSGj62pouebKJdroiSAKpLiQ8IF dyYAojL9AjH_IvOApd9HDgtydiOcBaS4nJimH6SBXuvErl55Ie5yte.J26uXBvmrB Received: by 76.13.26.137; Wed, 18 Feb 2015 00:46:50 +0000 Date: Wed, 18 Feb 2015 00:46:22 +0000 (UTC) From: Mark ZZZ Smith To: Mark Andrews Message-ID: <390182967.10574.1424220382446.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150217032029.87BA329A857B@rock.dv.isc.org> References: <20150217032029.87BA329A857B@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:49:55 -0000 ----- Original Message ----- From: Mark Andrews To: Mark ZZZ Smith Cc: David Conrad ; "v6ops@ietf.org" Sent: Tuesday, 17 February 2015, 14:20 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt In message <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com>, Ma rk ZZZ Smith writes: > > > > > ________________________________ > From: Mark Andrews > To: Mark ZZZ Smith > Cc: David Conrad ; "v6ops@ietf.org" > Sent: Tuesday, 17 February 2015, 12:23 > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p > refix-00.txt > > > > The fundemental reason for 127.0.0.0/8 was to give each node a > addresses block they could use. 127.0.0.1 evolved as the "standard" > loopback address over time. > > / Actually, 4.2BSD made added the '.1' as the default address, as the '0' the > y'd originally chosen was the BSD broadcast address: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_lo > op.c Yes, BSD squatted on the address. I was well aware of the history. > For the most part no one uses the rest > of 127.0.0.0/8 but it is useful to have available. > > / I'm not sure I completely agree with the idea, however the NTP reference cl > ock drivers use 127.127/16 addresses to make them available to the ntp daemon > . I think this use is a bit different to what ICANN specified, as those addre > sses only have local significance on the host that both the ntp daemon and th > e reference clocks are attached to. Outside of that host they're unreachable > and have no meaning. Fortunately with millions of other addresses within 127/ > 8 there are plenty of others to use for other purposes on the host. Yes, they have squatted on these address for internal uses. The only reason this doesn't cause issues is that for the most part 127.0.0.0/8 is not used. / How do you know "the most part 127.0.0.0/8 is not used"? I've used it for or seen it used for quite a number of purposes over the last 20 years. I wouldn't invest the 10s and perhaps more than 100 hours in writing an ID in my own time if I didn't see and hadn't seen a lot of value in the large address space that 127/8 provides that ::1/128 doesn't. > That said any > use of the rest of 127.0.0.0/8 has to be negotiated between the > users. You can't just grab 127.0.0.2 and hope that no one else is > using it for IP traffic. > > > / I'm a bit confused by this. 127.0.0.2 traffic should not be leaking outside > of the host, as that is contrary to RFC990/RFC1122 rules. So the only risk o > f collision is two users on the same host. That is of course possible, howeve > r the great thing is that there are millions of other loopback addresses avai > lable on the host that the users can choose from, and the ones in use can be > viewed with 'netstat -a -4 -n' or similar. Hosts have become pretty much sing > le user too these days. I have two different applications which have hard coded 127.0.0.2 port 2356 as the way to connect to them. Which one gets to use 127.0.0.2 port 2356? As I said the use of the rest of 127.0.0.0/8 needs to be negotiated. No one and "rights" on any part of it. / So I have a number of responses/questions about this: - Did you make up this example, because in my experience, it is more common for applications to at least allow specifying IP addresses to bind to if they don't allow changing port numbers. - Clearly the two application writers didn't negotiate with anybody about their use of 127.0.0.2 port 2356, because otherwise they wouldn't collide. - IOW, "As I said the use of the rest of 127.0.0.0/8 needs to be negotiated." is not true, proven by your own example. - 127/8 address space is local to the host - it has a host local scope. Addressing scopes to me define domains of expected uniqueness, domains of administration and domains of reachability. If each host has its own 127/8 address space, then the only domains of uniqueness, administration and reachability for 127/8 addresses is the local host. Trying to place global significance on values within 127, as ICANN have attempted to do with 127.0.53.53, violates the host local scope of 127/8. > / ::1/128 is pretty much single user use. > > In IPv6 we had both link local and site local addresses from the > get go. These gave the operator addresses they could use. They > were also slightly more complicated than a GUA as you needed to > specify scope. We now have ULA addresses which gets rid of the > need to specify scope. Just like with 127.0.0.2 you need to negotiate > the use of a address. > > Reserving a new block of addressing in IPv6 will not stop the need > to negotiate address use. > > If you need truly automatic assignment you need to go to IANA or a > RIR (e.g. ARIN and 100.64/10) and request a block for a specific > > purpose. There is no other way to do truly automatic. > > / From my draft: > > "9. IANA Considerations > > IANA is requested to allocate 0001::/32 from within 0000::/8 of the > Internet Protocol Version 6 Address Space, for use as a larger > loopback prefix for IPv6, as detailed in this memo, and to record it > in the [IANA-IPV6REG]." And 1::1 will have what automatic meaning? Which application get *exclusive* use of 1::1? / None, just like no application gets exclusive use of 127.0.0.1. 1::/32 would be scratch space. / Exactly. Another way to describe the difference between 127/8 and ::1/128 is that 127/8 provides millions of host local 'scratch space' addresses, where as ::1/128 provides none. 1::/32 provides plenty of scratch space of 64 IIDs, /64s and larger aggregates of /64s e.g., multiple /48s. We already have enough mechanisms to create scatch space. If you need a /32 then you can get one from ULA space. There are 16M /32's ULA blocks for local assignment. / You don't seem to understand the concept of ease of use due to ubiquity, despite repeated statements by myself and others that that would be the benefit of having a IANA defined larger loopback prefix for IPv6. If a application needs reserved address space that will never collide with anyone else then the vendor should request it from the RIR's for the use of the application. Even if 1::/32 is allocated it is useless for that purpose. / Quite frankly, I'm starting to think you haven't read the draft. If you have, you've missed literally the first sentence of the abstract, "During the *development and testing* of a network application, it can be useful to run multiple instances of the application using the same transport layer protocol port on the same development host, while also having network access to the application instances limited to the local host." Mark > Mark > > In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, M > ar > k ZZZ Smith writes: > > So the fundamental problem is 'configured like this'. It's a manual operati > on > > to generate and apply a ULA. ULAs on loopbacks aren't going to well known > or > > ubiquitous. > > > > If you want something to be used you need to make it easy, and the best way > t > > o make something easy is to make it automatic. > > > > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or > wo > > uld be automatically configured by the OS, with operator intervention. It's > a > > lways there, and always available to use. The 4.1c/2.9BSD people though the > re > > was value in automatic configuration of the loopback address on a loopback > i > > nterface, way back in 1982/1983: > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop > .c > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop. > c > > > > > > > > ----- Original Message ----- > > From: Mark Andrews > > To: David Conrad > > Cc: Mark ZZZ Smith ; "v6ops@ietf.org" f. > > org> > > Sent: Tuesday, 17 February 2015, 10:22 > > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback > -p > > refix-00.txt > > > > > > We don't need *more* reserved address for this. This is from my > > laptop and it has been configured like this for years. > > > > Yes, I have a ULA site on my loopback interface. If your loopback > > interface does not support this it is broken. > > > > > > Mark > > > > lo0: flags=8049 mtu 16384 > > options=3 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > > inet 127.0.0.1 netmask 0xff000000 > > inet6 ::1 prefixlen 128 > > inet 10.53.0.1 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::1 prefixlen 64 > > inet 10.53.0.2 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::2 prefixlen 64 > > inet 10.53.0.3 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::3 prefixlen 64 > > inet 10.53.0.4 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::4 prefixlen 64 > > inet 10.53.0.5 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::5 prefixlen 64 > > inet 10.53.0.6 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::6 prefixlen 64 > > inet 10.53.0.7 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > > inet 10.53.0.8 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::8 prefixlen 64 > > inet 10.53.0.9 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::9 prefixlen 64 > > inet 10.53.0.10 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::10 prefixlen 64 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 17 17:07:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884801A8BB0 for ; Tue, 17 Feb 2015 17:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.835 X-Spam-Level: X-Spam-Status: No, score=0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFOzf0A73R8w for ; Tue, 17 Feb 2015 17:07:12 -0800 (PST) Received: from nm47-vm2.bullet.mail.gq1.yahoo.com (nm47-vm2.bullet.mail.gq1.yahoo.com [67.195.87.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84B21A8AEA for ; Tue, 17 Feb 2015 17:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424221627; bh=7+o0r0GVYyXqKS6LQI1yOopWAUc+OS9WoGHlFqLP/Vc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SXPUhpaJ7MDgNz5ajyOSTyJc6FTH/XTjBhxkkFbzHHhhbH9Dxp5KontVoV2c5EthAUo9D1y+ielT3NTY0W8Nx6pIWMzdQW+FHBBKAkXi4eoc5ZsvQfcOMZHXLHzubiL4B2+xi+kjbnB9h8XJ0NYK1PpqFc3EfWARWA7mx6SI6CbBSIWw4WFX5NHsR5t8ggJrgre1u98E1hHScStshq1NmCt+a4OiViBMN8qXKociSSCfuyrdJb8tYr7IPyVciD1QPEt+tSmveUJEF+ptDeB1IXWKgE5Pjok1I4yADY1BXv1Ad+l6BsSEd2V5IqmullehNxPavJLo1bAeHFwnhlvkhw== Received: from [127.0.0.1] by nm47.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 01:07:07 -0000 Received: from [98.137.12.61] by nm47.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 01:04:12 -0000 Received: from [98.139.215.140] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 01:04:12 -0000 Received: from [98.139.212.245] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 01:04:12 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 01:04:12 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 68981.94809.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: k5PybxYVM1nM62jLUFHknToazE2UTnTH_dNAClR4MqkoD6R65P8EwtadDo7QZ2s vRoOGWWL1sXtEDK4Eg3YNgU5BDimh8EtiUPf7Z9_vJtT.bgEGy_1SWpjeGGQ6CCqVZa8SAar4H.P cirfuVNdcVW92JukTnIp8rtFEpVHSdccHxNzhVpwGB7i6eV4635LIHxj.21O.wZwMwA1MBV.5oYq IH9pe88kY63On0U2BhZTJ6FPQ3yWiiJE3U_IouQqsfsAGLPJvzycbKsalq6T0D4.9NMS5lJ0iy5M fC9n5bftaAIqTcezpKAx6HRf7d8_VBirk16eoDWlRc.ym9GdBNLcAbHFoVddMoLkMpCjLR_2fgH2 OW.1dtrRVmanZk28rpSDyswsHWckqH4o3AYsAbMtpoeWueKL9k2Mjp6W9IeUCpyQaeoARtNrrVtX hEM_Y45KJb5wz94GKM4YnI7bZTAsqu.EBOpzz3GjsCY9HuAMgEaZcFshNTXfO7PQNoD9kx6aQJaK H1c19pzdgQXZ7CkSGZMP4O8YzrVLeMd19ObqJsOfvK_7VO2XwO7k72QhQWwDyf4fZHVveIIH8tdG KmIGhkKB7RC9fnbw8tJeVJ00- Received: by 66.196.80.117; Wed, 18 Feb 2015 01:04:11 +0000 Date: Wed, 18 Feb 2015 01:04:10 +0000 (UTC) From: Mark ZZZ Smith To: "Carlos Pignataro (cpignata)" , Lorenzo Colitti Message-ID: <1644381191.101848.1424221451000.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:07:13 -0000 Which I also referenced in my draft on this topic. I also suggested slightl= y changed forwarding rules for my proposed larger and different loopback pr= efix that would support using native IPv6 addresses for this MPLS purpose r= ather than an IPv4-mapped IPv6 address. "5.2. Router Rules IPv4 loopback packet processing rules for routers, specified in [RFC1812], by default prohibited forwarding of packets with 127/8 destinations, other than those originated locally and returned back to the router itself. A software switch could be provided to disable this prohibition. This special case of allowing forwarding of packets towards 127/8 destinations has been taken advantage of by [RFC4379], for MPLS troubleshooting purposes. An equivalent function for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff: Smith Expires August 24, 2013 [Page 7] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 127.0.0.0/104. The existing ::1/128 packet processing rules for routers are the same as those for IPv6 hosts [RFC4291]. For the new larger loopback prefix, the IPv6 router processing rules are changed to match those of IPv4, to suit future uses similar to the MPLS troubleshooting case." ________________________________ From: Carlos Pignataro (cpignata) To: Lorenzo Colitti =20 Cc: "v6ops@ietf.org" =20 Sent: Wednesday, 18 February 2015, 3:43 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback= -prefix-00.txt On Feb 16, 2015, at 8:09 PM, Lorenzo Colitti wrote: > >The value of the loopback prefix is not that it's routed to loopback. It's= that *everybody knows* it's always routed to loopback. > > > > > +1. By the way, another use case for a loopback block is in http://tools.ietf.o= rg/html/rfc7439#section-3.4.2 Thanks, =E2=80=94 Carlos. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Feb 17 17:43:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381551A88F5 for ; Tue, 17 Feb 2015 17:43:13 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXHdr4ox5WIE for ; Tue, 17 Feb 2015 17:43:10 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CA81A87C8 for ; Tue, 17 Feb 2015 17:43:10 -0800 (PST) Received: by pdjp10 with SMTP id p10so47930740pdj.3 for ; Tue, 17 Feb 2015 17:43:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=4RkzQa1zjDR1/VwBas++I4XtDH5iINMF75SxomQkNvY=; b=MLQJc2mgKhkK5lHMXf5dFSCpho0w94lypmKGYt7Hwu8V6Z9Td96bbONqY+ZnxPdf40 DZ5Erl858r1pbmadPrsuzjyxb9E4qeTV7M0hVWBZNijhlu9uKcGFTafxl/Jv7Tx90U0t JgVAjICpO212iBRfbHOzFOMn1Emp/6+z8+9wVHphF95SemRmmmK2BhEKZBOQtssLewjh ZgusmJl0rlT9OmunZAq/WofXRQbWoXkd8oQvPkkCruis6ibIpH85zFX6NlDf0aiMB/ud XXjzSHEU3n+8lHH/uOFj6JsJ4psbrBniELqY3M2N0iH75tXZRR/dxE6iMyoMp1u/+hft KIcw== X-Gm-Message-State: ALoCoQnkeq6L/QGnUoLR8iou/A5jBMcdduNucatdIDOFso/W1cFA6fmXVG/Rjm2LFgOLJ+Qd/NvC X-Received: by 10.66.251.105 with SMTP id zj9mr55579010pac.4.1424223789805; Tue, 17 Feb 2015 17:43:09 -0800 (PST) Received: from [10.0.1.10] ([73.162.11.223]) by mx.google.com with ESMTPSA id ot6sm12914403pdb.28.2015.02.17.17.43.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 17:43:08 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6C02F160-CBFF-4488-99A0-D5BBA48227BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: David Conrad In-Reply-To: <390182967.10574.1424220382446.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Feb 2015 17:43:05 -0800 Message-Id: References: <20150217032029.87BA329A857B@rock.dv.isc.org> <390182967.10574.1424220382446.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:43:13 -0000 --Apple-Mail=_6C02F160-CBFF-4488-99A0-D5BBA48227BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > Trying to place global significance on values within 127, as ICANN = have attempted to do with 127.0.53.53, violates the host local scope of = 127/8. No it doesn't. In fact, the whole reason 127/8 was chosen was precisely = because it was guaranteed to be "host local" scope, in an effort to = ensure (as much as anything on the Internet can be ensured, which = unfortunately isn't 100%) that traffic destined to the answer returned = by an "A" query for a newly delegated top-level domain wouldn't leak and = thus constitute "controlled exfiltration" (to use Verisign's = terminology). Unfortunately, as IPv6 does not appear to have a direct analog to IPv4's = loopback prefix, we simply punted figuring the number of v6 only sites = that would be querying new gTLDs to be minimal (at least for the current = crop of new gTLDs). > Quite frankly, I'm starting to think you haven't read the draft. Well, it did expire 18 months ago. Perhaps a refresh is warranted? I, = for one, would support moving it forward (albeit I'm not entirely sure a = /32 is warranted: I'd think a /64 would be sufficient for "host local" = scope). And don't worry, I'd be supporting it for loopback = functionality, not for the "flag" function we used 127.0.53.53 for (I've = been convinced there are better ways to do that in IPv6) :). Regards, -drc (ICANN CTO, but speaking only for myself) --Apple-Mail=_6C02F160-CBFF-4488-99A0-D5BBA48227BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4+4qAAoJENV6ebf0/4rXePAH/RAHOwNQe1JzqEfSC4TZpp2e CEHiIE0y0dulXmSWy8XUajuClO1TnzENAKZ+81Fu+5DrtsYQ3bi2T+Bg5ZK7W9nv 07klndehlcQx3l5qbal/6de9Q02CB/d5WZZbdCvRILvGAXSSZxQcSvgV2cZj7D5F sEC/1jUE+vkmBRdbo9pnIUBf3TTzOq4hCtWPyhkjfSGKJ1AEWPDfxyPUOw2YerWz CU0vDO53AytNXwH8TMG5FJ9HImruINvee83olVL4QMUhqSnO/pfZeOwvqQJ48Wdf Y8zELLckvZFqG1xjDIjYGjyrQrHcvIyLiXiouw7YHsZZ4JsSzd/eu5LD6A4wqyk= =8JRw -----END PGP SIGNATURE----- --Apple-Mail=_6C02F160-CBFF-4488-99A0-D5BBA48227BD-- From nobody Tue Feb 17 19:14:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8091A8989 for ; Tue, 17 Feb 2015 19:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.535 X-Spam-Level: *** X-Spam-Status: No, score=3.535 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj3kuafj4oNR for ; Tue, 17 Feb 2015 19:14:30 -0800 (PST) Received: from nm50-vm3.bullet.mail.gq1.yahoo.com (nm50-vm3.bullet.mail.gq1.yahoo.com [67.195.87.243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823BA1A6EFE for ; Tue, 17 Feb 2015 19:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424229270; bh=XJZKK2Jd9e8J4t87H718Lz6fdQCq7w4GBYtdwsAEA8A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=HLtEekAq/H6IQwNLDXh598ESYvgsd3CAkfjMnKzd4peBkaXFV2ObcKUM81mN1sHoYFjw4Lht/Dg5r+mPzU/2IGQr3ViLuSsJOqu6dfb0vfXTjB8Whg9j4dQ67NxawhrC3xN3obFPrbhbNDl0EQDzrHAxT66V6BKzIfljPVmEJxa5SMIrP31XJh/ZdWtSiKnjwaGrKV0LNBb/YL7O5Sj2dVJwTVqKZz8RStVMdMhVal8ULcNAPanUoMPcJEOjFgtBs380wS4GtDnRQBDJSztQGN+b+lnY8r7csyl8Q4M8u80U17uw/Kl7Soh0w0Yc3X4OoPzwNHNMArUlaNFiBw3Yqg== Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 03:14:30 -0000 Received: from [98.137.12.56] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 03:11:37 -0000 Received: from [98.139.215.143] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 03:11:36 -0000 Received: from [98.139.212.203] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 03:11:36 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 03:11:36 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 624367.31571.bm@omp1012.mail.bf1.yahoo.com X-YMail-OSG: wb5LKWIVM1noMwtvnWVd_F7WhVJ047qGhyMTEnrdwUyBaohS2WEj9gPbmNrRxfN r7Tbbm.Zr7EM.DoFgW4orI9Sq4oAzoFQOh7A7mVgnDHuB6YZCxmvJwFBZoEGidiQTqnGJPYEW2Jn tRHr.xRzw7jmNgkfW0HGhLZhzqwMNkKuGuHk2.mNAuZ2oQ0D6E6uu.8WMC9zs20.wRnGkTwJAD04 5UAEgkIMjuYekcYQQpNGKFKg0lMhQAP_rfhovQ6ItJNTu5W4WJgUCOjrYXOYThFXgGWhy2QkVHIR n4u8Gawti1pqS_8FzbM0KEOKHRdk84mpn.duzPUZ9TlgFLHbdBGoNUagz.h8o7ywPlu2rb4d5xcV k6Fb8tIe1tsS.aFxE9qFWDJ_hsCB0zTIDB44Qz8fnUszkAlooeJS9QjmQOEXKHVSIroI3KHeM9Gg EX5kBqqsTxaJZo1J.2lYNyT.ref6DmqrBFgyGfhtcA3ycfqhGWYZ7jiHZT.5qBJ9QyRp9gIUcEWa zUPQVl15.u8fLuCF8oud5boAgXCb12VzyDyQ2we3NEdEkpQR.PUWSHlVxsZzNuw72ZQdndPMFZlp D3XSRradkzZKifarTYfF3Qbz57LFnLqk29L1Nm9fVQ9qGyg-- Received: by 76.13.27.55; Wed, 18 Feb 2015 03:11:36 +0000 Date: Wed, 18 Feb 2015 03:11:28 +0000 (UTC) From: Mark ZZZ Smith To: David Conrad Message-ID: <179402448.207544.1424229088242.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:14:32 -0000 ----- Original Message ----- From: David Conrad To: Mark ZZZ Smith Cc: "v6ops@ietf.org" Sent: Tuesday, 17 February 2015, 13:19 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Mark, >> A number of RBLs use localhost addresses as flags to designate different forms of block lists (e.g., https://www.spamhaus.org/zen/). Do you believe those should be registered in the IANA IPv4 special address registry? > Yes. If they're supposed to have global and universal meaning, they should be an global registry of some form. Are, for example, spamhaus the global authority on the semantic meaning of 127/8 addresses? Are they the global authority on the semantic meaning of 127/8 addresses when performing DNS blacklisting? Sorry, your "yes" confuses me. I don't believe Spamhaus' use of 127/8 is intended to have global or universal meaning: they are understood by the folks who make use of Spamhaus RBLs. Nor do I think Spamhaus assuming global authority for the semantic meaning of 127/8 or even when performing DNS blacklisting. Now, if Spamhaus wrote an RFC that says "if you want to use DNS to identify specific RBL sub-types, the address 127.0.0.2 means type X, .3 means type Y, etc." and other blacklist providers thought that was useful, I could see a point for listing those addresses in an IANA registry, however I don't think there's sufficient interest and it wouldn't be Spamhaus being the global authority, that would still rest with the IANA. / So the trouble I have with what Spamhaus and ICANN are doing/have done with 127/8 is to place semantic meaning on certain 127/8 values that they expect other parties to accept. Because 127/8 is local to a host, or has host local scope, the domain of semantic meaning for addresses within it are limited to each individual host. Different hosts should be able to have different semantic meaning, or no semantic meaning at all for their own local 127/8 address space. This means that Spamhaus and ICANN have now prevented other parties from placing their own semantic meaning on those values. If I started using 127.0.53.53 on a host, and it was exposed to somebody else, they might think it is somehow being used in relation to the ICANN DNS function. If at any time I'm told I can't use that address on my host, "because it is *the* DNS name collision address" (as a Google search apparently shows) it really means that one of the addresses within 127/8 doesn't belong to my host any more. I'm being forced to accept a semantic value defined by somebody else for an address that is actually mine to define on my host (and define differently or not at all on each my hosts.) I have suffered from this sort of problem with RFC1918 addresses. At one of the ISPs I worked at we were getting wholesale ADSL services being delivered via L2TP from the very large incumbent carrier. They had chosen to give their L2TP Access Concentrators IP addresses from a variety of /24s from within 172.16/12. To be able to use those LACs inside your network successfully you couldn't be using that address space yourself, or you had to renumber out of it. Yet this is *private* address space, private to each network, so each network should be able to use it for their own purposes. That incumbent carrier had in effect made that private space 'public' to their customers, and were taking away their customers ability to use that space for their own private purposes. We were highly amused when we received an email from them to all to all of their ISP customers saying "is anybody using 172.xyz/24" prefix? Another example is that Microsoft chose to use locally assigned IEEE MAC addresses for their server load balancing addresses, rather than getting their own IEEE OUI - clearly they could have afforded the cost, although they might have already had one. They've in effect taken away the right of other people to use those addresses for what ever they want - which is their right because they're supposed to be 'locally assigned'. The moral of the story is to keep private values and meanings private and local values and meanings local. The only alternative way to give back people's ability to place local semantic meaning on local addresses/identifiers is to add some context information, expressing how defined that semantic meaning. For example, if there was a way to present the Spamhaus and ICANN defined 127/8 addresses in DNS as "127.0.0.1@Spamhous" or "127.0.53.53@ICANN" or similar, then the ambiguity would be gone, and the whole of the host-local 127/8 address space would be available to the host. Of course, that isn't possible with A or AAAA records, which is why it is not an option. Regards, Mark. >> OK. However, for clarity, this isn't specifically about "Controlled Interruption" or what ICANN "wants". It is about trying to have the same sort of facility that is available in IPv4 for IPv6. > / What specific facility? Sorry, I was speaking of the general loopback network functionality. > I agree with having a larger IPv6 loopback prefix because of the reasons I outlined in the larger loopback ID I wrote a few years ago. I wasn't aware of that earlier effort. Thanks for the reference. Interesting reading. > I don't agree with then punching "global" holes in that host-local address space for specific meaning for specific application protocols. I gather then that you disagree with Spamhaus' use of 127/8 as flags for particular RBLs? > By themselves, IP addresses do not have any application semantics - they're either an end-point identifier or locator. A philosophical point, but I'd go further and say that by themselves, IP addresses are just integers -- the semantics, including end point identification and/or routing location, are imposed by the applications (including host and router software) that make use of them. Regards, -drc (ICANN CTO, but speaking only for myself) From nobody Tue Feb 17 19:19:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D851A9240 for ; Tue, 17 Feb 2015 19:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.901 X-Spam-Level: * X-Spam-Status: No, score=1.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXBHI6kBNX8a for ; Tue, 17 Feb 2015 19:19:02 -0800 (PST) Received: from nm31-vm0.bullet.mail.ne1.yahoo.com (nm31-vm0.bullet.mail.ne1.yahoo.com [98.138.229.40]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724E01A8972 for ; Tue, 17 Feb 2015 19:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424229541; bh=a/jIxX6KecFigXaS4fPtGCGR09LTLamM0Wg/dUSBBHw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=eGZemKAMnkY3lzz2UTT1kFm6+cxIV55JO8fpLRrAjkOyK3CLMGR0KYsfs3h9zdazLyjLQAaCnr5RicpkpyhU9VuSQ0e/9YQa/qQWh5swhNCzTLmAzJlLDdXDqQdJT+d2mWJ4E2NTljD/g2IkqHQDArvIYnpKptp+qDZsK1mdxQB2yHLrhCvDb6bwii8ZjUczCI2wfQcyOjazWvEwjE7Tvp5OmO7TA7877lbFjfm24XpKvKrwEAA1U1a1YT/vbzhyQg9mb0jVknZEaJKvX4X22ArRl9xtePBP6yOGredsvxOAYkUcdbgSQ67UB446UJdRtVk1YWkRz2npMYFF7/hb5Q== Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2015 03:19:01 -0000 Received: from [98.138.226.180] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2015 03:16:16 -0000 Received: from [66.196.81.171] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2015 03:16:16 -0000 Received: from [98.139.212.210] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 03:16:16 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 03:16:16 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 426697.37319.bm@omp1019.mail.bf1.yahoo.com X-YMail-OSG: fCbV7PMVM1kDZTaXfTxnLpBzgvo9lYJbdItcYAG82mhuiDyZHnkKGZil0bD2_Vj MoKgcvl3YCaFw_crTU5xSU7sPBJ7qHjmmzHijUo_3yHBOFIqtelbivGWygXvJD4Yfjo7NPFNSUjt 3jdr8nIAvmfEz0cYptCXmliA9Zt99Pd5YGOmrBrLzfyQtwXz9xKTM18z._nxNwxFLkZ0zVL.xei6 P5ySPlGMZzMlw0ilgjnDmtRzrGBpM8acY5EiIyHtlmtyqjJAnn3EUQkWhLflWTlTkTrk0q9ugTLB r1TDOEOLDANxRyvJTFy6Bq0bJUN4aW1oGbSQiayUA_aAk9KX2h3jumsV8F8sfD5m1YRWob7mSheB 8xiUSQu7C8WRqJQYHhEXurb22CBkdyhtvDX7vA5D5Vxv.RkfcCyFrDxq4U_zp_JBhHrSQuu0MJxj dQdfKckhymtKxnFXmpEPSFOAwvruqyJnQfQpUKRx5Hul7sZABAg.zDdyOXFjjhaf0HdVV593kJ8e ek4m.ig69qdEvLvdm5nHv1kzEAYMvsgHpNS85DbyhdkjqlwNaadU- Received: by 66.196.81.120; Wed, 18 Feb 2015 03:16:15 +0000 Date: Wed, 18 Feb 2015 03:16:14 +0000 (UTC) From: Mark ZZZ Smith To: David Conrad Message-ID: <1323953480.196825.1424229374244.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:19:03 -0000 Hmm, regarding the comment about not reading the draft, apologies for that, I thought I was responding to somebody else who I thought should have read the draft before because of their previous objections. In my latest email to you I've explained why I think designating semantic meaning on local values and then expecting other external parties to respect those in effect now non-local values causes problems. ----- Original Message ----- From: David Conrad To: Mark ZZZ Smith Cc: "v6ops@ietf.org" Sent: Wednesday, 18 February 2015, 12:43 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Mark, > Trying to place global significance on values within 127, as ICANN have attempted to do with 127.0.53.53, violates the host local scope of 127/8. No it doesn't. In fact, the whole reason 127/8 was chosen was precisely because it was guaranteed to be "host local" scope, in an effort to ensure (as much as anything on the Internet can be ensured, which unfortunately isn't 100%) that traffic destined to the answer returned by an "A" query for a newly delegated top-level domain wouldn't leak and thus constitute "controlled exfiltration" (to use Verisign's terminology). Unfortunately, as IPv6 does not appear to have a direct analog to IPv4's loopback prefix, we simply punted figuring the number of v6 only sites that would be querying new gTLDs to be minimal (at least for the current crop of new gTLDs). > Quite frankly, I'm starting to think you haven't read the draft. Well, it did expire 18 months ago. Perhaps a refresh is warranted? I, for one, would support moving it forward (albeit I'm not entirely sure a /32 is warranted: I'd think a /64 would be sufficient for "host local" scope). And don't worry, I'd be supporting it for loopback functionality, not for the "flag" function we used 127.0.53.53 for (I've been convinced there are better ways to do that in IPv6) :). Regards, -drc (ICANN CTO, but speaking only for myself) From nobody Tue Feb 17 23:20:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE34D1A902E for ; Tue, 17 Feb 2015 23:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-kGWdIJ1U6K for ; Tue, 17 Feb 2015 23:20:14 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558C01A8FD6 for ; Tue, 17 Feb 2015 23:20:14 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so50491igk.1 for ; Tue, 17 Feb 2015 23:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rZdZVzvEdq7lfUx6FrwYae1WOK4t5u5ow1AC7tu0f1o=; b=KTkBAioZOb3txcH0N+iN40Oyg0X9qmuv+VMIWUrEfvbKzfYtzcTz0l3WSJ5CBHUazC 6OlPJ0ZyzY5uaPiB0+yp9sCROITbv1yiaNIGpZnoq7K0Fv3P5tZOHYYW5sllpdSf84S7 fWnWCwF389AbB3ulUJbOowNEQ+iOyUpJKKjQDoJ8x2fSVZ66X9ReYu01B/IvD2LmXP5z /5kRTmnXT03aLmD1pJV3/1ySqrarVXFo2Mqm/P4LvtIKe7CyKlIwApWVv9P9ONX1bQLZ 0amDfYoc9ZFaWCWb7uGg69aQZIFQpSK2uzWUYm9tS2KsdNf/S83var8NPPRhUeCiPiTi FL9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rZdZVzvEdq7lfUx6FrwYae1WOK4t5u5ow1AC7tu0f1o=; b=ksyOmIPZ9QMree+9h5X5DA74UUSYhSb/qxWFMpliHO2CWKv3LBJ3043zr23Vb71fiK ZlrtDV107BlWy1kZWohMjMa2k+f7ki2FviBMf0mzppYRhNJp0/CraVRMJifggf26byJy h0G+ODzLSq8EL4Dp8ykf1CnoGZ13xGSHjckuXLZvcNroPN6AL8XwCW7jWKIENld+yCGB kAlweRDCRjn4fcy4BqgFX1etim1rV/TtDgHyrhW2errGdbtNBx4yVLba0jOmzntC/wO6 jhhVnI6GVz3xQHiW3IgQMfKwFr+CiLvDwoFunRfki3XxBNVwFBWx0twIjk3YxYx7d0Lk 0Z4Q== X-Gm-Message-State: ALoCoQl89a0llo3VG5OGmJWtMs7BHk/VtbX3CdVAxrSwZAW2d1NN/Xyjvf4ERyeNT2cHRM9Juytz X-Received: by 10.107.25.72 with SMTP id 69mr3858826ioz.44.1424244013403; Tue, 17 Feb 2015 23:20:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 23:19:53 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Wed, 18 Feb 2015 16:19:53 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=001a113fef7a7e35e5050f57a66d Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 07:20:17 -0000 --001a113fef7a7e35e5050f57a66d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't understand why you say this is a game of chicken. All the major device vendors (except Apple, if you need 464xlat) support IPv6 today - Verizon and T-Mobile have fixed that problem for you. Asking them to set the APN configuration for your network to IPv6 (or IPv4v6) is simple, and they are running that code already on other networks. It's not an unreasonable request. It's not like you're asking them to write off the national debt or give you all their phones for free or something. It seems that you are dismissing that approach as unrealistic. Fine. But what you *are* doing, though, is writing a profile document listing 30+ features, many of which those vendors don't implement today, and some of which will require substantial work. Then you're asking a technical standards organization - which is not an operator organization, and which is not in the business of publishing profile documents or influencing deployments, but only of defining standards - to publish that document with "this is not a standard, and compliance is not required" written on the first page. To me that sounds a lot less realistic than just asking the vendors to turn on the code they already have. On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick wrote: > This is the game of chicken approach, I have no doubt it works, but is > it inclusive to all mobile operators? > > For me, it has some limitations: > > - The operator must have top down backing for a terminal policy > of =E2=80=9CIPv6 or you are out=E2=80=9D (now that is a wildcard conditio= n in itself); it > may compromise relationships in a valuable ecosystem > > - Where the operator has high major market power helps. Where > markets have a number of players ready to play the IPv6 game, there is an > advantage. Otherwise the operator is very exposed to divide and conquer > > - Currently it tends to play out as a the simplest set of > requirements. Which also means simplest set of network capabilities. > Sometimes these simplest set of network capabilities are at odds with the > business priorities of the operator (clear examples are: APN strategy, > tethering approach, roaming approach, subsidised handset vs =E2=80=9CSIM-= only=E2=80=9D) > > (Not having an IPv6 capable network is a myth you are promoting to > discredit operator views, it is a red herring =E2=80=93 any operator spec= ifying * > *any** IPv6 requirements will very quickly need this capability to > validate terminals whatever the path they choose.) > > > > I can see why you argue for lowest common denominator of v6 requirements. > > I think your stance that this can work across the board is =E2=80=9Charmf= ully > restrictive=E2=80=9D. > > The other approach is understanding the differences and trying to set a > slightly higher bar that highlights conditional requirements of the > collective; what you call =E2=80=9Charmfully broad=E2=80=9D. > > > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* 17 February 2015 02:41 > *To:* Heatley, Nick > *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org) > *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti > wrote: > > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, an= d > give the OEMs a credible signal that from date X onwards, you *will* fail > TA on every device that doesn't implement IPv6, and you *will not* waive > the requirement. That's what Verizon and T-Mobile did, and it worked for > them. > > > > Also: if you think that this strategy is not feasible because you do not > have an IPv6 network yet, then yes, that's true - you can't make IPv6 a > device requirement until you have an IPv6 network. > > > > But I think the key point here is that apart from the lack of 464xlat on > iOS, the mobile operating systems are a lot more ready for IPv6 than you > might think they are. Once the network is complete, I think turning on IP= v6 > in the devices does work. Orange Poland, Telenor, and SK Telecom should b= e > able to confirm. > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or us= e > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachment= s > are free from any virus, but it remains your responsibility to ensure tha= t > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > --001a113fef7a7e35e5050f57a66d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't understand why you say this is a game of chick= en.

All the major device vendors (except Apple, if you n= eed 464xlat) support IPv6 today - Verizon and T-Mobile have fixed that prob= lem for you. Asking them to set the APN configuration for your network to I= Pv6 (or IPv4v6) is simple, and they are running that code already on other = networks. It's not an unreasonable request. It's not like you'r= e asking them to write off the national debt or give you all their phones f= or free or something. It seems that you are dismissing that approach as unr= ealistic. Fine.

But what you *are* doing, though, = is writing a profile document listing 30+ features, many of which those ven= dors don't implement today, and some of which will require substantial = work. Then you're asking a technical standards organization - which is = not an operator organization, and which is not in the business of publishin= g profile documents or influencing deployments, but only of defining standa= rds - to publish that document with "this is not a standard, and compl= iance is not required" written on the first page.

=
To me that sounds a lot less realistic than just asking the vendors to= turn on the code they already have.
On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick= <nick.heatley@ee.co.uk> wrote:

This is the game of chick= en approach, I have no doubt it works, but is it inclusive to all mobile op= erators?

For me, it has some limit= ations:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The operator must ha= ve top down backing for a terminal policy of =E2=80=9CIPv6 or you are out= =E2=80=9D (now that is a wildcard condition in itself); it may compromise relationships in a valuable ecosystem

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Where the operator h= as high major market power helps. Where markets have a number of players re= ady to play the IPv6 game, there is an advantage. Otherwise the operator is very exposed to divide and conquer

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Currently it tends t= o play out as a the simplest set of requirements. Which also means simplest= set of network capabilities. Sometimes these simplest set of network capabilities are at odds with the business priorities of th= e operator (clear examples are: APN strategy, tethering approach, roaming a= pproach, subsidised handset vs =E2=80=9CSIM-only=E2=80=9D)

(Not having an IPv6 capab= le network is a myth you are promoting to discredit operator views, it is a= red herring =E2=80=93 any operator specifying *any* IPv6 requirements will very quickly need this capability to validate terminals = whatever the path they choose.)

=C2=A0

I can see why you argue f= or lowest common denominator of v6 requirements.

I think your stance that = this can work across the board is =E2=80=9Charmfully restrictive=E2=80=9D.<= u>

The other approach is und= erstanding the differences and trying to set a slightly higher bar that hig= hlights conditional requirements of the collective; what you call =C2=A0=E2=80=9Charmfully broad=E2=80=9D.

=C2=A0

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG (v6ops@ietf.org)
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last cal= l- "harmfully broad"?

=C2=A0

On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti &l= t;lorenzo@google.co= m> wrote:

Yes. Make IPv6* (see below) a requirement for carrie= r-branded devices, and give the OEMs a credible signal that from date X onw= ards, you *will* fail TA on every device that doesn't implement IPv6, a= nd you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them.

=C2=A0

Also: if you think that this strategy is not feasibl= e because you do not have an IPv6 network yet, then yes, that's true - = you can't make IPv6 a device requirement until you have an IPv6 network= .

=C2=A0

But I think the key point here is that apart from th= e lack of 464xlat on iOS, the mobile operating systems are a lot more ready= for IPv6 than you might think they are. Once the network is complete, I th= ink turning on IPv6 in the devices does work. Orange Poland, Telenor, and SK Telecom should be able to confir= m.

NOTICE AND DISCLAIMER
This e-mail (including any attachments) i= s intended=20 for the above-named person(s).=C2=A0 If you are not the intended recipient,= =20 notify the sender immediately, delete this email from your system and do no= t=20 disclose or use for any purpose.=C2=A0
=C2=A0
We may monitor all inc= oming=20 and outgoing emails in line with current legislation. We have taken steps t= o=20 ensure that this email and attachments are free from any virus, but it rema= ins=20 your responsibility to ensure that viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Numb= er:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfiel= d,=20 Hertfordshire, AL10 9BW

=C2=A0


--001a113fef7a7e35e5050f57a66d-- From nobody Tue Feb 17 23:26:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475961A8743 for ; Tue, 17 Feb 2015 23:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weWCm6EW7VLu for ; Tue, 17 Feb 2015 23:26:04 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2381A033B for ; Tue, 17 Feb 2015 23:26:04 -0800 (PST) Received: by iecvy18 with SMTP id vy18so46635036iec.13 for ; Tue, 17 Feb 2015 23:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JX7RY+6XuUZyDvGCiww7gqJaK+gwM+8SGQ1pUmuHuKA=; b=WLtQR5Z/62ZcULunOhhIOmCpeGjCQC83s/tHFaOq1h2H6BZ7s/728aH5l4QGijqFLQ sSLA8TsSFzUYSBBDzY1WEstloHjP6F9ZWnPY8H4cVyx3s49r/fnbbhOpsBCX04GHS5ic qQ8kq0I6vWfnI4wl8VoPmrFCZPbQoa40nP9S69v2Bm5OVpjfyLqmwM8l3D/BBWewMydr sJ8q37QzJ2qnJ95w/Ny9bGiBUXn7DfRgIwIcfvoXJatU2ccqP7WwVbEnBiqqZW+Eqv2H /XtdQAckRdctogVJ9Nxl16C1mpGxGO3qQi0ZHOohrGg9WGSc4XhtCDZVtit6ok6EE3Nz c3aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JX7RY+6XuUZyDvGCiww7gqJaK+gwM+8SGQ1pUmuHuKA=; b=GgxEzsaDINht50Ehq+TOqcoa2mjU09lzhRLMVbteU8uSH9lqo+02X1JMBm2w/66VZv 23fd/32Okq5/FtEJ1IBB7YPqCJPWjg1C1+d8b7OiIQzY0UBpEtN+fe/64fOtmWTJfruF cADQrBk/iaNJznOAuJxDsz1YNaBhWwe/4i51gUuUbT32wuYaaWWdKWneF9Iek5CIO+3n dbXR6GWqMEbmthyv55KjLo2pmii5JRpBW1kUmkcmG6Fr0IblJdaiy2ZIfIomqXFPB5nL dmgRSItJqhDOWQxJJ745NRp5CSSQpVyEAYIWOCJXv2QqfyiaRlFIqiHlj3E+Q0GdpHkM qpTQ== X-Gm-Message-State: ALoCoQnjLkVUeovjdHvKNjUlLyO3WU/bVM42B4ye9Nm77q8JdtaXe0o+Vf97bvl8uEl8BlUmisK2 X-Received: by 10.42.58.139 with SMTP id i11mr1926940ich.68.1424244363693; Tue, 17 Feb 2015 23:26:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 23:25:43 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Wed, 18 Feb 2015 16:25:43 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=20cf30334b6f5f4f3d050f57bb91 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 07:26:07 -0000 --20cf30334b6f5f4f3d050f57bb91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick wrote: > I can see why you argue for lowest common denominator of v6 requirements= . > > I think your stance that this can work across the board is =E2=80=9Charmf= ully > restrictive=E2=80=9D. > > The other approach is understanding the differences and trying to set a > slightly higher bar that highlights conditional requirements of the > collective; what you call =E2=80=9Charmfully broad=E2=80=9D. > What I'm saying is that if your goal is IPv6 deployment in a reasonable timeframe, then the right strategy is *not* to make a list of all the features under the sun, wait until they have all been implemented, and deploy them. A better strategy is to start from the features that are required, test and deploy those, and then iterate. As the industry evolves and IPv6 becomes more common, IPv6 features will become higher priority for vendors and they will get implemented. On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick wrote: > This is the game of chicken approach, I have no doubt it works, but is > it inclusive to all mobile operators? > > For me, it has some limitations: > > - The operator must have top down backing for a terminal policy > of =E2=80=9CIPv6 or you are out=E2=80=9D (now that is a wildcard conditio= n in itself); it > may compromise relationships in a valuable ecosystem > > - Where the operator has high major market power helps. Where > markets have a number of players ready to play the IPv6 game, there is an > advantage. Otherwise the operator is very exposed to divide and conquer > > - Currently it tends to play out as a the simplest set of > requirements. Which also means simplest set of network capabilities. > Sometimes these simplest set of network capabilities are at odds with the > business priorities of the operator (clear examples are: APN strategy, > tethering approach, roaming approach, subsidised handset vs =E2=80=9CSIM-= only=E2=80=9D) > > (Not having an IPv6 capable network is a myth you are promoting to > discredit operator views, it is a red herring =E2=80=93 any operator spec= ifying * > *any** IPv6 requirements will very quickly need this capability to > validate terminals whatever the path they choose.) > > > > I can see why you argue for lowest common denominator of v6 requirements. > > I think your stance that this can work across the board is =E2=80=9Charmf= ully > restrictive=E2=80=9D. > > The other approach is understanding the differences and trying to set a > slightly higher bar that highlights conditional requirements of the > collective; what you call =E2=80=9Charmfully broad=E2=80=9D. > > > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* 17 February 2015 02:41 > *To:* Heatley, Nick > *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org) > *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti > wrote: > > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, an= d > give the OEMs a credible signal that from date X onwards, you *will* fail > TA on every device that doesn't implement IPv6, and you *will not* waive > the requirement. That's what Verizon and T-Mobile did, and it worked for > them. > > > > Also: if you think that this strategy is not feasible because you do not > have an IPv6 network yet, then yes, that's true - you can't make IPv6 a > device requirement until you have an IPv6 network. > > > > But I think the key point here is that apart from the lack of 464xlat on > iOS, the mobile operating systems are a lot more ready for IPv6 than you > might think they are. Once the network is complete, I think turning on IP= v6 > in the devices does work. Orange Poland, Telenor, and SK Telecom should b= e > able to confirm. > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or us= e > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachment= s > are free from any virus, but it remains your responsibility to ensure tha= t > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > --20cf30334b6f5f4f3d050f57bb91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:

I can see why you argue for lowest common de= nominator of v6 requirements.

I think your stance that this can work acros= s the board is =E2=80=9Charmfully restrictive=E2=80=9D.

The other approach is understanding the diff= erences and trying to set a slightly higher bar that highlights conditional= requirements of the collective; what you call =C2=A0=E2=80=9Charmfully broad=E2=80=9D.


What I'm saying is that if your goal is = IPv6 deployment in a reasonable timeframe, then the right strategy is=C2=A0= *not* to make a list of all the features under the sun, wait until they hav= e all been implemented, and deploy them. A better strategy is to start from= the features that are required, test and deploy those, and then iterate. A= s the industry evolves and IPv6 becomes more common, IPv6 features will bec= ome higher priority for vendors and they will get implemented.
<= /div>

On Tue= , Feb 17, 2015 at 8:31 PM, Heatley, Nick <nick.heatley@ee.co.uk>= ; wrote:

This is the game of chick= en approach, I have no doubt it works, but is it inclusive to all mobile op= erators?

For me, it has some limit= ations:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The operator must ha= ve top down backing for a terminal policy of =E2=80=9CIPv6 or you are out= =E2=80=9D (now that is a wildcard condition in itself); it may compromise relationships in a valuable ecosystem

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Where the operator h= as high major market power helps. Where markets have a number of players re= ady to play the IPv6 game, there is an advantage. Otherwise the operator is very exposed to divide and conquer

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Currently it tends t= o play out as a the simplest set of requirements. Which also means simplest= set of network capabilities. Sometimes these simplest set of network capabilities are at odds with the business priorities of th= e operator (clear examples are: APN strategy, tethering approach, roaming a= pproach, subsidised handset vs =E2=80=9CSIM-only=E2=80=9D)

(Not having an IPv6 capab= le network is a myth you are promoting to discredit operator views, it is a= red herring =E2=80=93 any operator specifying *any* IPv6 requirements will very quickly need this capability to validate terminals = whatever the path they choose.)

=C2=A0

I can see why you argue f= or lowest common denominator of v6 requirements.

I think your stance that = this can work across the board is =E2=80=9Charmfully restrictive=E2=80=9D.<= u>

The other approach is und= erstanding the differences and trying to set a slightly higher bar that hig= hlights conditional requirements of the collective; what you call =C2=A0=E2=80=9Charmfully broad=E2=80=9D.

=C2=A0

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG (v6ops@ietf.org)
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last cal= l- "harmfully broad"?

=C2=A0

On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti &l= t;lorenzo@google.co= m> wrote:

Yes. Make IPv6* (see below) a requirement for carrie= r-branded devices, and give the OEMs a credible signal that from date X onw= ards, you *will* fail TA on every device that doesn't implement IPv6, a= nd you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them.

=C2=A0

Also: if you think that this strategy is not feasibl= e because you do not have an IPv6 network yet, then yes, that's true - = you can't make IPv6 a device requirement until you have an IPv6 network= .

=C2=A0

But I think the key point here is that apart from th= e lack of 464xlat on iOS, the mobile operating systems are a lot more ready= for IPv6 than you might think they are. Once the network is complete, I th= ink turning on IPv6 in the devices does work. Orange Poland, Telenor, and SK Telecom should be able to confir= m.

NOTICE AND DISCLAIMER
This e-mail (including any att= achments) is intended=20 for the above-named person(s).=C2=A0 If you are not the intended recipient,= =20 notify the sender immediately, delete this email from your system and do no= t=20 disclose or use for any purpose.=C2=A0
=C2=A0
We may monitor all inc= oming=20 and outgoing emails in line with current legislation. We have taken steps t= o=20 ensure that this email and attachments are free from any virus, but it rema= ins=20 your responsibility to ensure that viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Numb= er:=20 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfiel= d,=20 Hertfordshire, AL10 9BW

=C2=A0


--20cf30334b6f5f4f3d050f57bb91-- From nobody Wed Feb 18 01:35:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3641A0360 for ; Wed, 18 Feb 2015 01:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv-B-6IFyggJ for ; Wed, 18 Feb 2015 01:35:22 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FFE1A00A9 for ; Wed, 18 Feb 2015 01:35:21 -0800 (PST) Received: from [85.158.136.3] by server-5.bemta-5.messagelabs.com id D2/AC-03164-7DC54E45; Wed, 18 Feb 2015 09:35:19 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-123.messagelabs.com!1424252119!38446682!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21727 invoked from network); 18 Feb 2015 09:35:19 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Feb 2015 09:35:19 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Wed, 18 Feb 2015 09:35:15 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Wed, 18 Feb 2015 09:35:18 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 09:35:17 +0000 From: "Heatley, Nick" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAFtSIAABXhFiAAAXD/SAAI6wAAAABhtuAABDDgdAAK3XWgAADyfKQ Date: Wed, 18 Feb 2015 09:35:16 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E08E9CUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:35:30 -0000 --_000_6536E263028723489CCD5B6821D4B21303E08E9CUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlIHdpdGggeW91LCB0aGF0IGlzIGEgc2Vuc2libGUgYXBwcm9hY2guDQpXb3Jr aW5nIHdpdGggZWFjaCB2ZW5kb3IgaW4gdHVybi4NCihZb3Uga25vdyBlYWNoIHZlbmRvciB3aG8g Y2xhaW1zIElQdjYgcmVhZGluZXNzIGZvciB0aGVpciB0ZXJtaW5hbCwgd2lsbCBuZXZlciBzYXkg d2hldGhlciB0aGUgZGV2aWNlIHdpbGwgd29yayBvbiB0aGUgb3BlcmF0b3JzIElQdjYgbmV0d29y ay4NClNvIGl0IG5lZWRzIHRvIGJlIGNvbGxhYm9yYXRpdmUuKQ0KDQpTbyBhbGwgdGhpcyBkb2N1 bWVudCBpcyBkb2luZyBpcyBzZXR0aW5nIGEgY29sbGVjdGl2ZSByb2FkbWFwLCByYXRoZXIgdGhh biBleHBlY3QgdmVuZG9ycyB0byBkbyB0aGVpciBvd24gdGhpbmcuIEdpdmVuIHdlIGFncmVlIG9u IHRoZSBhYm92ZSwgdGhpcyBpcyBub3QgaGFybWZ1bC4NCg0KSSB0aGluayB0aGUgcmVhbCBkaXNh Z3JlZW1lbnQgY29tZXMgZnJvbSB5b3VyIG9waW5pb24gdGhhdCB0aGlzIGlzIG5vdCBJRVRGLg0K KEJ5IHRoZSB3YXksIG1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBoYWQgZGlzY3Vzc2lvbnMgd2l0aCB0 aGUgc2lzdGVyIG9yZyBvZiB0aGUgSW50ZXJuZXQgU29jaWV0eSBhYm91dCB3aGF0IHdvdWxkIGhl bHAgbW9iaWxlIG9wZXJhdG9ycyBpbnRyb2R1Y2UgSVB2Ni4NCk9uZSBvZiB0aGUgbWFqb3IgbWFq b3IgdGhlbWVzIGhhcyBiZWVuIHRlcm1pbmFscy4pDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRp IFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogMTggRmVicnVhcnkgMjAxNSAwNzoy Ng0KVG86IEhlYXRsZXksIE5pY2sNCkNjOiBSb3NzIENoYW5kbGVyOyBJUHY2IE9wcyBXRyAodjZv cHNAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmls ZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUdWUs IEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUu Y28udWs8bWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51az4+IHdyb3RlOg0KSSBjYW4gc2VlIHdo eSB5b3UgYXJndWUgZm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1l bnRzLg0KSSB0aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBi b2FyZCBpcyDigJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9hY2gg aXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGln aHRseSBoaWdoZXIgYmFyIHRoYXQgaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMg b2YgdGhlIGNvbGxlY3RpdmU7IHdoYXQgeW91IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKAnS4N Cg0KV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgaWYgeW91ciBnb2FsIGlzIElQdjYgZGVwbG95bWVu dCBpbiBhIHJlYXNvbmFibGUgdGltZWZyYW1lLCB0aGVuIHRoZSByaWdodCBzdHJhdGVneSBpcyAq bm90KiB0byBtYWtlIGEgbGlzdCBvZiBhbGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4sIHdh aXQgdW50aWwgdGhleSBoYXZlIGFsbCBiZWVuIGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0u IEEgYmV0dGVyIHN0cmF0ZWd5IGlzIHRvIHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJl IHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBsb3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRo ZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJUHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVh dHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVyIHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdp bGwgZ2V0IGltcGxlbWVudGVkLg0KDQpPbiBUdWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBI ZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFpbHRvOm5pY2suaGVhdGxleUBl ZS5jby51az4+IHdyb3RlOg0KVGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFwcHJvYWNoLCBJ IGhhdmUgbm8gZG91YnQgaXQgd29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUgdG8gYWxsIG1vYmls ZSBvcGVyYXRvcnM/DQpGb3IgbWUsIGl0IGhhcyBzb21lIGxpbWl0YXRpb25zOg0KDQotICAgICAg ICAgIFRoZSBvcGVyYXRvciBtdXN0IGhhdmUgdG9wIGRvd24gYmFja2luZyBmb3IgYSB0ZXJtaW5h bCBwb2xpY3kgb2Yg4oCcSVB2NiBvciB5b3UgYXJlIG91dOKAnSAobm93IHRoYXQgaXMgYSB3aWxk Y2FyZCBjb25kaXRpb24gaW4gaXRzZWxmKTsgaXQgbWF5IGNvbXByb21pc2UgcmVsYXRpb25zaGlw cyBpbiBhIHZhbHVhYmxlIGVjb3N5c3RlbQ0KDQotICAgICAgICAgIFdoZXJlIHRoZSBvcGVyYXRv ciBoYXMgaGlnaCBtYWpvciBtYXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1hcmtldHMgaGF2ZSBh IG51bWJlciBvZiBwbGF5ZXJzIHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2FtZSwgdGhlcmUgaXMg YW4gYWR2YW50YWdlLiBPdGhlcndpc2UgdGhlIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBk aXZpZGUgYW5kIGNvbnF1ZXINCg0KLSAgICAgICAgICBDdXJyZW50bHkgaXQgdGVuZHMgdG8gcGxh eSBvdXQgYXMgYSB0aGUgc2ltcGxlc3Qgc2V0IG9mIHJlcXVpcmVtZW50cy4gV2hpY2ggYWxzbyBt ZWFucyBzaW1wbGVzdCBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMuIFNvbWV0aW1lcyB0aGVz ZSBzaW1wbGVzdCBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMgYXJlIGF0IG9kZHMgd2l0aCB0 aGUgYnVzaW5lc3MgcHJpb3JpdGllcyBvZiB0aGUgb3BlcmF0b3IgKGNsZWFyIGV4YW1wbGVzIGFy ZTogQVBOIHN0cmF0ZWd5LCB0ZXRoZXJpbmcgYXBwcm9hY2gsIHJvYW1pbmcgYXBwcm9hY2gsIHN1 YnNpZGlzZWQgaGFuZHNldCB2cyDigJxTSU0tb25seeKAnSkNCihOb3QgaGF2aW5nIGFuIElQdjYg Y2FwYWJsZSBuZXR3b3JrIGlzIGEgbXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQg b3BlcmF0b3Igdmlld3MsIGl0IGlzIGEgcmVkIGhlcnJpbmcg4oCTIGFueSBvcGVyYXRvciBzcGVj aWZ5aW5nICphbnkqIElQdjYgcmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhp cyBjYXBhYmlsaXR5IHRvIHZhbGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5 IGNob29zZS4pDQoNCkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRl bm9taW5hdG9yIG9mIHY2IHJlcXVpcmVtZW50cy4NCkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0 aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl 4oCdLg0KVGhlIG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2Vz IGFuZCB0cnlpbmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0IGhpZ2hsaWdodHMg Y29uZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxs ICDigJxoYXJtZnVsbHkgYnJvYWTigJ0uDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+XQ0KU2VudDog MTcgRmVicnVhcnkgMjAxNSAwMjo0MQ0KVG86IEhlYXRsZXksIE5pY2sNCkNjOiBSb3NzIENoYW5k bGVyOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPikN ClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9m aWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9uIFR1ZSwgRmViIDE3LCAyMDE1 IGF0IDEwOjU3IEFNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tPj4gd3JvdGU6DQpZZXMuIE1ha2UgSVB2NiogKHNlZSBiZWxvdykg YSByZXF1aXJlbWVudCBmb3IgY2Fycmllci1icmFuZGVkIGRldmljZXMsIGFuZCBnaXZlIHRoZSBP RU1zIGEgY3JlZGlibGUgc2lnbmFsIHRoYXQgZnJvbSBkYXRlIFggb253YXJkcywgeW91ICp3aWxs KiBmYWlsIFRBIG9uIGV2ZXJ5IGRldmljZSB0aGF0IGRvZXNuJ3QgaW1wbGVtZW50IElQdjYsIGFu ZCB5b3UgKndpbGwgbm90KiB3YWl2ZSB0aGUgcmVxdWlyZW1lbnQuIFRoYXQncyB3aGF0IFZlcml6 b24gYW5kIFQtTW9iaWxlIGRpZCwgYW5kIGl0IHdvcmtlZCBmb3IgdGhlbS4NCg0KQWxzbzogaWYg eW91IHRoaW5rIHRoYXQgdGhpcyBzdHJhdGVneSBpcyBub3QgZmVhc2libGUgYmVjYXVzZSB5b3Ug ZG8gbm90IGhhdmUgYW4gSVB2NiBuZXR3b3JrIHlldCwgdGhlbiB5ZXMsIHRoYXQncyB0cnVlIC0g eW91IGNhbid0IG1ha2UgSVB2NiBhIGRldmljZSByZXF1aXJlbWVudCB1bnRpbCB5b3UgaGF2ZSBh biBJUHY2IG5ldHdvcmsuDQoNCkJ1dCBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyB0aGF0 IGFwYXJ0IGZyb20gdGhlIGxhY2sgb2YgNDY0eGxhdCBvbiBpT1MsIHRoZSBtb2JpbGUgb3BlcmF0 aW5nIHN5c3RlbXMgYXJlIGEgbG90IG1vcmUgcmVhZHkgZm9yIElQdjYgdGhhbiB5b3UgbWlnaHQg dGhpbmsgdGhleSBhcmUuIE9uY2UgdGhlIG5ldHdvcmsgaXMgY29tcGxldGUsIEkgdGhpbmsgdHVy bmluZyBvbiBJUHY2IGluIHRoZSBkZXZpY2VzIGRvZXMgd29yay4gT3JhbmdlIFBvbGFuZCwgVGVs ZW5vciwgYW5kIFNLIFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29uZmlybS4NCg0KTk9USUNF IEFORCBESVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykg aXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwg ZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9y IHVzZSBmb3IgYW55IHB1cnBvc2UuDQoNCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQg b3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZl IHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFy ZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5 IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KDQpF RSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lz dGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVu dCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcN Cg0KDQoNCg0KTk9USUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocyku ICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8g bm90IGRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuICANCiANCldlIG1heSBtb25pdG9y IGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxl Z2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwg YW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5 b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2Vs eSBhZmZlY3QgeW91LiANCg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBX YWxlcw0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2Zm aWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRm b3Jkc2hpcmUsIEFMMTAgOUJXLg0K --_000_6536E263028723489CCD5B6821D4B21303E08E9CUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBhZ3JlZSB3aXRoIHlvdSwgdGhh dCBpcyBhIHNlbnNpYmxlIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X b3JraW5nIHdpdGggZWFjaCB2ZW5kb3IgaW4gdHVybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+KFlvdSBrbm93IGVhY2ggdmVuZG9yIHdobyBjbGFpbXMgSVB2NiByZWFkaW5lc3MgZm9y IHRoZWlyIHRlcm1pbmFsLCB3aWxsIG5ldmVyIHNheSB3aGV0aGVyIHRoZSBkZXZpY2Ugd2lsbCB3 b3JrIG9uIHRoZSBvcGVyYXRvcnMgSVB2NiBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TbyBpdCBuZWVkcyB0byBiZSBjb2xsYWJvcmF0aXZlLik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIGFs bCB0aGlzIGRvY3VtZW50IGlzIGRvaW5nIGlzIHNldHRpbmcgYSBjb2xsZWN0aXZlIHJvYWRtYXAs IHJhdGhlciB0aGFuIGV4cGVjdCB2ZW5kb3JzIHRvIGRvIHRoZWlyIG93biB0aGluZy4gR2l2ZW4g d2UgYWdyZWUgb24gdGhlIGFib3ZlLCB0aGlzIGlzIG5vdCBoYXJtZnVsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0 aGluayB0aGUgcmVhbCBkaXNhZ3JlZW1lbnQgY29tZXMgZnJvbSB5b3VyIG9waW5pb24gdGhhdCB0 aGlzIGlzIG5vdCBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oQnkgdGhlIHdh eSwgbW9iaWxlIG9wZXJhdG9ycyBoYXZlIGhhZCBkaXNjdXNzaW9ucyB3aXRoIHRoZSBzaXN0ZXIg b3JnIG9mIHRoZSBJbnRlcm5ldCBTb2NpZXR5IGFib3V0IHdoYXQgd291bGQgaGVscCBtb2JpbGUg b3BlcmF0b3JzIGludHJvZHVjZSBJUHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P bmUgb2YgdGhlIG1ham9yIG1ham9yIHRoZW1lcyBoYXMgYmVlbiB0ZXJtaW5hbHMuKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRp IFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEZlYnJ1 YXJ5IDIwMTUgMDc6MjY8YnI+DQo8Yj5Ubzo8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5DYzo8 L2I+IFJvc3MgQ2hhbmRsZXI7IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxNywg MjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrICZsdDs8YSBocmVmPSJtYWlsdG86bmljay5o ZWF0bGV5QGVlLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+bmljay5oZWF0bGV5QGVlLmNvLnVrPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2Fu IHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIG9mIHY2IHJl cXVpcmVtZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHlvdXIg c3RhbmNlIHRoYXQgdGhpcyBjYW4gd29yayBhY3Jvc3MgdGhlIGJvYXJkIGlzIOKAnGhhcm1mdWxs eSByZXN0cmljdGl2ZeKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3Ro ZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0 byBzZXQgYSBzbGlnaHRseSBoaWdoZXIgYmFyIHRoYXQNCiBoaWdobGlnaHRzIGNvbmRpdGlvbmFs IHJlcXVpcmVtZW50cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hhdCB5b3UgY2FsbCAmbmJzcDvigJxo YXJtZnVsbHkgYnJvYWTigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgSSdtIHNheWluZyBpcyB0aGF0IGlm IHlvdXIgZ29hbCBpcyBJUHY2IGRlcGxveW1lbnQgaW4gYSByZWFzb25hYmxlIHRpbWVmcmFtZSwg dGhlbiB0aGUgcmlnaHQgc3RyYXRlZ3kgaXMmbmJzcDsqbm90KiB0byBtYWtlIGEgbGlzdCBvZiBh bGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4sIHdhaXQgdW50aWwgdGhleSBoYXZlIGFsbCBi ZWVuIGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0uIEEgYmV0dGVyIHN0cmF0ZWd5DQogaXMg dG8gc3RhcnQgZnJvbSB0aGUgZmVhdHVyZXMgdGhhdCBhcmUgcmVxdWlyZWQsIHRlc3QgYW5kIGRl cGxveSB0aG9zZSwgYW5kIHRoZW4gaXRlcmF0ZS4gQXMgdGhlIGluZHVzdHJ5IGV2b2x2ZXMgYW5k IElQdjYgYmVjb21lcyBtb3JlIGNvbW1vbiwgSVB2NiBmZWF0dXJlcyB3aWxsIGJlY29tZSBoaWdo ZXIgcHJpb3JpdHkgZm9yIHZlbmRvcnMgYW5kIHRoZXkgd2lsbCBnZXQgaW1wbGVtZW50ZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNr ICZsdDs8YSBocmVmPSJtYWlsdG86bmljay5oZWF0bGV5QGVlLmNvLnVrIiB0YXJnZXQ9Il9ibGFu ayI+bmljay5oZWF0bGV5QGVlLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgdGhlIGdhbWUgb2YgY2hpY2tlbiBhcHByb2Fj aCwgSSBoYXZlIG5vIGRvdWJ0IGl0IHdvcmtzLCBidXQgaXMgaXQgaW5jbHVzaXZlIHRvIGFsbCBt b2JpbGUNCiBvcGVyYXRvcnM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIG1l LCBpdCBoYXMgc29tZSBsaW1pdGF0aW9uczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3BlcmF0b3IgbXVzdCBoYXZlIHRvcCBkb3du IGJhY2tpbmcgZm9yIGEgdGVybWluYWwgcG9saWN5IG9mIOKAnElQdjYgb3IgeW91IGFyZSBvdXTi gJ0gKG5vdyB0aGF0IGlzIGEgd2lsZGNhcmQgY29uZGl0aW9uIGluIGl0c2VsZik7IGl0IG1heSBj b21wcm9taXNlIHJlbGF0aW9uc2hpcHMgaW4gYQ0KIHZhbHVhYmxlIGVjb3N5c3RlbTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZXJlIHRo ZSBvcGVyYXRvciBoYXMgaGlnaCBtYWpvciBtYXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1hcmtl dHMgaGF2ZSBhIG51bWJlciBvZiBwbGF5ZXJzIHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2FtZSwg dGhlcmUgaXMgYW4gYWR2YW50YWdlLiBPdGhlcndpc2UgdGhlIG9wZXJhdG9yIGlzDQogdmVyeSBl eHBvc2VkIHRvIGRpdmlkZSBhbmQgY29ucXVlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCB0ZW5kcyB0byBwbGF5IG91 dCBhcyBhIHRoZSBzaW1wbGVzdCBzZXQgb2YgcmVxdWlyZW1lbnRzLiBXaGljaCBhbHNvIG1lYW5z IHNpbXBsZXN0IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcy4gU29tZXRpbWVzIHRoZXNlIHNp bXBsZXN0IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcw0KIGFyZSBhdCBvZGRzIHdpdGggdGhl IGJ1c2luZXNzIHByaW9yaXRpZXMgb2YgdGhlIG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6 IEFQTiBzdHJhdGVneSwgdGV0aGVyaW5nIGFwcHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJz aWRpc2VkIGhhbmRzZXQgdnMg4oCcU0lNLW9ubHnigJ0pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+KE5vdCBoYXZpbmcgYW4gSVB2NiBjYXBhYmxlIG5ldHdvcmsgaXMgYSBteXRoIHlv dSBhcmUgcHJvbW90aW5nIHRvIGRpc2NyZWRpdCBvcGVyYXRvciB2aWV3cywgaXQgaXMNCiBhIHJl ZCBoZXJyaW5nIOKAkyBhbnkgb3BlcmF0b3Igc3BlY2lmeWluZyAqPGI+YW55PC9iPiogSVB2NiBy ZXF1aXJlbWVudHMgd2lsbCB2ZXJ5IHF1aWNrbHkgbmVlZCB0aGlzIGNhcGFiaWxpdHkgdG8gdmFs aWRhdGUgdGVybWluYWxzIHdoYXRldmVyIHRoZSBwYXRoIHRoZXkgY2hvb3NlLik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGNhbiBzZWUgd2h5IHlvdSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRv ciBvZiB2NiByZXF1aXJlbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0 aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDi gJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhlIG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFu ZCB0cnlpbmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0DQogaGlnaGxpZ2h0cyBj b25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNvbGxlY3RpdmU7IHdoYXQgeW91IGNhbGwg Jm5ic3A74oCcaGFybWZ1bGx5IGJyb2Fk4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56bw0KIENvbGl0dGkgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bn b29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNyBGZWJydWFyeSAyMDE1IDAyOjQx PGJyPg0KPGI+VG86PC9iPiBIZWF0bGV5LCBOaWNrPGJyPg0KPGI+Q2M6PC9iPiBSb3NzIENoYW5k bGVyOyBJUHY2IE9wcyBXRyAoPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2 b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZx dW90O2hhcm1mdWxseSBicm9hZCZxdW90Oz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxNywgMjAxNSBhdCAxMDo1NyBB TSwgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlllcy4gTWFrZSBJUHY2KiAoc2VlIGJlbG93KSBhIHJlcXVpcmVt ZW50IGZvciBjYXJyaWVyLWJyYW5kZWQgZGV2aWNlcywgYW5kIGdpdmUgdGhlIE9FTXMgYSBjcmVk aWJsZSBzaWduYWwgdGhhdCBmcm9tIGRhdGUgWCBvbndhcmRzLCB5b3UgKndpbGwqIGZhaWwgVEEg b24gZXZlcnkgZGV2aWNlIHRoYXQgZG9lc24ndA0KIGltcGxlbWVudCBJUHY2LCBhbmQgeW91ICp3 aWxsIG5vdCogd2FpdmUgdGhlIHJlcXVpcmVtZW50LiBUaGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBU LU1vYmlsZSBkaWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BbHNvOiBpZiB5b3UgdGhpbmsgdGhhdCB0aGlzIHN0cmF0ZWd5IGlzIG5vdCBmZWFzaWJs ZSBiZWNhdXNlIHlvdSBkbyBub3QgaGF2ZSBhbiBJUHY2IG5ldHdvcmsgeWV0LCB0aGVuIHllcywg dGhhdCdzIHRydWUgLSB5b3UgY2FuJ3QgbWFrZSBJUHY2IGEgZGV2aWNlIHJlcXVpcmVtZW50IHVu dGlsIHlvdSBoYXZlDQogYW4gSVB2NiBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IEkgdGhpbmsgdGhlIGtleSBwb2lu dCBoZXJlIGlzIHRoYXQgYXBhcnQgZnJvbSB0aGUgbGFjayBvZiA0NjR4bGF0IG9uIGlPUywgdGhl IG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcyBhcmUgYSBsb3QgbW9yZSByZWFkeSBmb3IgSVB2NiB0 aGFuIHlvdSBtaWdodCB0aGluayB0aGV5IGFyZS4gT25jZSB0aGUNCiBuZXR3b3JrIGlzIGNvbXBs ZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2NiBpbiB0aGUgZGV2aWNlcyBkb2VzIHdvcmsuIE9y YW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBTSyBUZWxlY29tIHNob3VsZCBiZSBhYmxlIHRvIGNv bmZpcm0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPk5PVElDRSBBTkQgRElTQ0xBSU1FUjxicj4NClRoaXMg ZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFi b3ZlLW5hbWVkIHBlcnNvbihzKS4mbmJzcDsgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWls IGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJw b3NlLiZuYnNwOw0KPGJyPg0KJm5ic3A7PGJyPg0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5n IGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdl IGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVu dHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2li aWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3Uu DQo8bzpwPjwvbzpwPjwvcD4NCjxwPkVFIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xh bmQgYW5kIFdhbGVzPGJyPg0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjE8YnI+ DQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXks IEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJ U0NMQUlNRVI8QlI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGlu dGVuZGVkIA0KZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0Kbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Ns b3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1v bml0b3IgYWxsIGluY29taW5nIA0KYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3Vy cmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byANCmVuc3VyZSB0aGF0IHRo aXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQg cmVtYWlucyANCnlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIDwvUD4NCjxQPkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIGFuZCBXYWxlczxCUj5Db21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAy MzgyMTYxPEJSPlJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1 aXRvIFdheSwgSGF0ZmllbGQsIA0KSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L1A+DQo8UD4mbmJz cDs8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B21303E08E9CUK30S005EXS06EE_-- From nobody Wed Feb 18 01:49:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2821A86FC for ; Wed, 18 Feb 2015 01:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dcjna2VYMWq for ; Wed, 18 Feb 2015 01:49:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8121A870E for ; Wed, 18 Feb 2015 01:49:49 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3174922C3E4; Wed, 18 Feb 2015 10:49:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0CAC44C114; Wed, 18 Feb 2015 10:49:48 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 10:49:47 +0100 From: To: Lorenzo Colitti , "Heatley, Nick" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQS0wweECH9cbgt0ubFtZnFdWxx5z2KIIw Date: Wed, 18 Feb 2015 09:49:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490D66A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490D66AOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:49:53 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490D66AOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KSSBkb27igJl0IGtub3cgd2hvIGlzIGFkdm9jYXRpbmcgZm9yIOKAnHRoZW4g dGhlIHJpZ2h0IHN0cmF0ZWd5IGlzICpub3QqIHRvIG1ha2UgYSBsaXN0IG9mIGFsbCB0aGUgZmVh dHVyZXMgdW5kZXIgdGhlIHN1biwgd2FpdCB1bnRpbCB0aGV5IGhhdmUgYWxsIGJlZW4gaW1wbGVt ZW50ZWQsIGFuZCBkZXBsb3kgdGhlbS7igJ0gISENCg0KSSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkg dGhpcyBpcyBub3QgdGhlIHBvc2l0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCkNoZWVycywNCk1lZA0K DQpEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBMb3JlbnpvIENvbGl0dGkNCkVudm95w6kgOiBtZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDA4 OjI2DQrDgCA6IEhlYXRsZXksIE5pY2sNCkNjIDogSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3Jn KQ0KT2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJv ZmlsZSBsYXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUdWUsIEZlYiAxNywgMjAx NSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFpbHRv Om5pY2suaGVhdGxleUBlZS5jby51az4+IHdyb3RlOg0KSSBjYW4gc2VlIHdoeSB5b3UgYXJndWUg Zm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLg0KSSB0aGlu ayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDigJxo YXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFu ZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGlnaHRseSBoaWdoZXIg YmFyIHRoYXQgaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNvbGxl Y3RpdmU7IHdoYXQgeW91IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKAnS4NCg0KV2hhdCBJJ20g c2F5aW5nIGlzIHRoYXQgaWYgeW91ciBnb2FsIGlzIElQdjYgZGVwbG95bWVudCBpbiBhIHJlYXNv bmFibGUgdGltZWZyYW1lLCB0aGVuIHRoZSByaWdodCBzdHJhdGVneSBpcyAqbm90KiB0byBtYWtl IGEgbGlzdCBvZiBhbGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4sIHdhaXQgdW50aWwgdGhl eSBoYXZlIGFsbCBiZWVuIGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0uIEEgYmV0dGVyIHN0 cmF0ZWd5IGlzIHRvIHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0 ZXN0IGFuZCBkZXBsb3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBl dm9sdmVzIGFuZCBJUHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBi ZWNvbWUgaGlnaGVyIHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGltcGxl bWVudGVkLg0KDQpPbiBUdWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNr IDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51az4+IHdy b3RlOg0KVGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFwcHJvYWNoLCBJIGhhdmUgbm8gZG91 YnQgaXQgd29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUgdG8gYWxsIG1vYmlsZSBvcGVyYXRvcnM/ DQpGb3IgbWUsIGl0IGhhcyBzb21lIGxpbWl0YXRpb25zOg0KDQotICAgICAgICAgIFRoZSBvcGVy YXRvciBtdXN0IGhhdmUgdG9wIGRvd24gYmFja2luZyBmb3IgYSB0ZXJtaW5hbCBwb2xpY3kgb2Yg 4oCcSVB2NiBvciB5b3UgYXJlIG91dOKAnSAobm93IHRoYXQgaXMgYSB3aWxkY2FyZCBjb25kaXRp b24gaW4gaXRzZWxmKTsgaXQgbWF5IGNvbXByb21pc2UgcmVsYXRpb25zaGlwcyBpbiBhIHZhbHVh YmxlIGVjb3N5c3RlbQ0KDQotICAgICAgICAgIFdoZXJlIHRoZSBvcGVyYXRvciBoYXMgaGlnaCBt YWpvciBtYXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1hcmtldHMgaGF2ZSBhIG51bWJlciBvZiBw bGF5ZXJzIHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2FtZSwgdGhlcmUgaXMgYW4gYWR2YW50YWdl LiBPdGhlcndpc2UgdGhlIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUgYW5kIGNv bnF1ZXINCg0KLSAgICAgICAgICBDdXJyZW50bHkgaXQgdGVuZHMgdG8gcGxheSBvdXQgYXMgYSB0 aGUgc2ltcGxlc3Qgc2V0IG9mIHJlcXVpcmVtZW50cy4gV2hpY2ggYWxzbyBtZWFucyBzaW1wbGVz dCBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMuIFNvbWV0aW1lcyB0aGVzZSBzaW1wbGVzdCBz ZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMgYXJlIGF0IG9kZHMgd2l0aCB0aGUgYnVzaW5lc3Mg cHJpb3JpdGllcyBvZiB0aGUgb3BlcmF0b3IgKGNsZWFyIGV4YW1wbGVzIGFyZTogQVBOIHN0cmF0 ZWd5LCB0ZXRoZXJpbmcgYXBwcm9hY2gsIHJvYW1pbmcgYXBwcm9hY2gsIHN1YnNpZGlzZWQgaGFu ZHNldCB2cyDigJxTSU0tb25seeKAnSkNCihOb3QgaGF2aW5nIGFuIElQdjYgY2FwYWJsZSBuZXR3 b3JrIGlzIGEgbXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQgb3BlcmF0b3Igdmll d3MsIGl0IGlzIGEgcmVkIGhlcnJpbmcg4oCTIGFueSBvcGVyYXRvciBzcGVjaWZ5aW5nICphbnkq IElQdjYgcmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhpcyBjYXBhYmlsaXR5 IHRvIHZhbGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5IGNob29zZS4pDQoN CkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIG9m IHY2IHJlcXVpcmVtZW50cy4NCkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3Jr IGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLg0KVGhlIG90 aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFuZCB0cnlpbmcg dG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9uYWwg cmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICDigJxoYXJtZnVs bHkgYnJvYWTigJ0uDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bn b29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+XQ0KU2VudDogMTcgRmVicnVhcnkg MjAxNSAwMjo0MQ0KVG86IEhlYXRsZXksIE5pY2sNCkNjOiBSb3NzIENoYW5kbGVyOyBJUHY2IE9w cyBXRyAodjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPikNClN1YmplY3Q6IFJl OiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2Fs bC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDEwOjU3IEFN LCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29n bGUuY29tPj4gd3JvdGU6DQpZZXMuIE1ha2UgSVB2NiogKHNlZSBiZWxvdykgYSByZXF1aXJlbWVu dCBmb3IgY2Fycmllci1icmFuZGVkIGRldmljZXMsIGFuZCBnaXZlIHRoZSBPRU1zIGEgY3JlZGli bGUgc2lnbmFsIHRoYXQgZnJvbSBkYXRlIFggb253YXJkcywgeW91ICp3aWxsKiBmYWlsIFRBIG9u IGV2ZXJ5IGRldmljZSB0aGF0IGRvZXNuJ3QgaW1wbGVtZW50IElQdjYsIGFuZCB5b3UgKndpbGwg bm90KiB3YWl2ZSB0aGUgcmVxdWlyZW1lbnQuIFRoYXQncyB3aGF0IFZlcml6b24gYW5kIFQtTW9i aWxlIGRpZCwgYW5kIGl0IHdvcmtlZCBmb3IgdGhlbS4NCg0KQWxzbzogaWYgeW91IHRoaW5rIHRo YXQgdGhpcyBzdHJhdGVneSBpcyBub3QgZmVhc2libGUgYmVjYXVzZSB5b3UgZG8gbm90IGhhdmUg YW4gSVB2NiBuZXR3b3JrIHlldCwgdGhlbiB5ZXMsIHRoYXQncyB0cnVlIC0geW91IGNhbid0IG1h a2UgSVB2NiBhIGRldmljZSByZXF1aXJlbWVudCB1bnRpbCB5b3UgaGF2ZSBhbiBJUHY2IG5ldHdv cmsuDQoNCkJ1dCBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyB0aGF0IGFwYXJ0IGZyb20g dGhlIGxhY2sgb2YgNDY0eGxhdCBvbiBpT1MsIHRoZSBtb2JpbGUgb3BlcmF0aW5nIHN5c3RlbXMg YXJlIGEgbG90IG1vcmUgcmVhZHkgZm9yIElQdjYgdGhhbiB5b3UgbWlnaHQgdGhpbmsgdGhleSBh cmUuIE9uY2UgdGhlIG5ldHdvcmsgaXMgY29tcGxldGUsIEkgdGhpbmsgdHVybmluZyBvbiBJUHY2 IGluIHRoZSBkZXZpY2VzIGRvZXMgd29yay4gT3JhbmdlIFBvbGFuZCwgVGVsZW5vciwgYW5kIFNL IFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29uZmlybS4NCg0KTk9USUNFIEFORCBESVNDTEFJ TUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQg Zm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMg ZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55 IHB1cnBvc2UuDQoNCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1h aWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBz IHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20g YW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0 aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KDQpFRSBMaW1pdGVkDQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVy OiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9z cXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcNCg0KDQoNCg== --_000_787AE7BB302AE849A7480A190F8B93300490D66AOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5Mb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG9u4oCZdCBrbm93 IHdobyBpcyBhZHZvY2F0aW5nIGZvciDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij50aGVuIHRoZSByaWdodCBzdHJhdGVneSBpcyZuYnNwOypub3QqDQog dG8gbWFrZSBhIGxpc3Qgb2YgYWxsIHRoZSBmZWF0dXJlcyB1bmRlciB0aGUgc3VuLCB3YWl0IHVu dGlsIHRoZXkgaGF2ZSBhbGwgYmVlbiBpbXBsZW1lbnRlZCwgYW5kIGRlcGxveSB0aGVtLuKAnSAh ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5JIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSB0aGlzIGlzIG5vdCB0aGUgcG9zaXRpb24g b2YgdGhpcyBkcmFmdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5NZWQ8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9w cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTG9yZW56byBDb2xpdHRp PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDE4IGbDqXZyaWVyIDIwMTUgMDg6 MjY8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgODoz MSBQTSwgSGVhdGxleSwgTmljayAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2suaGVhdGxleUBlZS5j by51ayIgdGFyZ2V0PSJfYmxhbmsiPm5pY2suaGVhdGxleUBlZS5jby51azwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBj YW4gc2VlIHdoeSB5b3UgYXJndWUgZm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYg cmVxdWlyZW1lbnRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlz IGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCd Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBvdGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBk aWZmZXJlbmNlcyBhbmQgdHJ5aW5nIHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlcg0KIGJhciB0aGF0 IGhpZ2hsaWdodHMgY29uZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3 aGF0IHlvdSBjYWxsICZuYnNwO+KAnGhhcm1mdWxseSBicm9hZOKAnS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEknbSBzYXlpbmcgaXMgdGhhdCBpZiB5b3VyIGdv YWwgaXMgSVB2NiBkZXBsb3ltZW50IGluIGEgcmVhc29uYWJsZSB0aW1lZnJhbWUsIHRoZW4gdGhl IHJpZ2h0IHN0cmF0ZWd5IGlzJm5ic3A7Km5vdCogdG8gbWFrZSBhIGxpc3Qgb2YgYWxsIHRoZSBm ZWF0dXJlcyB1bmRlciB0aGUgc3VuLCB3YWl0IHVudGlsIHRoZXkgaGF2ZSBhbGwgYmVlbiBpbXBs ZW1lbnRlZCwgYW5kIGRlcGxveSB0aGVtLiBBIGJldHRlciBzdHJhdGVneQ0KIGlzIHRvIHN0YXJ0 IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBsb3kgdGhv c2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJUHY2IGJl Y29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVyIHByaW9y aXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGltcGxlbWVudGVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgODozMSBQTSwgSGVhdGxleSwgTmljayAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPm5pY2su aGVhdGxleUBlZS5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFw cHJvYWNoLCBJIGhhdmUgbm8gZG91YnQgaXQgd29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUNCiB0 byBhbGwgbW9iaWxlIG9wZXJhdG9ycz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgbWUsIGl0IGhhcyBzb21l IGxpbWl0YXRpb25zOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG9wZXJhdG9yIG11c3QgaGF2ZSB0b3AgZG93biBiYWNr aW5nIGZvciBhIHRlcm1pbmFsIHBvbGljeSBvZiDigJxJUHY2IG9yIHlvdSBhcmUgb3V04oCdIChu b3cgdGhhdCBpcyBhIHdpbGRjYXJkIGNvbmRpdGlvbiBpbiBpdHNlbGYpOyBpdCBtYXkgY29tcHJv bWlzZSByZWxhdGlvbnNoaXBzDQogaW4gYSB2YWx1YWJsZSBlY29zeXN0ZW08L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZXJl IHRoZSBvcGVyYXRvciBoYXMgaGlnaCBtYWpvciBtYXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1h cmtldHMgaGF2ZSBhIG51bWJlciBvZiBwbGF5ZXJzIHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2Ft ZSwgdGhlcmUgaXMgYW4gYWR2YW50YWdlLiBPdGhlcndpc2UgdGhlDQogb3BlcmF0b3IgaXMgdmVy eSBleHBvc2VkIHRvIGRpdmlkZSBhbmQgY29ucXVlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3VycmVudGx5IGl0IHRlbmRz IHRvIHBsYXkgb3V0IGFzIGEgdGhlIHNpbXBsZXN0IHNldCBvZiByZXF1aXJlbWVudHMuIFdoaWNo IGFsc28gbWVhbnMgc2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsgY2FwYWJpbGl0aWVzLiBTb21ldGlt ZXMgdGhlc2Ugc2ltcGxlc3Qgc2V0IG9mDQogbmV0d29yayBjYXBhYmlsaXRpZXMgYXJlIGF0IG9k ZHMgd2l0aCB0aGUgYnVzaW5lc3MgcHJpb3JpdGllcyBvZiB0aGUgb3BlcmF0b3IgKGNsZWFyIGV4 YW1wbGVzIGFyZTogQVBOIHN0cmF0ZWd5LCB0ZXRoZXJpbmcgYXBwcm9hY2gsIHJvYW1pbmcgYXBw cm9hY2gsIHN1YnNpZGlzZWQgaGFuZHNldCB2cyDigJxTSU0tb25seeKAnSk8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4oTm90IGhhdmluZyBhbiBJUHY2IGNhcGFibGUgbmV0d29yayBpcyBhIG15dGggeW91IGFyZSBw cm9tb3RpbmcgdG8gZGlzY3JlZGl0IG9wZXJhdG9yDQogdmlld3MsIGl0IGlzIGEgcmVkIGhlcnJp bmcg4oCTIGFueSBvcGVyYXRvciBzcGVjaWZ5aW5nICo8Yj5hbnk8L2I+KiBJUHY2IHJlcXVpcmVt ZW50cyB3aWxsIHZlcnkgcXVpY2tseSBuZWVkIHRoaXMgY2FwYWJpbGl0eSB0byB2YWxpZGF0ZSB0 ZXJtaW5hbHMgd2hhdGV2ZXIgdGhlIHBhdGggdGhleSBjaG9vc2UuKTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29t bW9uIGRlbm9taW5hdG9yIG9mIHY2IHJlcXVpcmVtZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5r IHlvdXIgc3RhbmNlIHRoYXQgdGhpcyBjYW4gd29yayBhY3Jvc3MgdGhlIGJvYXJkIGlzIOKAnGhh cm1mdWxseSByZXN0cmljdGl2ZeKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3RoZXIgYXBwcm9hY2gg aXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGln aHRseSBoaWdoZXINCiBiYXIgdGhhdCBoaWdobGlnaHRzIGNvbmRpdGlvbmFsIHJlcXVpcmVtZW50 cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hhdCB5b3UgY2FsbCAmbmJzcDvigJxoYXJtZnVsbHkgYnJv YWTigJ0uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVu em8NCiBDb2xpdHRpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gMTcgRmVicnVhcnkgMjAxNSAwMjo0MTxicj4NCjxiPlRvOjwvYj4gSGVhdGxleSwgTmljazxi cj4NCjxiPkNjOjwvYj4gUm9zcyBDaGFuZGxlcjsgSVB2NiBPcHMgV0cgKDxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPik8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj5PbiBUdWUsIEZlYiAxNywgMjAxNSBhdCAxMDo1NyBBTSwgTG9yZW56byBDb2xpdHRp ICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+WWVzLiBNYWtlIElQdjYqIChzZWUgYmVsb3cpIGEg cmVxdWlyZW1lbnQgZm9yIGNhcnJpZXItYnJhbmRlZCBkZXZpY2VzLCBhbmQgZ2l2ZSB0aGUgT0VN cyBhIGNyZWRpYmxlIHNpZ25hbCB0aGF0IGZyb20gZGF0ZSBYIG9ud2FyZHMsIHlvdSAqd2lsbCog ZmFpbCBUQSBvbiBldmVyeQ0KIGRldmljZSB0aGF0IGRvZXNuJ3QgaW1wbGVtZW50IElQdjYsIGFu ZCB5b3UgKndpbGwgbm90KiB3YWl2ZSB0aGUgcmVxdWlyZW1lbnQuIFRoYXQncyB3aGF0IFZlcml6 b24gYW5kIFQtTW9iaWxlIGRpZCwgYW5kIGl0IHdvcmtlZCBmb3IgdGhlbS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj5BbHNvOiBpZiB5b3UgdGhpbmsgdGhhdCB0aGlzIHN0cmF0ZWd5IGlzIG5vdCBmZWFz aWJsZSBiZWNhdXNlIHlvdSBkbyBub3QgaGF2ZSBhbiBJUHY2IG5ldHdvcmsgeWV0LCB0aGVuIHll cywgdGhhdCdzIHRydWUgLSB5b3UgY2FuJ3QgbWFrZSBJUHY2IGEgZGV2aWNlIHJlcXVpcmVtZW50 DQogdW50aWwgeW91IGhhdmUgYW4gSVB2NiBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkJ1dCBJIHRoaW5rIHRoZSBrZXkgcG9pbnQg aGVyZSBpcyB0aGF0IGFwYXJ0IGZyb20gdGhlIGxhY2sgb2YgNDY0eGxhdCBvbiBpT1MsIHRoZSBt b2JpbGUgb3BlcmF0aW5nIHN5c3RlbXMgYXJlIGEgbG90IG1vcmUgcmVhZHkgZm9yIElQdjYgdGhh biB5b3UgbWlnaHQgdGhpbmsNCiB0aGV5IGFyZS4gT25jZSB0aGUgbmV0d29yayBpcyBjb21wbGV0 ZSwgSSB0aGluayB0dXJuaW5nIG9uIElQdjYgaW4gdGhlIGRldmljZXMgZG9lcyB3b3JrLiBPcmFu Z2UgUG9sYW5kLCBUZWxlbm9yLCBhbmQgU0sgVGVsZWNvbSBzaG91bGQgYmUgYWJsZSB0byBjb25m aXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPk5PVElDRSBB TkQgRElTQ0xBSU1FUjxicj4NClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz KSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4mbmJzcDsgSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNj bG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOw0KPGJyPg0KJm5ic3A7PGJyPg0KV2Ug bWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRo IGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQg dGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBp dCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+RUUgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQg V2FsZXM8YnI+DQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MTxicj4NClJlZ2lz dGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0Zmll bGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300490D66AOPEXCLILM23corp_-- From nobody Wed Feb 18 01:54:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3C81A86FC for ; Wed, 18 Feb 2015 01:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZgjoIZazI8T for ; Wed, 18 Feb 2015 01:54:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514331A86F1 for ; Wed, 18 Feb 2015 01:54:26 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 565CFC022C; Wed, 18 Feb 2015 10:54:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2D555158178; Wed, 18 Feb 2015 10:54:24 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 10:54:24 +0100 From: To: "Heatley, Nick" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAFtSIAABXhFiAAAXD/SAAI6wAAAABhtuAABDDgdAAK3XWgAADyfKQAAFAAlA= Date: Wed, 18 Feb 2015 09:54:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490D690OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:54:30 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490D690OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KSSBmdWxseSBhZ3JlZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEhlYXRsZXksIE5p Y2sNCkVudm95w6kgOiBtZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDEwOjM1DQrDgCA6IExvcmVu em8gQ29saXR0aQ0KQ2MgOiBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpDQpPYmpldCA6IFJl OiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2Fs bC0gImhhcm1mdWxseSBicm9hZCI/DQoNClllcywgSSBhZ3JlZSB3aXRoIHlvdSwgdGhhdCBpcyBh IHNlbnNpYmxlIGFwcHJvYWNoLg0KV29ya2luZyB3aXRoIGVhY2ggdmVuZG9yIGluIHR1cm4uDQoo WW91IGtub3cgZWFjaCB2ZW5kb3Igd2hvIGNsYWltcyBJUHY2IHJlYWRpbmVzcyBmb3IgdGhlaXIg dGVybWluYWwsIHdpbGwgbmV2ZXIgc2F5IHdoZXRoZXIgdGhlIGRldmljZSB3aWxsIHdvcmsgb24g dGhlIG9wZXJhdG9ycyBJUHY2IG5ldHdvcmsuDQpTbyBpdCBuZWVkcyB0byBiZSBjb2xsYWJvcmF0 aXZlLikNCg0KU28gYWxsIHRoaXMgZG9jdW1lbnQgaXMgZG9pbmcgaXMgc2V0dGluZyBhIGNvbGxl Y3RpdmUgcm9hZG1hcCwgcmF0aGVyIHRoYW4gZXhwZWN0IHZlbmRvcnMgdG8gZG8gdGhlaXIgb3du IHRoaW5nLiBHaXZlbiB3ZSBhZ3JlZSBvbiB0aGUgYWJvdmUsIHRoaXMgaXMgbm90IGhhcm1mdWwu DQoNCkkgdGhpbmsgdGhlIHJlYWwgZGlzYWdyZWVtZW50IGNvbWVzIGZyb20geW91ciBvcGluaW9u IHRoYXQgdGhpcyBpcyBub3QgSUVURi4NCihCeSB0aGUgd2F5LCBtb2JpbGUgb3BlcmF0b3JzIGhh dmUgaGFkIGRpc2N1c3Npb25zIHdpdGggdGhlIHNpc3RlciBvcmcgb2YgdGhlIEludGVybmV0IFNv Y2lldHkgYWJvdXQgd2hhdCB3b3VsZCBoZWxwIG1vYmlsZSBvcGVyYXRvcnMgaW50cm9kdWNlIElQ djYuDQpPbmUgb2YgdGhlIG1ham9yIG1ham9yIHRoZW1lcyBoYXMgYmVlbiB0ZXJtaW5hbHMuKQ0K DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNl bnQ6IDE4IEZlYnJ1YXJ5IDIwMTUgMDc6MjYNClRvOiBIZWF0bGV5LCBOaWNrDQpDYzogUm9zcyBD aGFuZGxlcjsgSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4pDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2Ut cHJvZmlsZSBsYXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUdWUsIEZlYiAxNywg MjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFp bHRvOm5pY2suaGVhdGxleUBlZS5jby51az4+IHdyb3RlOg0KSSBjYW4gc2VlIHdoeSB5b3UgYXJn dWUgZm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLg0KSSB0 aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDi gJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJz dGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGlnaHRseSBoaWdo ZXIgYmFyIHRoYXQgaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNv bGxlY3RpdmU7IHdoYXQgeW91IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKAnS4NCg0KV2hhdCBJ J20gc2F5aW5nIGlzIHRoYXQgaWYgeW91ciBnb2FsIGlzIElQdjYgZGVwbG95bWVudCBpbiBhIHJl YXNvbmFibGUgdGltZWZyYW1lLCB0aGVuIHRoZSByaWdodCBzdHJhdGVneSBpcyAqbm90KiB0byBt YWtlIGEgbGlzdCBvZiBhbGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4sIHdhaXQgdW50aWwg dGhleSBoYXZlIGFsbCBiZWVuIGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0uIEEgYmV0dGVy IHN0cmF0ZWd5IGlzIHRvIHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVk LCB0ZXN0IGFuZCBkZXBsb3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3Ry eSBldm9sdmVzIGFuZCBJUHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2ls bCBiZWNvbWUgaGlnaGVyIHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGlt cGxlbWVudGVkLg0KDQpPbiBUdWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBO aWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51az4+ IHdyb3RlOg0KVGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFwcHJvYWNoLCBJIGhhdmUgbm8g ZG91YnQgaXQgd29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUgdG8gYWxsIG1vYmlsZSBvcGVyYXRv cnM/DQpGb3IgbWUsIGl0IGhhcyBzb21lIGxpbWl0YXRpb25zOg0KDQotICAgICAgICAgIFRoZSBv cGVyYXRvciBtdXN0IGhhdmUgdG9wIGRvd24gYmFja2luZyBmb3IgYSB0ZXJtaW5hbCBwb2xpY3kg b2Yg4oCcSVB2NiBvciB5b3UgYXJlIG91dOKAnSAobm93IHRoYXQgaXMgYSB3aWxkY2FyZCBjb25k aXRpb24gaW4gaXRzZWxmKTsgaXQgbWF5IGNvbXByb21pc2UgcmVsYXRpb25zaGlwcyBpbiBhIHZh bHVhYmxlIGVjb3N5c3RlbQ0KDQotICAgICAgICAgIFdoZXJlIHRoZSBvcGVyYXRvciBoYXMgaGln aCBtYWpvciBtYXJrZXQgcG93ZXIgaGVscHMuIFdoZXJlIG1hcmtldHMgaGF2ZSBhIG51bWJlciBv ZiBwbGF5ZXJzIHJlYWR5IHRvIHBsYXkgdGhlIElQdjYgZ2FtZSwgdGhlcmUgaXMgYW4gYWR2YW50 YWdlLiBPdGhlcndpc2UgdGhlIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUgYW5k IGNvbnF1ZXINCg0KLSAgICAgICAgICBDdXJyZW50bHkgaXQgdGVuZHMgdG8gcGxheSBvdXQgYXMg YSB0aGUgc2ltcGxlc3Qgc2V0IG9mIHJlcXVpcmVtZW50cy4gV2hpY2ggYWxzbyBtZWFucyBzaW1w bGVzdCBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMuIFNvbWV0aW1lcyB0aGVzZSBzaW1wbGVz dCBzZXQgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMgYXJlIGF0IG9kZHMgd2l0aCB0aGUgYnVzaW5l c3MgcHJpb3JpdGllcyBvZiB0aGUgb3BlcmF0b3IgKGNsZWFyIGV4YW1wbGVzIGFyZTogQVBOIHN0 cmF0ZWd5LCB0ZXRoZXJpbmcgYXBwcm9hY2gsIHJvYW1pbmcgYXBwcm9hY2gsIHN1YnNpZGlzZWQg aGFuZHNldCB2cyDigJxTSU0tb25seeKAnSkNCihOb3QgaGF2aW5nIGFuIElQdjYgY2FwYWJsZSBu ZXR3b3JrIGlzIGEgbXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQgb3BlcmF0b3Ig dmlld3MsIGl0IGlzIGEgcmVkIGhlcnJpbmcg4oCTIGFueSBvcGVyYXRvciBzcGVjaWZ5aW5nICph bnkqIElQdjYgcmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhpcyBjYXBhYmls aXR5IHRvIHZhbGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5IGNob29zZS4p DQoNCkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9y IG9mIHY2IHJlcXVpcmVtZW50cy4NCkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3 b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLg0KVGhl IG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFuZCB0cnlp bmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9u YWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICDigJxoYXJt ZnVsbHkgYnJvYWTigJ0uDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56 b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+XQ0KU2VudDogMTcgRmVicnVh cnkgMjAxNSAwMjo0MQ0KVG86IEhlYXRsZXksIE5pY2sNCkNjOiBSb3NzIENoYW5kbGVyOyBJUHY2 IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPikNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDEwOjU3 IEFNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bn b29nbGUuY29tPj4gd3JvdGU6DQpZZXMuIE1ha2UgSVB2NiogKHNlZSBiZWxvdykgYSByZXF1aXJl bWVudCBmb3IgY2Fycmllci1icmFuZGVkIGRldmljZXMsIGFuZCBnaXZlIHRoZSBPRU1zIGEgY3Jl ZGlibGUgc2lnbmFsIHRoYXQgZnJvbSBkYXRlIFggb253YXJkcywgeW91ICp3aWxsKiBmYWlsIFRB IG9uIGV2ZXJ5IGRldmljZSB0aGF0IGRvZXNuJ3QgaW1wbGVtZW50IElQdjYsIGFuZCB5b3UgKndp bGwgbm90KiB3YWl2ZSB0aGUgcmVxdWlyZW1lbnQuIFRoYXQncyB3aGF0IFZlcml6b24gYW5kIFQt TW9iaWxlIGRpZCwgYW5kIGl0IHdvcmtlZCBmb3IgdGhlbS4NCg0KQWxzbzogaWYgeW91IHRoaW5r IHRoYXQgdGhpcyBzdHJhdGVneSBpcyBub3QgZmVhc2libGUgYmVjYXVzZSB5b3UgZG8gbm90IGhh dmUgYW4gSVB2NiBuZXR3b3JrIHlldCwgdGhlbiB5ZXMsIHRoYXQncyB0cnVlIC0geW91IGNhbid0 IG1ha2UgSVB2NiBhIGRldmljZSByZXF1aXJlbWVudCB1bnRpbCB5b3UgaGF2ZSBhbiBJUHY2IG5l dHdvcmsuDQoNCkJ1dCBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyB0aGF0IGFwYXJ0IGZy b20gdGhlIGxhY2sgb2YgNDY0eGxhdCBvbiBpT1MsIHRoZSBtb2JpbGUgb3BlcmF0aW5nIHN5c3Rl bXMgYXJlIGEgbG90IG1vcmUgcmVhZHkgZm9yIElQdjYgdGhhbiB5b3UgbWlnaHQgdGhpbmsgdGhl eSBhcmUuIE9uY2UgdGhlIG5ldHdvcmsgaXMgY29tcGxldGUsIEkgdGhpbmsgdHVybmluZyBvbiBJ UHY2IGluIHRoZSBkZXZpY2VzIGRvZXMgd29yay4gT3JhbmdlIFBvbGFuZCwgVGVsZW5vciwgYW5k IFNLIFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29uZmlybS4NCg0KTk9USUNFIEFORCBESVND TEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5k ZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRo aXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBmb3Ig YW55IHB1cnBvc2UuDQoNCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcg ZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0 ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZy b20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3Vy ZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KDQpFRSBMaW1pdGVk DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVt YmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwg TW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcNCg0KDQoNCg0K Tk9USUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Ns b3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuDQoNCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWlu ZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBX ZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1l bnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNp YmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91 Lg0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55 IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczog VHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwx MCA5QlcNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B93300490D690OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJh bGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9y OmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBOaWNr LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SSBmdWxseSBhZ3JlZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUg bGEgcGFydCBkZTwvYj4gSGVhdGxleSwgTmljazxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBt ZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDEwOjM1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBMb3Jl bnpvIENvbGl0dGk8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRm Lm9yZyk8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2Fk JnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVz LCBJIGFncmVlIHdpdGggeW91LCB0aGF0IGlzIGEgc2Vuc2libGUgYXBwcm9hY2guPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Xb3JraW5nIHdpdGggZWFjaCB2ZW5k b3IgaW4gdHVybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihZ b3Uga25vdyBlYWNoIHZlbmRvciB3aG8gY2xhaW1zIElQdjYgcmVhZGluZXNzIGZvciB0aGVpciB0 ZXJtaW5hbCwgd2lsbCBuZXZlciBzYXkgd2hldGhlciB0aGUgZGV2aWNlIHdpbGwgd29yayBvbiB0 aGUgb3BlcmF0b3JzIElQdjYgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlNvIGl0IG5lZWRzIHRvIGJlIGNvbGxhYm9yYXRpdmUuKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBhbGwgdGhpcyBkb2N1bWVudCBpcyBkb2luZyBp cyBzZXR0aW5nIGEgY29sbGVjdGl2ZSByb2FkbWFwLCByYXRoZXIgdGhhbiBleHBlY3QgdmVuZG9y cyB0byBkbyB0aGVpciBvd24gdGhpbmcuIEdpdmVuIHdlIGFncmVlIG9uIHRoZSBhYm92ZSwgdGhp cw0KIGlzIG5vdCBoYXJtZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHRoaW5rIHRoZSByZWFsIGRpc2FncmVlbWVudCBjb21lcyBmcm9tIHlvdXIgb3BpbmlvbiB0aGF0 IHRoaXMgaXMgbm90IElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4oQnkgdGhlIHdheSwgbW9iaWxlIG9wZXJhdG9ycyBoYXZlIGhhZCBkaXNjdXNzaW9ucyB3 aXRoIHRoZSBzaXN0ZXIgb3JnIG9mIHRoZSBJbnRlcm5ldCBTb2NpZXR5IGFib3V0IHdoYXQgd291 bGQgaGVscCBtb2JpbGUgb3BlcmF0b3JzIGludHJvZHVjZQ0KIElQdjYuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgb2YgdGhlIG1ham9yIG1ham9yIHRoZW1l cyBoYXMgYmVlbiB0ZXJtaW5hbHMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg WzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPm1haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEZlYnJ1YXJ5IDIwMTUgMDc6MjY8YnI+ DQo8Yj5Ubzo8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgQ2hhbmRsZXI7 IElQdjYgT3BzIFdHICg8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYu b3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9w cy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQm cXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBUdWUsIEZl YiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrICZsdDs8YSBocmVmPSJtYWlsdG86 bmljay5oZWF0bGV5QGVlLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+bmljay5oZWF0bGV5QGVlLmNv LnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjYW4gc2VlIHdoeSB5b3UgYXJndWUgZm9yIGxvd2VzdCBj b21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCc aGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBvdGhlciBhcHByb2Fj aCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBkaWZmZXJlbmNlcyBhbmQgdHJ5aW5nIHRvIHNldCBhIHNs aWdodGx5IGhpZ2hlcg0KIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9uYWwgcmVxdWlyZW1l bnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICZuYnNwO+KAnGhhcm1mdWxseSBi cm9hZOKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5XaGF0IEknbSBzYXlpbmcgaXMgdGhh dCBpZiB5b3VyIGdvYWwgaXMgSVB2NiBkZXBsb3ltZW50IGluIGEgcmVhc29uYWJsZSB0aW1lZnJh bWUsIHRoZW4gdGhlIHJpZ2h0IHN0cmF0ZWd5IGlzJm5ic3A7Km5vdCogdG8gbWFrZSBhIGxpc3Qg b2YgYWxsIHRoZSBmZWF0dXJlcyB1bmRlciB0aGUgc3VuLCB3YWl0IHVudGlsIHRoZXkgaGF2ZSBh bGwgYmVlbiBpbXBsZW1lbnRlZCwgYW5kIGRlcGxveQ0KIHRoZW0uIEEgYmV0dGVyIHN0cmF0ZWd5 IGlzIHRvIHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0ZXN0IGFu ZCBkZXBsb3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBldm9sdmVz IGFuZCBJUHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBiZWNvbWUg aGlnaGVyIHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGltcGxlbWVudGVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sg Jmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrLmhlYXRsZXlAZWUuY28udWsiIHRhcmdldD0iX2JsYW5r Ij5uaWNrLmhlYXRsZXlAZWUuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHRoZSBnYW1l IG9mIGNoaWNrZW4gYXBwcm9hY2gsIEkgaGF2ZSBubyBkb3VidCBpdCB3b3JrcywgYnV0IGlzIGl0 IGluY2x1c2l2ZQ0KIHRvIGFsbCBtb2JpbGUgb3BlcmF0b3JzPzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBt ZSwgaXQgaGFzIHNvbWUgbGltaXRhdGlvbnM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3BlcmF0b3IgbXVzdCBoYXZl IHRvcCBkb3duIGJhY2tpbmcgZm9yIGEgdGVybWluYWwgcG9saWN5IG9mIOKAnElQdjYgb3IgeW91 IGFyZSBvdXTigJ0gKG5vdyB0aGF0IGlzIGEgd2lsZGNhcmQgY29uZGl0aW9uIGluIGl0c2VsZik7 IGl0IG1heSBjb21wcm9taXNlIHJlbGF0aW9uc2hpcHMNCiBpbiBhIHZhbHVhYmxlIGVjb3N5c3Rl bTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2hlcmUgdGhlIG9wZXJhdG9yIGhhcyBoaWdoIG1ham9yIG1hcmtldCBwb3dlciBo ZWxwcy4gV2hlcmUgbWFya2V0cyBoYXZlIGEgbnVtYmVyIG9mIHBsYXllcnMgcmVhZHkgdG8gcGxh eSB0aGUgSVB2NiBnYW1lLCB0aGVyZSBpcyBhbiBhZHZhbnRhZ2UuIE90aGVyd2lzZSB0aGUNCiBv cGVyYXRvciBpcyB2ZXJ5IGV4cG9zZWQgdG8gZGl2aWRlIGFuZCBjb25xdWVyPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DdXJy ZW50bHkgaXQgdGVuZHMgdG8gcGxheSBvdXQgYXMgYSB0aGUgc2ltcGxlc3Qgc2V0IG9mIHJlcXVp cmVtZW50cy4gV2hpY2ggYWxzbyBtZWFucyBzaW1wbGVzdCBzZXQgb2YgbmV0d29yayBjYXBhYmls aXRpZXMuIFNvbWV0aW1lcyB0aGVzZSBzaW1wbGVzdCBzZXQgb2YNCiBuZXR3b3JrIGNhcGFiaWxp dGllcyBhcmUgYXQgb2RkcyB3aXRoIHRoZSBidXNpbmVzcyBwcmlvcml0aWVzIG9mIHRoZSBvcGVy YXRvciAoY2xlYXIgZXhhbXBsZXMgYXJlOiBBUE4gc3RyYXRlZ3ksIHRldGhlcmluZyBhcHByb2Fj aCwgcm9hbWluZyBhcHByb2FjaCwgc3Vic2lkaXNlZCBoYW5kc2V0IHZzIOKAnFNJTS1vbmx54oCd KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPihOb3QgaGF2aW5nIGFuIElQdjYgY2FwYWJsZSBuZXR3b3JrIGlzIGEg bXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQgb3BlcmF0b3INCiB2aWV3cywgaXQg aXMgYSByZWQgaGVycmluZyDigJMgYW55IG9wZXJhdG9yIHNwZWNpZnlpbmcgKjxiPmFueTwvYj4q IElQdjYgcmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhpcyBjYXBhYmlsaXR5 IHRvIHZhbGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5IGNob29zZS4pPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjYW4gc2VlIHdoeSB5b3UgYXJndWUg Zm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUg Ym9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBv dGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBkaWZmZXJlbmNlcyBhbmQgdHJ5aW5n IHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlcg0KIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9u YWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICZuYnNwO+KA nGhhcm1mdWxseSBicm9hZOKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTG9yZW56bw0KIENvbGl0dGkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9yZW56 b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bnb29nbGUuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiAxNyBGZWJydWFyeSAyMDE1IDAyOjQxPGJyPg0KPGI+VG86PC9iPiBI ZWF0bGV5LCBOaWNrPGJyPg0KPGI+Q2M6PC9iPiBSb3NzIENoYW5kbGVyOyBJUHY2IE9wcyBXRyAo PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0 Zi5vcmc8L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2 b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90O2hhcm1mdWxseSBicm9h ZCZxdW90Oz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiPk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDEwOjU3IEFNLCBM b3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5ZZXMuIE1ha2UgSVB2Niog KHNlZSBiZWxvdykgYSByZXF1aXJlbWVudCBmb3IgY2Fycmllci1icmFuZGVkIGRldmljZXMsIGFu ZCBnaXZlIHRoZSBPRU1zIGEgY3JlZGlibGUgc2lnbmFsIHRoYXQgZnJvbSBkYXRlIFggb253YXJk cywgeW91ICp3aWxsKiBmYWlsIFRBIG9uIGV2ZXJ5DQogZGV2aWNlIHRoYXQgZG9lc24ndCBpbXBs ZW1lbnQgSVB2NiwgYW5kIHlvdSAqd2lsbCBub3QqIHdhaXZlIHRoZSByZXF1aXJlbWVudC4gVGhh dCdzIHdoYXQgVmVyaXpvbiBhbmQgVC1Nb2JpbGUgZGlkLCBhbmQgaXQgd29ya2VkIGZvciB0aGVt LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiPkFsc286IGlmIHlvdSB0aGluayB0aGF0IHRoaXMgc3RyYXRl Z3kgaXMgbm90IGZlYXNpYmxlIGJlY2F1c2UgeW91IGRvIG5vdCBoYXZlIGFuIElQdjYgbmV0d29y ayB5ZXQsIHRoZW4geWVzLCB0aGF0J3MgdHJ1ZSAtIHlvdSBjYW4ndCBtYWtlIElQdjYgYSBkZXZp Y2UgcmVxdWlyZW1lbnQNCiB1bnRpbCB5b3UgaGF2ZSBhbiBJUHY2IG5ldHdvcmsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QnV0IEkgdGhpbmsg dGhlIGtleSBwb2ludCBoZXJlIGlzIHRoYXQgYXBhcnQgZnJvbSB0aGUgbGFjayBvZiA0NjR4bGF0 IG9uIGlPUywgdGhlIG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcyBhcmUgYSBsb3QgbW9yZSByZWFk eSBmb3IgSVB2NiB0aGFuIHlvdSBtaWdodCB0aGluaw0KIHRoZXkgYXJlLiBPbmNlIHRoZSBuZXR3 b3JrIGlzIGNvbXBsZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2NiBpbiB0aGUgZGV2aWNlcyBk b2VzIHdvcmsuIE9yYW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBTSyBUZWxlY29tIHNob3VsZCBi ZSBhYmxlIHRvIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Tk9USUNFIEFORCBESVNDTEFJTUVSPGJyPg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMp LiZuYnNwOyBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBh bmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7DQo8YnI+DQom bmJzcDs8YnI+DQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWls cyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0 byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFu eSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhh dCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5FRSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kIGFuZCBXYWxlczxicj4NCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgy MTYxPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVp dG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj5OT1RJQ0UgQU5EIERJU0NMQUlNRVI8YnI+DQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocyku Jm5ic3A7IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4mbmJzcDsNCjxicj4NCiZu YnNwOzxicj4NCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxz IGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRv IGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55 IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0 IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkVFIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgYW5kIFdhbGVzPGJyPg0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIx NjE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0 byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490D690OPEXCLILM23corp_-- From nobody Wed Feb 18 02:49:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454C1A9122 for ; Wed, 18 Feb 2015 02:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su-4b7GlZNtj for ; Wed, 18 Feb 2015 02:49:35 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921EF1A872E for ; Wed, 18 Feb 2015 02:49:34 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 10:49:16 +0000 Message-ID: <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net> From: t.petch To: Mark ZZZ Smith , Mark Andrews References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> Date: Wed, 18 Feb 2015 10:27:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0028.eurprd05.prod.outlook.com (25.160.40.38) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) Authentication-Results: yahoo.com.au; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB055; X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(81686999)(44716002)(62236002)(47776003)(44736004)(33646002)(122386002)(66066001)(50986999)(76176999)(14496001)(92566002)(2420400003)(50226001)(77096005)(15975445007)(19580395003)(23756003)(19580405001)(84392001)(42186005)(62966003)(77156002)(50466002)(87976001)(61296003)(116806002)(40100003)(46102003)(86362001)(230783001)(2521001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 10:49:16.9429 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 10:49:37 -0000 ----- Original Message ----- From: "Mark Andrews" To: "Mark ZZZ Smith" Cc: Sent: Tuesday, February 17, 2015 1:23 AM > The fundemental reason for 127.0.0.0/8 was to give each node a > addresses block they could use. 127.0.0.1 evolved as the "standard" > loopback address over time. For the most part no one uses the rest > of 127.0.0.0/8 but it is useful to have available. That said any > use of the rest of 127.0.0.0/8 has to be negotiated between the > users. You can't just grab 127.0.0.2 and hope that no one else is > using it for IP traffic. Mark I would refer you to RFC5782 and RFC6471 for a discussion on the use of 127.0.0.2 (and ::FFFF:7F00:2 ). Perhaps those RFC should have included an IANA Considerations:-( Tom Petch > > In IPv6 we had both link local and site local addresses from the > get go. These gave the operator addresses they could use. They > were also slightly more complicated than a GUA as you needed to > specify scope. We now have ULA addresses which gets rid of the > need to specify scope. Just like with 127.0.0.2 you need to negotiate > the use of a address. > > Reserving a new block of addressing in IPv6 will not stop the need > to negotiate address use. > > If you need truly automatic assignment you need to go to IANA or a > RIR (e.g. ARIN and 100.64/10) and request a block for a specific > purpose. There is no other way to do truly automatic. > > Mark > > In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, Mar > k ZZZ Smith writes: > > So the fundamental problem is 'configured like this'. It's a manual operation > > to generate and apply a ULA. ULAs on loopbacks aren't going to well known or > > ubiquitous. > > > > If you want something to be used you need to make it easy, and the best way t > > o make something easy is to make it automatic. > > > > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or wo > > uld be automatically configured by the OS, with operator intervention. It's a > > lways there, and always available to use. The 4.1c/2.9BSD people though there > > was value in automatic configuration of the loopback address on a loopback i > > nterface, way back in 1982/1983: > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_l oop.c > > > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_lo op.c > > > > > > > > ----- Original Message ----- > > From: Mark Andrews > > To: David Conrad > > Cc: Mark ZZZ Smith ; "v6ops@ietf.org" > org> > > Sent: Tuesday, 17 February 2015, 10:22 > > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p > > refix-00.txt > > > > > > We don't need *more* reserved address for this. This is from my > > laptop and it has been configured like this for years. > > > > Yes, I have a ULA site on my loopback interface. If your loopback > > interface does not support this it is broken. > > > > > > Mark > > > > lo0: flags=8049 mtu 16384 > > options=3 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > > inet 127.0.0.1 netmask 0xff000000 > > inet6 ::1 prefixlen 128 > > inet 10.53.0.1 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::1 prefixlen 64 > > inet 10.53.0.2 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::2 prefixlen 64 > > inet 10.53.0.3 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::3 prefixlen 64 > > inet 10.53.0.4 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::4 prefixlen 64 > > inet 10.53.0.5 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::5 prefixlen 64 > > inet 10.53.0.6 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::6 prefixlen 64 > > inet 10.53.0.7 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > > inet 10.53.0.8 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::8 prefixlen 64 > > inet 10.53.0.9 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::9 prefixlen 64 > > inet 10.53.0.10 netmask 0xffffffff > > inet6 fd92:7065:b8e:ffff::10 prefixlen 64 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Feb 18 03:10:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1014A1A702D for ; Wed, 18 Feb 2015 03:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCFI0oyzBDC5 for ; Wed, 18 Feb 2015 03:10:34 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7211A911E for ; Wed, 18 Feb 2015 03:10:34 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 083831FCB60; Wed, 18 Feb 2015 11:10:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 56A05160067; Wed, 18 Feb 2015 11:17:22 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 1E5B6160058; Wed, 18 Feb 2015 11:17:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DCF1A29E9E3B; Wed, 18 Feb 2015 22:10:24 +1100 (EST) to: "t.petch" From: Mark Andrews References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net> In-reply-to: Your message of "Wed, 18 Feb 2015 10:27:00 -0000." <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net> Date: Wed, 18 Feb 2015 22:10:24 +1100 Message-Id: <20150218111024.DCF1A29E9E3B@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 11:10:39 -0000 In message <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net>, t.petch writes: > ----- Original Message ----- > From: "Mark Andrews" > To: "Mark ZZZ Smith" > Cc: > Sent: Tuesday, February 17, 2015 1:23 AM > > > The fundemental reason for 127.0.0.0/8 was to give each node a > > addresses block they could use. 127.0.0.1 evolved as the "standard" > > loopback address over time. For the most part no one uses the rest > > of 127.0.0.0/8 but it is useful to have available. That said any > > use of the rest of 127.0.0.0/8 has to be negotiated between the > > users. You can't just grab 127.0.0.2 and hope that no one else is > > using it for IP traffic. > > Mark > > I would refer you to RFC5782 and RFC6471 for a discussion on the use of > 127.0.0.2 (and ::FFFF:7F00:2 ). RFC5782 Informational. RFC6471 Informational. And they actually grabbed namespaces in the DNS not addresses. Neither of them use those "addresses" for IP traffic which is what the proposed reservation of the block is about. The only reason 127.0.0.2 etc. are use for rbls is that it was possible to get sendmail to do a address lookup from sendmail.cf without hacking the code. They returned values are tokens not addresses despite them being encoded in A/AAAA records. Raising RFC5782 and RFC6471 is a Red Herring. Mark > Perhaps those RFC should have included an IANA Considerations:-( > > Tom Petch -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 18 03:13:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90FE1A8785 for ; Wed, 18 Feb 2015 03:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.685 X-Spam-Level: * X-Spam-Status: No, score=1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1wjTphnxgdD for ; Wed, 18 Feb 2015 03:13:43 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8F21A702D for ; Wed, 18 Feb 2015 03:13:39 -0800 (PST) Received: from 10.236.62.154 (EHLO OPE10HT06.tp.gk.corp.tepenet) ([10.236.62.154]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DCA12075; Wed, 18 Feb 2015 12:13:30 +0100 (CET) From: Kossut Tomasz - Hurt To: Alexandru Petrescu , "BOUCADAIR Mohamed IMT/OLN" , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQSbedet4Jjc/nekOWukSYZ6hl8JzzD5+AgAADUwCAAyRKwA== Date: Wed, 18 Feb 2015 11:13:24 +0000 Message-ID: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> In-Reply-To: <54E1D42C.5040605@gmail.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.2.18.100319:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A010205.54E473DA.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010205.54E473DA.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 404d7d34ee41fabaf27bc96f6142f182 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 11:13:46 -0000 SGksDQoNCklubGluZSBjb21tZW50czoNCg0KSGksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJlcG9y dC4gSXQgaXMgZ29vZCB0byBzZWUgaG93IGdvb2QgY29uc2lkZXJhdGlvbiBpcyBnaXZlbiB0byBJ UHY2LCBhbmQgdGhlIHR3byBzZXBhcmF0ZWQgcGF0aHMgSVB2NC9JUHY2Lg0KDQpJdCBpcyBlbmNv dXJhZ2luZyB0byBzZWUgbnVtZXJvdXMgc21hcnRwaG9uZSBtYW51ZmFjdHVyZXJzIGhhdmluZyBl bWJyYWNlZCB0aGUgQ0xBVCB0ZWNobm9sb2d5Lg0KDQoodGspIC0gdGhpcyBpcyBub3Qgb25seSBD TEFULCAoQ0xBVCBpcyBpbiBnZW5lcmljIEFuZHJvaWQgdGhhbmtzIHRvIExvcmVuem8sIENhbWVy b24sIERhbiAmIG90aGVycykgZWFjaCB2ZW5kb3IgaGFzIGl0cyBvd24gY3VzdG9taXphdGlvbiBi YXNlZCBvbiBNQ0NNTkMvcmVnaW9uIHRvIGNvbnRyb2wgImZlYXR1cmVzIiBwZXIgb3BlcmF0b3Iu IEluIG91ciBjYXNlIHdlIGhhdmUgOiAgZGVkaWNhdGVkIGNsYXRkLmNvbmYgKG5vdCBnZW5lcmlj IG9uZSksIElQdjYgdGV0aGVyaW5nKERIQ1B2NiwgUkEsIFJlbGF5IElQdjYgRE5TKSBFSVQgYml0 ID0xLCBtb3Jlb3ZlciB0b2dldGhlciB3aXRoIFNhbXN1bmcgd2UgZGV2ZWxvcGVkICJJUHY2IHBh dGNoIiBmb3IgRG93bmxvYWQgQm9vc3RlciAoU2Ftc3VuZyBmZWF0dXJlIHRvIGFnZ3JlZ2F0ZSB5 b3VyIExURStXSUZJIGNvbm5lY3Rpb24gZm9yIGh0dHAgZG93bmxvYWQgLSBub3cgaXQgd29ya3Mg aW4gSXB2NiBuZXR3b3JrcyB3aXRoIG5vIEROUzY0IGxpa2UgT3JhbmdlIFBvbGFuZCApIA0KDQpJ cyB0aGUgbmV0d29yayBjb25zaWRlcmluZyBNYWNoaW5lLWNsYXNzIGRldmljZXMgKE0yTSk/IEZv ciBleGFtcGxlIFNpZXJyYSBXaXJlbGVzcyBBaXJwcmltZT8gDQpOb3QgcmVhbGx5IC0gd2UgYXJl IHdvcmtpbmcgd2l0aCBvbmUgb2YgdGhlIHZlbmRvciB0byBkZWxpdmVyIElQdjYgKENMQVQpIHJv dXRlciBleHBlY3RlZCBpbiBIMS8xNQ0KDQpNb3JlIHRoYW4gdGhlIHR5cGljYWwgc21hcnRwaG9u ZSB1c2VycyAoeWVzLCBpdCByZXByZXNlbnRzIGFscmVhZHkgYSBsYXJnZSBtYXJrZXQpIGlzIHRo ZSBMVEUgbmV0d29yayBjb25zaWRlcmluZyBjb25uZWN0aW9ucyBmcm9tIG1vcmUgZGVkaWNhdGVk IHNldHRpbmdzIGxpa2U6IGNvbm5lY3RlZCBwdWJsaWMgdHJhbnNwb3J0YXRpb24sIGhvbWUgZWxl Y3RyaWNpdHkgY291bnRlcnMsIGVsZWN0cmljIHZlaGljbGUgY2hhcmdpbmcgc3RhdGlvbnMsIGhh cmJvdXIgaW5zdGFsbGF0aW9ucywgY29ubmVjdGVkIHJvYWRzPw0KDQpZZXMsIHdlIGFyZSB0ZWNo bmljYWxseSByZWFkeSB0byBjcmVhdGUgIklQdjYgbWF0cml4IiANCg0KVGhlc2UgZGVkaWNhdGVk IHNldHRpbmdzIGxvb2sgdXAgdG8gd2lyZWxlc3MgTFRFIGFjY2VzcyBuZXR3b3JrcyBhcyBnb29k IGhvcGUgdG8gZ2V0IG9uIHRoZSBJbnRlcm5ldCwgZXNwZWNpYWxseSBpbiBhcmVhcyB3aGVyZSBs YW5kIGxpbmVzIGFyZSB0b28gZXhwZW5zaXZlIHRvIGRlcGxveS4NCkxURTQ1MCAtaW4gQnJhc2ls LCBMVEU4MDAgLSBFdXJvcGUNCg0KQ2hlZXJzLA0KdGsNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQWxleGFuZHJ1IFBldHJlc2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJl c2N1QGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE2LCAyMDE1IDEyOjI4IFBN DQpUbzogS29zc3V0IFRvbWFzeiAtIEh1cnQ7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEhl YXRsZXksIE5pY2sNCkNjOiB2Nm9wc0BpZXRmLm9yZzsgQ3plcndvbmthIE1pY2hhxYIgMSAtIEh1 cnQNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtbW9i aWxlLWRldmljZS1wcm9maWxlLTE3LnR4dCAtIENfUkVDIzkgNDY0WExBVA0KDQpMZSAxNi8wMi8y MDE1IDExOjQ3LCBLb3NzdXQgVG9tYXN6IC0gSHVydCBhIMOpY3JpdCA6DQo+IEhpLCBJUHY2LW9u bHkgKyBDTEFUK05BVDY0KG5vIGRuczY0KSBpcyB1c2VkIGluIE9yYW5nZSBQb2xhbmQgLSANCj4g c29tZXdoZXJlfiAzMCUgbW9iaWxlIHVzZXJzLiBZb3Ugd29uJ3Qgc2VlIHRoaXMgaW4gd29ybGR3 aWRlIElQdjYgDQo+IHN0YXRzIHsiTm8uIiBvZiBJUHY2IHVzZXJzIGFyZSBtZWFzdXJlZCBmb3Jt IHRyYWZmaWMgLWlwdjQvaXB2NiAtIA0KPiB0eXBpY2FsIG1vYmlsZSB1c2VyIChzbWFydHBob25l KSBnZW5lcmF0ZXMgdXAgdG8gNiB0aW1lcyBsb3dlciB0cmFmZmljIA0KPiBjb21wYXJpbmcgdG8g bGluZXMgdXNlcnMuLn0NCj4NCj4gQXNzdW1pbmcgb3VyIGV4cGVyaWVuY2U6DQo+IDEuIFRoZSBi ZXN0IGZvciBtb2JpbGUgbm93YWRheXMgaXMgQ0xBVCtQTEFUK0ROUyAqT25lIHBhdGggZm9yIElQ djQgDQo+IHRyYWZmaWMgKGFsd2F5cyB2aWEgQ0xBVCkgKkFMR+KAmXMgdHJlYXRlZCBhcyBOQVQ0 NA0KPiAqSVB2NCBsaXRlcmFsICYgZG9tYWluIHVzZSBzYW1lIHBhdGgNCj4gKk9uZSBwYXRoIGZv ciBJUHY2IHRyYWZmaWMgKG5hdGl2ZSBJUHY2KSAqTW90aXZhdGlvbiBmb3IgbmF0aXZlIElQdjYg DQo+IGNvbnRlbnQgKkFwcGxpY2F0aW9uIGFkZHJlc3MgZmFtaWx5IGluZGVwZW5kZW50ICo2NSUg LSB0cmFmZmljIGZyb20gDQo+IHN1YnNjcmliZXJzIGlzIG5hdGl2ZSBJUHY2ICpHb29nbGUgTmV4 dXMsIFNvbnksSFRDLCBTYW11bmcsTEcsIA0KPiBXaW5kb3dzUGhvbmUsIHN1cHBvcnRzIENMQVQu DQoNCkhpLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXBvcnQuIEl0IGlzIGdvb2QgdG8gc2VlIGhv dyBnb29kIGNvbnNpZGVyYXRpb24gaXMgZ2l2ZW4gdG8gSVB2NiwgYW5kIHRoZSB0d28gc2VwYXJh dGVkIHBhdGhzIElQdjQvSVB2Ni4NCg0KSXQgaXMgZW5jb3VyYWdpbmcgdG8gc2VlIG51bWVyb3Vz IHNtYXJ0cGhvbmUgbWFudWZhY3R1cmVycyBoYXZpbmcgZW1icmFjZWQgdGhlIENMQVQgdGVjaG5v bG9neS4NCg0KSXMgdGhlIG5ldHdvcmsgY29uc2lkZXJpbmcgTWFjaGluZS1jbGFzcyBkZXZpY2Vz IChNMk0pPyBGb3IgZXhhbXBsZSBTaWVycmEgV2lyZWxlc3MgQWlycHJpbWU/DQoNCk1vcmUgdGhh biB0aGUgdHlwaWNhbCBzbWFydHBob25lIHVzZXJzICh5ZXMsIGl0IHJlcHJlc2VudHMgYWxyZWFk eSBhIGxhcmdlIG1hcmtldCkgaXMgdGhlIExURSBuZXR3b3JrIGNvbnNpZGVyaW5nIGNvbm5lY3Rp b25zIGZyb20gbW9yZSBkZWRpY2F0ZWQgc2V0dGluZ3MgbGlrZTogY29ubmVjdGVkIHB1YmxpYyB0 cmFuc3BvcnRhdGlvbiwgaG9tZSBlbGVjdHJpY2l0eSBjb3VudGVycywgZWxlY3RyaWMgdmVoaWNs ZSBjaGFyZ2luZyBzdGF0aW9ucywgaGFyYm91ciBpbnN0YWxsYXRpb25zLCBjb25uZWN0ZWQgcm9h ZHM/DQoNClRoZXNlIGRlZGljYXRlZCBzZXR0aW5ncyBsb29rIHVwIHRvIHdpcmVsZXNzIExURSBh Y2Nlc3MgbmV0d29ya3MgYXMgZ29vZCBob3BlIHRvIGdldCBvbiB0aGUgSW50ZXJuZXQsIGVzcGVj aWFsbHkgaW4gYXJlYXMgd2hlcmUgbGFuZCBsaW5lcyBhcmUgdG9vIGV4cGVuc2l2ZSB0byBkZXBs b3kuDQoNCkFsZXgNCg0KPg0KPiBDaGVlcnMsDQo+IHRrDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gDQo+IFtt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gU2VudDogTW9uZGF5LCBGZWJy dWFyeSAxNiwgMjAxNSA3OjQzIEFNDQo+IFRvOiBBbGV4YW5kcnUgUGV0cmVzY3U7IEhlYXRsZXks IE5pY2sNCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IA0KPiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNy50eHQg LSBDX1JFQyM5IDQ2NFhMQVQNCj4NCj4gSGkgQWxleCwNCj4NCj4gUGxlYXNlIHNlZSBpbmxpbmUu DQo+DQo+IENoZWVycywNCj4gTWVkDQo+DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZSA6IEFsZXhhbmRydSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFp bC5jb21dDQo+IEVudm95w6kgOiB2ZW5kcmVkaSAxMyBmw6l2cmllciAyMDE1IDE3OjEzIMOAIDog SGVhdGxleSwgTmljazsgQk9VQ0FEQUlSIA0KPiBNb2hhbWVkIElNVC9PTE4gQ2MgOiB2Nm9wc0Bp ZXRmLm9yZyBPYmpldCA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IA0KPiBkcmFmdC1pZXRmLXY2 b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNy50eHQgLSBDX1JFQyM5IDQ2NFhMQVQNCj4NCj4g TGUgMTMvMDIvMjAxNSAxNjozMywgSGVhdGxleSwgTmljayBhIMOpY3JpdCA6DQo+Pg0KPj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEFsZXhhbmRydSBQZXRyZXNjdSANCj4+ IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0gU2VudDogMTMgRmVicnVhcnkg MjAxNSAxNDozNQ0KPj4gVG86IEhlYXRsZXksIE5pY2s7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20gQ2M6IHY2b3BzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0 aW9uOg0KPj4gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0g Q19SRUMjOSA0NjRYTEFUDQo+Pg0KPj4gTGUgMTMvMDIvMjAxNSAxNDoxNCwgSGVhdGxleSwgTmlj ayBhIMOpY3JpdCA6DQo+Pj4gSGkgQWxleCwgWWVzLCB0aGF0IGlzIHdyb25nLiBZb3UgY2FuIHBp bmcgYW55IElQdjQgbGl0ZXJhbCBmcm9tIGEgDQo+Pj4gNDY0eGxhdCBkZXZpY2UuIE15IGhhbmRz ZXQgb25seSBoYXMgYW4gSVB2NiBhZGRyZXNzICsgQ0xBVCBhbmQgSSBhbSANCj4+PiBwaW5naW5n IDguOC44LjggOi0pKQ0KPj4NCj4+IE9rLCBJIHNlZS4gIEkgZGlkbnQga25vdyBDTEFULW9uLWRl dmljZSB3YXMgcmVxdWlyZWQgd2hlbiB1c2luZyANCj4+IHY2LW9ubHkgQVBOcy4NCj4+DQo+PiBb SGVhdGxleSwgTmlja10gRm9yIHNlcnZpY2UgY29udGludWl0eSB3aXRoIElQdjQsIG9uIGFuIElQ djYtb25seSANCj4+IGJlYXJlciB1c2UgQ0xBVC4gQSBzbGlnaHRseSBwZWRhbnRpYyBub3RlLCAg aWYgeW91IGhhdmUgYSAiZHVhbCBzdGFjayANCj4+IEFQTiIgYnV0IHRoZSBkZXZpY2Ugb25seSBy ZXF1ZXN0cyBJUHY2IHRoZW4gdGhlIGRldmljZSB3aWxsIHJlY2VpdmUgDQo+PiBhbg0KPj4gSVB2 NiBiZWFyZXIgYW5kIHJlcXVpcmVzIENMQVQuIFlvdSB3aWxsIGhlYXIgZnJvbSBSb3NzIGFuZCBt ZSB0YWxraW5nIA0KPj4gYWJvdXQgaGF2aW5nIGEgc2luZ2xlIEFQTiBzdXBwb3J0aW5nIGFsbCBt b2RlcywgSVB2NCwgSVB2NHY2IGFuZCBJUHY2IA0KPj4gYmVhcmVycy4gVGhlcmUgbWF5IGJlIGJ1 c2luZXNzIHJlYXNvbnMgZm9yIHRoaXMsIGFzIHdlbGwgYXMgYXZvaWRpbmcgDQo+PiBjb25zdW1l cnMgaGF2aW5nIHRvIGNoYW5nZSBBUE5zLg0KPg0KPiBJbiBteSB1bmRlcnN0YW5kaW5nIDQ2NHhs YXQvY2xhdCBhcmUgdHJpYWxzIHRoZXNlIGRheXMuDQo+DQo+IFtNZWRdIE5vLCBpdCBpcyBpbiB1 c2UgaW4gbGl2ZSBuZXR3b3JrcywgaW5jbHVkaW5nIHdpdGhpbiBvdXIgR3JvdXAuDQo+DQo+ICAg IFRoZXkgY291bGQgYmUNCj4gaW1wcm92ZWQgYmVmb3JlIGdvaW5nIGxpdmUuICBJZiB0aGUgNDY0 eGxhdC9jbGF0IGhhcHBlbmVkIGVsc2V3aGVyZSB0aGFuIG9uIHRoZSB1c2VyIHRlcm1pbmFsIChl LmcuIEJBc2UgU3RhdGlvbikgSSB0aGluayBtb3JlIG9mIHRoZXNlIHRlcm1pbmFscyBjb3VsZCBi ZSBhY2NvbW1vZGF0ZWQsIG1vcmUgYnVzaW5lc3MuDQo+DQo+IFtNZWRdIElmIGFsbCBhcHBsaWNh dGlvbnMgYXJlIEFGLWluZGVwZW5kZW50IChpbmNsdWRpbmcgSVB2NCByZWZlcnJhbHMgYXJlIG5v dCBpbiB1c2Ugb3IgYWRkcmVzcyBzeW50aGVzaXMgYSBsYSBSRkM2MDUyIGlzIHN1cHBvcnRlZCks IHRoZW4gQ0xBVCBjYW4gYmUgYXZvaWRlZC4gU29tZSBvcGVyYXRvcnMgd2FudCB0byBhZG9wdCBh biBJUHY2LW9ubHkgY29ubmVjdGl2aXR5IG1vZGUgYnV0IHdpdGggYSBjb25kaXRpb24gdG8gcHJv dmlkZSB0aGUgc2FtZSBsZXZlbCBvZiBzZXJ2aWNlIGFzIElQdjQ7IEZvciB0aG9zZSBDTEFUIGlz IGV2ZW4gYSBtdXN0LiBJdCBtaWdodCBoYXBwZW4gdGhhdCBvdGhlciBvcGVyYXRvcnMgY2FuIGp1 ZGdlIHRoYXQgdGhlIGJyb2tlbiBhcHBsaWNhdGlvbnMgdW5kZXIgYW4gSVB2Ni1vbmx5IG1vZGUg KyBOQVQ2NCBhcmUgbm90IGltcG9ydGFudDsgZm9yIHRob3NlIENMQVQgaXMgbm90IG5lZWRlZC4g VGhlc2UgcmVhc29ucywgYW1vbmcgb3RoZXJzLCBhcmUgd2h5IHdlIHNldCB0aGUgbGFuZ3VhZ2Ug dG8gJ3Nob3VsZCcuDQo+DQo+PiBUaGF0IG1lYW5zIHRoYXQgdGhlIGRldmljZSB2ZW5kb3JzIE1V U1QgaW1wbGVtZW50IENMQVQgaW4gdGhlIA0KPj4gc21hcnRwaG9uZXMgd2hpY2ggY29ubmVjdCB0 byBhIHY2LW9ubHkgQVBOLiAgSXQgaXMgYSB0b28gc3Ryb25nIA0KPj4gcmVxdWlyZW1lbnQuDQo+ Pg0KPj4gW0hlYXRsZXksIE5pY2tdIFRvZGF5J3MgcmVhbGl0eSBpcyB0aGF0IG9wZXJhdG9ycyBj YW5ub3QgdGFrZSBkZXZpY2VzIA0KPj4gdG8gSVB2Ni1vbmx5IG1vZGUgb2Ygb3BlcmF0aW9uIHdp dGhvdXQgQ0xBVC4gSW4gdGhlIGZ1dHVyZSB3aWxsIG90aGVyIA0KPj4gYWx0ZXJuYXRpdmVzIGFw cGVhcj8NCj4NCj4gQWx0ZXJuYXRpdmVzIHRoZXJlIGFyZSB2ZXJ5IG1hbnkuDQo+DQo+IEUuZy4g NDY0bGF0L2NsYXQgdG8gcnVuIG9uIGFuIG9wZXJhdG9yLWNvbnRyb2xsZWQgbmV0d29yayBkZXZp Y2UsIG5vdCBvbiBlbmQtdXNlciB0ZXJtaW5hbC4NCj4NCj4gRS5nLiB1c2UgYSB2NC1BUE4gYW5k IHY2LWluLXY0IGVuY2Fwc3VsYXRpb24gb24gdGhlIGVuZC11c2VyIGRldmljZS4NCj4NCj4gM0dQ UCBhbHNvIGRlc2lnbmVkIGEgRFMtTUlQdjYsIG5vdCBzdXJlIHdoZXRoZXIgeW91IGFyZSBhd2Fy ZSBvZiBpdC4gIEl0IGhhZCB0aGUgc2FtZSBnb2FsIG9mIHRlcm1pbmFsIG9uIHY2LW9ubHkgbGlu ay4NCj4NCj4gW01lZF0gQWxsIHRob3NlIGFyZSBubyBvcHRpb25zIGluIHRoZSBtb2JpbGUgY29u dGV4dC4gSVB2Ni1vbmx5ICsgTkFUNjQgaXMgdGhlIG1vZGUgdGhhdCBpcyBjdXJyZW50bHkgYWRv cHRlZCBieSBzZXZlcmFsIG9wZXJhdG9ycy4NCj4NCg0KDQo= From nobody Wed Feb 18 04:57:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADEB1A87A6 for ; Wed, 18 Feb 2015 04:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGWp55_c4a6r for ; Wed, 18 Feb 2015 04:56:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301EE1A87A7 for ; Wed, 18 Feb 2015 04:56:56 -0800 (PST) Received: from CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) by CO2PR04MB603.namprd04.prod.outlook.com (10.141.197.17) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 12:56:31 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 18 Feb 2015 12:56:30 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0081.018; Wed, 18 Feb 2015 12:56:30 +0000 From: "Metzler, Dan J" To: Alexandru Petrescu , "mohamed.boucadair@orange.com" , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDwg1fzpxhvcUOCHDFyDxLETJzuJKAAgAA4+wCAACxpgIAABhmAgAAWtgCAABChgIAAF2sAgAA2ZOCAAx/ogIAELyWg Date: Wed, 18 Feb 2015 12:56:29 +0000 Message-ID: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> <54E0F9E3.8000802@gmail.com> In-Reply-To: <54E0F9E3.8000802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.55.230.66] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(164054003)(51704005)(24454002)(13464003)(46102003)(92566002)(75432002)(2501002)(102836002)(40100003)(15975445007)(2950100001)(2900100001)(66066001)(62966003)(77156002)(89122001)(88552001)(106116001)(90282001)(99286002)(122556002)(77096005)(74316001)(86362001)(87936001)(2656002)(19580405001)(19580395003)(33656002)(76576001)(76176999)(50986999)(54356999)(93886004)(230783001)(18886065003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 12:56:29.6889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB603; X-OriginatorOrg: uiowa.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:57:00 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZHJ1IFBldHJl c2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gU2VudDogU3VuZGF5 LCBGZWJydWFyeSAxNSwgMjAxNSAxOjU2IFBNDQo+IFRvOiBNZXR6bGVyLCBEYW4gSjsgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSGVhdGxleSwgTmljaw0KPiBDYzogdjZvcHNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0NCj4gQ19SRUMjOSA0NjRYTEFUDQo+IA0KPiBP biAxMy8wMi8yMDE1IDIyOjM2LCBNZXR6bGVyLCBEYW4gSiB3cm90ZToNCj4gPiBIaSwNCj4gPg0K PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiB2Nm9wcw0KPiA+PiBbbWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcnUgUGV0cmVzY3UN Cj4gPj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxMywgMjAxNSAxMDo1OSBBTSBUbzoNCj4gPj4g bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSGVhdGxleSwgTmljayBDYzogdjZvcHNAaWV0 Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjoNCj4gPj4gZHJhZnQt aWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19SRUMjOSA0NjRYTEFU DQo+ID4+DQo+ID4gPHNuaXAvPg0KPiA+Pg0KPiA+Pj4gU29tZSBvcGVyYXRvcnMgYXJlIHNlZWlu ZyBDTEFUIGFzIGNyaXRpY2FsIGJlY2F1c2UgdGhleSBkb24ndCB3YW50DQo+ID4+PiB0byBoYXZl IGEgc2VydmljZSBkaXNydXB0aW9uIGNvbXBhcmVkIHRvIElQdjQgd2hlbiBJUHY2LW9ubHkNCj4g Pj4+IGNvbm5lY3Rpdml0eSBpcyBwcm92aWRlZCB0byB0aGVpciBjdXN0b21lcnMuDQo+ID4+DQo+ ID4+IEkgYWdyZWUgYWJvdXQgdGhlIGNyaXRpY2FsaXR5IG9mIElQdjQgYXBwcyB3aGVuIElQdjYt b25seQ0KPiA+PiBjb25uZWN0aXZpdHkgaXMgaW4gcGxhY2UuDQo+ID4+DQo+ID4+IEJ1dCB3aHkg c2hvdWxkIHRoZXJlIGJlIElQdjYtb25seSBjb25uZWN0aXZpdHkgaW4gcGxhY2UgdG9kYXkgZm9y IHRoZQ0KPiA+PiBtYXNzZXM/DQo+ID4NCj4gPiBCZWNhdXNlIHdoZXRoZXIgaXQgZXhpc3RzIHRv ZGF5LCBvciBub3QsIHRoYXQncyB0aGUgZ29hbCB3ZSBhcmUNCj4gPiB3b3JraW5nIHRvd2FyZC4g IEl0J3MgZmFyIHRvbyBsYXRlIHRvIGJlIGRlc2lnbmluZyB0aGluZ3MgYmFzZWQgb24NCj4gPiBz b21lIGFzc3VtcHRpb24gdGhhdCBJUHY2LW9ubHkgY29ubmVjdGl2aXR5IGRvZXNuJ3QgaGF2ZSB0 byBhY3R1YWxseQ0KPiA+IHdvcmsgYW55d2F5LiAgVGhlIHVsdGltYXRlIGdvYWwgaXMgSVB2Ni1v bmx5IGNvbm5lY3Rpdml0eSBmb3IgdGhlDQo+ID4gbWFzc2VzLCBhbmQgaWYgd2UgbWFrZSBubyBv dGhlciBhc3N1bXB0aW9ucywgd2Ugb3VnaHQgdG8gYmUgYWJsZSB0bw0KPiA+IHN0YXJ0IHdpdGgg dGhlIGFzc3VtcHRpb24gdGhhdCBhdCBsZWFzdCB3b3JrcyB0byBhbGwgaW50ZXJuZXQNCj4gPiBj b25uZWN0ZWQgSVB2NiBlbmRwb2ludHMuDQo+IA0KPiBZZXMsIEkgYWdyZWUgd2l0aCB0aGUgZ29h bC4gIEJ1dCBJIHRoaW5rIGl0IGlzIHRvbyBlYXJseSB0byB0aGluayBJUHY2LW9ubHkgZm9yIHRo ZQ0KPiBtYXNzZXMuDQoNCkluIHRoaXMgZ3JvdXAsIGl0IGlzIHRvbyBsYXRlIG5vdCB0byB0aGlu ayBJUHY2LW9ubHkgZm9yIHRoZSBtYXNzZXMuICBXZSBwYXN0IHRoYXQgcG9pbnQgbG9uZyBhZ28u ICBDZXJ0YWlubHksIHdlIGFyZW4ndCByZWFkeSB0byBzdG9wIHRoaW5raW5nIGFib3V0IHRyYW5z aXRpb24gdGVjaG5vbG9naWVzLg0KDQo+IA0KPiBJIHRhbGsgdG8gYSBudW1iZXIgb2YgcHJvZmVz c2lvbmFsIGRlcGxveWVycyBhbmQgdGhlIG1ham9yaXR5IGlzIHN0aWxsDQo+IHF1ZXN0aW9uaW5n IHRoZSBuZWNlc3NpdHkgb2YgSVB2Ni4NCg0KSSB0aGluayB5b3UncmUgc3VnZ2VzdGluZyB0aGF0 LCBzaW5jZSB0aGUgbWFqb3JpdHkgb2YgYSBmZXcgc2VsZWN0ZWQgInByb2Zlc3Npb25hbCBkZXBs b3llcnMiLCBhcmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIG5lY2Vzc2l0eSBvZiBJUHY2LCB0aGF0 IHY2b3BzIHNob3VsZCBub3QgYmUgd29ycmllZCBhYm91dCBJUHY2IG9ubHkgYWN0dWFsbHkgd29y a2luZz8gIFRoYXQgZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UuICANCk91ciBqb2IgYXQgdGhpcyBw b2ludCBzaG91bGQgYmU6DQoxKSBNYWtlIHN1cmUgSVB2NiB3b3JrcywgYW5kIHdvcmtzIGJldHRl ciB0aGFuIElQdjQuICAoSWYgd2UgZG9uJ3QgZG8gdGhpcyBmaXJzdCwgdGhlbiB0aGVyZSBpcyBu byByZWFzb24gZm9yIG51bWJlciAyLikNCjIpIE1ha2Ugc3VyZSB0aGVyZSBpcyBhIGdvb2QgYW5k IGVmZmVjdGl2ZSB3b3JraW5nIGxvbmcgdGVybSBtaWdyYXRpb24gcGF0aCB0byBnZXQgZnJvbSBJ UHY0IG9ubHkgdG8gSVB2NiBvbmx5Lg0KDQpXaXRob3V0IG51bWJlciAxLCBudW1iZXIgMiBpcyBu b3QgYSB2aWFibGUgb3B0aW9uIHRoYXQgSSdtIGF3YXJlIG9mLg0KDQo+IA0KPiA+PiBOb2JvZHkg YnV0IHNvbWUgdWx0cmEtZ2VlayBkbyB0aGlzIElQdjYtb25seSB0b2RheS4NCj4gPg0KPiA+IE91 Y2ghDQo+IA0KPiBTb3JyeSwgZGlkbnQgbWVhbiB0byBodXJ0IGFueW9uZSdzIGZlZWxpbmdzLiAg R2VlayBpcyBzYWlkIHdpdGggcmVzcGVjdC4NCj4gDQo+IE9uZSBtdXN0IGJlIHVsdHJhLWdlZWsg dG8gdHVybiBvZmYgaGVyIElQdjQgc3RhY2suICBIYXZlIHlvdSB0cmllZD8NCj4gDQo+ID4+IEV2 ZW4gaWYgdGhlIG9wZXJhdG9yJ3MgbmV0d29yayBpcyBJUHY2IG9ubHksIGl0IHNob3VsZCBoYXZl IG1lYW5zIHRvDQo+ID4+IHRyYW5zbGF0ZSBiZXR3ZWVuIHY0IGFuZCB2NiBhdCBpdHMgZWRnZXMs IHN1Y2ggYXMgdG8gc2hvdyBwdXJlDQo+ID4+IElQdjQgYW5kIHB1cmUgSVB2NiB0IHVzZXIuDQo+ ID4+DQo+ID4NCj4gPiBJIHRoaW5rIHdlIHNob3VsZCBzdGF5IGF3YXkgZnJvbSBhc3N1bXB0aW9u cyBsaWtlIHRoaXMuDQo+IA0KPiBCdXQgNDY0eGxhdC9jbGF0IGlzIGFscmVhZHkgZG9pbmcgdHJh bnNsYXRpb24uIEV4Y2VwdCB0aGF0IGl0IGRvZXMgdHJhbnNsYXRpb24NCj4gb25seSBvbiBvbmUg ZWRnZSBhbmQgb24gdGhlIHRlcm1pbmFsLiAgSXQgc2hvdWxkIGhhdmUgZG9uZSB0cmFuc2xhdGlv biBvbg0KPiBib3RoIGVkZ2VzIGFuZCBsZXQgdGhlIHRlcm1pbmFsIGZyZWUgb2Ygbm90IGltcGxl bWVudGluZyBDTEFULg0KPiANCj4gPiBJZiBubyBvbmUgaXMgZ29pbmcgdG8gbWFuZGF0ZSB0aGF0 IGFsbCBJU1BzIE1VU1QgcHJvdmlkZSBJUHY2DQo+ID4gY29ubmVjdGl2aXR5LCAoYW5kIHRoYXQg aGFzbid0IGhhcHBlbmVkIHlldCksIHRoZW4gaXQgZG9lc24ndCBzZWVtDQo+ID4gbGlrZSB3ZSBj YW4gbWFrZSBhc3N1bXB0aW9ucyBhYm91dCB3aGVyZSB0aGUgdHJhbnNsYXRpb24gbmVlZHMgdG8N Cj4gPiBoYXBwZW4uDQo+IA0KPiBJIGFncmVlIHdpdGggeW91LCBJUHY2IG11c3QgYmUgcmVjb21t ZW5kZWQuICBCdXQgdGhlcmUgc2V2ZXJhbCB0eXBlcyBpbiB3aGljaA0KPiB0byBicmluZyBJUHY2 IGluLiAgU29tZSBhcmUgc21vb3RoZXIgdGhhbiBvdGhlcnMuDQo+IA0KPiBJbiB0aGUgY2FzZSBJ IHN0cnVnZ2xlIHdpdGgsIGluIHRoZSBjdXJyZW50IHNpdHVhdGlvbiAoQ0xBVCByZXF1aXJlZCBv biB0aGUNCj4gdGVybWluYWwpLCBJIHdpbGwgYmUgZm9yY2VkIHRvIHJlY29tbWVuZCBhbmQgdXNl IGFuIElQdjQtb25seSBBUE4gdHlwZSwgYW5kDQo+IGxlYXZlIElQdjYgZm9yIGEgZmV3IHllYXJz IGxhdGVyLg0KPiANCj4gVGhlIGVuZCB1c2VycyB3aWxsIG5vdCBldmVuIGhhdmUgYSBjaGFuY2Ug dG8gc2VlIGFuIFJBIGNvbWluZyBmcm9tIHRoZQ0KPiBuZXR3b3JrIGFuZCB0aGVpciBXaW5kb3dz IGVuZC1zeXN0ZW1zIG5hdHVyYWxseSBzZWxmLWNvbmZpZ3VyZSBhbiBhZGRyZXNzLg0KPiANCj4g VGhlIGVuZCB1c2VyIGRvZXMgbm90IHdhbnQgSVB2NiwgdGhlIGJhY2tlbmQgc3lzdGVtIGRvZXMg bm90IHdhbnQgdG8NCj4gcHJvdmlkZSBJUHY2LiAgT25seSB0aGUgY2VsbHVsYXIgc3lzdGVtIGlt cG9zZXMgSVB2Ni4NCg0KV2hhdCBkbyB5b3UgbWVhbiBieSBiYWNrZW5kIHN5c3RlbT8NCg0KVGhl IGVuZCB1c2VyIHVzdWFsbHkgZG9lcyBub3QgIndhbnQiIElQdjQsIGJ1dCB3ZSBzdGlsbCBnYXZl IGl0IHRvIHRoZW0uICBUaGF0IHRoZSBlbmQgdXNlciAiZG9lcyBub3Qgd2FudCBJUHY2IiBpcyBh IHF1ZXN0aW9uYWJsZSBzdGF0ZW1lbnQgaW4gbGlnaHQgb2YgdGhlIGN1cnJlbnQgc3RhdGUgb2Yg dGhlIGludGVybmV0LiAgVGhlIGVuZCB1c2VyIHJlYWxseSB3YW50cyB0aGUgSW50ZXJuZXQsIGFu ZCB0aGF0J3MgYXMgZmFyIGFzIGl0IGdvZXMuICBUaGUgdHlwaWNhbCBlbmQgdXNlciBpcyB1bmF3 YXJlIG9mIHdoYXQgdGhleSB3YW50IGF0IGxheWVyIDMsIGJlY2F1c2UgdGhleSB0ZW5kIG5vdCB0 byBsb29rIGJlbG93IGxheWVyIDcuICBUaGUgcmVhbGl0eSBpcywgZWl0aGVyIHRoZSBlbmQgdXNl ciB3YW50cyB0byBydW4gb3V0IG9mIElQdjQgYWRkcmVzc2VzLCBvciB0aGV5IHdhbnQgSVB2Ni4g IChUaGV5IGp1c3QgbWlnaHQgbm90IGJlIGF3YXJlIG9mIGl0IHlldC4pDQoNCj4gDQo+IEFsZXgN Cj4gDQo+ID4NCj4gPiA8c25pcC8+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiAtIERhbiAo cGFydCB0aW1lIHVsdHJhLWdlZWsgSSBndWVzcykNCj4gPg0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IC0tLQ0KPiBMJ2Fic2VuY2UgZGUgdmlydXMgZGFucyBj ZSBjb3VycmllciDDqWxlY3Ryb25pcXVlIGEgw6l0w6kgdsOpcmlmacOpZSBwYXIgbGUgbG9naWNp ZWwNCj4gYW50aXZpcnVzIEF2YXN0Lg0KPiBodHRwOi8vd3d3LmF2YXN0LmNvbQ0KDQo= From nobody Wed Feb 18 04:57:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FFE1A87C4 for ; Wed, 18 Feb 2015 04:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQnMkRcQAkOn for ; Wed, 18 Feb 2015 04:57:08 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBFD1A8749 for ; Wed, 18 Feb 2015 04:57:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1ICv4Na008798; Wed, 18 Feb 2015 13:57:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 33EC6201D06; Wed, 18 Feb 2015 13:58:08 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 21235201B9C; Wed, 18 Feb 2015 13:58:08 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1ICuqPr017815; Wed, 18 Feb 2015 13:57:04 +0100 Message-ID: <54E48C14.1000102@gmail.com> Date: Wed, 18 Feb 2015 13:56:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kossut Tomasz - Hurt , BOUCADAIR Mohamed IMT/OLN , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - Download Booster X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:57:12 -0000 > moreover together with Samsung we developed "IPv6 patch" for Download > Booster (Samsung feature to aggregate your LTE+WIFI connection for > http download - This is a very useful feature. I wonder whether the augmented bandwidth concerns a single http connection, or several? (there is a difference between single connection enjoying its bandwidth augmented when an interface is added, and pipelined http connections not disturbing each other when several interfaces are added). I am asking because two reasons. One is that I have seen demos where bandwidth is not really augmented, yet pipelined http apps give a better feeling when multiple interfaces are used. The other reason is that at IETF there are some activities about bandwidth augmentation which may be interested in Download Booster. In the MIF Working Group there is a bandwidth augmentation activity in relationship to the BroadBand Forum: add a cellular interface to a DSL box hoping to add bandwidth, and improve fail-over. In the Mobile IPv4 Working Group there is a draft-ietf-mip4-multiple-tunnel-support which may try to achieve the same, and an RFC for samein IPv6. > now it works in Ipv6 networks with no DNS64 like Orange Poland ) It is encouraging :-) > Is the network considering Machine-class devices (M2M)? For example > Sierra Wireless Airprime? Not really - we are working with one of the > vendor to deliver IPv6 (CLAT) router expected in H1/15 > > More than the typical smartphone users (yes, it represents already a > large market) is the LTE network considering connections from more > dedicated settings like: connected public transportation, home > electricity counters, electric vehicle charging stations, harbour > installations, connected roads? > > Yes, we are technically ready to create "IPv6 matrix" > > These dedicated settings look up to wireless LTE access networks as > good hope to get on the Internet, especially in areas where land > lines are too expensive to deploy. > >> LTE450 -in Brasil, LTE800 - Europe Ok, it is good to know. For the moment we consider LTE2600 which is also useful in remote areas, until LTE800 comes alive. Alex From nobody Wed Feb 18 04:57:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6461A87EE for ; Wed, 18 Feb 2015 04:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_62=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Rca_hi8BYM8 for ; Wed, 18 Feb 2015 04:57:23 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454AE1A8827 for ; Wed, 18 Feb 2015 04:57:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1ICvIGJ008836; Wed, 18 Feb 2015 13:57:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF47D201D06; Wed, 18 Feb 2015 13:58:21 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC090201B9C; Wed, 18 Feb 2015 13:58:21 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1ICvI3g018367; Wed, 18 Feb 2015 13:57:18 +0100 Message-ID: <54E48C2E.2020703@gmail.com> Date: Wed, 18 Feb 2015 13:57:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kossut Tomasz - Hurt , BOUCADAIR Mohamed IMT/OLN , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:57:26 -0000 Hi, Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit : > Hi, > > Inline comments: > > Hi, > > Thank you for the report. It is good to see how good consideration > is given to IPv6, and the two separated paths IPv4/IPv6. > > It is encouraging to see numerous smartphone manufacturers having > embraced the CLAT technology. > > (tk) - this is not only CLAT, (CLAT is in generic Android thanks to > Lorenzo, Cameron, Dan & others) each vendor has its own > customization based on MCCMNC/region to control "features" per > operator. In our case we have : dedicated clatd.conf (not generic > one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) It's good to see these mentioned. For tethering - is the network offering DHCPv6 Prefix Delegation service? Or is the device performing '64share' RFC7278? There are some advantages on doing the former rather than the latter. > EIT bit =1, What is the EIT bit? Alex > > Cheers, tk > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Monday, February 16, > 2015 12:28 PM To: Kossut Tomasz - Hurt; BOUCADAIR Mohamed IMT/OLN; > Heatley, Nick Cc: v6ops@ietf.org; Czerwonka Michał 1 - Hurt Subject: > Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt > - C_REC#9 464XLAT > > Le 16/02/2015 11:47, Kossut Tomasz - Hurt a écrit : >> Hi, IPv6-only + CLAT+NAT64(no dns64) is used in Orange Poland - >> somewhere~ 30% mobile users. You won't see this in worldwide IPv6 >> stats {"No." of IPv6 users are measured form traffic -ipv4/ipv6 - >> typical mobile user (smartphone) generates up to 6 times lower >> traffic comparing to lines users..} >> >> Assuming our experience: 1. The best for mobile nowadays is >> CLAT+PLAT+DNS *One path for IPv4 traffic (always via CLAT) *ALG’s >> treated as NAT44 *IPv4 literal & domain use same path *One path >> for IPv6 traffic (native IPv6) *Motivation for native IPv6 content >> *Application address family independent *65% - traffic from >> subscribers is native IPv6 *Google Nexus, Sony,HTC, Samung,LG, >> WindowsPhone, supports CLAT. > > Hi, > > Thank you for the report. It is good to see how good consideration > is given to IPv6, and the two separated paths IPv4/IPv6. > > It is encouraging to see numerous smartphone manufacturers having > embraced the CLAT technology. > > Is the network considering Machine-class devices (M2M)? For example > Sierra Wireless Airprime? > > More than the typical smartphone users (yes, it represents already a > large market) is the LTE network considering connections from more > dedicated settings like: connected public transportation, home > electricity counters, electric vehicle charging stations, harbour > installations, connected roads? > > These dedicated settings look up to wireless LTE access networks as > good hope to get on the Internet, especially in areas where land > lines are too expensive to deploy. > > Alex > >> >> Cheers, tk >> >> >> -----Original Message----- From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] Sent: Monday, February 16, >> 2015 7:43 AM To: Alexandru Petrescu; Heatley, Nick Cc: >> v6ops@ietf.org Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Hi Alex, >> >> Please see inline. >> >> Cheers, Med >> >> -----Message d'origine----- De : Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Envoyé : vendredi 13 février >> 2015 17:13 À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc : >> v6ops@ietf.org Objet : Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Le 13/02/2015 16:33, Heatley, Nick a écrit : >>> >>> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 >>> 14:35 To: Heatley, Nick; mohamed.boucadair@orange.com Cc: >>> v6ops@ietf.org Subject: Re: [v6ops] I-D Action: >>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >>> >>> Le 13/02/2015 14:14, Heatley, Nick a écrit : >>>> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal >>>> from a 464xlat device. My handset only has an IPv6 address + >>>> CLAT and I am pinging 8.8.8.8 :-)) >>> >>> Ok, I see. I didnt know CLAT-on-device was required when using >>> v6-only APNs. >>> >>> [Heatley, Nick] For service continuity with IPv4, on an IPv6-only >>> bearer use CLAT. A slightly pedantic note, if you have a "dual >>> stack APN" but the device only requests IPv6 then the device will >>> receive an IPv6 bearer and requires CLAT. You will hear from Ross >>> and me talking about having a single APN supporting all modes, >>> IPv4, IPv4v6 and IPv6 bearers. There may be business reasons for >>> this, as well as avoiding consumers having to change APNs. >> >> In my understanding 464xlat/clat are trials these days. >> >> [Med] No, it is in use in live networks, including within our >> Group. >> >> They could be improved before going live. If the 464xlat/clat >> happened elsewhere than on the user terminal (e.g. BAse Station) I >> think more of these terminals could be accommodated, more >> business. >> >> [Med] If all applications are AF-independent (including IPv4 >> referrals are not in use or address synthesis a la RFC6052 is >> supported), then CLAT can be avoided. Some operators want to adopt >> an IPv6-only connectivity mode but with a condition to provide the >> same level of service as IPv4; For those CLAT is even a must. It >> might happen that other operators can judge that the broken >> applications under an IPv6-only mode + NAT64 are not important; >> for those CLAT is not needed. These reasons, among others, are why >> we set the language to 'should'. >> >>> That means that the device vendors MUST implement CLAT in the >>> smartphones which connect to a v6-only APN. It is a too strong >>> requirement. >>> >>> [Heatley, Nick] Today's reality is that operators cannot take >>> devices to IPv6-only mode of operation without CLAT. In the >>> future will other alternatives appear? >> >> Alternatives there are very many. >> >> E.g. 464lat/clat to run on an operator-controlled network device, >> not on end-user terminal. >> >> E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user >> device. >> >> 3GPP also designed a DS-MIPv6, not sure whether you are aware of >> it. It had the same goal of terminal on v6-only link. >> >> [Med] All those are no options in the mobile context. IPv6-only + >> NAT64 is the mode that is currently adopted by several operators. >> > > From nobody Wed Feb 18 05:37:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C01A049C for ; Wed, 18 Feb 2015 05:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW4X8ygxYO1F for ; Wed, 18 Feb 2015 05:37:51 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BFF1A8854 for ; Wed, 18 Feb 2015 05:37:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1IDbb8H030929; Wed, 18 Feb 2015 14:37:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E573F201E27; Wed, 18 Feb 2015 14:38:40 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D4F3F201EC3; Wed, 18 Feb 2015 14:38:40 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1IDbWsX015468; Wed, 18 Feb 2015 14:37:37 +0100 Message-ID: <54E4959C.80602@gmail.com> Date: Wed, 18 Feb 2015 14:37:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Metzler, Dan J" , "mohamed.boucadair@orange.com" , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> <54E0F9E3.8000802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:37:54 -0000 Le 18/02/2015 13:56, Metzler, Dan J a écrit : > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Sunday, February 15, >> 2015 1:56 PM To: Metzler, Dan J; mohamed.boucadair@orange.com; >> Heatley, Nick Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> On 13/02/2015 22:36, Metzler, Dan J wrote: >>> Hi, >>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru >>>> Petrescu Sent: Friday, February 13, 2015 10:59 AM To: >>>> mohamed.boucadair@orange.com; Heatley, Nick Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] I-D Action: >>>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 >>>> 464XLAT >>>> >>> >>>> >>>>> Some operators are seeing CLAT as critical because they don't >>>>> want to have a service disruption compared to IPv4 when >>>>> IPv6-only connectivity is provided to their customers. >>>> >>>> I agree about the criticality of IPv4 apps when IPv6-only >>>> connectivity is in place. >>>> >>>> But why should there be IPv6-only connectivity in place today >>>> for the masses? >>> >>> Because whether it exists today, or not, that's the goal we are >>> working toward. It's far too late to be designing things based >>> on some assumption that IPv6-only connectivity doesn't have to >>> actually work anyway. The ultimate goal is IPv6-only >>> connectivity for the masses, and if we make no other assumptions, >>> we ought to be able to start with the assumption that at least >>> works to all internet connected IPv6 endpoints. >> >> Yes, I agree with the goal. But I think it is too early to think >> IPv6-only for the masses. > > In this group, it is too late not to think IPv6-only for the masses. > We past that point long ago. Certainly, we aren't ready to stop > thinking about transition technologies. I think IPv6-only for the masses is too early to plan for. Most notably I dont think linux platforms(2.x to 3.x) ready to turn off their IPv4 stacks. YEs, there could be a geeky Android out there not segfaulting upon IPv4 disable, but we're way away from devices sold at large which dont support IPv4. Nobody will buy a tablet without IPv4 an stack - it's perceived as a miss-feature: can't connect to all networks. It's as when I naïvely bought a smartphone without WCDMA thinking I'd never go to Korea, or that 4G solves it - it's no and no. Transition technologies: yes, but maybe we can learn from some of the past IPv4-IPv6 transition methods. Maybe the easiest transition is to offer both IPv4 and IPv6 to end user and let her decide when to switch. >> I talk to a number of professional deployers and the majority is >> still questioning the necessity of IPv6. > > I think you're suggesting that, since the majority of a few selected > "professional deployers", are still questioning the necessity of > IPv6, that v6ops should not be worried about IPv6 only actually > working? Right, no. I suggest v6ops activities are well on track. I disagree though with thinking an IPv6-only access is necessary today. > That doesn't make much sense. Our job at this point should be: 1) > Make sure IPv6 works, and works better than IPv4. Agree with point 1. But disagree to making it better than IPv4 (other than the larger address space). There is some time spent in migrating features from IPv6 back to IPv4. There is also resistance from IP deployers due to IPv6 being so different than IPv4. > (If we don't do this first, then there is no reason for number 2.) 2) > Make sure there is a good and effective working long term migration > path to get from IPv4 only to IPv6 only. > > Without number 1, number 2 is not a viable option that I'm aware of. I agree with you about the long term towards IPv6. It's just the near term that I disagree with. I think one is safe to plan for some good years of side-by-side IPv4-IPv6 access. >>>> Nobody but some ultra-geek do this IPv6-only today. >>> >>> Ouch! >> >> Sorry, didnt mean to hurt anyone's feelings. Geek is said with >> respect. >> >> One must be ultra-geek to turn off her IPv4 stack. Have you >> tried? >> >>>> Even if the operator's network is IPv6 only, it should have >>>> means to translate between v4 and v6 at its edges, such as to >>>> show pure IPv4 and pure IPv6 t user. >>>> >>> >>> I think we should stay away from assumptions like this. >> >> But 464xlat/clat is already doing translation. Except that it does >> translation only on one edge and on the terminal. It should have >> done translation on both edges and let the terminal free of not >> implementing CLAT. >> >>> If no one is going to mandate that all ISPs MUST provide IPv6 >>> connectivity, (and that hasn't happened yet), then it doesn't >>> seem like we can make assumptions about where the translation >>> needs to happen. >> >> I agree with you, IPv6 must be recommended. But there several >> types in which to bring IPv6 in. Some are smoother than others. >> >> In the case I struggle with, in the current situation (CLAT >> required on the terminal), I will be forced to recommend and use an >> IPv4-only APN type, and leave IPv6 for a few years later. >> >> The end users will not even have a chance to see an RA coming from >> the network and their Windows end-systems naturally self-configure >> an address. >> >> The end user does not want IPv6, the backend system does not want >> to provide IPv6. Only the cellular system imposes IPv6. > > What do you mean by backend system? Clouds, server farms, services. (and yes, I know google youtube facebook are on IPv6). > The end user usually does not "want" IPv4, but we still gave it to > them. That the end user "does not want IPv6" is a questionable > statement in light of the current state of the internet. The end > user really wants the Internet, and that's as far as it goes. The > typical end user is unaware of what they want at layer 3, because > they tend not to look below layer 7. The reality is, either the end > user wants to run out of IPv4 addresses, or they want IPv6. (They > just might not be aware of it yet.) Ok, yes, yes... But. If by the 'current state of the internet' you mean IPv4 address exhaust... IPv4 addresses exhaust unless they're NATted. One wouldn't argue that IPv6-only is a solution to IPv4 exhaustion; or that 464xlat/clat is such a solution for that matter. I suggest neither is a solution to IPv4 exhaust: IPv6-only does not accommodate IPv4 apps and 464xlat/clat deployments I am aware of use non-routable IPv4 addresses. In that sense, NAT is a solution to IPv4 exhaust, as before. If IPv6-only/464xlat/clat was offering a publicly routable IPv4 address to the smartphone's AF-dependent literal-using applications - then I would not complain about IPv6-only/464xlat/clat. Alex > >> >> Alex >> >>> >>> >>> >>> Thanks, >>> >>> - Dan (part time ultra-geek I guess) >>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> --- L'absence de virus dans ce courrier électronique a été vérifiée >> par le logiciel antivirus Avast. http://www.avast.com > From nobody Wed Feb 18 06:04:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730AD1A890F for ; Wed, 18 Feb 2015 06:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN1umnEo88R2 for ; Wed, 18 Feb 2015 06:03:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52B91A8854 for ; Wed, 18 Feb 2015 06:03:51 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EDF2222C1F0; Wed, 18 Feb 2015 15:03:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CAF654C072; Wed, 18 Feb 2015 15:03:49 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 15:03:49 +0100 From: To: Alexandru Petrescu , "Metzler, Dan J" , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant Thread-Index: AQHQS4AYvGcxO/9jMk+3olA6ZIhqyZz2blyg Date: Wed, 18 Feb 2015 14:03:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490D924@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> <54E0F9E3.8000802@gmail.com> <54E4959C.80602@gmail.com> In-Reply-To: <54E4959C.80602@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:04:05 -0000 SGkgQWxleCwgDQoNCkNhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB0aGlzIHBhcnQ/IA0KDQpJ IGd1ZXNzIGJ5ICJJUHY2LW9ubHkvNDY0eGxhdC9jbGF0IiB5b3UgbWVhbiAiSVB2Ni1vbmx5L2Ns YXQvTkFUNjQiLCBubz8NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21haWx0bzphbGV4 YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSANCkVudm95w6nCoDogbWVyY3JlZGkgMTggZsOpdnJp ZXIgMjAxNSAxNDozOA0Kw4DCoDogTWV0emxlciwgRGFuIEo7IEJPVUNBREFJUiBNb2hhbWVkIElN VC9PTE47IEhlYXRsZXksIE5pY2sNCkNjwqA6IHY2b3BzQGlldGYub3JnDQpPYmpldMKgOiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmls ZS0xNy50eHQgLSByYW50DQoNCg0KSWYgSVB2Ni1vbmx5LzQ2NHhsYXQvY2xhdCB3YXMgb2ZmZXJp bmcgYSBwdWJsaWNseSByb3V0YWJsZSBJUHY0IGFkZHJlc3MNCnRvIHRoZSBzbWFydHBob25lJ3Mg QUYtZGVwZW5kZW50IGxpdGVyYWwtdXNpbmcgYXBwbGljYXRpb25zIC0gdGhlbiBJDQp3b3VsZCBu b3QgY29tcGxhaW4gYWJvdXQgSVB2Ni1vbmx5LzQ2NHhsYXQvY2xhdC4NCg0KQWxleA0KDQo= From nobody Wed Feb 18 07:08:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE271A1B34 for ; Wed, 18 Feb 2015 07:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mUHHCdcDYjf for ; Wed, 18 Feb 2015 07:08:24 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98DB1A924B for ; Wed, 18 Feb 2015 07:08:21 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id k14so1737263wgh.4 for ; Wed, 18 Feb 2015 07:08:20 -0800 (PST) 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=XE0fM+oPGJ2Fxjgi1bgxCExme3G97l8ZTiUQUVxEKdo=; b=zQ6Y9K+z1U/4pBTBpwJKScnnFA9yO425weMnVSCOB4PQQZehZjGs4Dk+fgr2EDNm6s 53nfPOU0IQypoLWhKvXqUfWBoDbBAMfHYqdILLO6so5uajimJdEjZ9kLQ8EdZ2fs2VRM X3DKTTYUXi/Gbv3NwjnZQYhQsW4ugqe8IwKYi9WfOWJ98h8bT1o1Fgk9KV/UPLxHaTRP 4D6kEpGMV9mqbttPmzehuE6pujyOt4UWbTg+xdVBTej3SL9hjlHSyl8vCrAn+CGO2x3a L6Q0Esi3/uCFsxow9AjcCPlV1kRqmdmIqJJDZ51qiEQn0uzlk3SYOiy+dkNz/sBHy6N5 G7uA== MIME-Version: 1.0 X-Received: by 10.181.13.4 with SMTP id eu4mr901475wid.41.1424272099117; Wed, 18 Feb 2015 07:08:19 -0800 (PST) Received: by 10.194.127.102 with HTTP; Wed, 18 Feb 2015 07:08:18 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Wed, 18 Feb 2015 07:08:18 -0800 Message-ID: From: Ca By To: "mohamed.boucadair@orange.com" Content-Type: multipart/alternative; boundary=f46d043be152881222050f5e30a6 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:08:27 -0000 --f46d043be152881222050f5e30a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authors, I know you said the 3gpp is not interested in this work, what about GSMA ? They write profiles for mobile networks , right? CB On Wednesday, February 18, 2015, wrote: > Hi Nick, > > > > I fully agree. > > > > Cheers, > > Med > > > > *De :* v6ops [mailto:v6ops-bounces@ietf.org > ] *De la part de* > Heatley, Nick > *Envoy=C3=A9 :* mercredi 18 f=C3=A9vrier 2015 10:35 > *=C3=80 :* Lorenzo Colitti > *Cc :* IPv6 Ops WG (v6ops@ietf.org > ) > *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > Yes, I agree with you, that is a sensible approach. > > Working with each vendor in turn. > > (You know each vendor who claims IPv6 readiness for their terminal, will > never say whether the device will work on the operators IPv6 network. > > So it needs to be collaborative.) > > > > So all this document is doing is setting a collective roadmap, rather tha= n > expect vendors to do their own thing. Given we agree on the above, this i= s > not harmful. > > > > I think the real disagreement comes from your opinion that this is not > IETF. > > (By the way, mobile operators have had discussions with the sister org of > the Internet Society about what would help mobile operators introduce IPv= 6. > > One of the major major themes has been terminals.) > > > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com > ] > *Sent:* 18 February 2015 07:26 > *To:* Heatley, Nick > *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org > ) > *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick > wrote: > > I can see why you argue for lowest common denominator of v6 requirements. > > I think your stance that this can work across the board is =E2=80=9Charmf= ully > restrictive=E2=80=9D. > > The other approach is understanding the differences and trying to set a > slightly higher bar that highlights conditional requirements of the > collective; what you call =E2=80=9Charmfully broad=E2=80=9D. > > > > What I'm saying is that if your goal is IPv6 deployment in a reasonable > timeframe, then the right strategy is *not* to make a list of all the > features under the sun, wait until they have all been implemented, and > deploy them. A better strategy is to start from the features that are > required, test and deploy those, and then iterate. As the industry evolve= s > and IPv6 becomes more common, IPv6 features will become higher priority f= or > vendors and they will get implemented. > > > > On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick > wrote: > > This is the game of chicken approach, I have no doubt it works, but is it > inclusive to all mobile operators? > > For me, it has some limitations: > > - The operator must have top down backing for a terminal policy > of =E2=80=9CIPv6 or you are out=E2=80=9D (now that is a wildcard conditio= n in itself); it > may compromise relationships in a valuable ecosystem > > - Where the operator has high major market power helps. Where > markets have a number of players ready to play the IPv6 game, there is an > advantage. Otherwise the operator is very exposed to divide and conquer > > - Currently it tends to play out as a the simplest set of > requirements. Which also means simplest set of network capabilities. > Sometimes these simplest set of network capabilities are at odds with the > business priorities of the operator (clear examples are: APN strategy, > tethering approach, roaming approach, subsidised handset vs =E2=80=9CSIM-= only=E2=80=9D) > > (Not having an IPv6 capable network is a myth you are promoting to > discredit operator views, it is a red herring =E2=80=93 any operator spec= ifying * > *any** IPv6 requirements will very quickly need this capability to > validate terminals whatever the path they choose.) > > > > I can see why you argue for lowest common denominator of v6 requirements. > > I think your stance that this can work across the board is =E2=80=9Charmf= ully > restrictive=E2=80=9D. > > The other approach is understanding the differences and trying to set a > slightly higher bar that highlights conditional requirements of the > collective; what you call =E2=80=9Charmfully broad=E2=80=9D. > > > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com > ] > *Sent:* 17 February 2015 02:41 > *To:* Heatley, Nick > *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org > ) > *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? > > > > On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti > wrote: > > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, an= d > give the OEMs a credible signal that from date X onwards, you *will* fail > TA on every device that doesn't implement IPv6, and you *will not* waive > the requirement. That's what Verizon and T-Mobile did, and it worked for > them. > > > > Also: if you think that this strategy is not feasible because you do not > have an IPv6 network yet, then yes, that's true - you can't make IPv6 a > device requirement until you have an IPv6 network. > > > > But I think the key point here is that apart from the lack of 464xlat on > iOS, the mobile operating systems are a lot more ready for IPv6 than you > might think they are. Once the network is complete, I think turning on IP= v6 > in the devices does work. Orange Poland, Telenor, and SK Telecom should b= e > able to confirm. > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or us= e > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachment= s > are free from any virus, but it remains your responsibility to ensure tha= t > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > > > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or us= e > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachment= s > are free from any virus, but it remains your responsibility to ensure tha= t > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > --f46d043be152881222050f5e30a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authors,

I know you said the 3gpp is not interested in t= his work, what about GSMA ?=C2=A0 They write profiles for mobile networks ,= right? =C2=A0

CB

On Wednesday, February 18= , 2015, <mohamed.boucad= air@orange.com> wrote:

Hi Nick,

=C2=A0<= /p>

I fully agree.

=C2=A0<= /p>

Cheers,

Med=

=C2=A0=

De=C2=A0: v6op= s [mailto:v6ops-bounces@ietf.org] De la part de Heatley, Nick
Envoy=C3=A9=C2=A0: mercredi 18 f=C3=A9vrier 2015 10:35
=C3=80=C2=A0: Lorenzo Colitti
Cc=C2=A0: IPv6 Ops WG (v6ops@ietf.org)
Objet=C2=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last= call- "harmfully broad"?

=C2=A0

Yes, I agr= ee with you, that is a sensible approach.

Working wi= th each vendor in turn.

(You know = each vendor who claims IPv6 readiness for their terminal, will never say wh= ether the device will work on the operators IPv6 network.

So it need= s to be collaborative.)

=C2= =A0

So all thi= s document is doing is setting a collective roadmap, rather than expect ven= dors to do their own thing. Given we agree on the above, this is not harmful.

=C2= =A0

I think th= e real disagreement comes from your opinion that this is not IETF.

(By the wa= y, mobile operators have had discussions with the sister org of the Interne= t Society about what would help mobile operators introduce IPv6.

One of the= major major themes has been terminals.)

=C2= =A0

=C2= =A0

From: Lorenzo Colitti [mailto:lorenzo= @google.com]
Sent: 18 February 2015 07:26
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG (v6ops@ietf.org= )
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last cal= l- "harmfully broad"?

=C2=A0

On Tue, Feb 17, 2015 at 8:31 PM= , Heatley, Nick <nick.heatley@ee.co.uk> = wrote:

I can see = why you argue for lowest common denominator of v6 requirements.

I think yo= ur stance that this can work across the board is =E2=80=9Charmfully restric= tive=E2=80=9D.

The other = approach is understanding the differences and trying to set a slightly high= er bar that highlights conditional requirements of the collective; what you c= all =C2=A0=E2=80=9Charmfully broad=E2=80=9D.=

=C2=A0

What I'm saying is that if = your goal is IPv6 deployment in a reasonable timeframe, then the right stra= tegy is=C2=A0*not* to make a list of all the features under the sun, wait u= ntil they have all been implemented, and deploy them. A better strategy is to start from the features that are required, t= est and deploy those, and then iterate. As the industry evolves and IPv6 be= comes more common, IPv6 features will become higher priority for vendors an= d they will get implemented.

=C2=A0

On Tue, Feb 17, 2015 at 8:31 PM= , Heatley, Nick <nick.heatley@ee.co.uk> = wrote:

This is th= e game of chicken approach, I have no doubt it works, but is it inclusive to all mobile operators?<= /p>

For me, it= has some limitations:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 The operator must have top= down backing for a terminal policy of =E2=80=9CIPv6 or you are out=E2=80= =9D (now that is a wildcard condition in itself); it may compromise relatio= nships in a valuable ecosystem

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Where the operator has hig= h major market power helps. Where markets have a number of players ready to= play the IPv6 game, there is an advantage. Otherwise the operator is very exposed to divide and conquer=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Currently it tends to play= out as a the simplest set of requirements. Which also means simplest set o= f network capabilities. Sometimes these simplest set of network capabilities are at odds with the business priorities of the opera= tor (clear examples are: APN strategy, tethering approach, roaming approach= , subsidised handset vs =E2=80=9CSIM-only=E2=80=9D)

(Not havin= g an IPv6 capable network is a myth you are promoting to discredit operator views, it is a red herring =E2=80=93 any operator specifying *any* = IPv6 requirements will very quickly need this capability to validate termin= als whatever the path they choose.)

=C2=A0

I can see = why you argue for lowest common denominator of v6 requirements.

I think yo= ur stance that this can work across the board is =E2=80=9Charmfully restric= tive=E2=80=9D.

The other = approach is understanding the differences and trying to set a slightly high= er bar that highlights conditional requirements of the collective; what you c= all =C2=A0=E2=80=9Charmfully broad=E2=80=9D.=

=C2=A0

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: 17 February 2015 02:41
To: Heatley, Nick
Cc: Ross Chandler; IPv6 Ops WG (v6ops@ietf.org= )
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last cal= l- "harmfully broad"?

=C2=A0

On Tue, Feb 17, 2015 at 10:57 A= M, Lorenzo Colitti <lorenzo@google.com> wro= te:

Yes. Make IPv6* (see below) a r= equirement for carrier-branded devices, and give the OEMs a credible signal= that from date X onwards, you *will* fail TA on every device that doesn't implement IPv6, and you *will not* waive the requi= rement. That's what Verizon and T-Mobile did, and it worked for them.

=C2=A0

Also: if you think that this st= rategy is not feasible because you do not have an IPv6 network yet, then ye= s, that's true - you can't make IPv6 a device requirement until you have an IPv6 network.

=C2=A0

But I think the key point here = is that apart from the lack of 464xlat on iOS, the mobile operating systems= are a lot more ready for IPv6 than you might think they are. Once the network is complete, I think turning on IPv6 in the dev= ices does work. Orange Poland, Telenor, and SK Telecom should be able to co= nfirm.

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named per= son(s).=C2=A0 If you are not the intended recipient, notify the sender imme= diately, delete this email from your system and do not disclose or use for = any purpose.=C2=A0
=C2=A0
We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW

=C2=A0

=C2=A0

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named per= son(s).=C2=A0 If you are not the intended recipient, notify the sender imme= diately, delete this email from your system and do not disclose or use for = any purpose.=C2=A0
=C2=A0
We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfords= hire, AL10 9BW

=C2=A0

--f46d043be152881222050f5e30a6-- From nobody Wed Feb 18 07:08:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADA1A916C for ; Wed, 18 Feb 2015 07:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekutJIQFsnT1 for ; Wed, 18 Feb 2015 07:08:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B18D1A893E for ; Wed, 18 Feb 2015 07:08:55 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1IF8rCs021453; Wed, 18 Feb 2015 16:08:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E8C0201E06; Wed, 18 Feb 2015 16:09:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F253F200E1F; Wed, 18 Feb 2015 16:09:56 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1IF8hTl013350; Wed, 18 Feb 2015 16:08:53 +0100 Message-ID: <54E4AAFB.8060107@gmail.com> Date: Wed, 18 Feb 2015 16:08:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Metzler, Dan J" , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <787AE7BB302AE849A7480A190F8B93300490AEF6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DE2D40.50908@gmail.com> <54E0F9E3.8000802@gmail.com> <54E4959C.80602@gmail.com> <787AE7BB302AE849A7480A190F8B93300490D924@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490D924@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:08:58 -0000 Le 18/02/2015 15:03, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > Can you please elaborate on this part? > > I guess by "IPv6-only/464xlat/clat" you mean "IPv6-only/clat/NAT64", no? 464xlat is the same as saying NAT64 two times, no? I meant to say that the *AT address translation involved in a NAT64-and-464XLAT-and-CLAT IPv6-only access network offers an IPv6 address and a private IPv4 address to the end user. Right? Alex > > Thank you. > > Cheers, > Med > > -----Message d'origine----- > De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Envoyé : mercredi 18 février 2015 14:38 > À : Metzler, Dan J; BOUCADAIR Mohamed IMT/OLN; Heatley, Nick > Cc : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant > > > If IPv6-only/464xlat/clat was offering a publicly routable IPv4 address > to the smartphone's AF-dependent literal-using applications - then I > would not complain about IPv6-only/464xlat/clat. > > Alex > From nobody Wed Feb 18 07:46:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBC1A8852 for ; Wed, 18 Feb 2015 07:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZsU-0VUT1nx for ; Wed, 18 Feb 2015 07:46:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6938E1A876E for ; Wed, 18 Feb 2015 07:46:29 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 5B6F7374038; Wed, 18 Feb 2015 16:46:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3E1CB1800A5; Wed, 18 Feb 2015 16:46:27 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 16:46:27 +0100 From: To: Ca By Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQS4y5ixBJZ1L350WogIuKXDMPO5z2h/nw Date: Wed, 18 Feb 2015 15:46:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490DAE5OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.18.143920 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:46:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490DAE5OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FtZXJvbiwNCg0KSXQgaXMgd2FzdGVmdWwgdG8gaW5pdGlhdGUgdGhpcyB3b3JrIGluIGFu b3RoZXIgZm9ydW0gd2hpbGUgYm90aCB0aGUgSVB2NiBleHBlcnRpc2UgYW5kIHRoZSBrbm93bGVk Z2Ugb2YgbW9iaWxlIG5ldHdvcmtzIGlzIGF2YWlsYWJsZSBhdCB0aGUgSUVURi4NCg0KRldJVywg dGhlIElFVEYgcHJvZHVjZWQgcHJvZmlsZSBkb2N1bWVudHMgKHJlYWQgQ1BFIHJlcXVpcmVtZW50 cyBSRkNzKSB3aGlsZSBvbmUgY2FuIHRoaW5rIEJCRiBjYW4gYmUgYSBsZWdpdGltYXRlIGZvcnVt IHRvIHByb2R1Y2Ugc3VjaCBkb2N1bWVudHMuIFRoaXMgZG9jdW1lbnQgaXMgbm90IGFuIGV4Y2Vw dGlvbi4NCg0KSeKAmW0gc3VyZSB3ZSB3aWxsIGNvbWUgdXAgdG8gYSBiYWxhbmNlZCBhcHByb2Fj aCB0byBzYXRpc2Z5IHRoZSBjb21tZW50cyByZWNlaXZlZCBzbyBmYXIuDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IENhIEJ5IFttYWlsdG86Y2IubGlzdDZAZ21haWwuY29tXQ0KRW52b3nDqSA6IG1l cmNyZWRpIDE4IGbDqXZyaWVyIDIwMTUgMTY6MDgNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1U L09MTg0KQ2MgOiBIZWF0bGV5LCBOaWNrOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpDQpP YmpldCA6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxl IGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCkF1dGhvcnMsDQoNCkkga25vdyB5b3Ug c2FpZCB0aGUgM2dwcCBpcyBub3QgaW50ZXJlc3RlZCBpbiB0aGlzIHdvcmssIHdoYXQgYWJvdXQg R1NNQSA/ICBUaGV5IHdyaXRlIHByb2ZpbGVzIGZvciBtb2JpbGUgbmV0d29ya3MgLCByaWdodD8N Cg0KQ0INCg0KT24gV2VkbmVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNSwgPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90 ZToNCkhpIE5pY2ssDQoNCkkgZnVsbHkgYWdyZWUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwn Y3ZtbCcsJ3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmcnKTs+XSBEZSBsYSBwYXJ0IGRlIEhlYXRsZXks IE5pY2sNCkVudm95w6kgOiBtZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDEwOjM1DQrDgCA6IExv cmVuem8gQ29saXR0aQ0KQ2MgOiBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmc8amF2YXNjcmlw dDpfZSglN0IlN0QsJ2N2bWwnLCd2Nm9wc0BpZXRmLm9yZycpOz4pDQpPYmpldCA6IFJlOiBbdjZv cHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhh cm1mdWxseSBicm9hZCI/DQoNClllcywgSSBhZ3JlZSB3aXRoIHlvdSwgdGhhdCBpcyBhIHNlbnNp YmxlIGFwcHJvYWNoLg0KV29ya2luZyB3aXRoIGVhY2ggdmVuZG9yIGluIHR1cm4uDQooWW91IGtu b3cgZWFjaCB2ZW5kb3Igd2hvIGNsYWltcyBJUHY2IHJlYWRpbmVzcyBmb3IgdGhlaXIgdGVybWlu YWwsIHdpbGwgbmV2ZXIgc2F5IHdoZXRoZXIgdGhlIGRldmljZSB3aWxsIHdvcmsgb24gdGhlIG9w ZXJhdG9ycyBJUHY2IG5ldHdvcmsuDQpTbyBpdCBuZWVkcyB0byBiZSBjb2xsYWJvcmF0aXZlLikN Cg0KU28gYWxsIHRoaXMgZG9jdW1lbnQgaXMgZG9pbmcgaXMgc2V0dGluZyBhIGNvbGxlY3RpdmUg cm9hZG1hcCwgcmF0aGVyIHRoYW4gZXhwZWN0IHZlbmRvcnMgdG8gZG8gdGhlaXIgb3duIHRoaW5n LiBHaXZlbiB3ZSBhZ3JlZSBvbiB0aGUgYWJvdmUsIHRoaXMgaXMgbm90IGhhcm1mdWwuDQoNCkkg dGhpbmsgdGhlIHJlYWwgZGlzYWdyZWVtZW50IGNvbWVzIGZyb20geW91ciBvcGluaW9uIHRoYXQg dGhpcyBpcyBub3QgSUVURi4NCihCeSB0aGUgd2F5LCBtb2JpbGUgb3BlcmF0b3JzIGhhdmUgaGFk IGRpc2N1c3Npb25zIHdpdGggdGhlIHNpc3RlciBvcmcgb2YgdGhlIEludGVybmV0IFNvY2lldHkg YWJvdXQgd2hhdCB3b3VsZCBoZWxwIG1vYmlsZSBvcGVyYXRvcnMgaW50cm9kdWNlIElQdjYuDQpP bmUgb2YgdGhlIG1ham9yIG1ham9yIHRoZW1lcyBoYXMgYmVlbiB0ZXJtaW5hbHMuKQ0KDQoNCkZy b206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbTxqYXZhc2NyaXB0 Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9AZ29vZ2xlLmNvbScpOz5dDQpTZW50OiAxOCBGZWJy dWFyeSAyMDE1IDA3OjI2DQpUbzogSGVhdGxleSwgTmljaw0KQ2M6IFJvc3MgQ2hhbmRsZXI7IElQ djYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2 b3BzQGlldGYub3JnJyk7PikNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMt bW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9u IFR1ZSwgRmViIDE3LCAyMDE1IGF0IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sgPG5pY2suaGVhdGxl eUBlZS5jby51azxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ25pY2suaGVhdGxleUBlZS5j by51aycpOz4+IHdyb3RlOg0KSSBjYW4gc2VlIHdoeSB5b3UgYXJndWUgZm9yIGxvd2VzdCBjb21t b24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLg0KSSB0aGluayB5b3VyIHN0YW5jZSB0 aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDigJxoYXJtZnVsbHkgcmVzdHJp Y3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVy ZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGlnaHRseSBoaWdoZXIgYmFyIHRoYXQgaGlnaGxp Z2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNvbGxlY3RpdmU7IHdoYXQgeW91 IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKAnS4NCg0KV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQg aWYgeW91ciBnb2FsIGlzIElQdjYgZGVwbG95bWVudCBpbiBhIHJlYXNvbmFibGUgdGltZWZyYW1l LCB0aGVuIHRoZSByaWdodCBzdHJhdGVneSBpcyAqbm90KiB0byBtYWtlIGEgbGlzdCBvZiBhbGwg dGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4sIHdhaXQgdW50aWwgdGhleSBoYXZlIGFsbCBiZWVu IGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0uIEEgYmV0dGVyIHN0cmF0ZWd5IGlzIHRvIHN0 YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBsb3kg dGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJUHY2 IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVyIHBy aW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGltcGxlbWVudGVkLg0KDQpPbiBU dWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlA ZWUuY28udWs8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCduaWNrLmhlYXRsZXlAZWUuY28u dWsnKTs+PiB3cm90ZToNClRoaXMgaXMgdGhlIGdhbWUgb2YgY2hpY2tlbiBhcHByb2FjaCwgSSBo YXZlIG5vIGRvdWJ0IGl0IHdvcmtzLCBidXQgaXMgaXQgaW5jbHVzaXZlIHRvIGFsbCBtb2JpbGUg b3BlcmF0b3JzPw0KRm9yIG1lLCBpdCBoYXMgc29tZSBsaW1pdGF0aW9uczoNCg0KLSAgICAgICAg ICBUaGUgb3BlcmF0b3IgbXVzdCBoYXZlIHRvcCBkb3duIGJhY2tpbmcgZm9yIGEgdGVybWluYWwg cG9saWN5IG9mIOKAnElQdjYgb3IgeW91IGFyZSBvdXTigJ0gKG5vdyB0aGF0IGlzIGEgd2lsZGNh cmQgY29uZGl0aW9uIGluIGl0c2VsZik7IGl0IG1heSBjb21wcm9taXNlIHJlbGF0aW9uc2hpcHMg aW4gYSB2YWx1YWJsZSBlY29zeXN0ZW0NCg0KLSAgICAgICAgICBXaGVyZSB0aGUgb3BlcmF0b3Ig aGFzIGhpZ2ggbWFqb3IgbWFya2V0IHBvd2VyIGhlbHBzLiBXaGVyZSBtYXJrZXRzIGhhdmUgYSBu dW1iZXIgb2YgcGxheWVycyByZWFkeSB0byBwbGF5IHRoZSBJUHY2IGdhbWUsIHRoZXJlIGlzIGFu IGFkdmFudGFnZS4gT3RoZXJ3aXNlIHRoZSBvcGVyYXRvciBpcyB2ZXJ5IGV4cG9zZWQgdG8gZGl2 aWRlIGFuZCBjb25xdWVyDQoNCi0gICAgICAgICAgQ3VycmVudGx5IGl0IHRlbmRzIHRvIHBsYXkg b3V0IGFzIGEgdGhlIHNpbXBsZXN0IHNldCBvZiByZXF1aXJlbWVudHMuIFdoaWNoIGFsc28gbWVh bnMgc2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsgY2FwYWJpbGl0aWVzLiBTb21ldGltZXMgdGhlc2Ug c2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsgY2FwYWJpbGl0aWVzIGFyZSBhdCBvZGRzIHdpdGggdGhl IGJ1c2luZXNzIHByaW9yaXRpZXMgb2YgdGhlIG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6 IEFQTiBzdHJhdGVneSwgdGV0aGVyaW5nIGFwcHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJz aWRpc2VkIGhhbmRzZXQgdnMg4oCcU0lNLW9ubHnigJ0pDQooTm90IGhhdmluZyBhbiBJUHY2IGNh cGFibGUgbmV0d29yayBpcyBhIG15dGggeW91IGFyZSBwcm9tb3RpbmcgdG8gZGlzY3JlZGl0IG9w ZXJhdG9yIHZpZXdzLCBpdCBpcyBhIHJlZCBoZXJyaW5nIOKAkyBhbnkgb3BlcmF0b3Igc3BlY2lm eWluZyAqYW55KiBJUHY2IHJlcXVpcmVtZW50cyB3aWxsIHZlcnkgcXVpY2tseSBuZWVkIHRoaXMg Y2FwYWJpbGl0eSB0byB2YWxpZGF0ZSB0ZXJtaW5hbHMgd2hhdGV2ZXIgdGhlIHBhdGggdGhleSBj aG9vc2UuKQ0KDQpJIGNhbiBzZWUgd2h5IHlvdSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5v bWluYXRvciBvZiB2NiByZXF1aXJlbWVudHMuDQpJIHRoaW5rIHlvdXIgc3RhbmNlIHRoYXQgdGhp cyBjYW4gd29yayBhY3Jvc3MgdGhlIGJvYXJkIGlzIOKAnGhhcm1mdWxseSByZXN0cmljdGl2ZeKA nS4NClRoZSBvdGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBkaWZmZXJlbmNlcyBh bmQgdHJ5aW5nIHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlciBiYXIgdGhhdCBoaWdobGlnaHRzIGNv bmRpdGlvbmFsIHJlcXVpcmVtZW50cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hhdCB5b3UgY2FsbCAg 4oCcaGFybWZ1bGx5IGJyb2Fk4oCdLg0KDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9A Z29vZ2xlLmNvbScpOz5dDQpTZW50OiAxNyBGZWJydWFyeSAyMDE1IDAyOjQxDQpUbzogSGVhdGxl eSwgTmljaw0KQ2M6IFJvc3MgQ2hhbmRsZXI7IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZzxq YXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2b3BzQGlldGYub3JnJyk7PikNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDEwOjU3 IEFNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxqYXZhc2NyaXB0Ol9lKCU3 QiU3RCwnY3ZtbCcsJ2xvcmVuem9AZ29vZ2xlLmNvbScpOz4+IHdyb3RlOg0KWWVzLiBNYWtlIElQ djYqIChzZWUgYmVsb3cpIGEgcmVxdWlyZW1lbnQgZm9yIGNhcnJpZXItYnJhbmRlZCBkZXZpY2Vz LCBhbmQgZ2l2ZSB0aGUgT0VNcyBhIGNyZWRpYmxlIHNpZ25hbCB0aGF0IGZyb20gZGF0ZSBYIG9u d2FyZHMsIHlvdSAqd2lsbCogZmFpbCBUQSBvbiBldmVyeSBkZXZpY2UgdGhhdCBkb2Vzbid0IGlt cGxlbWVudCBJUHY2LCBhbmQgeW91ICp3aWxsIG5vdCogd2FpdmUgdGhlIHJlcXVpcmVtZW50LiBU aGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBULU1vYmlsZSBkaWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRo ZW0uDQoNCkFsc286IGlmIHlvdSB0aGluayB0aGF0IHRoaXMgc3RyYXRlZ3kgaXMgbm90IGZlYXNp YmxlIGJlY2F1c2UgeW91IGRvIG5vdCBoYXZlIGFuIElQdjYgbmV0d29yayB5ZXQsIHRoZW4geWVz LCB0aGF0J3MgdHJ1ZSAtIHlvdSBjYW4ndCBtYWtlIElQdjYgYSBkZXZpY2UgcmVxdWlyZW1lbnQg dW50aWwgeW91IGhhdmUgYW4gSVB2NiBuZXR3b3JrLg0KDQpCdXQgSSB0aGluayB0aGUga2V5IHBv aW50IGhlcmUgaXMgdGhhdCBhcGFydCBmcm9tIHRoZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0 aGUgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zIGFyZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2 IHRoYW4geW91IG1pZ2h0IHRoaW5rIHRoZXkgYXJlLiBPbmNlIHRoZSBuZXR3b3JrIGlzIGNvbXBs ZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2NiBpbiB0aGUgZGV2aWNlcyBkb2VzIHdvcmsuIE9y YW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBTSyBUZWxlY29tIHNob3VsZCBiZSBhYmxlIHRvIGNv bmZpcm0uDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMp LiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRv IG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLg0KDQpXZSBtYXkgbW9uaXRvciBh bGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdp c2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFu ZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91 ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkg YWZmZWN0IHlvdS4NCg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxl cw0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNl IEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jk c2hpcmUsIEFMMTAgOUJXDQoNCg0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1h aWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUt bmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91 ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLg0KDQpX ZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdp dGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhh dCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0 IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRv IG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4NCg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBF bmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJl Z2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0 ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93300490DAE5OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5IaSBDYW1lcm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl0IGlzIHdhc3Rl ZnVsIHRvIGluaXRpYXRlIHRoaXMgd29yayBpbiBhbm90aGVyIGZvcnVtIHdoaWxlIGJvdGggdGhl IElQdjYgZXhwZXJ0aXNlIGFuZCB0aGUga25vd2xlZGdlIG9mIG1vYmlsZSBuZXR3b3JrcyBpcyBh dmFpbGFibGUgYXQgdGhlIElFVEYuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RldJ VywgdGhlIElFVEYgcHJvZHVjZWQgcHJvZmlsZSBkb2N1bWVudHMgKHJlYWQgQ1BFIHJlcXVpcmVt ZW50cyBSRkNzKSB3aGlsZSBvbmUgY2FuIHRoaW5rIEJCRiBjYW4gYmUgYSBsZWdpdGltYXRlIGZv cnVtIHRvIHByb2R1Y2Ugc3VjaCBkb2N1bWVudHMuDQogVGhpcyBkb2N1bWVudCBpcyBub3QgYW4g ZXhjZXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZbSBzdXJlIHdlIHdp bGwgY29tZSB1cCB0byBhIGJhbGFuY2VkIGFwcHJvYWNoIHRvIHNhdGlzZnkgdGhlIGNvbW1lbnRz IHJlY2VpdmVkIHNvIGZhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBDYSBCeSBbbWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNvbV0NCjxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDE2OjA4PGJyPg0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7DgCZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxi cj4NCjxiPkNjJm5ic3A7OjwvYj4gSGVhdGxleSwgTmljazsgSVB2NiBPcHMgV0cgKHY2b3BzQGll dGYub3JnKTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12 Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJv YWQmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg a25vdyB5b3Ugc2FpZCB0aGUgM2dwcCBpcyBub3QgaW50ZXJlc3RlZCBpbiB0aGlzIHdvcmssIHdo YXQgYWJvdXQgR1NNQSA/Jm5ic3A7IFRoZXkgd3JpdGUgcHJvZmlsZXMgZm9yIG1vYmlsZSBuZXR3 b3JrcyAsIHJpZ2h0PyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q0I8YnI+DQo8YnI+DQpPbiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE4 LCAyMDE1LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgTmljayw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGZ1bGx5IGFncmVlLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g djZvcHMgW21haWx0bzo8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2b3Bz LWJvdW5jZXNAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj52Nm9wcy1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTggZsOpdnJpZXIgMjAxNSAxMDozNTxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gTG9yZW56byBDb2xpdHRpPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBJUHY2IE9w cyBXRyAoPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd2Nm9wc0BpZXRmLm9y ZycpOyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9m aWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBhZ3JlZSB3aXRoIHlv dSwgdGhhdCBpcyBhIHNlbnNpYmxlIGFwcHJvYWNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Xb3JraW5nIHdpdGggZWFjaCB2ZW5kb3IgaW4gdHVybi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KFlvdSBrbm93IGVhY2gg dmVuZG9yIHdobyBjbGFpbXMgSVB2NiByZWFkaW5lc3MgZm9yIHRoZWlyIHRlcm1pbmFsLCB3aWxs IG5ldmVyIHNheSB3aGV0aGVyDQogdGhlIGRldmljZSB3aWxsIHdvcmsgb24gdGhlIG9wZXJhdG9y cyBJUHY2IG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNvIGl0IG5lZWRzIHRvIGJlIGNvbGxhYm9yYXRpdmUuKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gYWxsIHRoaXMgZG9jdW1lbnQgaXMgZG9pbmcgaXMgc2V0 dGluZyBhIGNvbGxlY3RpdmUgcm9hZG1hcCwgcmF0aGVyIHRoYW4gZXhwZWN0IHZlbmRvcnMNCiB0 byBkbyB0aGVpciBvd24gdGhpbmcuIEdpdmVuIHdlIGFncmVlIG9uIHRoZSBhYm92ZSwgdGhpcyBp cyBub3QgaGFybWZ1bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg dGhpbmsgdGhlIHJlYWwgZGlzYWdyZWVtZW50IGNvbWVzIGZyb20geW91ciBvcGluaW9uIHRoYXQg dGhpcyBpcyBub3QgSUVURi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+KEJ5IHRoZSB3YXksIG1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBoYWQgZGlzY3Vzc2lvbnMg d2l0aCB0aGUgc2lzdGVyIG9yZyBvZiB0aGUgSW50ZXJuZXQNCiBTb2NpZXR5IGFib3V0IHdoYXQg d291bGQgaGVscCBtb2JpbGUgb3BlcmF0b3JzIGludHJvZHVjZSBJUHY2Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgb2YgdGhlIG1ham9yIG1ham9yIHRo ZW1lcyBoYXMgYmVlbiB0ZXJtaW5hbHMuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3Jlbnpv DQogQ29saXR0aSBbPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdsb3Jlbnpv QGdvb2dsZS5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bG9yZW56b0Bnb29nbGUuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBGZWJydWFyeSAyMDE1IDA3OjI2PGJyPg0KPGI+ VG86PC9iPiBIZWF0bGV5LCBOaWNrPGJyPg0KPGI+Q2M6PC9iPiBSb3NzIENoYW5kbGVyOyBJUHY2 IE9wcyBXRyAoPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd2Nm9wc0BpZXRm Lm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2Zp bGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgODoz MSBQTSwgSGVhdGxleSwgTmljayAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2 bWwnLCduaWNrLmhlYXRsZXlAZWUuY28udWsnKTsiIHRhcmdldD0iX2JsYW5rIj5uaWNrLmhlYXRs ZXlAZWUuY28udWs8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbiBzZWUgd2h5IHlvdSBhcmd1ZSBmb3Ig bG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZiB2NiByZXF1aXJlbWVudHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgeW91ciBzdGFuY2UgdGhh dCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0 aXZl4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUg b3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWlu ZyB0byBzZXQgYSBzbGlnaHRseSBoaWdoZXINCiBiYXIgdGhhdCBoaWdobGlnaHRzIGNvbmRpdGlv bmFsIHJlcXVpcmVtZW50cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hhdCB5b3UgY2FsbCAmbmJzcDvi gJxoYXJtZnVsbHkgYnJvYWTigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5XaGF0IEknbSBzYXlpbmcgaXMgdGhhdCBpZiB5b3Vy IGdvYWwgaXMgSVB2NiBkZXBsb3ltZW50IGluIGEgcmVhc29uYWJsZSB0aW1lZnJhbWUsIHRoZW4g dGhlIHJpZ2h0IHN0cmF0ZWd5IGlzJm5ic3A7Km5vdCogdG8gbWFrZSBhIGxpc3Qgb2YgYWxsIHRo ZSBmZWF0dXJlcyB1bmRlciB0aGUNCiBzdW4sIHdhaXQgdW50aWwgdGhleSBoYXZlIGFsbCBiZWVu IGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRoZW0uIEEgYmV0dGVyIHN0cmF0ZWd5IGlzIHRvIHN0 YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBsb3kg dGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJUHY2 IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVyDQog cHJpb3JpdHkgZm9yIHZlbmRvcnMgYW5kIHRoZXkgd2lsbCBnZXQgaW1wbGVtZW50ZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sgJmx0 OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbmljay5oZWF0bGV5QGVlLmNv LnVrJyk7IiB0YXJnZXQ9Il9ibGFuayI+bmljay5oZWF0bGV5QGVlLmNvLnVrPC9hPiZndDsgd3Jv dGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhpcyBpcyB0aGUgZ2FtZSBvZiBjaGlja2VuIGFwcHJvYWNoLCBJIGhhdmUgbm8gZG91 YnQgaXQgd29ya3MsIGJ1dCBpcyBpdCBpbmNsdXNpdmUNCiB0byBhbGwgbW9iaWxlIG9wZXJhdG9y cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIG1lLCBp dCBoYXMgc29tZSBsaW1pdGF0aW9uczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgb3BlcmF0b3IgbXVzdCBoYXZlIHRvcCBkb3duIGJhY2tpbmcgZm9yIGEgdGVybWlu YWwgcG9saWN5IG9mIOKAnElQdjYgb3IgeW91IGFyZSBvdXTigJ0gKG5vdyB0aGF0IGlzIGEgd2ls ZGNhcmQgY29uZGl0aW9uIGluIGl0c2VsZik7IGl0IG1heSBjb21wcm9taXNlIHJlbGF0aW9uc2hp cHMNCiBpbiBhIHZhbHVhYmxlIGVjb3N5c3RlbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldoZXJlIHRoZSBvcGVyYXRvciBoYXMgaGlnaCBtYWpvciBtYXJrZXQgcG93ZXIg aGVscHMuIFdoZXJlIG1hcmtldHMgaGF2ZSBhIG51bWJlciBvZiBwbGF5ZXJzIHJlYWR5IHRvIHBs YXkgdGhlIElQdjYgZ2FtZSwgdGhlcmUgaXMgYW4gYWR2YW50YWdlLiBPdGhlcndpc2UgdGhlDQog b3BlcmF0b3IgaXMgdmVyeSBleHBvc2VkIHRvIGRpdmlkZSBhbmQgY29ucXVlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCB0ZW5kcyB0byBwbGF5IG91 dCBhcyBhIHRoZSBzaW1wbGVzdCBzZXQgb2YgcmVxdWlyZW1lbnRzLiBXaGljaCBhbHNvIG1lYW5z IHNpbXBsZXN0IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcy4gU29tZXRpbWVzIHRoZXNlIHNp bXBsZXN0IHNldCBvZg0KIG5ldHdvcmsgY2FwYWJpbGl0aWVzIGFyZSBhdCBvZGRzIHdpdGggdGhl IGJ1c2luZXNzIHByaW9yaXRpZXMgb2YgdGhlIG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6 IEFQTiBzdHJhdGVneSwgdGV0aGVyaW5nIGFwcHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJz aWRpc2VkIGhhbmRzZXQgdnMg4oCcU0lNLW9ubHnigJ0pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihOb3QgaGF2aW5nIGFuIElQdjYgY2FwYWJsZSBuZXR3b3Jr IGlzIGEgbXl0aCB5b3UgYXJlIHByb21vdGluZyB0byBkaXNjcmVkaXQgb3BlcmF0b3INCiB2aWV3 cywgaXQgaXMgYSByZWQgaGVycmluZyDigJMgYW55IG9wZXJhdG9yIHNwZWNpZnlpbmcgKjxiPmFu eTwvYj4qIElQdjYgcmVxdWlyZW1lbnRzIHdpbGwgdmVyeSBxdWlja2x5IG5lZWQgdGhpcyBjYXBh YmlsaXR5IHRvIHZhbGlkYXRlIHRlcm1pbmFscyB3aGF0ZXZlciB0aGUgcGF0aCB0aGV5IGNob29z ZS4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbiBzZWUgd2h5 IHlvdSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZiB2NiByZXF1aXJlbWVu dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsg eW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFy bWZ1bGx5IHJlc3RyaWN0aXZl4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgb3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVy ZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGlnaHRseSBoaWdoZXINCiBiYXIgdGhhdCBoaWdo bGlnaHRzIGNvbmRpdGlvbmFsIHJlcXVpcmVtZW50cyBvZiB0aGUgY29sbGVjdGl2ZTsgd2hhdCB5 b3UgY2FsbCAmbmJzcDvigJxoYXJtZnVsbHkgYnJvYWTigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IExvcmVuem8NCiBDb2xpdHRpIFttYWlsdG86PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0Il N0QsJ2N2bWwnLCdsb3JlbnpvQGdvb2dsZS5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj5sb3Jlbnpv QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE3IEZlYnJ1YXJ5IDIwMTUgMDI6 NDE8YnI+DQo8Yj5Ubzo8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgQ2hh bmRsZXI7IElQdjYgT3BzIFdHICg8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcs J3Y2b3BzQGlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+KTxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90O2hhcm1mdWxseSBicm9hZCZxdW90Oz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBUdWUsIEZlYiAxNywg MjAxNSBhdCAxMDo1NyBBTSwgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0 Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9AZ29vZ2xlLmNvbScpOyIgdGFyZ2V0PSJfYmxhbmsi PmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlllcy4gTWFrZSBJUHY2KiAoc2VlIGJlbG93KSBh IHJlcXVpcmVtZW50IGZvciBjYXJyaWVyLWJyYW5kZWQgZGV2aWNlcywgYW5kIGdpdmUgdGhlIE9F TXMgYSBjcmVkaWJsZSBzaWduYWwgdGhhdCBmcm9tIGRhdGUgWCBvbndhcmRzLCB5b3UgKndpbGwq IGZhaWwgVEEgb24gZXZlcnkNCiBkZXZpY2UgdGhhdCBkb2Vzbid0IGltcGxlbWVudCBJUHY2LCBh bmQgeW91ICp3aWxsIG5vdCogd2FpdmUgdGhlIHJlcXVpcmVtZW50LiBUaGF0J3Mgd2hhdCBWZXJp em9uIGFuZCBULU1vYmlsZSBkaWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRoZW0uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+QWxzbzogaWYgeW91IHRoaW5rIHRoYXQgdGhpcyBzdHJhdGVneSBpcyBub3QgZmVh c2libGUgYmVjYXVzZSB5b3UgZG8gbm90IGhhdmUgYW4gSVB2NiBuZXR3b3JrIHlldCwgdGhlbiB5 ZXMsIHRoYXQncyB0cnVlIC0geW91IGNhbid0IG1ha2UgSVB2NiBhIGRldmljZSByZXF1aXJlbWVu dA0KIHVudGlsIHlvdSBoYXZlIGFuIElQdjYgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5CdXQgSSB0aGluayB0aGUga2V5IHBvaW50 IGhlcmUgaXMgdGhhdCBhcGFydCBmcm9tIHRoZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0aGUg bW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zIGFyZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2IHRo YW4geW91IG1pZ2h0IHRoaW5rDQogdGhleSBhcmUuIE9uY2UgdGhlIG5ldHdvcmsgaXMgY29tcGxl dGUsIEkgdGhpbmsgdHVybmluZyBvbiBJUHY2IGluIHRoZSBkZXZpY2VzIGRvZXMgd29yay4gT3Jh bmdlIFBvbGFuZCwgVGVsZW5vciwgYW5kIFNLIFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29u ZmlybS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5OT1RJQ0Ug QU5EIERJU0NMQUlNRVI8YnI+DQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50 cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlz Y2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4mbmJzcDsNCjxicj4NCiZuYnNwOzxicj4NCldl IG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0 aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0 IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQg aXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8g bm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPkVFIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5k IFdhbGVzPGJyPg0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjE8YnI+DQpSZWdp c3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZp ZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Tk9USUNF IEFORCBESVNDTEFJTUVSPGJyPg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiZuYnNwOyBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRp c2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7DQo8YnI+DQombmJzcDs8YnI+DQpX ZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdp dGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhh dCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0 IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRv IG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj5FRSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFu ZCBXYWxlczxicj4NCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxPGJyPg0KUmVn aXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRm aWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490DAE5OPEXCLILM23corp_-- From nobody Wed Feb 18 08:20:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3626F1A89F9 for ; Wed, 18 Feb 2015 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFn7hB1-vu0X for ; Wed, 18 Feb 2015 08:20:42 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09BB1A89FD for ; Wed, 18 Feb 2015 08:20:32 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 0dbb4e45.2b4bf1e82940.1717256.00-2474.4866538.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 18 Feb 2015 16:20:32 +0000 (UTC) X-MXL-Hash: 54e4bbd030e4c5d1-ac404a69881722f7cdbb78f880a6edefb0646901 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 8cbb4e45.0.1717192.00-2137.4866086.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 18 Feb 2015 16:20:26 +0000 (UTC) X-MXL-Hash: 54e4bbca57dd902a-51946cbbc4ce511b61d7cff3876b7ff6d762a374 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1IGKNcL006877; Wed, 18 Feb 2015 11:20:24 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1IGKJGW006791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Feb 2015 11:20:20 -0500 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 18 Feb 2015 16:20:08 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.126]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 11:20:07 -0500 From: "STARK, BARBARA H" To: "Heatley, Nick" , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABSNY8AAB3XhwAACIyKIP//62+AgACoRwCAALakAIACvCOAgAA1nwCAARXhAIAADDeAgACUIICAAU2qgIAAJDIA///04cA= Date: Wed, 18 Feb 2015 16:20:07 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F294E4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.91.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=hoBwcu8XsvUA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=Rk_B-SlLw] X-AnalysisOut: [kFu32K_rJUA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:20:44 -0000 PiBTbyBhbGwgdGhpcyBkb2N1bWVudCBpcyBkb2luZyBpcyBzZXR0aW5nIGEgY29sbGVjdGl2ZSBy b2FkbWFwLCByYXRoZXIgdGhhbiBleHBlY3QgdmVuZG9ycyB0byBkbyB0aGVpciBvd24gdGhpbmcu IEdpdmVuIHdlIGFncmVlIG9uIHRoZSBhYm92ZSwgdGhpcyBpcyBub3QgaGFybWZ1bC4NCg0KSXTi gJlzIG5vdCBjbGVhciB0byBtZSB3aG8gdGhpcyDigJxjb2xsZWN0aXZl4oCdIGlzLiBJdCBzZWVt cyBsaWtlIGhlcmUgdGhlICJjb2xsZWN0aXZlIiBpcyB0aGUgc2V0IG9mIGF1dGhvcnMsIGJ1dCBz b21lIHBlb3BsZSBmZWFyIHRoZSBvdXRzaWRlIHdvcmxkIG1pZ2h0IHZpZXcgImNvbGxlY3RpdmUi IGFzICJJRVRGIi4gVGhhdCBzZWVtcyB0byBiZSBhIG1ham9yIHN0aWNraW5nIHBvaW50LCBhbmQs IEkgdGhpbmssIHRoZSBwZXJjZWl2ZWQgcG90ZW50aWFsICJoYXJtIi4gSXQncyB2ZXJ5IGNsZWFy IHRvIG1lIHRoYXQgImNvbGxlY3RpdmUiIGlzIG5vdCAiSUVURiIgKGFuZCBpbmZvcm1hdGlvbmFs IFJGQ3Mgc2hvdWxkIG5ldmVyIGJlIHNlZW4gYXMgImNvbGxlY3RpdmUiID0gIklFVEYiLCB0aG91 Z2ggc29tZSBvbiB0aGUgb3V0c2lkZSBkbyBoYXZlIGRpZmZpY3VsdHkgd2l0aCB0aGlzIGNvbmNl cHQpOyBub3IgaXMgImNvbGxlY3RpdmUiIGFsbCB3aXJlbGVzcyBvcGVyYXRvcnMuIEl0J3MganVz dCB0aGUgYXV0aG9ycy4NCg0KSSByZW1lbWJlciBiYWNrIHdoZW4gRFNMIHdhcyBpbiBpdHMgaW5m YW5jeSwgYW5kIHRlbGNvcyB3ZXJlIHN0cnVnZ2xpbmcgdG8gZGVwbG95IGR1ZSB0byB0aGUgbGFj ayBvZiBEU0xBTXMgYW5kIERTTCBtb2RlbXMuIFNldmVyYWwgZ290IHRvZ2V0aGVyLCBmb3JtZWQg YSBzaW5nbGUtcHVycG9zZSAiam9pbnQgcHJvY3VyZW1lbnQgZ3JvdXAiLCBkZWZpbmVkIGNvbW1v biByZXF1aXJlbWVudHMsIGFuZCBhbGwgaXNzdWVkIHRoZSBzYW1lIFJGUC4gIFRoaXMgd2FzIGRv bmUgZXh0ZXJuYWwgdG8gYWxsIFNET3Mgb3Igb3RoZXIgaW5kdXN0cnkgZ3JvdXBzLiBDb21wYW5p ZXMgd2hvIHdlcmUgbm90IHBhcnQgb2YgdGhpcyBqb2ludCBwcm9jdXJlbWVudCBncm91cCBiZW5l Zml0ZWQgYXMgd2VsbCwgYmVjYXVzZSB0aGVuIHRoZXkgY291bGQgc2F5ICJJJ2xsIGhhdmUgd2hh dCB0aGV5J3JlIGhhdmluZy4iIEl0J3MgdmVyeSBjb21tb24gZm9yIHRoZSBjb21wYW5pZXMgd2hv IGRlcGxveSBsYXRlciB0byB1c2UgdGhlIGFwcHJvYWNoIG9mIGRlcGxveWluZyB3aGF0IHRoZSAi bWFya2V0IGxlYWRlcnMiIGFyZSBkZXBsb3lpbmcuIFRoaXMgd2F5IHRoZXkgZG9uJ3QgbmVlZCB0 byBoYXZlIHBlb3BsZSB3aG8gcmVhZC91bmRlcnN0YW5kIFJGQ3MgYW5kIHN1Y2guIFRoZXkganVz dCB0cnVzdCB0aGF0IHRoZSAibWFya2V0IGxlYWRlcnMiIGhhdmUgc3VjaCBwZW9wbGUgYW5kIGtu b3cgd2hhdCB0aGV5J3JlIGRvaW5nLiBBbiBhZGRlZCBiZW5lZml0IG9mIHdhaXRpbmcgZm9yICJt YXJrZXQgbGVhZGVyIiBkZXBsb3ltZW50IGlzIHRoYXQgInVucmVhbGlzdGljIiBSRlAgcmVxdWly ZW1lbnRzIGhhdmUgYmVlbiB3ZWVkZWQgb3V0IGJ5IHRoYXQgdGltZS4gQXMgc29tZW9uZSB3aG8g aGFzIGhlbHBlZCB3cml0ZSBtYW55IFJGUHMgSSBjYW4gc2F5IHdpdGggY2VydGFpbnR5IHRoYXQg dGhlcmUgd2VyZSAibXVzdCIgaXRlbXMgaW4gYWxsIHRob3NlIFJGUHMgdGhhdCBuZXZlciBtYWRl IGl0IGludG8gdGhlIGRlcGxveWVkIHByb2R1Y3RzLiBPbmNlIGEgdGltZWxpbmUgb3IgcHJpY2Ug dGFnIGlzIGFzc29jaWF0ZWQgd2l0aCBhICJtdXN0IiwgaXQgY2FuIGxvc2UgaXRzICJtdXN0Ii1u ZXNzLg0KDQpCYXJiYXJhDQo= From nobody Wed Feb 18 08:40:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EB31A8A3B for ; Wed, 18 Feb 2015 08:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQkKZ7Nl_T4n for ; Wed, 18 Feb 2015 08:40:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F8F1A8879 for ; Wed, 18 Feb 2015 08:40:01 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6F84822C9C5; Wed, 18 Feb 2015 17:39:57 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4BB6535C048; Wed, 18 Feb 2015 17:39:57 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 17:39:57 +0100 From: To: Lorenzo Colitti , "Heatley, Nick" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABFougAAB3XhwAAAwysgAAC7dSAABUI1QAAFtSIAABXhFiAAGlOIKMAEwwNkA== Date: Wed, 18 Feb 2015 16:39:56 +0000 Message-ID: <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_A729C0B3952BEE45A1AA136ADD556BE80493F147OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:40:05 -0000 --_000_A729C0B3952BEE45A1AA136ADD556BE80493F147OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KT24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgODozMSBQTSwgSGVhdGxleSwgTmljayA8 bmljay5oZWF0bGV5QGVlLmNvLnVrPG1haWx0bzpuaWNrLmhlYXRsZXlAZWUuY28udWs+PiB3cm90 ZToNCkkgY2FuIHNlZSB3aHkgeW91IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9y IG9mIHY2IHJlcXVpcmVtZW50cy4NCkkgdGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3 b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLg0KVGhl IG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFuZCB0cnlp bmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyIGJhciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9u YWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICDigJxoYXJt ZnVsbHkgYnJvYWTigJ0uDQoNCldoYXQgSSdtIHNheWluZyBpcyB0aGF0IGlmIHlvdXIgZ29hbCBp cyBJUHY2IGRlcGxveW1lbnQgaW4gYSByZWFzb25hYmxlIHRpbWVmcmFtZSwgdGhlbiB0aGUgcmln aHQgc3RyYXRlZ3kgaXMgKm5vdCogdG8gbWFrZSBhIGxpc3Qgb2YgYWxsIHRoZSBmZWF0dXJlcyB1 bmRlciB0aGUgc3VuLCB3YWl0IHVudGlsIHRoZXkgaGF2ZSBhbGwgYmVlbiBpbXBsZW1lbnRlZCwg YW5kIGRlcGxveSB0aGVtLiBBIGJldHRlciBzdHJhdGVneSBpcyB0byBzdGFydCBmcm9tIHRoZSBm ZWF0dXJlcyB0aGF0IGFyZSByZXF1aXJlZCwgdGVzdCBhbmQgZGVwbG95IHRob3NlLCBhbmQgdGhl biBpdGVyYXRlLiBBcyB0aGUgaW5kdXN0cnkgZXZvbHZlcyBhbmQgSVB2NiBiZWNvbWVzIG1vcmUg Y29tbW9uLCBJUHY2IGZlYXR1cmVzIHdpbGwgYmVjb21lIGhpZ2hlciBwcmlvcml0eSBmb3IgdmVu ZG9ycyBhbmQgdGhleSB3aWxsIGdldCBpbXBsZW1lbnRlZC4NCltEQl0gQ291bGQgeW91IGJlIG1v cmUgZXhwbGljaXQgYW5kIGluZGljYXRlIHdoaWNoIGZlYXR1cmVzIGFyZSBub3QgdXNlZnVsIGlu IHRoZSBkcmFmdCA/IEFzIHlvdSBjYW4gbWVudGlvbiBpdCwgYWxsIGZlYXR1cmVzIGFyZSBub3Qg aW5kaWNhdGVkIGFzIG1hbmRhdG9yeSBpbiB0aGUgZHJhZnQgc28gSSBkbyBub3QgY2xlYXJseSB1 bmRlcnN0YW5kIGhvdyB0aGlzIGRvY3VtZW50IGNvbmZsaWN0cyB3aXRoIHdoYXQgeW91IHNheSBj b25zaWRlcmluZyB0aGF0IHRoZSBnb2FsIGZvciB0aGUgb3BlcmF0b3IgaXMgdG8gcHJvdmlkZSBh dCBsZWFzdCB0aGUgc2FtZSBzZXJ2aWNlIGFjY2VzcyBmb3IgdXNlcnMgd2l0aCBJUHY2IGNvbm5l Y3Rpdml0eSB0aGFuIGZvciB1c2VycyB3aXRoIElQdjQgY29ubmVjdGl2aXR5IHdoYXRldmVyIHRo ZSBzdHJhdGVneSByZXRhaW5lZCBieSB0aGUgb3BlcmF0b3IuDQoNCk9uIFR1ZSwgRmViIDE3LCAy MDE1IGF0IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sgPG5pY2suaGVhdGxleUBlZS5jby51azxtYWls dG86bmljay5oZWF0bGV5QGVlLmNvLnVrPj4gd3JvdGU6DQpUaGlzIGlzIHRoZSBnYW1lIG9mIGNo aWNrZW4gYXBwcm9hY2gsIEkgaGF2ZSBubyBkb3VidCBpdCB3b3JrcywgYnV0IGlzIGl0IGluY2x1 c2l2ZSB0byBhbGwgbW9iaWxlIG9wZXJhdG9ycz8NCkZvciBtZSwgaXQgaGFzIHNvbWUgbGltaXRh dGlvbnM6DQoNCi0gICAgICAgICAgVGhlIG9wZXJhdG9yIG11c3QgaGF2ZSB0b3AgZG93biBiYWNr aW5nIGZvciBhIHRlcm1pbmFsIHBvbGljeSBvZiDigJxJUHY2IG9yIHlvdSBhcmUgb3V04oCdIChu b3cgdGhhdCBpcyBhIHdpbGRjYXJkIGNvbmRpdGlvbiBpbiBpdHNlbGYpOyBpdCBtYXkgY29tcHJv bWlzZSByZWxhdGlvbnNoaXBzIGluIGEgdmFsdWFibGUgZWNvc3lzdGVtDQoNCi0gICAgICAgICAg V2hlcmUgdGhlIG9wZXJhdG9yIGhhcyBoaWdoIG1ham9yIG1hcmtldCBwb3dlciBoZWxwcy4gV2hl cmUgbWFya2V0cyBoYXZlIGEgbnVtYmVyIG9mIHBsYXllcnMgcmVhZHkgdG8gcGxheSB0aGUgSVB2 NiBnYW1lLCB0aGVyZSBpcyBhbiBhZHZhbnRhZ2UuIE90aGVyd2lzZSB0aGUgb3BlcmF0b3IgaXMg dmVyeSBleHBvc2VkIHRvIGRpdmlkZSBhbmQgY29ucXVlcg0KDQotICAgICAgICAgIEN1cnJlbnRs eSBpdCB0ZW5kcyB0byBwbGF5IG91dCBhcyBhIHRoZSBzaW1wbGVzdCBzZXQgb2YgcmVxdWlyZW1l bnRzLiBXaGljaCBhbHNvIG1lYW5zIHNpbXBsZXN0IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGll cy4gU29tZXRpbWVzIHRoZXNlIHNpbXBsZXN0IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcyBh cmUgYXQgb2RkcyB3aXRoIHRoZSBidXNpbmVzcyBwcmlvcml0aWVzIG9mIHRoZSBvcGVyYXRvciAo Y2xlYXIgZXhhbXBsZXMgYXJlOiBBUE4gc3RyYXRlZ3ksIHRldGhlcmluZyBhcHByb2FjaCwgcm9h bWluZyBhcHByb2FjaCwgc3Vic2lkaXNlZCBoYW5kc2V0IHZzIOKAnFNJTS1vbmx54oCdKQ0KKE5v dCBoYXZpbmcgYW4gSVB2NiBjYXBhYmxlIG5ldHdvcmsgaXMgYSBteXRoIHlvdSBhcmUgcHJvbW90 aW5nIHRvIGRpc2NyZWRpdCBvcGVyYXRvciB2aWV3cywgaXQgaXMgYSByZWQgaGVycmluZyDigJMg YW55IG9wZXJhdG9yIHNwZWNpZnlpbmcgKmFueSogSVB2NiByZXF1aXJlbWVudHMgd2lsbCB2ZXJ5 IHF1aWNrbHkgbmVlZCB0aGlzIGNhcGFiaWxpdHkgdG8gdmFsaWRhdGUgdGVybWluYWxzIHdoYXRl dmVyIHRoZSBwYXRoIHRoZXkgY2hvb3NlLikNCg0KSSBjYW4gc2VlIHdoeSB5b3UgYXJndWUgZm9y IGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWlyZW1lbnRzLg0KSSB0aGluayB5 b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDigJxoYXJt ZnVsbHkgcmVzdHJpY3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9hY2ggaXMgdW5kZXJzdGFuZGlu ZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBzbGlnaHRseSBoaWdoZXIgYmFy IHRoYXQgaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNvbGxlY3Rp dmU7IHdoYXQgeW91IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKAnS4NCg0KDQpGcm9tOiBMb3Jl bnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbT5dDQpTZW50OiAxNyBGZWJydWFyeSAyMDE1IDAyOjQxDQpUbzogSGVhdGxleSwgTmlj aw0KQ2M6IFJvc3MgQ2hhbmRsZXI7IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1t b2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24g VHVlLCBGZWIgMTcsIDIwMTUgYXQgMTA6NTcgQU0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bn b29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNClllcy4gTWFrZSBJ UHY2KiAoc2VlIGJlbG93KSBhIHJlcXVpcmVtZW50IGZvciBjYXJyaWVyLWJyYW5kZWQgZGV2aWNl cywgYW5kIGdpdmUgdGhlIE9FTXMgYSBjcmVkaWJsZSBzaWduYWwgdGhhdCBmcm9tIGRhdGUgWCBv bndhcmRzLCB5b3UgKndpbGwqIGZhaWwgVEEgb24gZXZlcnkgZGV2aWNlIHRoYXQgZG9lc24ndCBp bXBsZW1lbnQgSVB2NiwgYW5kIHlvdSAqd2lsbCBub3QqIHdhaXZlIHRoZSByZXF1aXJlbWVudC4g VGhhdCdzIHdoYXQgVmVyaXpvbiBhbmQgVC1Nb2JpbGUgZGlkLCBhbmQgaXQgd29ya2VkIGZvciB0 aGVtLg0KDQpBbHNvOiBpZiB5b3UgdGhpbmsgdGhhdCB0aGlzIHN0cmF0ZWd5IGlzIG5vdCBmZWFz aWJsZSBiZWNhdXNlIHlvdSBkbyBub3QgaGF2ZSBhbiBJUHY2IG5ldHdvcmsgeWV0LCB0aGVuIHll cywgdGhhdCdzIHRydWUgLSB5b3UgY2FuJ3QgbWFrZSBJUHY2IGEgZGV2aWNlIHJlcXVpcmVtZW50 IHVudGlsIHlvdSBoYXZlIGFuIElQdjYgbmV0d29yay4NCg0KQnV0IEkgdGhpbmsgdGhlIGtleSBw b2ludCBoZXJlIGlzIHRoYXQgYXBhcnQgZnJvbSB0aGUgbGFjayBvZiA0NjR4bGF0IG9uIGlPUywg dGhlIG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcyBhcmUgYSBsb3QgbW9yZSByZWFkeSBmb3IgSVB2 NiB0aGFuIHlvdSBtaWdodCB0aGluayB0aGV5IGFyZS4gT25jZSB0aGUgbmV0d29yayBpcyBjb21w bGV0ZSwgSSB0aGluayB0dXJuaW5nIG9uIElQdjYgaW4gdGhlIGRldmljZXMgZG9lcyB3b3JrLiBP cmFuZ2UgUG9sYW5kLCBUZWxlbm9yLCBhbmQgU0sgVGVsZWNvbSBzaG91bGQgYmUgYWJsZSB0byBj b25maXJtLg0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihz KS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBk byBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4NCg0KV2UgbWF5IG1vbml0b3Ig YWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVn aXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBh bmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlv dXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5 IGFmZmVjdCB5b3UuDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2Fs ZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmlj ZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9y ZHNoaXJlLCBBTDEwIDlCVw0KDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_A729C0B3952BEE45A1AA136ADD556BE80493F147OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1 bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4 dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0 IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmljay5o ZWF0bGV5QGVlLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPm5pY2su aGVhdGxleUBlZS5jby51azwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSBjYW4gc2VlIHdoeSB5b3UgYXJndWUgZm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Ig b2YgdjYgcmVxdWlyZW1lbnRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgeW91ciBzdGFuY2UgdGhh dCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg4oCcaGFybWZ1bGx5IHJlc3RyaWN0 aXZl4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBvdGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5n IHRoZSBkaWZmZXJlbmNlcyBhbmQgdHJ5aW5nIHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlcg0KIGJh ciB0aGF0IGhpZ2hsaWdodHMgY29uZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0 aXZlOyB3aGF0IHlvdSBjYWxsICZuYnNwO+KAnGhhcm1mdWxseSBicm9hZOKAnS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEknbSBzYXlpbmcgaXMgdGhhdCBpZiB5 b3VyIGdvYWwgaXMgSVB2NiBkZXBsb3ltZW50IGluIGEgcmVhc29uYWJsZSB0aW1lZnJhbWUsIHRo ZW4gdGhlIHJpZ2h0IHN0cmF0ZWd5IGlzJm5ic3A7Km5vdCogdG8gbWFrZSBhIGxpc3Qgb2YgYWxs IHRoZSBmZWF0dXJlcyB1bmRlciB0aGUgc3VuLCB3YWl0IHVudGlsIHRoZXkgaGF2ZSBhbGwgYmVl biBpbXBsZW1lbnRlZCwgYW5kIGRlcGxveSB0aGVtLiBBIGJldHRlciBzdHJhdGVneQ0KIGlzIHRv IHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQgYXJlIHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBs b3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFzIHRoZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJ UHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYgZmVhdHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVy IHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5IHdpbGwgZ2V0IGltcGxlbWVudGVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltEQl0gQ291bGQgeW91IGJlIG1vcmUgZXhwbGlj aXQgYW5kIGluZGljYXRlIHdoaWNoIGZlYXR1cmVzIGFyZSBub3QgdXNlZnVsIGluIHRoZSBkcmFm dCA/IEFzIHlvdSBjYW4gbWVudGlvbiBpdCwgYWxsIGZlYXR1cmVzIGFyZSBub3QgaW5kaWNhdGVk IGFzDQogbWFuZGF0b3J5IGluIHRoZSBkcmFmdCBzbyBJIGRvIG5vdCBjbGVhcmx5IHVuZGVyc3Rh bmQgaG93IHRoaXMgZG9jdW1lbnQgY29uZmxpY3RzIHdpdGggd2hhdCB5b3Ugc2F5IGNvbnNpZGVy aW5nIHRoYXQgdGhlIGdvYWwgZm9yIHRoZSBvcGVyYXRvciBpcyB0byBwcm92aWRlIGF0IGxlYXN0 IHRoZSBzYW1lIHNlcnZpY2UgYWNjZXNzIGZvciB1c2VycyB3aXRoIElQdjYgY29ubmVjdGl2aXR5 IHRoYW4gZm9yIHVzZXJzIHdpdGggSVB2NCBjb25uZWN0aXZpdHkNCiB3aGF0ZXZlciB0aGUgc3Ry YXRlZ3kgcmV0YWluZWQgYnkgdGhlIG9wZXJhdG9yLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0 IDg6MzEgUE0sIEhlYXRsZXksIE5pY2sgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrLmhlYXRsZXlA ZWUuY28udWsiIHRhcmdldD0iX2JsYW5rIj5uaWNrLmhlYXRsZXlAZWUuY28udWs8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgdGhlIGdhbWUgb2YgY2hpY2tlbiBhcHByb2FjaCwgSSBoYXZlIG5vIGRvdWJ0IGl0 IHdvcmtzLCBidXQgaXMgaXQgaW5jbHVzaXZlDQogdG8gYWxsIG1vYmlsZSBvcGVyYXRvcnM/PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Rm9yIG1lLCBpdCBoYXMgc29tZSBsaW1pdGF0aW9uczo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBv cGVyYXRvciBtdXN0IGhhdmUgdG9wIGRvd24gYmFja2luZyBmb3IgYSB0ZXJtaW5hbCBwb2xpY3kg b2Yg4oCcSVB2NiBvciB5b3UgYXJlIG91dOKAnSAobm93IHRoYXQgaXMgYSB3aWxkY2FyZCBjb25k aXRpb24gaW4gaXRzZWxmKTsgaXQgbWF5IGNvbXByb21pc2UgcmVsYXRpb25zaGlwcw0KIGluIGEg dmFsdWFibGUgZWNvc3lzdGVtPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVyZSB0aGUgb3BlcmF0b3IgaGFzIGhpZ2ggbWFq b3IgbWFya2V0IHBvd2VyIGhlbHBzLiBXaGVyZSBtYXJrZXRzIGhhdmUgYSBudW1iZXIgb2YgcGxh eWVycyByZWFkeSB0byBwbGF5IHRoZSBJUHY2IGdhbWUsIHRoZXJlIGlzIGFuIGFkdmFudGFnZS4g T3RoZXJ3aXNlIHRoZQ0KIG9wZXJhdG9yIGlzIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUgYW5kIGNv bnF1ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCB0ZW5kcyB0byBwbGF5IG91dCBhcyBhIHRoZSBzaW1w bGVzdCBzZXQgb2YgcmVxdWlyZW1lbnRzLiBXaGljaCBhbHNvIG1lYW5zIHNpbXBsZXN0IHNldCBv ZiBuZXR3b3JrIGNhcGFiaWxpdGllcy4gU29tZXRpbWVzIHRoZXNlIHNpbXBsZXN0IHNldCBvZg0K IG5ldHdvcmsgY2FwYWJpbGl0aWVzIGFyZSBhdCBvZGRzIHdpdGggdGhlIGJ1c2luZXNzIHByaW9y aXRpZXMgb2YgdGhlIG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6IEFQTiBzdHJhdGVneSwg dGV0aGVyaW5nIGFwcHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJzaWRpc2VkIGhhbmRzZXQg dnMg4oCcU0lNLW9ubHnigJ0pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KE5vdCBoYXZpbmcgYW4gSVB2NiBjYXBh YmxlIG5ldHdvcmsgaXMgYSBteXRoIHlvdSBhcmUgcHJvbW90aW5nIHRvIGRpc2NyZWRpdCBvcGVy YXRvcg0KIHZpZXdzLCBpdCBpcyBhIHJlZCBoZXJyaW5nIOKAkyBhbnkgb3BlcmF0b3Igc3BlY2lm eWluZyAqPGI+YW55PC9iPiogSVB2NiByZXF1aXJlbWVudHMgd2lsbCB2ZXJ5IHF1aWNrbHkgbmVl ZCB0aGlzIGNhcGFiaWxpdHkgdG8gdmFsaWRhdGUgdGVybWluYWxzIHdoYXRldmVyIHRoZSBwYXRo IHRoZXkgY2hvb3NlLik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbiBz ZWUgd2h5IHlvdSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZiB2NiByZXF1 aXJlbWVudHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2Fu IHdvcmsgYWNyb3NzIHRoZSBib2FyZCBpcyDigJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3RhbmRpbmcgdGhlIGRpZmZl cmVuY2VzIGFuZCB0cnlpbmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVyDQogYmFyIHRoYXQgaGln aGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNvbGxlY3RpdmU7IHdoYXQg eW91IGNhbGwgJm5ic3A74oCcaGFybWZ1bGx5IGJyb2Fk4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvDQogQ29saXR0aSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQGdv b2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE3IEZlYnJ1YXJ5IDIwMTUgMDI6NDE8 YnI+DQo8Yj5Ubzo8L2I+IEhlYXRsZXksIE5pY2s8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgQ2hhbmRs ZXI7IElQdjYgT3BzIFdHICg8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZv cHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1 b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gVHVlLCBGZWIgMTcsIDIw MTUgYXQgMTA6NTcgQU0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii Plllcy4gTWFrZSBJUHY2KiAoc2VlIGJlbG93KSBhIHJlcXVpcmVtZW50IGZvciBjYXJyaWVyLWJy YW5kZWQgZGV2aWNlcywgYW5kIGdpdmUgdGhlIE9FTXMgYSBjcmVkaWJsZSBzaWduYWwgdGhhdCBm cm9tIGRhdGUgWCBvbndhcmRzLCB5b3UgKndpbGwqIGZhaWwgVEEgb24gZXZlcnkNCiBkZXZpY2Ug dGhhdCBkb2Vzbid0IGltcGxlbWVudCBJUHY2LCBhbmQgeW91ICp3aWxsIG5vdCogd2FpdmUgdGhl IHJlcXVpcmVtZW50LiBUaGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBULU1vYmlsZSBkaWQsIGFuZCBp dCB3b3JrZWQgZm9yIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QWxzbzogaWYgeW91IHRoaW5r IHRoYXQgdGhpcyBzdHJhdGVneSBpcyBub3QgZmVhc2libGUgYmVjYXVzZSB5b3UgZG8gbm90IGhh dmUgYW4gSVB2NiBuZXR3b3JrIHlldCwgdGhlbiB5ZXMsIHRoYXQncyB0cnVlIC0geW91IGNhbid0 IG1ha2UgSVB2NiBhIGRldmljZSByZXF1aXJlbWVudA0KIHVudGlsIHlvdSBoYXZlIGFuIElQdjYg bmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj5CdXQgSSB0aGluayB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCBhcGFydCBmcm9tIHRo ZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0aGUgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zIGFy ZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2IHRoYW4geW91IG1pZ2h0IHRoaW5rDQogdGhleSBh cmUuIE9uY2UgdGhlIG5ldHdvcmsgaXMgY29tcGxldGUsIEkgdGhpbmsgdHVybmluZyBvbiBJUHY2 IGluIHRoZSBkZXZpY2VzIGRvZXMgd29yay4gT3JhbmdlIFBvbGFuZCwgVGVsZW5vciwgYW5kIFNL IFRlbGVjb20gc2hvdWxkIGJlIGFibGUgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5OT1RJQ0UgQU5EIERJU0NMQUlNRVI8YnI+DQpUaGlzIGUt bWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92 ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9z ZS4mbmJzcDsNCjxicj4NCiZuYnNwOzxicj4NCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBh bmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBo YXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRz IGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmls aXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkVFIExpbWl0ZWQ8 YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzPGJyPg0KQ29tcGFueSBSZWdpc3Rl cmVkIE51bWJlcjogMDIzODIxNjE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlk ZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlC VzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_A729C0B3952BEE45A1AA136ADD556BE80493F147OPEXCLILM23corp_-- From nobody Wed Feb 18 08:47:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30B1A8A78 for ; Wed, 18 Feb 2015 08:47:09 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJRvigKLT2rH for ; Wed, 18 Feb 2015 08:47:07 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212CB1A8A77 for ; Wed, 18 Feb 2015 08:47:07 -0800 (PST) Received: by labpv20 with SMTP id pv20so2347452lab.8 for ; Wed, 18 Feb 2015 08:47:05 -0800 (PST) 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=w1XHBhlWujWIkhfejn5q088E2gp16M/yHd1Z0EQWP+U=; b=xChhvNH77boRYkXGIekIiDZCi3FH0jx0SrkCvgPDQv5VgcGra7EB9wtcxi7wZ2bCj1 aS65EEpSBHjr+qmQSix8eC8jDCu3/+RULDZ2MmjblBp3ItV9UAXN5TGkhopDKo3LeccO zAUSftK8dtF/EkMcmkRlr9cachbQGtj8NmXJZb0eYkMrmjY1dQVaCuxDtmCEkhzC9MiC w10KnwuNp4jcDi+k+sH/7xEsqtGsGXO/hkcdIKL1UmJkk9LvmEUhxlDkmseM74SV3CMI ubgHY7GOWC+M+EQWIaZXaZ4QsqEqPXiANDKFXBEaLc8etL0D7o8cl+o/1Cjuz/h0wcDi wT9w== MIME-Version: 1.0 X-Received: by 10.112.141.228 with SMTP id rr4mr16471lbb.119.1424278025665; Wed, 18 Feb 2015 08:47:05 -0800 (PST) Received: by 10.25.212.73 with HTTP; Wed, 18 Feb 2015 08:47:05 -0800 (PST) In-Reply-To: <54E48C2E.2020703@gmail.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> Date: Wed, 18 Feb 2015 08:47:05 -0800 Message-ID: From: jouni korhonen To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a11c260cec8013e050f5f918a Archived-At: Cc: "v6ops@ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:47:09 -0000 --001a11c260cec8013e050f5f918a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hi, > > Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit : > >> Hi, >> >> Inline comments: >> >> Hi, >> >> Thank you for the report. It is good to see how good consideration >> is given to IPv6, and the two separated paths IPv4/IPv6. >> >> It is encouraging to see numerous smartphone manufacturers having >> embraced the CLAT technology. >> >> (tk) - this is not only CLAT, (CLAT is in generic Android thanks to >> Lorenzo, Cameron, Dan & others) each vendor has its own >> customization based on MCCMNC/region to control "features" per >> operator. In our case we have : dedicated clatd.conf (not generic >> one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) >> > > It's good to see these mentioned. > > For tethering - is the network offering DHCPv6 Prefix Delegation > service? Or is the device performing '64share' RFC7278? > > There are some advantages on doing the former rather than the latter. > > EIT bit =3D1, >> > > What is the EIT bit? > My wild guess is that it is the ESM information transfer flag bit in the ES= M information transfer flag information element. If it is, it does not really have anything to do with IPv6 IMHO. - Jouni > > Alex > > --001a11c260cec8013e050f5f918a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu &= lt;alexan= dru.petrescu@gmail.com> wrote:
Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit :
Hi,

Inline comments:

Hi,

Thank you for the report. It is good to see how good consideration
is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to
Lorenzo, Cameron, Dan & others) each vendor has its own
customization based on MCCMNC/region to control "features" per operator. In our case we have :=C2=A0 dedicated clatd.conf (not generic
one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?=C2=A0 Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

EIT bit =3D1,

What is the EIT bit?

My wild guess is t= hat it is the ESM information transfer flag bit i= n the ESM information transfer flag information element. If it is, it does not really have anything to do = with IPv6 IMHO.

- Jouni<= br>

=C2=A0

Alex


--001a11c260cec8013e050f5f918a-- From nobody Wed Feb 18 12:48:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA361A1A8B for ; Wed, 18 Feb 2015 12:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PxxxwN183gu for ; Wed, 18 Feb 2015 12:48:15 -0800 (PST) Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by ietfa.amsl.com (Postfix) with SMTP id 202CC1A1A54 for ; Wed, 18 Feb 2015 12:48:14 -0800 (PST) Received: (qmail 87184 messnum 13086391 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 18 Feb 2015 20:48:12 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail02.svc.cra.dublin.eircom.net (qp 87184) with SMTP; 18 Feb 2015 20:48:12 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id two91p0054BK5ly01woCRS; Wed, 18 Feb 2015 20:48:12 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_892E8AA3-0B6F-4C76-AEEF-E36BDB6D9A90" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: Date: Wed, 18 Feb 2015 20:48:08 +0000 Message-Id: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:48:17 -0000 --Apple-Mail=_892E8AA3-0B6F-4C76-AEEF-E36BDB6D9A90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Feb 2015, at 16:47, jouni korhonen = wrote: >=20 >=20 >=20 > On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu = > = wrote: > Hi, >=20 > Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit : > Hi, >=20 > Inline comments: >=20 > Hi, >=20 > Thank you for the report. It is good to see how good consideration > is given to IPv6, and the two separated paths IPv4/IPv6. >=20 > It is encouraging to see numerous smartphone manufacturers having > embraced the CLAT technology. >=20 > (tk) - this is not only CLAT, (CLAT is in generic Android thanks to > Lorenzo, Cameron, Dan & others) each vendor has its own > customization based on MCCMNC/region to control "features" per > operator. In our case we have : dedicated clatd.conf (not generic > one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) >=20 > It's good to see these mentioned. >=20 > For tethering - is the network offering DHCPv6 Prefix Delegation > service? Or is the device performing '64share' RFC7278? >=20 > There are some advantages on doing the former rather than the latter. >=20 > EIT bit =3D1, >=20 > What is the EIT bit? >=20 > My wild guess is that it is the ESM information transfer flag bit in = the ESM information transfer flag information element. If it is, it does = not really have anything to do with IPv6 IMHO. >=20 > - Jouni As far as I can tell from a previous answer on v6ops by Orange PL the = EIT bit (think it is ESM info transfer flag IE) has an effect when the = HSS has a default APN different from the one requested by the UE. = Without the EIT bit set the network doesn=E2=80=99t let the UE requested = APN override the default from the HSS, so two PDN connections are set = up, one with IPv4 (assuming the default is an IPv4 only APN) and the = other IPv6 (assuming that was requested by the UE). So strictly = speaking it does look independent of IP version but it is being noticed = as operators introduce IPv6. Ross --Apple-Mail=_892E8AA3-0B6F-4C76-AEEF-E36BDB6D9A90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 18 Feb 2015, at 16:47, jouni korhonen <jouni.nospam@gmail.com> wrote:



On Wed, Feb 18, 2015 at 4:57 AM, Alexandru = Petrescu <alexandru.petrescu@gmail.com> wrote:
Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit :
Hi,

Inline comments:

Hi,

Thank you for the report. It is good to see how good consideration
is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to
Lorenzo, Cameron, Dan & others) each vendor has its own
= customization based on MCCMNC/region to control "features" per
operator. In our case we have :  dedicated clatd.conf (not = generic
one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?  Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

EIT bit =3D1,

What is the EIT bit?

My wild guess is that it is the ESM information = transfer flag bit in the ESM information = transfer flag information element. If it is, it does not really have anything to = do with IPv6 IMHO.

- = Jouni

As far as I can tell from a previous answer on = v6ops by Orange PL the EIT bit (think it is ESM info transfer flag IE) = has an effect when the HSS has a default APN different from the one = requested by the UE.  Without the EIT bit set the network doesn=E2=80= =99t let the UE requested APN override the default from the HSS, so two = PDN connections are set up, one with IPv4 (assuming the default is an = IPv4 only APN) and the other IPv6 (assuming that was requested by the = UE).  So strictly speaking it does look independent of IP version = but it is being noticed as operators introduce IPv6.

Ross

= --Apple-Mail=_892E8AA3-0B6F-4C76-AEEF-E36BDB6D9A90-- From nobody Wed Feb 18 12:57:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84731A1A52; Wed, 18 Feb 2015 12:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaTKNrb99k_r; Wed, 18 Feb 2015 12:57:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BA1A1AE6; Wed, 18 Feb 2015 12:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 12:57:28 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:57:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-04.txt Pages : 17 Date : 2015-02-18 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 18 13:24:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA871A1AEC for ; Wed, 18 Feb 2015 13:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijW6_yG5M-oB for ; Wed, 18 Feb 2015 13:24:15 -0800 (PST) Received: from mail-08.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA811A001A for ; Wed, 18 Feb 2015 13:24:15 -0800 (PST) Received: from [24.114.101.26] (helo=[172.20.10.4]) by mail-08.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YOC6Q-0000XT-D8; Wed, 18 Feb 2015 16:24:14 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 16:23:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> References: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.101.26] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 21:24:17 -0000 Hi Everyone: Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 A few highlights: * The wording in the title, abstract and introduction has been modified = to narrow the scope of the document. The document no longer claims to = cover all choices around designing IPv6 network, but just certain = choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. * The text around using BGP sessions to link-local addresses has been = updated after some email exchanges with Francis Dupont (co-author of RFC = 2545), who observed that RFC 2545 forbids this (even though most vendors = support it). * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. * The initial few sentences in a number of sections has been changed in = an attempt to improve the document flow. * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. There were many other small changes to try to improve document wording = and clarity, and I thank a number of my colleagues at Alcatel-Lucent for = their helpful reviews. Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. - Philip On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-04.txt > Pages : 17 > Date : 2015-02-18 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Feb 18 14:51:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96D31A1B77 for ; Wed, 18 Feb 2015 14:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB5RWqZsTqeL for ; Wed, 18 Feb 2015 14:51:04 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D861A1B12 for ; Wed, 18 Feb 2015 14:51:04 -0800 (PST) Received: by padbj1 with SMTP id bj1so4651452pad.5 for ; Wed, 18 Feb 2015 14:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Sd+31FLX6A5KFAquOmj2FusgwFAmP48vTSXyexRlQDQ=; b=M0eAxdO9ROY6SGLz7wrn+tvOcZdSBYMc0GFDB9LHBjpy+XzngLa8yGa/TiebGzRd/e wGha3qsC6v8F7Hs/HbKrB/qDEiVXJXEeL0zKYyU6e7sRPkDUK3tgX+8HOmd4WPQIT/ba 0shjv7Y1wDcCLZiKfsE05m+egYQWqigycCfjitPoxcBQ8R5zgLBIoEeAdSHkleCJxy8D Kuk1NBaA/u/IexQsDOp8aVxwlxhJw7UnfUFuT8KsOfq4npPZzjYpubsv3Sr8my/LNB7c B+elgJ/kN9YoOe/re3NV22qsUkpaU9KqqaU/Rzz/3sdxHwMJM6nGmLVFeNcnWXJt1oZN kLOw== X-Received: by 10.68.132.229 with SMTP id ox5mr2703537pbb.94.1424299864106; Wed, 18 Feb 2015 14:51:04 -0800 (PST) Received: from ?IPv6:2406:e007:5091:1:28cc:dc4c:9703:6781? ([2406:e007:5091:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id gj9sm21649047pbc.32.2015.02.18.14.51.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 14:51:02 -0800 (PST) Message-ID: <54E5176B.7000404@gmail.com> Date: Thu, 19 Feb 2015 11:51:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> In-Reply-To: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:51:05 -0000 > It is very difficult to impossible to ping a link-local address > from a device that is not on the same subnet. This is a > troubleshooting disadvantage, though it can also be viewed as a > security advantage. I am puzzled by how it could ever be possible at all. Link-local addresses are by definition meaningless off the link in question, and they should never even be known by any node on another link. (And of course it gets even more complicated on devices with several interfaces, such as routers, since a link local address is only meaningful with a ZoneID, and that is a node-specific value, meaningless to other nodes on the *same* link.) Brian From nobody Wed Feb 18 16:24:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDE91A1B93 for ; Wed, 18 Feb 2015 16:24:44 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VuVbNy4k4Bp for ; Wed, 18 Feb 2015 16:24:43 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DA61A1B91 for ; Wed, 18 Feb 2015 16:24:43 -0800 (PST) Received: by pablf10 with SMTP id lf10so5105645pab.12 for ; Wed, 18 Feb 2015 16:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J3SwRDM9Gg7hPSCqf2juS2vf1d3TVWc9/3bg6FfwNXs=; b=SkzzXgFlkPX6k5xWnCJUm58wCVwelSOBbinYVNDRuff6ul08HCiscyc/dHjagB7Qy/ cqRwplISSiI2Rv72RKzIi7lvUsZXBeEv/YCWZv5+eucEz80tiiJUtbElEJdDolUJKaEA niOmUY9Rw9Ebk1qf+DcuQXkoEGww/otmV+nE+206G9SFtt0WVHvR+sIvrGbWSPBeZ2fu lp/1pgU5eYLd9YR1cK8k/faWR5xiNGXRQ1Z2S8L3KMVeybbJOnOa3DgM90TH/2+Y34c1 K/nYWkJRhaO9X2Wl3saR9f/L52WN7UNoLSj14hIARa4QV8LyDCr0I13Tm7P2n1zRVDbO Cjqw== X-Received: by 10.66.66.230 with SMTP id i6mr3100950pat.108.1424305482988; Wed, 18 Feb 2015 16:24:42 -0800 (PST) Received: from ?IPv6:2406:e007:5091:1:28cc:dc4c:9703:6781? ([2406:e007:5091:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ca2sm21710081pbc.68.2015.02.18.16.24.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 16:24:41 -0800 (PST) Message-ID: <54E52D5E.9000105@gmail.com> Date: Thu, 19 Feb 2015 13:25:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexandru Petrescu , Kossut Tomasz - Hurt , BOUCADAIR Mohamed IMT/OLN , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C14.1000102@gmail.com> In-Reply-To: <54E48C14.1000102@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - Download Booster X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 00:24:45 -0000 On 19/02/2015 01:56, Alexandru Petrescu wrote: >> moreover together with Samsung we developed "IPv6 patch" for Download >> Booster (Samsung feature to aggregate your LTE+WIFI connection for >> http download - > > This is a very useful feature. I wonder whether the augmented bandwidth > concerns a single http connection, or several? (there is a difference > between single connection enjoying its bandwidth augmented when an > interface is added, and pipelined http connections not disturbing each > other when several interfaces are added). > > I am asking because two reasons. One is that I have seen demos where > bandwidth is not really augmented, yet pipelined http apps give a better > feeling when multiple interfaces are used. I know nothing about HTTP/2 beyond blog posts and the FAQ, but if they have done what they say, HTTP/2 will make all this irrelevant. Brian > > The other reason is that at IETF there are some activities about > bandwidth augmentation which may be interested in Download Booster. > > In the MIF Working Group there is a bandwidth augmentation activity in > relationship to the BroadBand Forum: add a cellular interface to a DSL > box hoping to add bandwidth, and improve fail-over. > > In the Mobile IPv4 Working Group there is a > draft-ietf-mip4-multiple-tunnel-support which may try to achieve the > same, and an RFC for samein IPv6. > >> now it works in Ipv6 networks with no DNS64 like Orange Poland ) > > It is encouraging :-) > >> Is the network considering Machine-class devices (M2M)? For example >> Sierra Wireless Airprime? Not really - we are working with one of the >> vendor to deliver IPv6 (CLAT) router expected in H1/15 >> >> More than the typical smartphone users (yes, it represents already a >> large market) is the LTE network considering connections from more >> dedicated settings like: connected public transportation, home >> electricity counters, electric vehicle charging stations, harbour >> installations, connected roads? >> >> Yes, we are technically ready to create "IPv6 matrix" >> >> These dedicated settings look up to wireless LTE access networks as >> good hope to get on the Internet, especially in areas where land >> lines are too expensive to deploy. >> >>> LTE450 -in Brasil, LTE800 - Europe > > Ok, it is good to know. For the moment we consider LTE2600 which is > also useful in remote areas, until LTE800 comes alive. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Feb 18 17:04:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD971A1DBE for ; Wed, 18 Feb 2015 17:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp8CN3ZXV9zy for ; Wed, 18 Feb 2015 17:04:05 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BC21A1C05 for ; Wed, 18 Feb 2015 17:04:05 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so55804369iga.1 for ; Wed, 18 Feb 2015 17:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0yORFv8hx+LJxvtilutVG01ddT+pIwgQgBN5kScxrHM=; b=nAzM1r7FFqIAibKIXZAxlWC4fWONlS01oUtrBS2Gv4wtBaaBZet1ncuzBr+OynMGfm 1U4YVBZpE1Ef/w9ddh+ic1Sc9j0fkh93cDh9HvlYL0L5FXZs47OtpgufTarqwVqLJlle hQPi5kBP8jBjRu/yNy+FLPHuFLBvv6YKEBu3uZXXZdIRxl2buyPuElsRG0hBZqG93JzE nVypIbWpKX5iYjiGHYWQL/wbpaA5kEzV7X4dJfI7zNh5RP2NoVLg12EYnrKTg99cZ0nL 3ZlcVaymx6WXJpUfW8UjxuHg0nRG0EKHdjoThbBiZA+3DK94V69z2cmF8MZeFsKHDAro mR4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0yORFv8hx+LJxvtilutVG01ddT+pIwgQgBN5kScxrHM=; b=kLzJGDatZ/VpMiCsuBo2epGxbukMVRlOyflLVhRTBCAoepCwR8choC23fMp4V/GlR7 bZPEkIosUsV+ISx9GFIZJkho6kC/XxagLXLsXojMhGB0UPPI9LThXRo0sp02IBDX2fLr xhv9tXG6Kypj+pTTfz0WFQgFUInqugvROPbvj9aOE2NsWzgx8R2axQv0Rp4XBo71NrSZ L008LJIpfC7BkZkwv5vrShrfBKgzbanXHUr/3pH6nnKrme3x5SRX3/iYWn7IcQb9hJNS bQOMe/WdSbEElfHnZYE51qCi94tpS+08m4DCxNSdXlR/KdqnvJic8YJrO6MZXPCeQILp FFPg== X-Gm-Message-State: ALoCoQnaOTm3K/c6UdA+OgTnPvb2iD+rnFFMxSStEy9DTqtyc4VQ/7etMILGjDewfpbRo1hbG2PC X-Received: by 10.50.78.232 with SMTP id e8mr3972854igx.5.1424307844553; Wed, 18 Feb 2015 17:04:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Wed, 18 Feb 2015 17:03:44 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 10:03:44 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e013c6a20204a38050f6683c0 Archived-At: Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 01:04:08 -0000 --089e013c6a20204a38050f6683c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 4, 2015 at 4:17 AM, Fred Baker (fred) wrote: > Before I bother the IESG with it a third time, I=E2=80=99d really like to= hear a > clear consensus, not a rough one. Where it stands right now, that=E2=80= =99s not at > all obvious. > So did we have clear consensus? The WLGC was supposed to go until February 15. --089e013c6a20204a38050f6683c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 4, 2015 at 4:17 AM, Fred Baker (fred) <fred@cisco.com> = wrote:
Before I bother the IESG with it a= third time, I=E2=80=99d really like to hear a clear consensus, not a rough= one. Where it stands right now, that=E2=80=99s not at all obvious.

So did we have clear consensus? The WLGC was s= upposed to go until February 15.
--089e013c6a20204a38050f6683c0-- From nobody Wed Feb 18 22:20:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC311A8859; Wed, 18 Feb 2015 22:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d76tPVhq_WCA; Wed, 18 Feb 2015 22:20:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8631A885C; Wed, 18 Feb 2015 22:20:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219062001.13891.86128.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 22:20:01 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-18.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 06:20:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Dave Michaud Diego R. Lopez Filename : draft-ietf-v6ops-mobile-device-profile-18.txt Pages : 19 Date : 2015-02-18 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network) with a special focus on IPv4 service continuity features. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 18 22:33:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C311A1F70 for ; Wed, 18 Feb 2015 22:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_TQSWAteUAN for ; Wed, 18 Feb 2015 22:33:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E521E1A1F02 for ; Wed, 18 Feb 2015 22:33:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 5762C2641AD for ; Thu, 19 Feb 2015 07:33:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3D5AF238140 for ; Thu, 19 Feb 2015 07:33:48 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 07:33:44 +0100 From: To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-18.txt Thread-Index: AQHQTAwiJeDVZ00SLUe2F5lna1aTg5z3gDtw Date: Thu, 19 Feb 2015 06:33:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490E09A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150219062001.13891.86128.idtracker@ietfa.amsl.com> In-Reply-To: <20150219062001.13891.86128.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-18.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 06:33:52 -0000 Dear all, This version tries to address comments raised during the WGLC (in addition = to those already implemented in -16 and -17): * Remove two sections for a more acceptable scope: Section 2.1 on WLAN and = Section 5 (application). We tried to find a balanced approach between the "= harmfully broad" and "harmfully restricted" positions. * Add text about missing features in the RFC7066 and the IPv6 node requirem= ents. * Add a definition of the IPv4 service continuity as requested by Alex. * Add text to clarify the support of the profile does not mean that all ite= ms MUST be supported. * Add text to precise that items are listed in a priority order. * Enhance the CLAT text * Update the text about "cellular CPE" to clarify several of the points dis= cussed in the thread with James.=20 * Welcome two co-authors. In order to track changes since the call is initiated, here is a an URL for= your convenience: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-mobi= le-device-profile-15&difftype=3D--html&submit=3DGo!&url2=3Ddraft-ietf-v6ops= -mobile-device-profile-18=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 19 f=E9vrier 2015 07:20 > =C0=A0: i-d-announce@ietf.org > Cc=A0: v6ops@ietf.org > Objet=A0: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-18.t= xt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : An Internet Protocol Version 6 (IPv6) Profile > for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Gang Chen > Nick Heatley > Ross Chandler > Dave Michaud > Diego R. Lopez > Filename : draft-ietf-v6ops-mobile-device-profile-18.txt > Pages : 19 > Date : 2015-02-18 >=20 > Abstract: > This document defines a profile that is a superset of that of the > connection to IPv6 cellular networks defined in the IPv6 for Third > Generation Partnership Project (3GPP) Cellular Hosts document. This > document defines an IPv6 profile that a number of operators recommend > in order to connect 3GPP mobile devices to an IPv6-only or dual-stack > wireless network (including 3GPP cellular network) with a special > focus on IPv4 service continuity features. >=20 > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-18 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile= -18 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 19 01:14:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA141A8966 for ; Thu, 19 Feb 2015 01:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhsig8WH0zgn for ; Thu, 19 Feb 2015 01:14:27 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2231A894C for ; Thu, 19 Feb 2015 01:14:26 -0800 (PST) Received: from [85.158.136.3] by server-2.bemta-5.messagelabs.com id B2/06-03511-079A5E45; Thu, 19 Feb 2015 09:14:24 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-12.tower-123.messagelabs.com!1424337263!35601507!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11286 invoked from network); 19 Feb 2015 09:14:23 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-12.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Feb 2015 09:14:23 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Thu, 19 Feb 2015 09:14:18 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Thu, 19 Feb 2015 09:14:22 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 09:14:22 +0000 From: "Heatley, Nick" To: "mohamed.boucadair@orange.com" , Ca By Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAFtSIAABXhFiAAAXD/SAAI6wAAAABhtuAABDDgdAAK3XWgAADyfKQAAFAAlAACx3dAAABVPAAACQXRJA= Date: Thu, 19 Feb 2015 09:14:21 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E097FBUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 09:14:33 -0000 --_000_6536E263028723489CCD5B6821D4B21303E097FBUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgb2JzZXJ2YXRpb24gaXMgYXJvdW5kIGFjY291bnRhYmlsaXR5IHZzIHJlc3BvbnNpYmlsaXR5 ICh0aGUgUkFDSSBtYXRyaXgpLg0KDQpUaGUgaXNzdWUgd2Ugc2VlbSB0byBoYXZlIGlzIHRoYXQg dGhlIElFVEYgZXhwZXJ0aXNlIGlzIG5lZWRlZCwgc28gd2UgbmVlZCB0aGUgSUVURiBjb21tdW5p dHkgdG8gZWZmZWN0aXZlbHkgYmUgdGhlIHJlc3BvbnNpYmxlIGFnZW5jeSBmb3IgdGhlIHRlY2hu aWNhbCBjb250ZW50Lg0KTm9ybWFsbHkgU0RPcyBhcmUgYm90aCBhY2NvdW50YWJsZSBhbmQgcmVz cG9uc2libGUuDQpBY2NvdW50YWJpbGl0eSwgd2VsbCwgY2xlYXJseSBzb21lIGZpbmQgaXQgdW5l YXN5IHRoYXQgSUVURiB3b3VsZCBoYXZlIGFjY291bnRhYmlsaXR5IGZvciB0aGUgZG9jdW1lbnQu DQoNCklmIGFub3RoZXIgYm9keSBjb3VsZCBiZSBhY2NvdW50YWJsZSBmb3IgdGhlIGRvY3VtZW50 LCB0aGF0IGl0IHJlcHJlc2VudHMgdGhlIHZpZXdzIG9mIGEgc3VpdGFibGUgY29sbGVjdGl2ZSAo bW9iaWxlIG9wZXJhdG9ycyksIGJ1dCB0aGUgdGVjaG5pY2FsIGNvbnRlbnQgd2FzIGZpbHRlcmVk IHZpYSBJRVRGLCB0aGF0IHdvdWxkIGJlIGlkZWFsLCBubz8NCkkgaGF2ZSBubyBpZGVhIGhvdyB0 byBlbmdpbmVlciBzdWNoIGFuIG91dGNvbWUsIGJ1dCBpZiBpdCBjb3VsZCBiZSBkb25lIHRoZW4g dGhpcyB3b3JrIHNob3VsZCBub3QgYmUgd2FzdGVkIOKAkyBjb3VsZCBiZSBhIOKAnEdTTUEgc3Bv bnNvcmVkIFJGQ+KAnT8NCg0KVGhpcyBwcm9ibGVtIG9mIGV4cGVydGlzZSBpcyBub3QgZ29pbmcg YXdheSBzbyBJIHNoYXJlIE1lZHMgY29uY2VybnMuDQoNCihCYXJiYXJh4oCZcyBjb21tZW50IG9u IGEgZ3JvdXAgUkZQLCBhYnNvbHV0ZWx5IG5vdCB3b3JrYWJsZSBkdWUgdG8gYWxsIHRoZSBOREFz IHRoYXQgcmVzaWRlIGFyb3VuZCB0ZXJtaW5hbHMuKQ0KDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NClNlbnQ6 IDE4IEZlYnJ1YXJ5IDIwMTUgMTU6NDYNClRvOiBDYSBCeQ0KQ2M6IEhlYXRsZXksIE5pY2s7IElQ djYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZykNClN1YmplY3Q6IFJFOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9h ZCI/DQoNCkhpIENhbWVyb24sDQoNCkl0IGlzIHdhc3RlZnVsIHRvIGluaXRpYXRlIHRoaXMgd29y ayBpbiBhbm90aGVyIGZvcnVtIHdoaWxlIGJvdGggdGhlIElQdjYgZXhwZXJ0aXNlIGFuZCB0aGUg a25vd2xlZGdlIG9mIG1vYmlsZSBuZXR3b3JrcyBpcyBhdmFpbGFibGUgYXQgdGhlIElFVEYuDQoN CkZXSVcsIHRoZSBJRVRGIHByb2R1Y2VkIHByb2ZpbGUgZG9jdW1lbnRzIChyZWFkIENQRSByZXF1 aXJlbWVudHMgUkZDcykgd2hpbGUgb25lIGNhbiB0aGluayBCQkYgY2FuIGJlIGEgbGVnaXRpbWF0 ZSBmb3J1bSB0byBwcm9kdWNlIHN1Y2ggZG9jdW1lbnRzLiBUaGlzIGRvY3VtZW50IGlzIG5vdCBh biBleGNlcHRpb24uDQoNCknigJltIHN1cmUgd2Ugd2lsbCBjb21lIHVwIHRvIGEgYmFsYW5jZWQg YXBwcm9hY2ggdG8gc2F0aXNmeSB0aGUgY29tbWVudHMgcmVjZWl2ZWQgc28gZmFyLg0KDQpDaGVl cnMsDQpNZWQNCg0KRGUgOiBDYSBCeSBbbWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNvbV0NCkVudm95 w6kgOiBtZXJjcmVkaSAxOCBmw6l2cmllciAyMDE1IDE2OjA4DQrDgCA6IEJPVUNBREFJUiBNb2hh bWVkIElNVC9PTE4NCkNjIDogSGVhdGxleSwgTmljazsgSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4pDQpPYmpldCA6IFJlOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9h ZCI/DQoNCkF1dGhvcnMsDQoNCkkga25vdyB5b3Ugc2FpZCB0aGUgM2dwcCBpcyBub3QgaW50ZXJl c3RlZCBpbiB0aGlzIHdvcmssIHdoYXQgYWJvdXQgR1NNQSA/ICBUaGV5IHdyaXRlIHByb2ZpbGVz IGZvciBtb2JpbGUgbmV0d29ya3MgLCByaWdodD8NCg0KQ0INCg0KT24gV2VkbmVzZGF5LCBGZWJy dWFyeSAxOCwgMjAxNSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIE5pY2ssDQoNCkkgZnVsbHkgYWdy ZWUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2b3BzLWJvdW5jZXNAaWV0Zi5v cmcnKTs+XSBEZSBsYSBwYXJ0IGRlIEhlYXRsZXksIE5pY2sNCkVudm95w6kgOiBtZXJjcmVkaSAx OCBmw6l2cmllciAyMDE1IDEwOjM1DQrDgCA6IExvcmVuem8gQ29saXR0aQ0KQ2MgOiBJUHY2IE9w cyBXRyAodjZvcHNAaWV0Zi5vcmc8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd2Nm9wc0Bp ZXRmLm9yZycpOz4pDQpPYmpldCA6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxl LWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNClllcywgSSBh Z3JlZSB3aXRoIHlvdSwgdGhhdCBpcyBhIHNlbnNpYmxlIGFwcHJvYWNoLg0KV29ya2luZyB3aXRo IGVhY2ggdmVuZG9yIGluIHR1cm4uDQooWW91IGtub3cgZWFjaCB2ZW5kb3Igd2hvIGNsYWltcyBJ UHY2IHJlYWRpbmVzcyBmb3IgdGhlaXIgdGVybWluYWwsIHdpbGwgbmV2ZXIgc2F5IHdoZXRoZXIg dGhlIGRldmljZSB3aWxsIHdvcmsgb24gdGhlIG9wZXJhdG9ycyBJUHY2IG5ldHdvcmsuDQpTbyBp dCBuZWVkcyB0byBiZSBjb2xsYWJvcmF0aXZlLikNCg0KU28gYWxsIHRoaXMgZG9jdW1lbnQgaXMg ZG9pbmcgaXMgc2V0dGluZyBhIGNvbGxlY3RpdmUgcm9hZG1hcCwgcmF0aGVyIHRoYW4gZXhwZWN0 IHZlbmRvcnMgdG8gZG8gdGhlaXIgb3duIHRoaW5nLiBHaXZlbiB3ZSBhZ3JlZSBvbiB0aGUgYWJv dmUsIHRoaXMgaXMgbm90IGhhcm1mdWwuDQoNCkkgdGhpbmsgdGhlIHJlYWwgZGlzYWdyZWVtZW50 IGNvbWVzIGZyb20geW91ciBvcGluaW9uIHRoYXQgdGhpcyBpcyBub3QgSUVURi4NCihCeSB0aGUg d2F5LCBtb2JpbGUgb3BlcmF0b3JzIGhhdmUgaGFkIGRpc2N1c3Npb25zIHdpdGggdGhlIHNpc3Rl ciBvcmcgb2YgdGhlIEludGVybmV0IFNvY2lldHkgYWJvdXQgd2hhdCB3b3VsZCBoZWxwIG1vYmls ZSBvcGVyYXRvcnMgaW50cm9kdWNlIElQdjYuDQpPbmUgb2YgdGhlIG1ham9yIG1ham9yIHRoZW1l cyBoYXMgYmVlbiB0ZXJtaW5hbHMuKQ0KDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9A Z29vZ2xlLmNvbScpOz5dDQpTZW50OiAxOCBGZWJydWFyeSAyMDE1IDA3OjI2DQpUbzogSGVhdGxl eSwgTmljaw0KQ2M6IFJvc3MgQ2hhbmRsZXI7IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZzxq YXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2b3BzQGlldGYub3JnJyk7PikNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCk9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDg6MzEg UE0sIEhlYXRsZXksIE5pY2sgPG5pY2suaGVhdGxleUBlZS5jby51azxqYXZhc2NyaXB0Ol9lKCU3 QiU3RCwnY3ZtbCcsJ25pY2suaGVhdGxleUBlZS5jby51aycpOz4+IHdyb3RlOg0KSSBjYW4gc2Vl IHdoeSB5b3UgYXJndWUgZm9yIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgdjYgcmVxdWly ZW1lbnRzLg0KSSB0aGluayB5b3VyIHN0YW5jZSB0aGF0IHRoaXMgY2FuIHdvcmsgYWNyb3NzIHRo ZSBib2FyZCBpcyDigJxoYXJtZnVsbHkgcmVzdHJpY3RpdmXigJ0uDQpUaGUgb3RoZXIgYXBwcm9h Y2ggaXMgdW5kZXJzdGFuZGluZyB0aGUgZGlmZmVyZW5jZXMgYW5kIHRyeWluZyB0byBzZXQgYSBz bGlnaHRseSBoaWdoZXIgYmFyIHRoYXQgaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVu dHMgb2YgdGhlIGNvbGxlY3RpdmU7IHdoYXQgeW91IGNhbGwgIOKAnGhhcm1mdWxseSBicm9hZOKA nS4NCg0KV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgaWYgeW91ciBnb2FsIGlzIElQdjYgZGVwbG95 bWVudCBpbiBhIHJlYXNvbmFibGUgdGltZWZyYW1lLCB0aGVuIHRoZSByaWdodCBzdHJhdGVneSBp cyAqbm90KiB0byBtYWtlIGEgbGlzdCBvZiBhbGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4s IHdhaXQgdW50aWwgdGhleSBoYXZlIGFsbCBiZWVuIGltcGxlbWVudGVkLCBhbmQgZGVwbG95IHRo ZW0uIEEgYmV0dGVyIHN0cmF0ZWd5IGlzIHRvIHN0YXJ0IGZyb20gdGhlIGZlYXR1cmVzIHRoYXQg YXJlIHJlcXVpcmVkLCB0ZXN0IGFuZCBkZXBsb3kgdGhvc2UsIGFuZCB0aGVuIGl0ZXJhdGUuIEFz IHRoZSBpbmR1c3RyeSBldm9sdmVzIGFuZCBJUHY2IGJlY29tZXMgbW9yZSBjb21tb24sIElQdjYg ZmVhdHVyZXMgd2lsbCBiZWNvbWUgaGlnaGVyIHByaW9yaXR5IGZvciB2ZW5kb3JzIGFuZCB0aGV5 IHdpbGwgZ2V0IGltcGxlbWVudGVkLg0KDQpPbiBUdWUsIEZlYiAxNywgMjAxNSBhdCA4OjMxIFBN LCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8amF2YXNjcmlwdDpfZSglN0Il N0QsJ2N2bWwnLCduaWNrLmhlYXRsZXlAZWUuY28udWsnKTs+PiB3cm90ZToNClRoaXMgaXMgdGhl IGdhbWUgb2YgY2hpY2tlbiBhcHByb2FjaCwgSSBoYXZlIG5vIGRvdWJ0IGl0IHdvcmtzLCBidXQg aXMgaXQgaW5jbHVzaXZlIHRvIGFsbCBtb2JpbGUgb3BlcmF0b3JzPw0KRm9yIG1lLCBpdCBoYXMg c29tZSBsaW1pdGF0aW9uczoNCg0KLSAgICAgICAgICBUaGUgb3BlcmF0b3IgbXVzdCBoYXZlIHRv cCBkb3duIGJhY2tpbmcgZm9yIGEgdGVybWluYWwgcG9saWN5IG9mIOKAnElQdjYgb3IgeW91IGFy ZSBvdXTigJ0gKG5vdyB0aGF0IGlzIGEgd2lsZGNhcmQgY29uZGl0aW9uIGluIGl0c2VsZik7IGl0 IG1heSBjb21wcm9taXNlIHJlbGF0aW9uc2hpcHMgaW4gYSB2YWx1YWJsZSBlY29zeXN0ZW0NCg0K LSAgICAgICAgICBXaGVyZSB0aGUgb3BlcmF0b3IgaGFzIGhpZ2ggbWFqb3IgbWFya2V0IHBvd2Vy IGhlbHBzLiBXaGVyZSBtYXJrZXRzIGhhdmUgYSBudW1iZXIgb2YgcGxheWVycyByZWFkeSB0byBw bGF5IHRoZSBJUHY2IGdhbWUsIHRoZXJlIGlzIGFuIGFkdmFudGFnZS4gT3RoZXJ3aXNlIHRoZSBv cGVyYXRvciBpcyB2ZXJ5IGV4cG9zZWQgdG8gZGl2aWRlIGFuZCBjb25xdWVyDQoNCi0gICAgICAg ICAgQ3VycmVudGx5IGl0IHRlbmRzIHRvIHBsYXkgb3V0IGFzIGEgdGhlIHNpbXBsZXN0IHNldCBv ZiByZXF1aXJlbWVudHMuIFdoaWNoIGFsc28gbWVhbnMgc2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsg Y2FwYWJpbGl0aWVzLiBTb21ldGltZXMgdGhlc2Ugc2ltcGxlc3Qgc2V0IG9mIG5ldHdvcmsgY2Fw YWJpbGl0aWVzIGFyZSBhdCBvZGRzIHdpdGggdGhlIGJ1c2luZXNzIHByaW9yaXRpZXMgb2YgdGhl IG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6IEFQTiBzdHJhdGVneSwgdGV0aGVyaW5nIGFw cHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJzaWRpc2VkIGhhbmRzZXQgdnMg4oCcU0lNLW9u bHnigJ0pDQooTm90IGhhdmluZyBhbiBJUHY2IGNhcGFibGUgbmV0d29yayBpcyBhIG15dGggeW91 IGFyZSBwcm9tb3RpbmcgdG8gZGlzY3JlZGl0IG9wZXJhdG9yIHZpZXdzLCBpdCBpcyBhIHJlZCBo ZXJyaW5nIOKAkyBhbnkgb3BlcmF0b3Igc3BlY2lmeWluZyAqYW55KiBJUHY2IHJlcXVpcmVtZW50 cyB3aWxsIHZlcnkgcXVpY2tseSBuZWVkIHRoaXMgY2FwYWJpbGl0eSB0byB2YWxpZGF0ZSB0ZXJt aW5hbHMgd2hhdGV2ZXIgdGhlIHBhdGggdGhleSBjaG9vc2UuKQ0KDQpJIGNhbiBzZWUgd2h5IHlv dSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBvZiB2NiByZXF1aXJlbWVudHMu DQpJIHRoaW5rIHlvdXIgc3RhbmNlIHRoYXQgdGhpcyBjYW4gd29yayBhY3Jvc3MgdGhlIGJvYXJk IGlzIOKAnGhhcm1mdWxseSByZXN0cmljdGl2ZeKAnS4NClRoZSBvdGhlciBhcHByb2FjaCBpcyB1 bmRlcnN0YW5kaW5nIHRoZSBkaWZmZXJlbmNlcyBhbmQgdHJ5aW5nIHRvIHNldCBhIHNsaWdodGx5 IGhpZ2hlciBiYXIgdGhhdCBoaWdobGlnaHRzIGNvbmRpdGlvbmFsIHJlcXVpcmVtZW50cyBvZiB0 aGUgY29sbGVjdGl2ZTsgd2hhdCB5b3UgY2FsbCAg4oCcaGFybWZ1bGx5IGJyb2Fk4oCdLg0KDQoN CkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbTxqYXZhc2Ny aXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9AZ29vZ2xlLmNvbScpOz5dDQpTZW50OiAxNyBG ZWJydWFyeSAyMDE1IDAyOjQxDQpUbzogSGVhdGxleSwgTmljaw0KQ2M6IFJvc3MgQ2hhbmRsZXI7 IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcs J3Y2b3BzQGlldGYub3JnJyk7PikNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoN Ck9uIFR1ZSwgRmViIDE3LCAyMDE1IGF0IDEwOjU3IEFNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVu em9AZ29vZ2xlLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2xvcmVuem9AZ29vZ2xl LmNvbScpOz4+IHdyb3RlOg0KWWVzLiBNYWtlIElQdjYqIChzZWUgYmVsb3cpIGEgcmVxdWlyZW1l bnQgZm9yIGNhcnJpZXItYnJhbmRlZCBkZXZpY2VzLCBhbmQgZ2l2ZSB0aGUgT0VNcyBhIGNyZWRp YmxlIHNpZ25hbCB0aGF0IGZyb20gZGF0ZSBYIG9ud2FyZHMsIHlvdSAqd2lsbCogZmFpbCBUQSBv biBldmVyeSBkZXZpY2UgdGhhdCBkb2Vzbid0IGltcGxlbWVudCBJUHY2LCBhbmQgeW91ICp3aWxs IG5vdCogd2FpdmUgdGhlIHJlcXVpcmVtZW50LiBUaGF0J3Mgd2hhdCBWZXJpem9uIGFuZCBULU1v YmlsZSBkaWQsIGFuZCBpdCB3b3JrZWQgZm9yIHRoZW0uDQoNCkFsc286IGlmIHlvdSB0aGluayB0 aGF0IHRoaXMgc3RyYXRlZ3kgaXMgbm90IGZlYXNpYmxlIGJlY2F1c2UgeW91IGRvIG5vdCBoYXZl IGFuIElQdjYgbmV0d29yayB5ZXQsIHRoZW4geWVzLCB0aGF0J3MgdHJ1ZSAtIHlvdSBjYW4ndCBt YWtlIElQdjYgYSBkZXZpY2UgcmVxdWlyZW1lbnQgdW50aWwgeW91IGhhdmUgYW4gSVB2NiBuZXR3 b3JrLg0KDQpCdXQgSSB0aGluayB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCBhcGFydCBmcm9t IHRoZSBsYWNrIG9mIDQ2NHhsYXQgb24gaU9TLCB0aGUgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1z IGFyZSBhIGxvdCBtb3JlIHJlYWR5IGZvciBJUHY2IHRoYW4geW91IG1pZ2h0IHRoaW5rIHRoZXkg YXJlLiBPbmNlIHRoZSBuZXR3b3JrIGlzIGNvbXBsZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2 NiBpbiB0aGUgZGV2aWNlcyBkb2VzIHdvcmsuIE9yYW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBT SyBUZWxlY29tIHNob3VsZCBiZSBhYmxlIHRvIGNvbmZpcm0uDQoNCk5PVElDRSBBTkQgRElTQ0xB SU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVk IGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlz IGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFu eSBwdXJwb3NlLg0KDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVt YWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVw cyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9t IGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUg dGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4NCg0KRUUgTGltaXRlZA0K UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJl cjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1v c3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQoNCg0KDQoNCk5P VElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9z ZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLg0KDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcg YW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2Ug aGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50 cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJp bGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4N Cg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBS ZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRy aWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAg OUJXDQoNCg0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihz KS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBk byBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1vbml0 b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQg bGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFp bCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5z IHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJz ZWx5IGFmZmVjdCB5b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5k IFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBP ZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVy dGZvcmRzaGlyZSwgQUwxMCA5QlcuDQo= --_000_6536E263028723489CCD5B6821D4B21303E097FBUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5UZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRlYnVsbGVzLCBkaXYuVGV4dGVk ZWJ1bGxlcw0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIjsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToi VGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk15IG9ic2VydmF0aW9uIGlzIGFyb3VuZCBhY2NvdW50YWJpbGl0eSB2cyByZXNwb25zaWJpbGl0 eSAodGhlIFJBQ0kgbWF0cml4KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBpc3N1ZSB3ZSBzZWVtIHRvIGhhdmUg aXMgdGhhdCB0aGUgSUVURiBleHBlcnRpc2UgaXMgbmVlZGVkLCBzbyB3ZSBuZWVkIHRoZSBJRVRG IGNvbW11bml0eSB0byBlZmZlY3RpdmVseSBiZSB0aGUgcmVzcG9uc2libGUgYWdlbmN5IGZvciB0 aGUgdGVjaG5pY2FsIGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vcm1h bGx5IFNET3MgYXJlIGJvdGggYWNjb3VudGFibGUgYW5kIHJlc3BvbnNpYmxlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BY2NvdW50YWJpbGl0eSwgd2VsbCwgY2xlYXJseSBzb21lIGZp bmQgaXQgdW5lYXN5IHRoYXQgSUVURiB3b3VsZCBoYXZlIGFjY291bnRhYmlsaXR5IGZvciB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JZiBhbm90aGVyIGJvZHkgY291bGQgYmUgYWNjb3VudGFibGUg Zm9yIHRoZSBkb2N1bWVudCwgdGhhdCBpdCByZXByZXNlbnRzIHRoZSB2aWV3cyBvZiBhIHN1aXRh YmxlIGNvbGxlY3RpdmUgKG1vYmlsZSBvcGVyYXRvcnMpLCBidXQgdGhlIHRlY2huaWNhbCBjb250 ZW50IHdhcw0KIGZpbHRlcmVkIHZpYSBJRVRGLCB0aGF0IHdvdWxkIGJlIGlkZWFsLCBubz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIG5vIGlkZWEgaG93IHRvIGVuZ2luZWVy IHN1Y2ggYW4gb3V0Y29tZSwgYnV0IGlmIGl0IGNvdWxkIGJlIGRvbmUgdGhlbiB0aGlzIHdvcmsg c2hvdWxkIG5vdCBiZSB3YXN0ZWQg4oCTIGNvdWxkIGJlIGEg4oCcR1NNQSBzcG9uc29yZWQgUkZD 4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhpcyBwcm9ibGVtIG9mIGV4cGVydGlzZSBpcyBub3QgZ29pbmcgYXdh eSBzbyBJIHNoYXJlIE1lZHMgY29uY2VybnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oQmFyYmFyYeKAmXMgY29tbWVu dCBvbiBhIGdyb3VwIFJGUCwgYWJzb2x1dGVseSBub3Qgd29ya2FibGUgZHVlIHRvIGFsbCB0aGUg TkRBcyB0aGF0IHJlc2lkZSBhcm91bmQgdGVybWluYWxzLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gW21h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4 IEZlYnJ1YXJ5IDIwMTUgMTU6NDY8YnI+DQo8Yj5Ubzo8L2I+IENhIEJ5PGJyPg0KPGI+Q2M6PC9i PiBIZWF0bGV5LCBOaWNrOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9m aWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+SGkgQ2FtZXJvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+SXQgaXMgd2FzdGVmdWwgdG8gaW5pdGlhdGUgdGhpcyB3b3JrIGluIGFub3Ro ZXIgZm9ydW0gd2hpbGUgYm90aCB0aGUgSVB2NiBleHBlcnRpc2UgYW5kIHRoZSBrbm93bGVkZ2Ug b2YgbW9iaWxlIG5ldHdvcmtzIGlzIGF2YWlsYWJsZSBhdCB0aGUgSUVURi4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5GV0lXLCB0aGUgSUVURiBw cm9kdWNlZCBwcm9maWxlIGRvY3VtZW50cyAocmVhZCBDUEUgcmVxdWlyZW1lbnRzIFJGQ3MpIHdo aWxlIG9uZSBjYW4gdGhpbmsgQkJGIGNhbiBiZSBhIGxlZ2l0aW1hdGUgZm9ydW0gdG8gcHJvZHVj ZSBzdWNoIGRvY3VtZW50cy4gVGhpcyBkb2N1bWVudA0KIGlzIG5vdCBhbiBleGNlcHRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPknigJltIHN1 cmUgd2Ugd2lsbCBjb21lIHVwIHRvIGEgYmFsYW5jZWQgYXBwcm9hY2ggdG8gc2F0aXNmeSB0aGUg Y29tbWVudHMgcmVjZWl2ZWQgc28gZmFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IENhIEJ5IFs8YSBocmVmPSJtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tIj5tYWlsdG86 Y2IubGlzdDZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJj cmVkaSAxOCBmw6l2cmllciAyMDE1IDE2OjA4PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBIZWF0bGV5LCBOaWNrOyBJ UHY2IE9wcyBXRyAoPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+djZvcHNA aWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPik8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5 IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPkF1dGhvcnMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+SSBrbm93IHlvdSBzYWlkIHRoZSAzZ3Bw IGlzIG5vdCBpbnRlcmVzdGVkIGluIHRoaXMgd29yaywgd2hhdCBhYm91dCBHU01BID8mbmJzcDsg VGhleSB3cml0ZSBwcm9maWxlcyBmb3IgbW9iaWxlIG5ldHdvcmtzICwgcmlnaHQ/ICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+Q0I8YnI+DQo8YnI+DQpP biBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE1LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBOaWNrLDwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgZnVsbHkgYWdyZWUuDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzo8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwn Y3ZtbCcsJ3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj52Nm9wcy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEhlYXRsZXksIE5pY2s8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTggZsOpdnJpZXIgMjAxNSAxMDoz NTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gTG9yZW56byBDb2xpdHRpPGJyPg0KPGI+Q2MmbmJzcDs6 PC9iPiBJUHY2IE9wcyBXRyAoPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd2 Nm9wc0BpZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPik8YnI+ DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxl LWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7Pzwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBhZ3JlZSB3aXRoIHlvdSwgdGhhdCBpcyBh IHNlbnNpYmxlIGFwcHJvYWNoLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+V29ya2luZyB3aXRoIGVhY2ggdmVuZG9yIGluIHR1cm4uPC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oWW91IGtu b3cgZWFjaCB2ZW5kb3Igd2hvIGNsYWltcyBJUHY2IHJlYWRpbmVzcyBmb3IgdGhlaXIgdGVybWlu YWwsIHdpbGwgbmV2ZXIgc2F5IHdoZXRoZXIgdGhlIGRldmljZQ0KIHdpbGwgd29yayBvbiB0aGUg b3BlcmF0b3JzIElQdjYgbmV0d29yay48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIGl0IG5lZWRzIHRvIGJlIGNvbGxhYm9yYXRpdmUuKTwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TbyBhbGwgdGhpcyBkb2N1bWVudCBpcyBkb2luZyBpcyBzZXR0aW5nIGEgY29sbGVjdGl2ZSBy b2FkbWFwLCByYXRoZXIgdGhhbiBleHBlY3QgdmVuZG9ycyB0byBkbyB0aGVpcg0KIG93biB0aGlu Zy4gR2l2ZW4gd2UgYWdyZWUgb24gdGhlIGFib3ZlLCB0aGlzIGlzIG5vdCBoYXJtZnVsLjwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHRoaW5rIHRoZSByZWFsIGRpc2FncmVlbWVudCBjb21lcyBmcm9tIHlvdXIgb3BpbmlvbiB0aGF0 IHRoaXMgaXMgbm90IElFVEYuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4oQnkgdGhlIHdheSwgbW9iaWxlIG9wZXJhdG9ycyBoYXZlIGhhZCBk aXNjdXNzaW9ucyB3aXRoIHRoZSBzaXN0ZXIgb3JnIG9mIHRoZSBJbnRlcm5ldCBTb2NpZXR5IGFi b3V0DQogd2hhdCB3b3VsZCBoZWxwIG1vYmlsZSBvcGVyYXRvcnMgaW50cm9kdWNlIElQdjYuPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUg b2YgdGhlIG1ham9yIG1ham9yIHRoZW1lcyBoYXMgYmVlbiB0ZXJtaW5hbHMuKTwvc3Bhbj48c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g TG9yZW56bw0KIENvbGl0dGkgWzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywn bG9yZW56b0Bnb29nbGUuY29tJyk7IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTggRmVicnVhcnkgMjAxNSAwNzoyNjxi cj4NCjxiPlRvOjwvYj4gSGVhdGxleSwgTmljazxicj4NCjxiPkNjOjwvYj4gUm9zcyBDaGFuZGxl cjsgSVB2NiBPcHMgV0cgKDxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywndjZv cHNAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4pPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7Pzwvc3Bhbj48 c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxNywgMjAx NSBhdCA4OjMxIFBNLCBIZWF0bGV5LCBOaWNrICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3 QiU3RCwnY3ZtbCcsJ25pY2suaGVhdGxleUBlZS5jby51aycpOyIgdGFyZ2V0PSJfYmxhbmsiPm5p Y2suaGVhdGxleUBlZS5jby51azwvYT4mZ3Q7IHdyb3RlOjxzcGFuIGxhbmc9IkZSIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIHNlZSB3aHkgeW91 IGFyZ3VlIGZvciBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIG9mIHY2IHJlcXVpcmVtZW50cy48 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg dGhpbmsgeW91ciBzdGFuY2UgdGhhdCB0aGlzIGNhbiB3b3JrIGFjcm9zcyB0aGUgYm9hcmQgaXMg 4oCcaGFybWZ1bGx5IHJlc3RyaWN0aXZl4oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG90aGVyIGFwcHJvYWNoIGlzIHVuZGVyc3Rh bmRpbmcgdGhlIGRpZmZlcmVuY2VzIGFuZCB0cnlpbmcgdG8gc2V0IGEgc2xpZ2h0bHkgaGlnaGVy IGJhciB0aGF0DQogaGlnaGxpZ2h0cyBjb25kaXRpb25hbCByZXF1aXJlbWVudHMgb2YgdGhlIGNv bGxlY3RpdmU7IHdoYXQgeW91IGNhbGwgJm5ic3A74oCcaGFybWZ1bGx5IGJyb2Fk4oCdLjwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PldoYXQgSSdtIHNheWluZyBpcyB0aGF0IGlmIHlvdXIgZ29hbCBpcyBJUHY2IGRlcGxveW1lbnQg aW4gYSByZWFzb25hYmxlIHRpbWVmcmFtZSwgdGhlbiB0aGUgcmlnaHQgc3RyYXRlZ3kgaXMmbmJz cDsqbm90KiB0byBtYWtlIGEgbGlzdCBvZiBhbGwgdGhlIGZlYXR1cmVzIHVuZGVyIHRoZSBzdW4s IHdhaXQgdW50aWwNCiB0aGV5IGhhdmUgYWxsIGJlZW4gaW1wbGVtZW50ZWQsIGFuZCBkZXBsb3kg dGhlbS4gQSBiZXR0ZXIgc3RyYXRlZ3kgaXMgdG8gc3RhcnQgZnJvbSB0aGUgZmVhdHVyZXMgdGhh dCBhcmUgcmVxdWlyZWQsIHRlc3QgYW5kIGRlcGxveSB0aG9zZSwgYW5kIHRoZW4gaXRlcmF0ZS4g QXMgdGhlIGluZHVzdHJ5IGV2b2x2ZXMgYW5kIElQdjYgYmVjb21lcyBtb3JlIGNvbW1vbiwgSVB2 NiBmZWF0dXJlcyB3aWxsIGJlY29tZSBoaWdoZXIgcHJpb3JpdHkgZm9yDQogdmVuZG9ycyBhbmQg dGhleSB3aWxsIGdldCBpbXBsZW1lbnRlZC48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQg ODozMSBQTSwgSGVhdGxleSwgTmljayAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0Qs J2N2bWwnLCduaWNrLmhlYXRsZXlAZWUuY28udWsnKTsiIHRhcmdldD0iX2JsYW5rIj5uaWNrLmhl YXRsZXlAZWUuY28udWs8L2E+Jmd0OyB3cm90ZTo8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHRoZSBnYW1lIG9mIGNo aWNrZW4gYXBwcm9hY2gsIEkgaGF2ZSBubyBkb3VidCBpdCB3b3JrcywgYnV0IGlzIGl0IGluY2x1 c2l2ZSB0byBhbGwgbW9iaWxlDQogb3BlcmF0b3JzPzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIG1lLCBpdCBoYXMgc29tZSBsaW1pdGF0 aW9uczo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBvcGVyYXRvciBtdXN0IGhhdmUgdG9wIGRv d24gYmFja2luZyBmb3IgYSB0ZXJtaW5hbCBwb2xpY3kgb2Yg4oCcSVB2NiBvciB5b3UgYXJlIG91 dOKAnSAobm93IHRoYXQgaXMgYSB3aWxkY2FyZCBjb25kaXRpb24gaW4gaXRzZWxmKTsgaXQgbWF5 IGNvbXByb21pc2UgcmVsYXRpb25zaGlwcyBpbiBhDQogdmFsdWFibGUgZWNvc3lzdGVtPC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5XaGVyZSB0aGUgb3BlcmF0b3IgaGFzIGhpZ2ggbWFqb3IgbWFya2V0 IHBvd2VyIGhlbHBzLiBXaGVyZSBtYXJrZXRzIGhhdmUgYSBudW1iZXIgb2YgcGxheWVycyByZWFk eSB0byBwbGF5IHRoZSBJUHY2IGdhbWUsIHRoZXJlIGlzIGFuIGFkdmFudGFnZS4gT3RoZXJ3aXNl IHRoZSBvcGVyYXRvciBpcw0KIHZlcnkgZXhwb3NlZCB0byBkaXZpZGUgYW5kIGNvbnF1ZXI8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCB0ZW5kcyB0byBwbGF5IG91dCBhcyBhIHRo ZSBzaW1wbGVzdCBzZXQgb2YgcmVxdWlyZW1lbnRzLiBXaGljaCBhbHNvIG1lYW5zIHNpbXBsZXN0 IHNldCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcy4gU29tZXRpbWVzIHRoZXNlIHNpbXBsZXN0IHNl dCBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcw0KIGFyZSBhdCBvZGRzIHdpdGggdGhlIGJ1c2luZXNz IHByaW9yaXRpZXMgb2YgdGhlIG9wZXJhdG9yIChjbGVhciBleGFtcGxlcyBhcmU6IEFQTiBzdHJh dGVneSwgdGV0aGVyaW5nIGFwcHJvYWNoLCByb2FtaW5nIGFwcHJvYWNoLCBzdWJzaWRpc2VkIGhh bmRzZXQgdnMg4oCcU0lNLW9ubHnigJ0pPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oTm90IGhhdmluZyBhbiBJUHY2IGNhcGFibGUgbmV0d29y ayBpcyBhIG15dGggeW91IGFyZSBwcm9tb3RpbmcgdG8gZGlzY3JlZGl0IG9wZXJhdG9yIHZpZXdz LCBpdCBpcw0KIGEgcmVkIGhlcnJpbmcg4oCTIGFueSBvcGVyYXRvciBzcGVjaWZ5aW5nICo8Yj5h bnk8L2I+KiBJUHY2IHJlcXVpcmVtZW50cyB3aWxsIHZlcnkgcXVpY2tseSBuZWVkIHRoaXMgY2Fw YWJpbGl0eSB0byB2YWxpZGF0ZSB0ZXJtaW5hbHMgd2hhdGV2ZXIgdGhlIHBhdGggdGhleSBjaG9v c2UuKTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGNhbiBzZWUgd2h5IHlvdSBhcmd1ZSBmb3IgbG93ZXN0IGNvbW1vbiBkZW5vbWlu YXRvciBvZiB2NiByZXF1aXJlbWVudHMuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHlvdXIgc3RhbmNlIHRoYXQgdGhpcyBjYW4g d29yayBhY3Jvc3MgdGhlIGJvYXJkIGlzIOKAnGhhcm1mdWxseSByZXN0cmljdGl2ZeKAnS48L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBv dGhlciBhcHByb2FjaCBpcyB1bmRlcnN0YW5kaW5nIHRoZSBkaWZmZXJlbmNlcyBhbmQgdHJ5aW5n IHRvIHNldCBhIHNsaWdodGx5IGhpZ2hlciBiYXIgdGhhdA0KIGhpZ2hsaWdodHMgY29uZGl0aW9u YWwgcmVxdWlyZW1lbnRzIG9mIHRoZSBjb2xsZWN0aXZlOyB3aGF0IHlvdSBjYWxsICZuYnNwO+KA nGhhcm1mdWxseSBicm9hZOKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8NCiBDb2xpdHRpIFttYWlsdG86 PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdsb3JlbnpvQGdvb2dsZS5jb20n KTsiIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IDE3IEZlYnJ1YXJ5IDIwMTUgMDI6NDE8YnI+DQo8Yj5Ubzo8L2I+IEhlYXRsZXksIE5p Y2s8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgQ2hhbmRsZXI7IElQdjYgT3BzIFdHICg8YSBocmVmPSJq YXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Y2b3BzQGlldGYub3JnJyk7IiB0YXJnZXQ9Il9i bGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3Bz XSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90 O2hhcm1mdWxseSBicm9hZCZxdW90Oz88L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgMTA6NTcgQU0sIExvcmVuem8gQ29s aXR0aSAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdsb3JlbnpvQGdv b2dsZS5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0OyB3 cm90ZTo8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMu IE1ha2UgSVB2NiogKHNlZSBiZWxvdykgYSByZXF1aXJlbWVudCBmb3IgY2Fycmllci1icmFuZGVk IGRldmljZXMsIGFuZCBnaXZlIHRoZSBPRU1zIGEgY3JlZGlibGUgc2lnbmFsIHRoYXQgZnJvbSBk YXRlIFggb253YXJkcywgeW91ICp3aWxsKiBmYWlsIFRBIG9uIGV2ZXJ5IGRldmljZSB0aGF0IGRv ZXNuJ3QNCiBpbXBsZW1lbnQgSVB2NiwgYW5kIHlvdSAqd2lsbCBub3QqIHdhaXZlIHRoZSByZXF1 aXJlbWVudC4gVGhhdCdzIHdoYXQgVmVyaXpvbiBhbmQgVC1Nb2JpbGUgZGlkLCBhbmQgaXQgd29y a2VkIGZvciB0aGVtLjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsc286IGlmIHlvdSB0aGluayB0aGF0IHRoaXMg c3RyYXRlZ3kgaXMgbm90IGZlYXNpYmxlIGJlY2F1c2UgeW91IGRvIG5vdCBoYXZlIGFuIElQdjYg bmV0d29yayB5ZXQsIHRoZW4geWVzLCB0aGF0J3MgdHJ1ZSAtIHlvdSBjYW4ndCBtYWtlIElQdjYg YSBkZXZpY2UgcmVxdWlyZW1lbnQgdW50aWwgeW91IGhhdmUNCiBhbiBJUHY2IG5ldHdvcmsuPHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IEkgdGhpbmsg dGhlIGtleSBwb2ludCBoZXJlIGlzIHRoYXQgYXBhcnQgZnJvbSB0aGUgbGFjayBvZiA0NjR4bGF0 IG9uIGlPUywgdGhlIG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcyBhcmUgYSBsb3QgbW9yZSByZWFk eSBmb3IgSVB2NiB0aGFuIHlvdSBtaWdodCB0aGluayB0aGV5IGFyZS4gT25jZSB0aGUNCiBuZXR3 b3JrIGlzIGNvbXBsZXRlLCBJIHRoaW5rIHR1cm5pbmcgb24gSVB2NiBpbiB0aGUgZGV2aWNlcyBk b2VzIHdvcmsuIE9yYW5nZSBQb2xhbmQsIFRlbGVub3IsIGFuZCBTSyBUZWxlY29tIHNob3VsZCBi ZSBhYmxlIHRvIGNvbmZpcm0uPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHA+Tk9USUNFIEFORCBESVNDTEFJTUVSPGJyPg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiZu YnNwOyBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQg ZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7DQo8YnI+DQombmJz cDs8YnI+DQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBp biBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBl bnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2 aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2 aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4NCjxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD5FRSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kIGFuZCBXYWxlczxicj4NCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxPGJy Pg0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5 LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwPk5PVElDRSBB TkQgRElTQ0xBSU1FUjxicj4NClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz KSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4mbmJzcDsgSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNj bG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOw0KPGJyPg0KJm5ic3A7PGJyPg0KV2Ug bWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRo IGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQg dGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBp dCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuDQo8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+RUUgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2Fs ZXM8YnI+DQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MTxicj4NClJlZ2lzdGVy ZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQs IEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJ U0NMQUlNRVI8QlI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGlu dGVuZGVkIA0KZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0Kbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Ns b3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1v bml0b3IgYWxsIGluY29taW5nIA0KYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3Vy cmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byANCmVuc3VyZSB0aGF0IHRo aXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQg cmVtYWlucyANCnlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIDwvUD4NCjxQPkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIGFuZCBXYWxlczxCUj5Db21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAy MzgyMTYxPEJSPlJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1 aXRvIFdheSwgSGF0ZmllbGQsIA0KSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L1A+DQo8UD4mbmJz cDs8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B21303E097FBUK30S005EXS06EE_-- From nobody Thu Feb 19 02:20:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B281A8A75 for ; Thu, 19 Feb 2015 02:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7w3qVIgzj9X for ; Thu, 19 Feb 2015 02:20:04 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6D61A8A44 for ; Thu, 19 Feb 2015 02:20:03 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hn18so42931217igb.2 for ; Thu, 19 Feb 2015 02:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UitTqFGB/qBts3AMBlUq1bOAsmYj5KZ4KVoiAUf+XGQ=; b=K5IfRl7hiZAAOac237JoEPpmAQ9UWIfhLPhqMpOZ1CbLgf6HR6TrUR0DFPnOoVrTJm DCN//4jKTOGXnAS9fbTeDIfYMNGmLkUgWkOXeC8JtuLQ+AhaJNDnecSoQDJXWzhLtWis Mk5BGncVRITIXAfwvaBTTODdznTDZ/E5S+sE2lBGfu198p6a1AzbJsTRwIekyzDcSMow FIMLvwSKxQIZyl2XQ7I3y5/NyFwMuPxymk+RMIFwy1czUZVv7rlkS9UR8X379yAo9nnv cWj4d171N3M+2Hcam26UQ/6SFNEgcqTOrtXBEYazNYyFXT5L0m/rLKBn6EsZ8xa/s2r0 gfug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UitTqFGB/qBts3AMBlUq1bOAsmYj5KZ4KVoiAUf+XGQ=; b=SpZSV5ZzkUCVOA3zuyMbz0xTxYxmPnk3wVevHqGHl3q/4uGyt4KayE+3yTGpjZv8Gt r9tJOrOitO7ZnukZgSi642tWxOOYRTglDVY3yT5eTnWAbXzPVZkTZrl/9brDtV4iyomg Hm6TNiOmhM3u7C5RECZUBeRZWY/TZMZBY3VrPsH/pcpOn/bPU3m+frpK1dPYIENxQZra EYaaZPYVNSc1/GFRlN/h86CL9gYFTmDo3ED4t8CucTtHOYmYkUfhy6VZuqnTDyFEnckP jV4GO2cMI9E+XkXBeOelH0FSMFUt9K7nKLwjZ5pPwQQQjUGhEdUreA03DtPRRNUoQeXV g7rg== X-Gm-Message-State: ALoCoQl/v5KSj1sg0gwk0Q6YRipkGthebbyZtAhxmpR1NC/GEPk30LrxjdDOJY+b7sHyDiIt1uvn X-Received: by 10.42.138.199 with SMTP id d7mr5099374icu.3.1424341203026; Thu, 19 Feb 2015 02:20:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 02:19:42 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 19:19:42 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=90e6ba1efc1272559d050f6e479d Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:20:05 -0000 --90e6ba1efc1272559d050f6e479d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick wrote: > If another body could be accountable for the document, that it > represents the views of a suitable collective (mobile operators), but the > technical content was filtered via IETF, that would be ideal, no? > > I have no idea how to engineer such an outcome, but if it could be done > then this work should not be wasted =E2=80=93 could be a =E2=80=9CGSMA sp= onsored RFC=E2=80=9D? > You could make it an independent submission, and say that it represents the recommendations of the authors (see RFC 4846 for a description of the process, or RFC 6732 for an example of such an independent submission RFC). If what you're after is IETF expertise, then I think the document has had plenty of exposure to that already, given it's been in the WG for over a year and a half. --90e6ba1efc1272559d050f6e479d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 6:14 PM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:

If another body could be accountable for the= document, that it represents the views of a suitable collective (mobile op= erators), but the technical content was filtered via IETF, that would be ideal, no?

I have no idea how to engineer such an outco= me, but if it could be done then this work should not be wasted =E2=80=93 c= ould be a =E2=80=9CGSMA sponsored RFC=E2=80=9D?


You could make it an independent submission, an= d say that it represents the recommendations of the authors (see RFC 4846 f= or a description of the process, or RFC 6732 for an example of such an inde= pendent submission RFC).

If what you're after = is IETF expertise, then I think the document has had plenty of exposure to = that already, given it's been in the WG for over a year and a half.
--90e6ba1efc1272559d050f6e479d-- From nobody Thu Feb 19 02:33:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A591A8A9C for ; Thu, 19 Feb 2015 02:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXRraiXPHPHr for ; Thu, 19 Feb 2015 02:33:12 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693E51A8A8E for ; Thu, 19 Feb 2015 02:33:12 -0800 (PST) Received: by iecvy18 with SMTP id vy18so8319516iec.6 for ; Thu, 19 Feb 2015 02:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9klFWRg1oj3CrayV7OBEHKfUEgRfY6nSjOuYNzvjMVA=; b=Y0qzb10tq6+I7GokHbaEMw69y8pPlBf6+2ZcRCtUUrt6menDE6m/OAtipwSQQk5m8J 8/MyFHYGeAy+5/sC99na0FlvRPs+EqvWm3SUD7C4njTPchqEs5YTsZl62hLv33vU9OgE Yh4UzYYg8jat21TU7lgGRz2NtQI/0lOR1lHLmQu+cWw048D6HHHaXtyESLp2cVPeFFu1 WIHU0WO64VszcEmDmVlWllICwy3rnonl2JNkirIU9reO8IKo4hS6yqeywkjVORwnKtL8 1Lw/9jOIPHE2kckW1JgKwkVdiC5yn8sEk9wipiO2nfa2rHdJ3COMdpvKxJA7x7sQ+MOG dNbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9klFWRg1oj3CrayV7OBEHKfUEgRfY6nSjOuYNzvjMVA=; b=SzWAwADkdgJ/So01iXsCaLZ/nh+VsE3xIxzGef8qNZbqSclQ9OfK2ZBIeov2vUzbvD pmE9uo2qoaVoRyIHg6Av96UXhoiPGkNAjvfEyGAK4aTpcGJYv7XtG7XIq8Ny+vHDC2eJ 7UuVbUHdW7bfizKa6ryCD3v2kG3kBzBNSn+lsujgaqcG0VML6Hlpa1ZsrLY/FmxquQrr /jXV2hvHqyYqB1FPa/q8hyts5Gz86evglQWLXr7li4f5w9Ruez3t1ZAuxEufH6fOTN1V f0dcC4MhnmfyPgm4nIIOA9cyCs0dig2CFy85onao9s3iYq7c0SASgqkw4s1bvrBKWcC4 xxKQ== X-Gm-Message-State: ALoCoQke0F49jYGxGVxMJhC8SoA8PF9YUjZoEbe/RpiRlGkT7LzOcuW9af5auPqbZgIBEOBN92Jh X-Received: by 10.43.76.9 with SMTP id zc9mr5122178icb.84.1424341991845; Thu, 19 Feb 2015 02:33:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 02:32:51 -0800 (PST) In-Reply-To: <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 19:32:51 +0900 Message-ID: To: "BINET David IMT/OLN" Content-Type: multipart/alternative; boundary=001a11c3a3c27697a3050f6e7660 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:33:15 -0000 --001a11c3a3c27697a3050f6e7660 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 1:39 AM, wrote: > > [DB] Could you be more explicit and indicate which features are not useful > in the draft ? As you can mention it, all features are not indicated as > mandatory in the draft so I do not clearly understand how this document > conflicts with what you say considering that the goal for the operator is > to provide at least the same service access for users with IPv6 > connectivity than for users with IPv4 connectivity whatever the strategy > retained by the operator. > If the goal of the document is "to provide at least the same service access for users with IPv6 connectivity than for users with IPv4 connectivity whatever the strategy retained by the operator" then you can reduce the document to two requirements: 1. Support both IPv4v6 and IPv6. 2. Support 464xlat. --001a11c3a3c27697a3050f6e7660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 1:39 AM, <david.binet@orange.com> = wrote:


[DB] Could you be more explicit and indicate= which features are not useful in the draft ? As you can mention it, all fe= atures are not indicated as mandatory in the draft so I do not clearly understand how this document co= nflicts with what you say considering that the goal for the operator is to = provide at least the same service access for users with IPv6 connectivity t= han for users with IPv4 connectivity whatever the strategy retained by the operator.

=C2=A0
If the goal of= the document is "to provide at least the same service access for user= s with IPv6 connectivity than for users with IPv4 connectivity whatever the= strategy retained by the operator" then you can reduce the document t= o two requirements:

1. Support both IPv4v6 and IPv= 6.
2. Support 464xlat.
--001a11c3a3c27697a3050f6e7660-- From nobody Thu Feb 19 02:41:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0719A1A8ABA for ; Thu, 19 Feb 2015 02:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcmFX4Q-yRCo for ; Thu, 19 Feb 2015 02:41:48 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FFF1A8AB9 for ; Thu, 19 Feb 2015 02:41:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1JAfjPS014281 for ; Thu, 19 Feb 2015 11:41:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A724020232F for ; Thu, 19 Feb 2015 11:42:49 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9F53D20227B for ; Thu, 19 Feb 2015 11:42:49 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1JAfI57004956 for ; Thu, 19 Feb 2015 11:41:44 +0100 Message-ID: <54E5BDCE.3050805@gmail.com> Date: Thu, 19 Feb 2015 11:41:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:41:50 -0000 Le 19/02/2015 11:19, Lorenzo Colitti a écrit : > On Thu, Feb 19, 2015 at 6:14 PM, Heatley, Nick > wrote: > > If another body could be accountable for the document, that it > represents the views of a suitable collective (mobile operators), but > the technical content was filtered via IETF, that would be ideal, > no? > > I have no idea how to engineer such an outcome, but if it could be > done then this work should not be wasted – could be a “GSMA sponsored > RFC”? > > > You could make it an independent submission, and say that it > represents the recommendations of the authors (see RFC 4846 for a > description of the process, or RFC 6732 for an example of such an > independent submission RFC). > > If what you're after is IETF expertise, then I think the document has > had plenty of exposure to that already, given it's been in the WG for > over a year and a half. As an alternative for more than independent submission, one could (1) squeeze it into few requirements having more tract than the set, (2) get software writers to expose running code, (3) get complimentary profiles other than cellular operators interested, and call it a deal. For example, squeeze it to recommend only DHCP-PD, tell how OSS implementations exist, and get an equipment manufacturer on board. For the 464xlat/nat64/dns64/CLAT recommendation part - I personally think it is way too strict in its reaches, although I fully agree with a long-term goal of IPv6-only. It is strict, because many other IETF RFCs offer much more solutions to this kind of problem; other new solutions can be developped as well (Problem Statement first?). It has wide reaches because it recommends 'should' a _set_ RFCs. Finally, if all we have is facing a widely used deployment, with no means to influence operator's network to end-user needs, tired of discussions, then this should be an INFORMATIONAL and that's that. There is much value in it as well. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Feb 19 02:42:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43DD1A8AC2 for ; Thu, 19 Feb 2015 02:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j59G3gxfzvG for ; Thu, 19 Feb 2015 02:42:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649331A8AAC for ; Thu, 19 Feb 2015 02:42:12 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.87.18; Thu, 19 Feb 2015 10:41:46 +0000 Message-ID: <034e01d04c30$66fde1c0$4001a8c0@gateway.2wire.net> From: t.petch To: Mark Andrews References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net> <20150218111024.DCF1A29E9E3B@rock.dv.isc.org> Date: Thu, 19 Feb 2015 10:15:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0033.eurprd05.prod.outlook.com (25.160.40.43) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) Authentication-Results: isc.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB056; X-Forefront-PRVS: 0492FD61DD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(61296003)(62236002)(23756003)(86362001)(40100003)(77156002)(62966003)(66066001)(42186005)(122386002)(47776003)(116806002)(93886004)(230783001)(44716002)(92566002)(46102003)(87976001)(110136001)(33646002)(77096005)(81686999)(19580395003)(50986999)(19580405001)(76176999)(84392001)(50466002)(14496001)(50226001)(44736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2015 10:41:46.7595 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:42:17 -0000 --- Original Message ----- From: "Mark Andrews" Sent: Wednesday, February 18, 2015 11:10 AM > In message <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net>, t.petch writes: > > ----- Original Message ----- > > From: "Mark Andrews" > > Sent: Tuesday, February 17, 2015 1:23 AM > > > > > The fundemental reason for 127.0.0.0/8 was to give each node a > > > addresses block they could use. 127.0.0.1 evolved as the "standard" > > > loopback address over time. For the most part no one uses the rest > > > of 127.0.0.0/8 but it is useful to have available. That said any > > > use of the rest of 127.0.0.0/8 has to be negotiated between the > > > users. You can't just grab 127.0.0.2 and hope that no one else is > > > using it for IP traffic. > > > > Mark > > > > I would refer you to RFC5782 and RFC6471 for a discussion on the use of > > 127.0.0.2 (and ::FFFF:7F00:2 ). > > RFC5782 Informational. > RFC6471 Informational. > > And they actually grabbed namespaces in the DNS not addresses. > Neither of them use those "addresses" for IP traffic which > is what the proposed reservation of the block is about. > > The only reason 127.0.0.2 etc. are use for rbls is that it > was possible to get sendmail to do a address lookup from > sendmail.cf without hacking the code. They returned values > are tokens not addresses despite them being encoded in > A/AAAA records. > > Raising RFC5782 and RFC6471 is a Red Herring. Mark Classifying those two RFC as Informational is a subtlety that those reading this e-mail will understand but most will not (as I am reminded of when I have seen manufacturers cite conformance to Internet Drafts:-). I am sure that if I looked hard enough I would find these RFC being cited as if they were Standards, let alone a BCP. And note the title of RFC6471 'overview of Best email dns-based list (DNSBL) Operational Practices ' (my capitalisation). As I recall, the reason why it is not a BCP, when it is a BCP in all but name, is political, that the BCP stream is owned by the IETF and that RFC is not a product of the IETF. So, rightly or wrongly, the IETF has implicitly endorsed a usage of 127.0.0.n, where n is a small number, and it would be foolish, IMHO, to endorse a separate usage. (For some reason, the choice of percent for interface identifiers, when percent was already spoken for in URIs, comes to mind). Last I heard, IPv6 is different, that the number of MX is small, the namespace is enormous and so while ::FFFF:7F00:2 was posited, it is unlikely to gain much traction. Tom Petch > Mark > > > Perhaps those RFC should have included an IANA Considerations:-( > > > > Tom Petch > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 19 04:13:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0F1A8ADB for ; Thu, 19 Feb 2015 04:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BiyoNsUVwA8 for ; Thu, 19 Feb 2015 04:13:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C057C1A87D5 for ; Thu, 19 Feb 2015 04:13:28 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CB0343B413C; Thu, 19 Feb 2015 13:13:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AA1DB27C0B2; Thu, 19 Feb 2015 13:13:26 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 13:13:21 +0100 From: To: Lorenzo Colitti , BINET David IMT/OLN Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTC9pixBJZ1L350WogIuKXDMPO5z33+Tw Date: Thu, 19 Feb 2015 12:13:21 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_fdc7ab8c4f6343eba77b4764f24d9486OPEXCLILH01corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.110025 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:13:33 -0000 --_000_fdc7ab8c4f6343eba77b4764f24d9486OPEXCLILH01corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBMb3Jl bnpvIENvbGl0dGkNCkVudm95w6kgOiBqZXVkaSAxOSBmw6l2cmllciAyMDE1IDExOjMzDQrDgCA6 IEJJTkVUIERhdmlkIElNVC9PTE4NCkNjIDogSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnKQ0K T2JqZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmls ZSBsYXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUaHUsIEZlYiAxOSwgMjAxNSBh dCAxOjM5IEFNLCA8ZGF2aWQuYmluZXRAb3JhbmdlLmNvbTxtYWlsdG86ZGF2aWQuYmluZXRAb3Jh bmdlLmNvbT4+IHdyb3RlOg0KDQpbREJdIENvdWxkIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGFuZCBp bmRpY2F0ZSB3aGljaCBmZWF0dXJlcyBhcmUgbm90IHVzZWZ1bCBpbiB0aGUgZHJhZnQgPyBBcyB5 b3UgY2FuIG1lbnRpb24gaXQsIGFsbCBmZWF0dXJlcyBhcmUgbm90IGluZGljYXRlZCBhcyBtYW5k YXRvcnkgaW4gdGhlIGRyYWZ0IHNvIEkgZG8gbm90IGNsZWFybHkgdW5kZXJzdGFuZCBob3cgdGhp cyBkb2N1bWVudCBjb25mbGljdHMgd2l0aCB3aGF0IHlvdSBzYXkgY29uc2lkZXJpbmcgdGhhdCB0 aGUgZ29hbCBmb3IgdGhlIG9wZXJhdG9yIGlzIHRvIHByb3ZpZGUgYXQgbGVhc3QgdGhlIHNhbWUg c2VydmljZSBhY2Nlc3MgZm9yIHVzZXJzIHdpdGggSVB2NiBjb25uZWN0aXZpdHkgdGhhbiBmb3Ig dXNlcnMgd2l0aCBJUHY0IGNvbm5lY3Rpdml0eSB3aGF0ZXZlciB0aGUgc3RyYXRlZ3kgcmV0YWlu ZWQgYnkgdGhlIG9wZXJhdG9yLg0KDQpJZiB0aGUgZ29hbCBvZiB0aGUgZG9jdW1lbnQgaXMgInRv IHByb3ZpZGUgYXQgbGVhc3QgdGhlIHNhbWUgc2VydmljZSBhY2Nlc3MgZm9yIHVzZXJzIHdpdGgg SVB2NiBjb25uZWN0aXZpdHkgdGhhbiBmb3IgdXNlcnMgd2l0aCBJUHY0IGNvbm5lY3Rpdml0eSB3 aGF0ZXZlciB0aGUgc3RyYXRlZ3kgcmV0YWluZWQgYnkgdGhlIG9wZXJhdG9yIg0KDQpbTWVkXSBU aGlzIGlzIG9uZSBvZiB0aGUgZ29hbHMgb2YgdGhlIEktRCBub3QgdGhlIG9ubHkgb25lLiBlLmcu LCB0aGUgSS1EIGxpc3RzIGZlYXR1cmVzIHRoYXQgYXJlIG5vdCBjb3ZlcmVkIGluIFJGQzcwNjYg YW5kIFJGQzY0MzQ6IGUuZy4sIHByZWZpeCBkZWxlZ2F0aW9uIG9yIHByZWZpeCBzaGFyaW5nLg0K DQp0aGVuIHlvdSBjYW4gcmVkdWNlIHRoZSBkb2N1bWVudCB0byB0d28gcmVxdWlyZW1lbnRzOg0K DQpbTWVkXSBJ4oCZbSBhZnJhaWQgY29tcGFjdGluZyB0aGUgcmVjb21tZW5kYXRpb25zIGlzIG5v dCBoZWxwZnVsLiBGb3IgZXhhbXBsZSwgdGhlc2UgdHdvIGl0ZW1zIGFyZSBjb3ZlcmVkIGFzIGZv bGxvd3MgaW4gdGhlIEktRCBmb3IgdGhlIHNha2Ugb2YgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvci4N Cg0KMS4gU3VwcG9ydCBib3RoIElQdjR2NiBhbmQgSVB2Ni4NCg0KW01lZF0gVGhlc2UgaXRlbXMg Y292ZXIgdGhpcyAxc3QgcG9pbnQ6DQoNCiAgIENfUkVDIzE6ICBJbiBvcmRlciB0byBhbGxvdyBl YWNoIG9wZXJhdG9yIHRvIHNlbGVjdCB0aGVpciBvd24NCiAgICAgICAgICAgICBzdHJhdGVneSBy ZWdhcmRpbmcgSVB2NiBpbnRyb2R1Y3Rpb24sIHRoZSBjZWxsdWxhciBob3N0DQogICAgICAgICAg ICAgbXVzdCBzdXBwb3J0IGJvdGggSVB2NiBhbmQgSVB2NHY2IFBEUC1Db250ZXh0cyBbVFMuMjMw NjA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUtMTgjcmVmLVRTLjIzMDYwPl0uDQogICAgICAgICAgICAgSVB2NCwgSVB2NiBv ciBJUHY0djYgUERQLUNvbnRleHQgcmVxdWVzdCBhY2NlcHRhbmNlIGRlcGVuZHMNCiAgICAgICAg ICAgICBvbiB0aGUgY2VsbHVsYXIgbmV0d29yayBjb25maWd1cmF0aW9uLg0KDQogICBDX1JFQyMy OiAgVGhlIGNlbGx1bGFyIGhvc3QgbXVzdCBjb21wbHkgd2l0aCB0aGUgYmVoYXZpb3IgZGVmaW5l ZCBpbg0KICAgICAgICAgICAgIFtUUy4yMzA2MDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xOCNyZWYtVFMuMjMwNjA+XSBb VFMuMjM0MDE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUtMTgjcmVmLVRTLjIzNDAxPl0gW1RTLjI0MDA4PGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE4 I3JlZi1UUy4yNDAwOD5dIGZvciByZXF1ZXN0aW5nIGEgUERQLQ0KICAgICAgICAgICAgIENvbnRl eHQgdHlwZS4gIEluIHBhcnRpY3VsYXIsIHRoZSBjZWxsdWxhciBob3N0IG11c3QNCiAgICAgICAg ICAgICByZXF1ZXN0IGJ5IGRlZmF1bHQgYW4gSVB2NiBQRFAtQ29udGV4dCBpZiB0aGUgY2VsbHVs YXIgaG9zdA0KICAgICAgICAgICAgIGlzIElQdjYtb25seSBhbmQgcmVxdWVzdCBhbiBJUHY0djYg UERQLUNvbnRleHQgaWYgdGhlDQogICAgICAgICAgICAgY2VsbHVsYXIgaG9zdCBpcyBkdWFsLXN0 YWNrIG9yIHdoZW4gdGhlIGNlbGx1bGFyIGhvc3QgaXMNCiAgICAgICAgICAgICBub3QgYXdhcmUg b2YgY29ubmVjdGl2aXR5IHR5cGVzIHJlcXVlc3RlZCBieSBkZXZpY2VzDQogICAgICAgICAgICAg Y29ubmVjdGVkIHRvIGl0IChlLmcuLCBjZWxsdWxhciBob3N0IHdpdGggTEFOIGNhcGFiaWxpdGll cw0KICAgICAgICAgICAgIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDM8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTgjc2Vj dGlvbi0zPik6DQoNCiAgICAgICAgICAgICAqICBJZiB0aGUgcmVxdWVzdGVkIElQdjR2NiBQRFAt Q29udGV4dCBpcyBub3Qgc3VwcG9ydGVkIGJ5DQogICAgICAgICAgICAgICAgdGhlIG5ldHdvcmss IGJ1dCBJUHY0IGFuZCBJUHY2IFBEUCB0eXBlcyBhcmUgYWxsb3dlZCwNCiAgICAgICAgICAgICAg ICB0aGVuIHRoZSBjZWxsdWxhciBob3N0IHdpbGwgYmUgY29uZmlndXJlZCB3aXRoIGFuIElQdjQN CiAgICAgICAgICAgICAgICBhZGRyZXNzIG9yIGFuIElQdjYgcHJlZml4IGJ5IHRoZSBuZXR3b3Jr LiAgSXQgbXVzdA0KICAgICAgICAgICAgICAgIGluaXRpYXRlIGFub3RoZXIgUERQLUNvbnRleHQg YWN0aXZhdGlvbiBpbiBhZGRpdGlvbiB0bw0KICAgICAgICAgICAgICAgIHRoZSBvbmUgYWxyZWFk eSBhY3RpdmF0ZWQgZm9yIGEgZ2l2ZW4gQVBOIChBY2Nlc3MgUG9pbnQNCiAgICAgICAgICAgICAg ICBOYW1lKS4NCg0KICAgICAgICAgICAgICogIElmIHRoZSBzdWJzY3JpcHRpb24gZGF0YSBvciBu ZXR3b3JrIGNvbmZpZ3VyYXRpb24gYWxsb3dzDQogICAgICAgICAgICAgICAgb25seSBvbmUgSVAg YWRkcmVzcyBmYW1pbHkgKElQdjQgb3IgSVB2NiksIHRoZSBjZWxsdWxhcg0KICAgICAgICAgICAg ICAgIGhvc3QgbXVzdCBub3QgcmVxdWVzdCBhIHNlY29uZCBQRFAtQ29udGV4dCB0byB0aGUgc2Ft ZQ0KICAgICAgICAgICAgICAgIEFQTiBmb3IgdGhlIG90aGVyIElQIGFkZHJlc3MgZmFtaWx5Lg0K DQogICAgICAgICAgICAgVGhlIHRleHQgYWJvdmUgZm9jdXNlcyBvbiB0aGUgc3BlY2lmaWNhdGlv biBwYXJ0IHdoaWNoDQogICAgICAgICAgICAgZXhwbGFpbnMgdGhlIGJlaGF2aW9yIGZvciByZXF1 ZXN0aW5nIElQdjYtcmVsYXRlZCBQRFAtDQogICAgICAgICAgICAgQ29udGV4dChzKS4gIFVuZGVy c3RhbmRpbmcgdGhpcyBiZWhhdmlvciBpcyBpbXBvcnRhbnQgdG8NCiAgICAgICAgICAgICBhdm9p ZCBoYXZpbmcgYnJva2VuIElQdjYgaW1wbGVtZW50YXRpb25zIGluIGNlbGx1bGFyDQogICAgICAg ICAgICAgZGV2aWNlcy4NCg0KDQogICBDX1JFQyMzOiAgVGhlIGNlbGx1bGFyIGhvc3QgbXVzdCBz dXBwb3J0IHRoZSBQQ08gKFByb3RvY29sDQogICAgICAgICAgICAgQ29uZmlndXJhdGlvbiBPcHRp b25zKSBbVFMuMjQwMDg8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9w cy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTgjcmVmLVRTLjI0MDA4Pl0gdG8gcmV0cmlldmUgdGhl IElQdjYNCiAgICAgICAgICAgICBhZGRyZXNzKGVzKSBvZiB0aGUgUmVjdXJzaXZlIEROUyBzZXJ2 ZXIocykuDQoNCiAgICAgICAgICAgICAgICBJbi1iYW5kIHNpZ25hbGluZyBpcyBhIGNvbnZlbmll bnQgbWV0aG9kIHRvIGluZm9ybSB0aGUNCiAgICAgICAgICAgICAgICBjZWxsdWxhciBob3N0IGFi b3V0IHZhcmlvdXMgc2VydmljZXMsIGluY2x1ZGluZyBETlMNCiAgICAgICAgICAgICAgICBzZXJ2 ZXIgaW5mb3JtYXRpb24uICBJdCBkb2VzIG5vdCByZXF1aXJlIGFueSBzcGVjaWZpYw0KICAgICAg ICAgICAgICAgIHByb3RvY29sIHRvIGJlIHN1cHBvcnRlZCBhbmQgaXQgaXMgYWxyZWFkeSBkZXBs b3llZCBpbg0KICAgICAgICAgICAgICAgIElQdjQgY2VsbHVsYXIgbmV0d29ya3MgdG8gY29udmV5 IHN1Y2ggRE5TIGluZm9ybWF0aW9uLg0KDQogICBDX1JFQyM0OiAgVGhlIGNlbGx1bGFyIGhvc3Qg bXVzdCBzdXBwb3J0IElQdjYgYXdhcmUgVHJhZmZpYyBGbG93DQogICAgICAgICAgICAgVGVtcGxh dGVzIChURlQpIFtUUy4yNDAwODxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xOCNyZWYtVFMuMjQwMDg+XS4NCg0KICAgICAg ICAgICAgICAgIFRyYWZmaWMgRmxvdyBUZW1wbGF0ZXMgYXJlIGVtcGxveWluZyBhIHBhY2tldCBm aWx0ZXIgdG8NCiAgICAgICAgICAgICAgICBjb3VwbGUgYW4gSVAgdHJhZmZpYyB3aXRoIGEgUERQ LUNvbnRleHQuICBUaHVzIGENCiAgICAgICAgICAgICAgICBkZWRpY2F0ZWQgUERQLUNvbnRleHQg YW5kIHJhZGlvIHJlc291cmNlcyBjYW4gYmUNCiAgICAgICAgICAgICAgICBwcm92aWRlZCBieSB0 aGUgY2VsbHVsYXIgbmV0d29yayBmb3IgY2VydGFpbiBJUCB0cmFmZmljLg0KDQoNCjIuIFN1cHBv cnQgNDY0eGxhdC4NCltNZWRdIOKAnDQ2NHhsYXTigJ0gaXMgbWVhbmluZ2xlc3MgZm9yIHRoZSBk ZXZpY2U7LSkgYnV0IEkgZ290IHlvdXIgcG9pbnQuIFRoaXMgaXMgY292ZXJlZCBieSB0aGUgZm9s bG93aW5nIHR3byBpdGVtczoNCg0KDQogICBDX1JFQyM4OiAgSW4gb3JkZXIgdG8gZW5zdXJlIElQ djQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQdjYtb25seQ0KDQogICAgICAgICAgICAgZGVw bG95bWVudCBjb250ZXh0LCB0aGUgY2VsbHVsYXIgaG9zdCBzaG91bGQgc3VwcG9ydCBhDQoNCiAg ICAgICAgICAgICBtZXRob2QgdG8gbG9jYWxseSBjb25zdHJ1Y3QgSVB2NC1lbWJlZGRlZCBJUHY2 IGFkZHJlc3Nlcw0KDQogICAgICAgICAgICAgW1JGQzYwNTI8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjA1Mj5dLiAgQSBtZXRob2QgdG8gbGVhcm4gUFJFRklYNjQgc2hvdWxkIGJlIHN1 cHBvcnRlZA0KDQogICAgICAgICAgICAgYnkgdGhlIGNlbGx1bGFyIGhvc3QuDQoNCg0KDQogICAg ICAgICAgICAgICAgVGhpcyBzb2x2ZXMgdGhlIGlzc3VlIHdoZW4gYXBwbGljYXRpb25zIHVzZSBJ UHY0DQoNCiAgICAgICAgICAgICAgICByZWZlcnJhbHMgb24gSVB2Ni1vbmx5IGFjY2VzcyBuZXR3 b3Jrcy4NCg0KDQoNCiAgICAgICAgICAgICAgICBJbiBQQ1AtYmFzZWQgZW52aXJvbm1lbnRzLCBj ZWxsdWxhciBob3N0cyBzaG91bGQgZm9sbG93DQoNCiAgICAgICAgICAgICAgICBbUkZDNzIyNTxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjI1Pl0gdG8gbGVhcm4gdGhlIElQdjYgUHJl Zml4IHVzZWQgYnkgYW4gdXBzdHJlYW0NCg0KICAgICAgICAgICAgICAgIFBDUC1jb250cm9sbGVk IE5BVDY0IGRldmljZS4gIElmIFBDUCBpcyBub3QgZW5hYmxlZCwgdGhlDQoNCiAgICAgICAgICAg ICAgICBjZWxsdWxhciBob3N0IHNob3VsZCBpbXBsZW1lbnQgdGhlIG1ldGhvZCBzcGVjaWZpZWQg aW4NCg0KICAgICAgICAgICAgICAgIFtSRkM3MDUwPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcwNTA+XSB0byByZXRyaWV2ZSB0aGUgUFJFRklYNjQuDQoNCg0KDQogICBDX1JFQyM5OiAg SW4gb3JkZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQdjYtb25s eQ0KDQogICAgICAgICAgICAgZGVwbG95bWVudCBjb250ZXh0LCB0aGUgY2VsbHVsYXIgaG9zdCBz aG91bGQgaW1wbGVtZW50IHRoZQ0KDQogICAgICAgICAgICAgQ3VzdG9tZXIgU2lkZSBUcmFuc2xh dG9yIChDTEFULCBbUkZDNjg3NzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODc3Pl0p IGZ1bmN0aW9uIGluDQoNCiAgICAgICAgICAgICBjb21wbGlhbmNlIHdpdGggW1JGQzYwNTI8aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1Mj5dW1JGQzYxNDVdW1JGQzYxNDY8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0Nj5dLg0KDQoNCg0KICAgICAgICAgICAgICAgIENM QVQgZnVuY3Rpb24gaW4gdGhlIGNlbGx1bGFyIGhvc3QgYWxsb3dzIGZvciBJUHY0LW9ubHkNCg0K ICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uIGFuZCBJUHY0LXJlZmVyYWxzIHRvIHdvcmsgb24g YW4gSVB2Ni1vbmx5DQoNCiAgICAgICAgICAgICAgICBjb25uZWN0aXZpdHkuICBUaGUgbW9yZSBh cHBsaWNhdGlvbnMgYXJlIGFkZHJlc3MgZmFtaWx5DQoNCiAgICAgICAgICAgICAgICBpbmRlcGVu ZGVudCwgdGhlIGxlc3MgQ0xBVCBmdW5jdGlvbiBpcyBzb2xpY2l0ZWQuICBDTEFUDQoNCiAgICAg ICAgICAgICAgICBmdW5jdGlvbiByZXF1aXJlcyBhIE5BVDY0IGNhcGFiaWxpdHkgW1JGQzYxNDY8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0Nj5dIGluIHRoZQ0KDQogICAgICAgICAg ICAgICAgbmV0d29yay4NCg0KDQoNCiAgICAgICAgICAgICAgICBUaGUgY2VsbHVsYXIgaG9zdCBz aG91bGQgb25seSBpbnZva2UgdGhlIENMQVQgaW4gdGhlDQoNCiAgICAgICAgICAgICAgICBhYnNl bmNlIG9mIHRoZSBJUHY0IGNvbm5lY3Rpdml0eSBvbiB0aGUgY2VsbHVsYXIgc2lkZSwNCg0KICAg ICAgICAgICAgICAgIGkuZS4sIHdoZW4gdGhlIG5ldHdvcmsgZG9lcyBub3QgYXNzaWduIGFuIElQ djQgYWRkcmVzcw0KDQogICAgICAgICAgICAgICAgb24gdGhlIGNlbGx1bGFyIGludGVyZmFjZS4g IE5vdGUsIE5BVDY0IGFzc3VtZXMgYW4NCg0KICAgICAgICAgICAgICAgIElQdjYtb25seSBtb2Rl IFtSRkM2MTQ2PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDY+XS4NCg0KDQoNCiAg ICAgICAgICAgICAgICBUaGUgSVB2NCBTZXJ2aWNlIENvbnRpbnVpdHkgUHJlZml4IHVzZWQgYnkg Q0xBVCBpcw0KDQogICAgICAgICAgICAgICAgZGVmaW5lZCBpbiBbUkZDNzMzNTxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3MzM1Pl0uDQoNCg0KDQogICAgICAgICAgICAgICAgQ0xBVCBh bmQvb3IgTkFUNjQgZG8gbm90IGludGVyZmVyZSB3aXRoIG5hdGl2ZSBJUHY2DQoNCiAgICAgICAg ICAgICAgICBjb21tdW5pY2F0aW9ucy4NCg0KDQoNCg== --_000_fdc7ab8c4f6343eba77b4764f24d9486OPEXCLILH01corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsN CgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUt bmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uZ3JleQ0KCXttc28tc3R5 bGUtbmFtZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IExvcmVuem8gQ29saXR0 aTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAxOSBmw6l2cmllciAyMDE1IDExOjMz PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCSU5FVCBEYXZpZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0KPGI+T2JqZXQmbmJzcDs6 PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBs YXN0IGNhbGwtICZxdW90O2hhcm1mdWxseSBicm9hZCZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IEZlYiAxOSwgMjAxNSBhdCAxOjM5IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJpbmV0 QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5iaW5ldEBvcmFuZ2UuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJy Pg0KW0RCXSBDb3VsZCB5b3UgYmUgbW9yZSBleHBsaWNpdCBhbmQgaW5kaWNhdGUgd2hpY2ggZmVh dHVyZXMgYXJlIG5vdCB1c2VmdWwgaW4gdGhlIGRyYWZ0ID8gQXMgeW91IGNhbiBtZW50aW9uIGl0 LCBhbGwgZmVhdHVyZXMgYXJlIG5vdCBpbmRpY2F0ZWQgYXMgbWFuZGF0b3J5IGluIHRoZSBkcmFm dCBzbyBJIGRvIG5vdCBjbGVhcmx5IHVuZGVyc3RhbmQgaG93IHRoaXMgZG9jdW1lbnQgY29uZmxp Y3RzIHdpdGggd2hhdCB5b3Ugc2F5IGNvbnNpZGVyaW5nDQogdGhhdCB0aGUgZ29hbCBmb3IgdGhl IG9wZXJhdG9yIGlzIHRvIHByb3ZpZGUgYXQgbGVhc3QgdGhlIHNhbWUgc2VydmljZSBhY2Nlc3Mg Zm9yIHVzZXJzIHdpdGggSVB2NiBjb25uZWN0aXZpdHkgdGhhbiBmb3IgdXNlcnMgd2l0aCBJUHY0 IGNvbm5lY3Rpdml0eSB3aGF0ZXZlciB0aGUgc3RyYXRlZ3kgcmV0YWluZWQgYnkgdGhlIG9wZXJh dG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgdGhlIGdvYWwgb2YgdGhlIGRvY3VtZW50IGlzICZxdW90O3RvIHByb3ZpZGUgYXQgbGVhc3Qg dGhlIHNhbWUgc2VydmljZSBhY2Nlc3MgZm9yIHVzZXJzIHdpdGggSVB2NiBjb25uZWN0aXZpdHkg dGhhbiBmb3IgdXNlcnMgd2l0aCBJUHY0IGNvbm5lY3Rpdml0eSB3aGF0ZXZlciB0aGUgc3RyYXRl Z3kgcmV0YWluZWQgYnkgdGhlIG9wZXJhdG9yJnF1b3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5b TWVkXSBUaGlzIGlzIG9uZSBvZiB0aGUgZ29hbHMgb2YgdGhlIEktRCBub3QgdGhlIG9ubHkgb25l LiBlLmcuLCB0aGUgSS1EIGxpc3RzIGZlYXR1cmVzIHRoYXQgYXJlIG5vdCBjb3ZlcmVkIGluIFJG QzcwNjYgYW5kIFJGQzY0MzQ6IGUuZy4sIHByZWZpeCBkZWxlZ2F0aW9uDQogb3IgcHJlZml4IHNo YXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhlbiB5b3UgY2FuIHJl ZHVjZSB0aGUgZG9jdW1lbnQgdG8gdHdvIHJlcXVpcmVtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSeKAmW0gYWZyYWlkIGNvbXBh Y3RpbmcgdGhlIHJlY29tbWVuZGF0aW9ucyBpcyBub3QgaGVscGZ1bC4gRm9yIGV4YW1wbGUsIHRo ZXNlIHR3byBpdGVtcyBhcmUgY292ZXJlZCBhcyBmb2xsb3dzIGluIHRoZSBJLUQgZm9yIHRoZSBz YWtlIG9mIGRldGVybWluaXN0aWMNCiBiZWhhdmlvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEuIFN1cHBvcnQgYm90aCBJUHY0djYgYW5kIElQdjYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5b TWVkXSBUaGVzZSBpdGVtcyBjb3ZlciB0aGlzIDE8c3VwPnN0PC9zdXA+IHBvaW50OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ19SRUMjMTombmJz cDsgSW4gb3JkZXIgdG8gYWxsb3cgZWFjaCBvcGVyYXRvciB0byBzZWxlY3QgdGhlaXIgb3duPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyYXRlZ3kgcmVnYXJkaW5nIElQdjYgaW50cm9kdWN0 aW9uLCB0aGUgY2VsbHVsYXIgaG9zdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11c3Qgc3Vw cG9ydCBib3RoIElQdjYgYW5kIElQdjR2NiBQRFAtQ29udGV4dHMgWzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUtMTgjcmVmLVRTLjIzMDYwIj48c3BhbiBsYW5nPSJFTi1VUyI+VFMu MjMwNjA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSVB2NCwgSVB2NiBvciBJUHY0djYgUERQLUNvbnRleHQgcmVxdWVz dCBhY2NlcHRhbmNlIGRlcGVuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvbiB0aGUgY2Vs bHVsYXIgbmV0d29yayBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgQ19SRUMjMjombmJzcDsgVGhlIGNlbGx1bGFyIGhvc3QgbXVzdCBjb21wbHkg d2l0aCB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE4I3JlZi1UUy4yMzA2MCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRTLjIzMDYwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5dDQogWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTgjcmVmLVRTLjIz NDAxIj48c3BhbiBsYW5nPSJFTi1VUyI+VFMuMjM0MDE8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPl0NCiBbPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0x OCNyZWYtVFMuMjQwMDgiPjxzcGFuIGxhbmc9IkVOLVVTIj5UUy4yNDAwODwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XQ0KIGZvciByZXF1ZXN0aW5nIGEgUERQLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnRleHQgdHlwZS4mbmJzcDsgSW4gcGFydGljdWxhciwg dGhlIGNlbGx1bGFyIGhvc3QgbXVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3Qg YnkgZGVmYXVsdCBhbiBJUHY2IFBEUC1Db250ZXh0IGlmIHRoZSBjZWxsdWxhciBob3N0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgSVB2Ni1vbmx5IGFuZCByZXF1ZXN0IGFuIElQdjR2NiBQ RFAtQ29udGV4dCBpZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjZWxsdWxhciBob3N0 IGlzIGR1YWwtc3RhY2sgb3Igd2hlbiB0aGUgY2VsbHVsYXIgaG9zdCBpczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5vdCBhd2FyZSBvZiBjb25uZWN0aXZpdHkgdHlwZXMgcmVxdWVzdGVkIGJ5 IGRldmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0ZWQgdG8gaXQgKGUuZy4s IGNlbGx1bGFyIGhvc3Qgd2l0aCBMQU4gY2FwYWJpbGl0aWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YXMgZGlzY3Vzc2VkIGluIDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxl LTE4I3NlY3Rpb24tMyI+DQpTZWN0aW9uIDM8L2E+KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKiZuYnNwOyBJZiB0aGUgcmVxdWVzdGVkIElQdjR2NiBQRFAtQ29udGV4dCBpcyBub3Qg c3VwcG9ydGVkIGJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhlIG5ldHdvcmssIGJ1dCBJUHY0IGFuZCBJUHY2IFBEUCB0eXBlcyBhcmUgYWxsb3dlZCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVuIHRoZSBjZWxsdWxh ciBob3N0IHdpbGwgYmUgY29uZmlndXJlZCB3aXRoIGFuIElQdjQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzIG9yIGFuIElQdjYgcHJlZml4IGJ5IHRo ZSBuZXR3b3JrLiZuYnNwOyBJdCBtdXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW5pdGlhdGUgYW5vdGhlciBQRFAtQ29udGV4dCBhY3RpdmF0aW9uIGluIGFk ZGl0aW9uIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl IG9uZSBhbHJlYWR5IGFjdGl2YXRlZCBmb3IgYSBnaXZlbiBBUE4gKEFjY2VzcyBQb2ludDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbWUpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBJZiB0aGUgc3Vic2NyaXB0 aW9uIGRhdGEgb3IgbmV0d29yayBjb25maWd1cmF0aW9uIGFsbG93czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ubHkgb25lIElQIGFkZHJlc3MgZmFtaWx5IChJ UHY0IG9yIElQdjYpLCB0aGUgY2VsbHVsYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBob3N0IG11c3Qgbm90IHJlcXVlc3QgYSBzZWNvbmQgUERQLUNvbnRleHQg dG8gdGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB UE4gZm9yIHRoZSBvdGhlciBJUCBhZGRyZXNzIGZhbWlseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSB0ZXh0IGFib3ZlIGZvY3VzZXMgb24gdGhlIHNwZWNp ZmljYXRpb24gcGFydCB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2V4cGxhaW5zIHRo ZSBiZWhhdmlvciBmb3IgcmVxdWVzdGluZyBJUHY2LXJlbGF0ZWQgUERQLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENvbnRleHQocykuJm5ic3A7IFVuZGVyc3RhbmRpbmcgdGhpcyBiZWhhdmlv ciBpcyBpbXBvcnRhbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdm9pZCBoYXZpbmcg YnJva2VuIElQdjYgaW1wbGVtZW50YXRpb25zIGluIGNlbGx1bGFyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ19SRUMjMzombmJzcDsgVGhlIGNl bGx1bGFyIGhvc3QgbXVzdCBzdXBwb3J0IHRoZSBQQ08gKFByb3RvY29sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQ29uZmlndXJhdGlvbiBPcHRpb25zKSBbPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZS0xOCNyZWYtVFMuMjQwMDgiPjxzcGFuIGxhbmc9IkVOLVVTIj5UUy4yNDAw ODwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XQ0KIHRvIHJldHJpZXZl IHRoZSBJUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRkcmVzcyhlcykgb2YgdGhlIFJl Y3Vyc2l2ZSBETlMgc2VydmVyKHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4tYmFuZCBzaWduYWxpbmcgaXMgYSBjb252ZW5p ZW50IG1ldGhvZCB0byBpbmZvcm0gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY2VsbHVsYXIgaG9zdCBhYm91dCB2YXJpb3VzIHNlcnZpY2VzLCBpbmNsdWRp bmcgRE5TPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVy IGluZm9ybWF0aW9uLiZuYnNwOyBJdCBkb2VzIG5vdCByZXF1aXJlIGFueSBzcGVjaWZpYzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3RvY29sIHRvIGJlIHN1 cHBvcnRlZCBhbmQgaXQgaXMgYWxyZWFkeSBkZXBsb3llZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElQdjQgY2VsbHVsYXIgbmV0d29ya3MgdG8gY29udmV5 IHN1Y2ggRE5TIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgQ19SRUMjNDombmJzcDsgVGhlIGNlbGx1bGFyIGhvc3QgbXVzdCBzdXBwb3J0IElQdjYg YXdhcmUgVHJhZmZpYyBGbG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGVtcGxhdGVzIChU RlQpIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTE4I3JlZi1UUy4yNDAwOCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRTLjI0MDA4PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVHJhZmZpYyBGbG93IFRlbXBsYXRlcyBhcmUgZW1wbG95aW5nIGEg cGFja2V0IGZpbHRlciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvdXBsZSBhbiBJUCB0cmFmZmljIHdpdGggYSBQRFAtQ29udGV4dC4mbmJzcDsgVGh1cyBh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVkaWNhdGVkIFBE UC1Db250ZXh0IGFuZCByYWRpbyByZXNvdXJjZXMgY2FuIGJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZWQgYnkgdGhlIGNlbGx1bGFyIG5ldHdvcmsg Zm9yIGNlcnRhaW4gSVAgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gU3VwcG9ydCA0NjR4bGF0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSDigJw0NjR4bGF04oCdIGlzIG1lYW5pbmdsZXNzIGZvciB0aGUgZGV2aWNlOy0p IGJ1dCBJIGdvdCB5b3VyIHBvaW50LiBUaGlzIGlzIGNvdmVyZWQgYnkgdGhlIGZvbGxvd2luZyB0 d28gaXRlbXM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBDX1JFQyM4OiZuYnNw OyBJbiBvcmRlciB0byBlbnN1cmUgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkgaW4gYW4gSVB2Ni1v bmx5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZGVwbG95bWVudCBjb250ZXh0LCB0aGUgY2VsbHVsYXIgaG9zdCBzaG91bGQg c3VwcG9ydCBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbWV0aG9kIHRvIGxvY2FsbHkgY29uc3RydWN0IElQdjQtZW1iZWRk ZWQgSVB2NiBhZGRyZXNzZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYwNTIiIHRpdGxlPSImcXVvdDtJUHY2IEFkZHJlc3Npbmcgb2YgSVB2 NC9JUHY2IFRyYW5zbGF0b3JzJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjA1Mjwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPl0uJm5ic3A7IEEgbWV0aG9kIHRvIGxlYXJuIFBSRUZJ WDY0IHNob3VsZCBiZSBzdXBwb3J0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieSB0aGUgY2VsbHVsYXIgaG9zdC48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgc29sdmVzIHRoZSBpc3N1ZSB3aGVuIGFwcGxpY2F0 aW9ucyB1c2UgSVB2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZmVycmFscyBvbiBJUHY2 LW9ubHkgYWNjZXNzIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gUENQLWJh c2VkIGVudmlyb25tZW50cywgY2VsbHVsYXIgaG9zdHMgc2hvdWxkIGZvbGxvdzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzIyNSIgdGl0bGU9IiZxdW90O0Rpc2NvdmVyaW5nIE5BVDY0IElQdjYgUHJlZml4ZXMg VXNpbmcgdGhlIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSZxdW90OyI+PHNwYW4gbGFuZz0i RU4tVVMiPlJGQzcyMjU8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj5dIHRvIGxlYXJuIHRo ZSBJUHY2IFByZWZpeCB1c2VkIGJ5IGFuIHVwc3RyZWFtPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUENQLWNvbnRyb2xsZWQgTkFUNjQgZGV2aWNlLiZuYnNwOyBJZiBQQ1AgaXMgbm90IGVuYWJs ZWQsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNlbGx1bGFyIGhvc3Qgc2hvdWxkIGlt cGxlbWVudCB0aGUgbWV0aG9kIHNwZWNpZmllZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA1MCIgdGl0 bGU9IiZxdW90O0Rpc2NvdmVyeSBvZiB0aGUgSVB2NiBQcmVmaXggVXNlZCBmb3IgSVB2NiBBZGRy ZXNzIFN5bnRoZXNpcyZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzcwNTA8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj5dIHRvIHJldHJpZXZlIHRoZSBQUkVGSVg2NC48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IENfUkVD Izk6Jm5ic3A7IEluIG9yZGVyIHRvIGVuc3VyZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSBpbiBh biBJUHY2LW9ubHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBkZXBsb3ltZW50IGNvbnRleHQsIHRoZSBjZWxsdWxhciBob3N0 IHNob3VsZCBpbXBsZW1lbnQgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ3VzdG9tZXIgU2lkZSBUcmFuc2xhdG9yIChD TEFULCBbPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4Nzci IHRpdGxlPSImcXVvdDs0NjRYTEFUOiBDb21iaW5hdGlvbiBvZiBTdGF0ZWZ1bCBhbmQgU3RhdGVs ZXNzIFRyYW5zbGF0aW9uJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjg3Nzwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iRU4tVVMiPl0pIGZ1bmN0aW9uIGluPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tcGxpYW5jZSB3 aXRoIFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1MiIg dGl0bGU9IiZxdW90O0lQdjYgQWRkcmVzc2luZyBvZiBJUHY0L0lQdjYgVHJhbnNsYXRvcnMmcXVv dDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM2MDUyPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1V UyI+XVtSRkM2MTQ1XVs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjE0NiIgdGl0bGU9IiZxdW90O1N0YXRlZnVsIE5BVDY0OiBOZXR3b3JrIEFkZHJlc3MgYW5k IFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGllbnRzIHRvIElQdjQgU2VydmVycyZx dW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzYxNDY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIj5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0xBVCBmdW5jdGlvbiBpbiB0aGUgY2Vs bHVsYXIgaG9zdCBhbGxvd3MgZm9yIElQdjQtb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFwcGxpY2F0aW9uIGFuZCBJUHY0LXJlZmVyYWxzIHRvIHdvcmsgb24gYW4gSVB2Ni1vbmx5PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ubmVjdGl2aXR5LiZuYnNwOyBUaGUgbW9yZSBhcHBs aWNhdGlvbnMgYXJlIGFkZHJlc3MgZmFtaWx5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5k ZXBlbmRlbnQsIHRoZSBsZXNzIENMQVQgZnVuY3Rpb24gaXMgc29saWNpdGVkLiZuYnNwOyBDTEFU PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnVuY3Rpb24gcmVxdWlyZXMgYSBOQVQ2NCBjYXBh YmlsaXR5IFs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0 NiIgdGl0bGU9IiZxdW90O1N0YXRlZnVsIE5BVDY0OiBOZXR3b3JrIEFkZHJlc3MgYW5kIFByb3Rv Y29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGllbnRzIHRvIElQdjQgU2VydmVycyZxdW90OyI+ PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzYxNDY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj5d IGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldHdvcmsuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgY2VsbHVsYXIgaG9zdCBzaG91bGQgb25seSBpbnZva2UgdGhlIENMQVQg aW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWJzZW5jZSBvZiB0aGUgSVB2NCBjb25u ZWN0aXZpdHkgb24gdGhlIGNlbGx1bGFyIHNpZGUsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 aS5lLiwgd2hlbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhc3NpZ24gYW4gSVB2NCBhZGRyZXNzPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb24gdGhlIGNlbGx1bGFyIGludGVyZmFjZS4mbmJzcDsg Tm90ZSwgTkFUNjQgYXNzdW1lcyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5J UHY2LW9ubHkgbW9kZSBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0 NiIgdGl0bGU9IiZxdW90O1N0YXRlZnVsIE5BVDY0OiBOZXR3b3JrIEFkZHJlc3MgYW5kIFByb3Rv Y29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGllbnRzIHRvIElQdjQgU2VydmVycyZxdW90OyI+ UkZDNjE0NjwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgSVB2NCBTZXJ2aWNlIENvbnRpbnVp dHkgUHJlZml4IHVzZWQgYnkgQ0xBVCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmlu ZWQgaW4gWzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MzM1 IiB0aXRsZT0iJnF1b3Q7SVB2NCBTZXJ2aWNlIENvbnRpbnVpdHkgUHJlZml4JnF1b3Q7Ij48c3Bh biBsYW5nPSJFTi1VUyI+UkZDNzMzNTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPl0uPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDTEFUIGFuZC9vciBOQVQ2NCBkbyBub3QgaW50ZXJmZXJl IHdpdGggbmF0aXZlIElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+Y29tbXVu aWNhdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_fdc7ab8c4f6343eba77b4764f24d9486OPEXCLILH01corporateadr_-- From nobody Thu Feb 19 04:31:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E151A8A6E for ; Thu, 19 Feb 2015 04:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-TKr7_AchxS for ; Thu, 19 Feb 2015 04:31:25 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F8E1A889C for ; Thu, 19 Feb 2015 04:31:24 -0800 (PST) Received: from DM2PR0401MB1069.namprd04.prod.outlook.com (25.160.98.20) by DM2PR0401MB1072.namprd04.prod.outlook.com (25.160.98.23) with Microsoft SMTP Server (TLS) id 15.1.87.18; Thu, 19 Feb 2015 12:31:07 +0000 Received: from DM2PR0401MB1069.namprd04.prod.outlook.com ([25.160.98.20]) by DM2PR0401MB1069.namprd04.prod.outlook.com ([25.160.98.20]) with mapi id 15.01.0087.013; Thu, 19 Feb 2015 12:31:07 +0000 From: Dave Michaud To: "mohamed.boucadair@orange.com" , "Lorenzo Colitti" , BINET David IMT/OLN Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAbl5AwAAGrn8AACK8HgAAAYbbgAAShBCAACm1R4AAE1sVAAAleKCAAAOCioD//7EhAA== Date: Thu, 19 Feb 2015 12:31:07 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [99.234.22.8] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0401MB1072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0401MB1072; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(377454003)(199003)(87936001)(83506001)(19580405001)(19580395003)(74826001)(2656002)(99286002)(105586002)(106356001)(19625215002)(101416001)(97736003)(62966003)(77156002)(1720100001)(92566002)(230783001)(93886004)(19617315012)(2950100001)(2900100001)(2501002)(68736005)(15975445007)(102836002)(16236675004)(50986999)(76176999)(54356999)(122556002)(40100003)(46102003)(19300405004)(64706001)(86362001)(66066001)(19273905006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1072; H:DM2PR0401MB1069.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D10B3F461A731davemichaudrcirogerscom_" MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2015 12:31:07.1895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1072 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:31:30 -0000 --_000_D10B3F461A731davemichaudrcirogerscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Mohamed. The goal of the document is broader than to ensure sa= me service set in IPv6 than in IPv4 but to provide a base set of practical = requirements to actually make it happen. As an operator, having IPv4v6, IPv6 and 464XLAT is enough to cover the simp= lest case (user browsing or using an app that connects to an IPv4 endpoint,= while on the home network). When you start considering roaming, tethering, migration strategy, grey mar= ket devices and service evolution, the situation becomes slightly more comp= lex. These variables are part of the core offering and must be handled from= day one. As an engineer, I will get NO support from my executives if any o= f the previous item is broken by one of my solutions. In the mobile world, there are 2 classes of operator, the big ones that can= get whatever configuration/personalization they want from their UE vendors= and the others. For the others, having a set of common requirements goes a= long way in helping immediate transition into the IPv6 world. This is directly in line with the v6ops charter: The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. Dave Michaud Sr. Architect Mobility =96 Access Networks & IP Network Services Network Technology | Rogers Communications dave.michaud@rci.rogers.com | tel: +1 6= 47.747.9442 | mobile: +1 416.219.5531 From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Thursday, February 19, 2015 at 07:13 To: Lorenzo Colitti >, BINET = IMT/OLN > Cc: IPv6 WG > Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "har= mfully broad"? Hi Lorenzo, Please see inline. Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Lorenzo Colitti Envoy=E9 : jeudi 19 f=E9vrier 2015 11:33 =C0 : BINET David IMT/OLN Cc : IPv6 Ops WG (v6ops@ietf.org) Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harm= fully broad"? On Thu, Feb 19, 2015 at 1:39 AM, > wrote: [DB] Could you be more explicit and indicate which features are not useful = in the draft ? As you can mention it, all features are not indicated as man= datory in the draft so I do not clearly understand how this document confli= cts with what you say considering that the goal for the operator is to prov= ide at least the same service access for users with IPv6 connectivity than = for users with IPv4 connectivity whatever the strategy retained by the oper= ator. If the goal of the document is "to provide at least the same service access= for users with IPv6 connectivity than for users with IPv4 connectivity wha= tever the strategy retained by the operator" [Med] This is one of the goals of the I-D not the only one. e.g., the I-D l= ists features that are not covered in RFC7066 and RFC6434: e.g., prefix del= egation or prefix sharing. then you can reduce the document to two requirements: [Med] I=92m afraid compacting the recommendations is not helpful. For examp= le, these two items are covered as follows in the I-D for the sake of deter= ministic behavior. 1. Support both IPv4v6 and IPv6. [Med] These items cover this 1st point: C_REC#1: In order to allow each operator to select their own strategy regarding IPv6 introduction, the cellular host must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends on the cellular network configuration. C_REC#2: The cellular host must comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for r= equesting a PDP- Context type. In particular, the cellular host must request by default an IPv6 PDP-Context if the cellular host is IPv6-only and request an IPv4v6 PDP-Context if the cellular host is dual-stack or when the cellular host is not aware of connectivity types requested by devices connected to it (e.g., cellular host with LAN capabilities as discussed in Section 3): * If the requested IPv4v6 PDP-Context is not supported by the network, but IPv4 and IPv6 PDP types are allowed, then the cellular host will be configured with an IPv4 address or an IPv6 prefix by the network. It must initiate another PDP-Context activation in addition to the one already activated for a given APN (Access Point Name). * If the subscription data or network configuration allows only one IP address family (IPv4 or IPv6), the cellular host must not request a second PDP-Context to the same APN for the other IP address family. The text above focuses on the specification part which explains the behavior for requesting IPv6-related PDP- Context(s). Understanding this behavior is important to avoid having broken IPv6 implementations in cellular devices. C_REC#3: The cellular host must support the PCO (Protocol Configuration Options) [TS.24008] to retrieve the IPv6 address(es) of the Recursive DNS server(s). In-band signaling is a convenient method to inform the cellular host about various services, including DNS server information. It does not require any specific protocol to be supported and it is already deployed in IPv4 cellular networks to convey such DNS information. C_REC#4: The cellular host must support IPv6 aware Traffic Flow Templates (TFT) [TS.24008]. Traffic Flow Templates are employing a packet filter to couple an IP traffic with a PDP-Context. Thus a dedicated PDP-Context and radio resources can be provided by the cellular network for certain IP traffic. 2. Support 464xlat. [Med] =93464xlat=94 is meaningless for the device;-) but I got your point. = This is covered by the following two items: C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular host should support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to le= arn PREFIX64 should be supported by the cellular host. This solves the issue when applications use IPv4 referrals on IPv6-only access networks. In PCP-based environments, cellular hosts should follow [RFC7225] to learn the = IPv6 Prefix used by an upstream PCP-controlled NAT64 device. If PCP is not enabled, the cellular host should implement the method specified in [RFC7050] to retrieve t= he PREFIX64. C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular host should implement the Customer Side Translator (CLAT, [RFC6877]) function in compliance with [RFC6052][= RFC6145][RFC6146]. CLAT function in the cellular host allows for IPv4-only application and IPv4-referals to work on an IPv6-only connectivity. The more applications are address family independent, the less CLAT function is solicited. CLAT function requires a NAT64 capability [RFC6146] in the network. The cellular host should only invoke the CLAT in the absence of the IPv4 connectivity on the cellular side, i.e., when the network does not assign an IPv4 address on the cellular interface. Note, NAT64 assumes an IPv6-only mode [RFC6146= ]. The IPv4 Service Continuity Prefix used by CLAT is defined in [RFC7335]. CLAT and/or NAT64 do not interfere with native IPv6 communications. ________________________________ This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l=92avis pub= li=E9 =E0 www.rogers.com/aviscourriel ________________________________ --_000_D10B3F461A731davemichaudrcirogerscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <54EF0D9E077D09409047348489875D2B@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
I agree with Mohamed. The goal of the document is broader than to ensu= re same service set in IPv6 than in IPv4 but to provide a base set of pract= ical requirements to actually make it happen.

As an operator, having IPv4v6, IPv6 and 464XLAT is enough to cover the= simplest case (user browsing or using an app that connects to an IPv4 endp= oint, while on the home network).

When you start considering roaming, tethering, migration strategy, gre= y market devices and service evolution, the situation becomes slightly more= complex. These variables are part of the core offering and must be handled= from day one. As an engineer, I will get NO support from my executives if any of the previous item is brok= en by one of my solutions.

In the mobile world, there are 2 classes of operator, the big ones tha= t can get whatever configuration/personalization they want from their UE ve= ndors and the others. For the others, having a set of common requirements g= oes a long way in helping immediate transition into the IPv6 world.

This is directly in line with the v6ops charter:

The IPv6 Operations Working Group (v6ops) d= evelops guidelines for the
operation of a shared IPv4/IPv6 Internet and pro= vides operational
guidance on how to deploy IPv6 into existing IPv= 4-only networks,
as well as into new network installations.

The main focus of the v6ops WG is to look at the= immediate
deployment issues; more advanced stages of deplo= yment and transition
are a lower priority.




Dave Michaud
Sr. Architect Mobility =96 Access Networks & IP Network Services
Network Technology | Rogers Communications&= nbsp;
dave.michaud@rci.rogers.c= om | tel: +1 647.747.9442 | mobile: +1 416.219.5531=


From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Thursday, February 19, 2015 a= t 07:13
To: Lorenzo Colitti <lorenzo@google.com>, BINET IMT/OLN <david.binet@orange.com>
Cc: IPv6 WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6o= ps-mobile-device-profile last call- "harmfully broad"?

Hi Lorenzo,

 

Please see inline.<= /p>

 

Cheers,

Med

 

De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Lorenzo Colitti
Envoy=E9 : jeudi 19 f=E9vrier 2015 11:33
=C0 : BINET David IMT/OLN
Cc : IPv6 Ops WG (v6ops@ietf.= org)
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last= call- "harmfully broad"?

 

On Thu, Feb 19, 2015 at 1:39 AM, <david.binet@orange.com>= wrote:


[DB] Could you be more explicit and indicate which features are not useful = in the draft ? As you can mention it, all features are not indicated as man= datory in the draft so I do not clearly understand how this document confli= cts with what you say considering that the goal for the operator is to provide at least the same service acc= ess for users with IPv6 connectivity than for users with IPv4 connectivity = whatever the strategy retained by the operator.

 

If the goal of the document is "to provide at l= east the same service access for users with IPv6 connectivity than for user= s with IPv4 connectivity whatever the strategy retained by the operator&quo= t;

 

[Med] This is one of the goals of the= I-D not the only one. e.g., the I-D lists features that are not covered in= RFC7066 and RFC6434: e.g., prefix delegation or prefix sharing.

 

then you can reduce the documen= t to two requirements:

 

[Med] I=92m afraid compacting the rec= ommendations is not helpful. For example, these two items are covered as fo= llows in the I-D for the sake of deterministic behavior.

 

1. Support both IPv4v6 and IPv6= .

&nbs= p;

[Med] These items cover this 1st= point:

 

   C_REC#1:  In order to allow each = operator to select their own

        &nb= sp;    strategy regarding IPv6 introduction, the cellular ho= st

        &nb= sp;    must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060].

        &nb= sp;    IPv4, IPv6 or IPv4v6 PDP-Context request acceptance d= epends

        &nb= sp;    on the cellular network configuration.

 

   C_REC#2:  The cellular host must = comply with the behavior defined in

        &nb= sp;    [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-

        &nb= sp;    Context type.  In particular, the cellular host = must

        &nb= sp;    request by default an IPv6 PDP-Context if the cellula= r host

        &nb= sp;    is IPv6-only and request an IPv4v6 PDP-Context if the=

        &nb= sp;    cellular host is dual-stack or when the cellular host= is

        &nb= sp;    not aware of connectivity types requested by devices<= o:p>

        &nb= sp;    connected to it (e.g., cellular host with LAN capabil= ities

        &nb= sp;    as disc= ussed in Section 3):

 

        &nb= sp;    *  If the requested IPv4v6 PDP-Context is not su= pported by

        &nb= sp;       the network, but IPv4 and IPv6 PDP = types are allowed,

        &nb= sp;       then the cellular host will be conf= igured with an IPv4

        &nb= sp;       address or an IPv6 prefix by the ne= twork.  It must

        &nb= sp;       initiate another PDP-Context activa= tion in addition to

        &nb= sp;       the one already activated for a giv= en APN (Access Point

        &nb= sp;       Name).

 

        &nb= sp;    *  If the subscription data or network configura= tion allows

        &nb= sp;       only one IP address family (IPv4 or= IPv6), the cellular

        &nb= sp;       host must not request a second PDP-= Context to the same

        &nb= sp;       APN for the other IP address family= .

 

        &nb= sp;    The text above focuses on the specification part whic= h

         &n= bsp;   explains the behavior for requesting IPv6-related PDP= -

        &nb= sp;    Context(s).  Understanding this behavior is impo= rtant to

        &nb= sp;    avoid having broken IPv6 implementations in cellular<= o:p>

        &nb= sp;    devices= .

 

 

   C_REC#3:  The cellular host must = support the PCO (Protocol

        &nb= sp;    Configuration Options) [TS.24008] to retrieve the IPv6

        &nb= sp;    address(es) of the Recursive DNS server(s).

 

         &n= bsp;      In-band signaling is a convenient m= ethod to inform the

        &nb= sp;       cellular host about various service= s, including DNS

        &nb= sp;       server information.  It does n= ot require any specific

        &nb= sp;       protocol to be supported and it is = already deployed in

        &nb= sp;       IPv4 cellular networks to convey su= ch DNS information.

 

   C_REC#4:  The cellular host must = support IPv6 aware Traffic Flow

        &nb= sp;    Templates (TFT) [TS.24008].

 

        &nb= sp;       Traffic Flow Templates are employin= g a packet filter to

        &nb= sp;       couple an IP traffic with a PDP-Con= text.  Thus a

        &nb= sp;       dedicated PDP-Context and radio res= ources can be

        &nb= sp;       provided by the cellular network fo= r certain IP traffic.

 

 

2. Support 464xlat.

[Med] =93464xlat=94 is meaningless fo= r the device;-) but I got your point. This is covered by the following two = items:

 

   C_REC#8:  In order to ensure IP=
v4 service continuity in an IPv6-only
        &=
nbsp;    deployment context, the cellular host should suppor=
t a
        &=
nbsp;    method to locally construct IPv4-embedded IPv6 addr=
esses
        &=
nbsp;    [RFC6052].  A method to le=
arn PREFIX64 should be supported
        &=
nbsp;    by the cellular host.
 
        &=
nbsp;       This solves the issue when applic=
ations use IPv4
        &=
nbsp;       referrals on IPv6-only access net=
works.
 
        &=
nbsp;       In PCP-based environments, cellul=
ar hosts should follow
        &=
nbsp;       [RFC7225<=
/a>] to learn the IPv6 Prefix used by an upstream=

        &=
nbsp;       PCP-controlled NAT64 device. =
; If PCP is not enabled, the
        &=
nbsp;       cellular host should implement th=
e method specified in
        &=
nbsp;       [RFC7050] to retrieve the PREFIX64.
 
   C_REC#9:  In order to ensure IP=
v4 service continuity in an IPv6-only
        &=
nbsp;    deployment context, the cellular host should implem=
ent the
        &=
nbsp;    Customer Side Translator (CLAT, [RFC6877]) function in
        &=
nbsp;    compliance with [RFC6052][RFC61=
45][RFC6146].
 
        &=
nbsp;       CLAT function in the cellular hos=
t allows for IPv4-only
        &=
nbsp;       application and IPv4-referals to =
work on an IPv6-only
        &=
nbsp;       connectivity.  The more appl=
ications are address family
        &=
nbsp;       independent, the less CLAT functi=
on is solicited.  CLAT
        &=
nbsp;       function requires a NAT64 capabil=
ity [RFC6146] in the
        &=
nbsp;       network.
 
        &=
nbsp;       The cellular host should only inv=
oke the CLAT in the
        &=
nbsp;       absence of the IPv4 connectivity =
on the cellular side,
        &=
nbsp;       i.e., when the network does not a=
ssign an IPv4 address
        &=
nbsp;       on the cellular interface.  =
Note, NAT64 assumes an
        &=
nbsp;       IPv6-only mode [=
RFC6146].
 
        &=
nbsp;       The IPv4 Service Continuity Prefi=
x used by CLAT is
        &=
nbsp;       defined in [RFC7335].
 
        &=
nbsp;       CLAT and/or NAT64 do not interfer=
e with native IPv6
        &=
nbsp;       communications.=

 

 

 





This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/we= b/content/emailnotice



Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l=92avis pub= li=E9 =E0 www.rogers.com/aviscourriel
--_000_D10B3F461A731davemichaudrcirogerscom_-- From nobody Thu Feb 19 04:32:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29F21A8FD7 for ; Thu, 19 Feb 2015 04:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg91a_0STS-W for ; Thu, 19 Feb 2015 04:32:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FDF1A8FD3 for ; Thu, 19 Feb 2015 04:32:06 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3F6D418C105; Thu, 19 Feb 2015 13:32:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1AEB14C072; Thu, 19 Feb 2015 13:32:01 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 13:32:01 +0100 From: To: Lorenzo Colitti , "Heatley, Nick" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTC2TixBJZ1L350WogIuKXDMPO5z34qow Date: Thu, 19 Feb 2015 12:32:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490E4E7OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.110025 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:32:09 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490E4E7OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBraW5kIHN1Z2dlc3Rpb24gYnV0IEnigJltIGFsbCBv cHRpbWlzdCB0aGUgSS1EIGNhbiBiZSBwdWJsaXNoZWQgaW4gdGhlIElFVEYgc3RyZWFtLiBJZiB0 aGUgSUVURiBjb25zZW5zdXMgd2FzIGRlY2xhcmVkIG9uY2UsIEnigJlkIGhvcGUgdGhpcyB3aWxs IGhhcHBlbiBmb3IgdGhpcyB2ZXJzaW9uIGhhdmluZyBhIHJlc3RyaWN0ZWQgc2NvcGUgKGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlLykNCg0KSXQgaXMgb2J2aW91cyB0aGVyZSBpcyBhIHZvaWQgZmlsbGVkIGJ5IHRo aXMgZHJhZnQuIEl0IGlzIGJ1aWx0IG9uIGV4aXN0aW5nIFJGQ3MgYWxyZWFkeSBwdWJsaXNoZWQg aW4gdGhpcyBhcmVhLiBUaGlzIGRvY3VtZW50IGlzIG5vdCBvcmlnaW5hbCBpbiBpdHMgYW1iaXRp b24gbm9yIGl0IGlzIGRpZmZlcmVudCBpbiBpdHMgc3RydWN0dXJlLg0KDQpUZWNobmljYWwgaXNz dWVzIGNhbiBhbHdheXMgYmUgZml4ZWQgKG9yIGF0IHdvcnNlIHJlY29yZGVkKSwgZGlzYWdyZWVt ZW50cyBjYW4gYmUgYWNrbm93bGVkZ2VkLCBjb21wcm9taXNlcyBjYW4gYmUgZm91bmQsIHRoZSBz Y29wZSBjYW4gYmUgYWRqdXN0ZWQsIGV0Yy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDE5 IGbDqXZyaWVyIDIwMTUgMTE6MjANCsOAIDogSGVhdGxleSwgTmljaw0KQ2MgOiBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBDYSBCeTsgSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnKQ0KT2Jq ZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBs YXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUaHUsIEZlYiAxOSwgMjAxNSBhdCA2 OjE0IFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs8bWFpbHRvOm5pY2su aGVhdGxleUBlZS5jby51az4+IHdyb3RlOg0KSWYgYW5vdGhlciBib2R5IGNvdWxkIGJlIGFjY291 bnRhYmxlIGZvciB0aGUgZG9jdW1lbnQsIHRoYXQgaXQgcmVwcmVzZW50cyB0aGUgdmlld3Mgb2Yg YSBzdWl0YWJsZSBjb2xsZWN0aXZlIChtb2JpbGUgb3BlcmF0b3JzKSwgYnV0IHRoZSB0ZWNobmlj YWwgY29udGVudCB3YXMgZmlsdGVyZWQgdmlhIElFVEYsIHRoYXQgd291bGQgYmUgaWRlYWwsIG5v Pw0KSSBoYXZlIG5vIGlkZWEgaG93IHRvIGVuZ2luZWVyIHN1Y2ggYW4gb3V0Y29tZSwgYnV0IGlm IGl0IGNvdWxkIGJlIGRvbmUgdGhlbiB0aGlzIHdvcmsgc2hvdWxkIG5vdCBiZSB3YXN0ZWQg4oCT IGNvdWxkIGJlIGEg4oCcR1NNQSBzcG9uc29yZWQgUkZD4oCdPw0KDQpZb3UgY291bGQgbWFrZSBp dCBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9uLCBhbmQgc2F5IHRoYXQgaXQgcmVwcmVzZW50cyB0 aGUgcmVjb21tZW5kYXRpb25zIG9mIHRoZSBhdXRob3JzIChzZWUgUkZDIDQ4NDYgZm9yIGEgZGVz Y3JpcHRpb24gb2YgdGhlIHByb2Nlc3MsIG9yIFJGQyA2NzMyIGZvciBhbiBleGFtcGxlIG9mIHN1 Y2ggYW4gaW5kZXBlbmRlbnQgc3VibWlzc2lvbiBSRkMpLg0KDQpJZiB3aGF0IHlvdSdyZSBhZnRl ciBpcyBJRVRGIGV4cGVydGlzZSwgdGhlbiBJIHRoaW5rIHRoZSBkb2N1bWVudCBoYXMgaGFkIHBs ZW50eSBvZiBleHBvc3VyZSB0byB0aGF0IGFscmVhZHksIGdpdmVuIGl0J3MgYmVlbiBpbiB0aGUg V0cgZm9yIG92ZXIgYSB5ZWFyIGFuZCBhIGhhbGYuDQo= --_000_787AE7BB302AE849A7480A190F8B93300490E4E7OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdSBm b3IgdGhlIGtpbmQgc3VnZ2VzdGlvbiBidXQgSeKAmW0gYWxsIG9wdGltaXN0IHRoZSBJLUQgY2Fu IGJlIHB1Ymxpc2hlZCBpbiB0aGUgSUVURiBzdHJlYW0uIElmIHRoZSBJRVRGIGNvbnNlbnN1cyB3 YXMgZGVjbGFyZWQgb25jZSwgSeKAmWQgaG9wZSB0aGlzDQogd2lsbCBoYXBwZW4gZm9yIHRoaXMg dmVyc2lvbiBoYXZpbmcgYSByZXN0cmljdGVkIHNjb3BlICg8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmls ZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbW9i aWxlLWRldmljZS1wcm9maWxlLzwvYT4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkl0IGlzIG9idmlvdXMgdGhlcmUgaXMgYSB2b2lkIGZpbGxlZCBi eSB0aGlzIGRyYWZ0LiBJdCBpcyBidWlsdCBvbiBleGlzdGluZyBSRkNzIGFscmVhZHkgcHVibGlz aGVkIGluIHRoaXMgYXJlYS4gVGhpcyBkb2N1bWVudCBpcyBub3Qgb3JpZ2luYWwgaW4gaXRzIGFt Yml0aW9uDQogbm9yIGl0IGlzIGRpZmZlcmVudCBpbiBpdHMgc3RydWN0dXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UZWNobmljYWwgaXNzdWVz IGNhbiBhbHdheXMgYmUgZml4ZWQgKG9yIGF0IHdvcnNlIHJlY29yZGVkKSwgZGlzYWdyZWVtZW50 cyBjYW4gYmUgYWNrbm93bGVkZ2VkLCBjb21wcm9taXNlcyBjYW4gYmUgZm91bmQsIHRoZSBzY29w ZSBjYW4gYmUgYWRqdXN0ZWQsIGV0Yy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkgW21h aWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1 ZGkgMTkgZsOpdnJpZXIgMjAxNSAxMToyMDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gSGVhdGxleSwg Tmljazxicj4NCjxiPkNjJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgQ2Eg Qnk7IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZyk8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3Qg Y2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRmVi IDE5LCAyMDE1IGF0IDY6MTQgUE0sIEhlYXRsZXksIE5pY2sgJmx0OzxhIGhyZWY9Im1haWx0bzpu aWNrLmhlYXRsZXlAZWUuY28udWsiIHRhcmdldD0iX2JsYW5rIj5uaWNrLmhlYXRsZXlAZWUuY28u dWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklmIGFub3RoZXIgYm9keSBjb3VsZCBiZSBhY2NvdW50YWJsZSBmb3IgdGhl IGRvY3VtZW50LCB0aGF0IGl0IHJlcHJlc2VudHMgdGhlIHZpZXdzDQogb2YgYSBzdWl0YWJsZSBj b2xsZWN0aXZlIChtb2JpbGUgb3BlcmF0b3JzKSwgYnV0IHRoZSB0ZWNobmljYWwgY29udGVudCB3 YXMgZmlsdGVyZWQgdmlhIElFVEYsIHRoYXQgd291bGQgYmUgaWRlYWwsIG5vPzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgaGF2ZSBubyBpZGVhIGhvdyB0byBlbmdpbmVlciBzdWNoIGFuIG91dGNvbWUsIGJ1dCBp ZiBpdCBjb3VsZCBiZSBkb25lIHRoZW4gdGhpcyB3b3JrDQogc2hvdWxkIG5vdCBiZSB3YXN0ZWQg 4oCTIGNvdWxkIGJlIGEg4oCcR1NNQSBzcG9uc29yZWQgUkZD4oCdPzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjb3VsZCBtYWtlIGl0IGFuIGluZGVwZW5kZW50IHN1 Ym1pc3Npb24sIGFuZCBzYXkgdGhhdCBpdCByZXByZXNlbnRzIHRoZSByZWNvbW1lbmRhdGlvbnMg b2YgdGhlIGF1dGhvcnMgKHNlZSBSRkMgNDg0NiBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJv Y2Vzcywgb3IgUkZDIDY3MzIgZm9yIGFuIGV4YW1wbGUgb2Ygc3VjaCBhbiBpbmRlcGVuZGVudCBz dWJtaXNzaW9uIFJGQykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklmIHdoYXQgeW91J3JlIGFmdGVyIGlzIElFVEYgZXhwZXJ0aXNlLCB0aGVu IEkgdGhpbmsgdGhlIGRvY3VtZW50IGhhcyBoYWQgcGxlbnR5IG9mIGV4cG9zdXJlIHRvIHRoYXQg YWxyZWFkeSwgZ2l2ZW4gaXQncyBiZWVuIGluIHRoZSBXRyBmb3Igb3ZlciBhIHllYXIgYW5kIGEg aGFsZi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490E4E7OPEXCLILM23corp_-- From nobody Thu Feb 19 04:45:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3FC1A878B for ; Thu, 19 Feb 2015 04:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk4k8X2ixESC for ; Thu, 19 Feb 2015 04:45:53 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9321A876B for ; Thu, 19 Feb 2015 04:45:53 -0800 (PST) Received: by iecar1 with SMTP id ar1so9191501iec.0 for ; Thu, 19 Feb 2015 04:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rTzGpr081ubd65reEBOh2Nku9cvmbDmTpB6+1a0kmOs=; b=lqV9aBWzjdw23u9ntOOoqOr5zs33OI86FH3ktJ4UInmCH9hHZCXx7TdJ0HvKCnpZ6p rGdU8B4YgTATYl3s/dRJkj469509HIqsNQD9+nk6UOox2DWPtgxJftUWyNNspd6kSfnG iCPzQx1MN6ZMQRLmQAGkj8DyAl+bql2YsDJh+aqbN++UUOBKdwSFWXCOzKu8U325rhbO qtWLY21JQt/ueoiEy0ppGKCyOnRGqfLhm3tWGIAJ+b00+tGiHKmm7333k1i6bY9zzySZ F7Hg2vIA29SdkrmCy45PKMY4hFy3eMlX3bG2fKd3BmuNpysWvg+3jbCMQ7lwvhzfHtfs PsQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rTzGpr081ubd65reEBOh2Nku9cvmbDmTpB6+1a0kmOs=; b=k1AP6coSmsGL1Zg42F2zCdVoCiKjD/mNW67j/OMHLUgm3uNikhVSMYOy5RbpO1xZhQ JUVwGuHSo2JpmDUcdV62oNB5YEeizdAD2TAIku4HvnqLXBA/qTnPfk1/N/P10SeKx4WA kXyebnyQsnx/9AQB+I29OxEq+6873Q8EEBuJE+NwMccdn42z1+Y6o4Py8uPR0+auyonc AncpIJtLBuioOqQq6VN26HXmVLGcvMy0sS/dRbzZ6XfN6IcEjCrqPYAvN3y74QykN6YN VRSvO4Fwx7gtWNJCBLoKogFy6ZxnpRcAlV+0qRMcpkr7710WDscfy3zUMe/EfaJMqCBB /rrw== X-Gm-Message-State: ALoCoQk1wHZ/5ClTEsJi3A328ARUu8PVIB6xJg/qjUn9iZFHN2Y5F55OVUM/1lzPLrB2j7msI6Te X-Received: by 10.107.170.220 with SMTP id g89mr5776266ioj.31.1424349953036; Thu, 19 Feb 2015 04:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 04:45:32 -0800 (PST) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 21:45:32 +0900 Message-ID: To: Dave Michaud Content-Type: multipart/alternative; boundary=001a114159b8fcb83b050f7050f2 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:45:55 -0000 --001a114159b8fcb83b050f7050f2 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud wrote: > This is directly in line with the v6ops charter: > > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides operational > guidance on how to deploy IPv6 into existing IPv4-only networks, > as well as into new network installations. > > The main focus of the v6ops WG is to look at the immediate > deployment issues; more advanced stages of deployment and transition > are a lower priority. > > Actually, it isn't, really. The charter is operational guidance for the IPv4/IPv6 Internet. Not host requirements. In fact, if you look at the numbered list in the charter, the items are "identify operational issues and determine solutions", "identify potential security risks", "identify portions of the specs that can cause operational concerns", and "analyze solutions for deploying IPv6 within network environments". None of those cover this document. --001a114159b8fcb83b050f7050f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 9:31 PM, Dave Michaud <Dave.Michaud@rci.roge= rs.com> wrote:
This is directly in line with the v6ops charter:

The IPv6 Operations Working Group (v6ops) develops g= uidelines for the
operation of a shared IPv4/IPv6 Internet and provides ope= rational
guidance on how to deploy IPv6 into existing IPv4-only ne= tworks,
as well as into new network installations.

The main focus of the v6ops WG is to look at the immediat= e
deployment issues; more advanced stages of deployment and= transition
are a lower priority.

Actually, it isn't, really. The char= ter is operational guidance for the IPv4/IPv6 Internet. Not host requiremen= ts.

In fact, if you look at the numbered list in t= he charter, the items are "identify operational issues and determine s= olutions", "identify potential security risks", "identi= fy portions of the specs that can cause operational concerns", and &qu= ot;analyze solutions for deploying IPv6 within network environments". = None of those cover this document.
--001a114159b8fcb83b050f7050f2-- From nobody Thu Feb 19 04:48:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FAB1A888B for ; Thu, 19 Feb 2015 04:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.212 X-Spam-Level: X-Spam-Status: No, score=0.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP9rZgfhcU4A for ; Thu, 19 Feb 2015 04:48:13 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCA01A8731 for ; Thu, 19 Feb 2015 04:48:13 -0800 (PST) Received: by iecrl12 with SMTP id rl12so9107362iec.4 for ; Thu, 19 Feb 2015 04:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hX4Jk+0XkatsTkLDvqiBpFai9mJ6CLwnBxiq/QBNLig=; b=ZaoCmgZwUMvLUEnJ7ePg11fh0n/2pu6h7exF3DjaUV4fX16sytMqxqVp5UhQfw2mAQ gVluQdfEn/9nqN6mqQRepNWYZ2rt1I3L3RbIcL+HVEQCnDe172W0ZoL/Sn9/JtTaj2oL 1VXWOgFuJc/eX7qpXrTnEdd/6UNnbnrDraSYSm0NxqOF4+737SflpOmNszeD6eDX2BGs oABsnlJg8OBb6yOpHz0Xz+RxPa3iABYIFA7pd3AKeDmU+zdZcqsxFj/el5hofiQimKOq Okg188jGZizKpLvlFTeve/t0P+M6+OdlPjRizDqd+wxN2Q1rErOolDZS7DNC/Mu87ghL 7i8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hX4Jk+0XkatsTkLDvqiBpFai9mJ6CLwnBxiq/QBNLig=; b=mVkRAMYzbKagS5y/Qjl8n2fEwIMushUV3xbehIeECSVQ8CmoJXkjjMM2XBP2EhLlwQ Pljse5LE/Z5eOJHAwQ8ZvL/fYdLiqHpOFnnK2X4T/B9ZQxL4P2XpUYWQOPQa3VpFhb96 GAmfidzvegeNkcTuZV62636Sy/As44qDraBf0nVSZq+VmTRcYrTyKqDzdr+F1Tojqaei 9RCvjT3kY4hgJuQkWRbzWJDnCBHlXR7qmpqCCKFiZzu+1VtYl72M9fgsERLM+bCLH0q8 NuMatgXzZMB2/j32udk5cqTqQ6Gojjvzd8IBfl++H00wQTxX1aC92rmnOrLhXhKYFKpW 3aLw== X-Gm-Message-State: ALoCoQmWdwF6+YJCbp6327B2KbFrXp7BxV0hCNMuGtb2ppabI1olRYmWhAP96EblkzvxV8JhuKBQ X-Received: by 10.50.61.238 with SMTP id t14mr6987875igr.34.1424350092793; Thu, 19 Feb 2015 04:48:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 04:47:52 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 21:47:52 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdca5bc5141b3050f705933 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:48:14 -0000 --047d7bdca5bc5141b3050f705933 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 9:32 PM, wrote: > It is obvious there is a void filled by this draft. It is built on > existing RFCs already published in this area. This document is not original > in its ambition nor it is different in its structure. > Actually, I don't see a void. IPv6 deployment on mobile networks (ok, perhaps not those of the authors) is happening now. Tens of millions of mobile devices are running IPv6 today. And a lot of it happened before this draft was even written. --047d7bdca5bc5141b3050f705933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 9:32 PM, <mohamed.boucadair@orange.com= > wrote:

It is obvious there is a void filled by this draft= . It is built on existing RFCs already published in this area. This documen= t is not original in its ambition nor it is different in its structure.

<= div>
Actually, I don't see a void. IPv6 deployment on mob= ile networks (ok, perhaps not those of the authors) is happening now. Tens = of millions of mobile devices are running IPv6 today. And a lot of it happe= ned before this draft was even written.
--047d7bdca5bc5141b3050f705933-- From nobody Thu Feb 19 05:03:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1C1A802E for ; Thu, 19 Feb 2015 05:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeee6wYanoBL for ; Thu, 19 Feb 2015 05:03:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40C01A1B2E for ; Thu, 19 Feb 2015 05:03:36 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1E73418C2BB; Thu, 19 Feb 2015 14:03:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E63684C076; Thu, 19 Feb 2015 14:03:34 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%35]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 14:03:34 +0100 From: To: Lorenzo Colitti , Dave Michaud Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEHyixBJZ1L350WogIuKXDMPO5z37j1A Date: Thu, 19 Feb 2015 13:03:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490E580OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.190922 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:03:39 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490E580OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDE5 IGbDqXZyaWVyIDIwMTUgMTM6NDYNCsOAIDogRGF2ZSBNaWNoYXVkDQpDYyA6IEJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE47IEJJTkVUIERhdmlkIElNVC9PTE47IElQdjYgT3BzIFdHICh2Nm9wc0Bp ZXRmLm9yZykNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24gVGh1LCBGZWIg MTksIDIwMTUgYXQgOTozMSBQTSwgRGF2ZSBNaWNoYXVkIDxEYXZlLk1pY2hhdWRAcmNpLnJvZ2Vy cy5jb208bWFpbHRvOkRhdmUuTWljaGF1ZEByY2kucm9nZXJzLmNvbT4+IHdyb3RlOg0KVGhpcyBp cyBkaXJlY3RseSBpbiBsaW5lIHdpdGggdGhlIHY2b3BzIGNoYXJ0ZXI6DQoNClRoZSBJUHY2IE9w ZXJhdGlvbnMgV29ya2luZyBHcm91cCAodjZvcHMpIGRldmVsb3BzIGd1aWRlbGluZXMgZm9yIHRo ZQ0Kb3BlcmF0aW9uIG9mIGEgc2hhcmVkIElQdjQvSVB2NiBJbnRlcm5ldCBhbmQgcHJvdmlkZXMg b3BlcmF0aW9uYWwNCmd1aWRhbmNlIG9uIGhvdyB0byBkZXBsb3kgSVB2NiBpbnRvIGV4aXN0aW5n IElQdjQtb25seSBuZXR3b3JrcywNCmFzIHdlbGwgYXMgaW50byBuZXcgbmV0d29yayBpbnN0YWxs YXRpb25zLg0KDQpUaGUgbWFpbiBmb2N1cyBvZiB0aGUgdjZvcHMgV0cgaXMgdG8gbG9vayBhdCB0 aGUgaW1tZWRpYXRlDQpkZXBsb3ltZW50IGlzc3VlczsgbW9yZSBhZHZhbmNlZCBzdGFnZXMgb2Yg ZGVwbG95bWVudCBhbmQgdHJhbnNpdGlvbg0KYXJlIGEgbG93ZXIgcHJpb3JpdHkuDQoNCkFjdHVh bGx5LCBpdCBpc24ndCwgcmVhbGx5LiBUaGUgY2hhcnRlciBpcyBvcGVyYXRpb25hbCBndWlkYW5j ZSBmb3IgdGhlIElQdjQvSVB2NiBJbnRlcm5ldC4gTm90IGhvc3QgcmVxdWlyZW1lbnRzLg0KDQpb TWVkXSBIdW1tbeKApiBJIHN1Z2dlc3QgeW91IGhhdmUgYSBxdWljayBsb29rIGF0IHRoaXMgcGFn ZSA6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdjZvcHMvZG9jdW1lbnRzLyAoaGlu dDogc2VhcmNoIGZvciDigJhob3N04oCZIG9yIOKAmENQReKAmSkuDQoNCkluIGZhY3QsIGlmIHlv dSBsb29rIGF0IHRoZSBudW1iZXJlZCBsaXN0IGluIHRoZSBjaGFydGVyLCB0aGUgaXRlbXMgYXJl ICJpZGVudGlmeSBvcGVyYXRpb25hbCBpc3N1ZXMgYW5kIGRldGVybWluZSBzb2x1dGlvbnMiLCAi aWRlbnRpZnkgcG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzIiwgImlkZW50aWZ5IHBvcnRpb25zIG9m IHRoZSBzcGVjcyB0aGF0IGNhbiBjYXVzZSBvcGVyYXRpb25hbCBjb25jZXJucyIsIGFuZCAiYW5h bHl6ZSBzb2x1dGlvbnMgZm9yIGRlcGxveWluZyBJUHY2IHdpdGhpbiBuZXR3b3JrIGVudmlyb25t ZW50cyIuIE5vbmUgb2YgdGhvc2UgY292ZXIgdGhpcyBkb2N1bWVudC4NCg0KW01lZF0gSXMgdGhp cyBhIGpva2U/IFlvdXIgYXNzZXJ0aW9uIGlzIGVycm9uZW91cy4gSSB3aWxsIHRha2Ugb25lIGl0 ZW0gcmFuZG9tbHkgZnJvbSB0aGUgSS1EIHRvIGlsbHVzdHJhdGUgdGhlIGZpcnN0IGl0ZW0gaW4g eW91ciBsaXN0Og0KDQogICBDX1JFQyM3OiAgQmVjYXVzZSBvZiBwb3RlbnRpYWwgb3BlcmF0aW9u YWwgZGVmaWNpZW5jaWVzIHRvIGJlDQogICAgICAgICAgICAgZXhwZXJpZW5jZWQgaW4gc29tZSBy b2FtaW5nIHNpdHVhdGlvbnMsIHRoZSBjZWxsdWxhciBob3N0DQogICAgICAgICAgICAgbXVzdCBi ZSBhYmxlIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIGhvbWUgUERQLUNvbnRleHQNCiAgICAgICAg ICAgICB0eXBlKHMpIGFuZCBhIHJvYW1pbmcgUERQLUNvbnRleHQgdHlwZShzKS4gIFRoZSBwdXJw b3NlIG9mDQogICAgICAgICAgICAgdGhlIG9mIHRoZSByb2FtaW5nIHByb2ZpbGUgaXMgdG8gbGlt aXQgdGhlIFBEUCB0eXBlKHMpDQogICAgICAgICAgICAgcmVxdWVzdGVkIGJ5IHRoZSBjZWxsdWxh ciBob3N0IHdoZW4gb3V0IG9mIHRoZSBob21lDQogICAgICAgICAgICAgbmV0d29yay4gIE5vdGUg dGhhdCBkaXN0aW5jdCBQRFAgdHlwZShzKSBhbmQgQVBOKHMpIGNhbiBiZQ0KICAgICAgICAgICAg IGNvbmZpZ3VyZWQgZm9yIGhvbWUgYW5kIHJvYW1pbmcgY2FzZXMuDQoNCg== --_000_787AE7BB302AE849A7480A190F8B93300490E580OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5SZS0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5N ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5i c3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0 dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gamV1ZGkgMTkgZsOpdnJpZXIgMjAxNSAxMzo0Njxicj4NCjxiPsOAJm5ic3A7OjwvYj4gRGF2 ZSBNaWNoYXVkPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO OyBCSU5FVCBEYXZpZCBJTVQvT0xOOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90O2hhcm1mdWxseSBicm9hZCZxdW90Oz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUaHUsIEZlYiAxOSwgMjAxNSBhdCA5OjMxIFBNLCBEYXZlIE1pY2hhdWQgJmx0 OzxhIGhyZWY9Im1haWx0bzpEYXZlLk1pY2hhdWRAcmNpLnJvZ2Vycy5jb20iIHRhcmdldD0iX2Js YW5rIj5EYXZlLk1pY2hhdWRAcmNpLnJvZ2Vycy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBpcyBkaXJlY3RseSBpbiBsaW5l IHdpdGggdGhlIHY2b3BzIGNoYXJ0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdyb3VwICh2Nm9wcykgZGV2ZWxvcHMgZ3Vp ZGVsaW5lcyBmb3IgdGhlPGJyPg0Kb3BlcmF0aW9uIG9mIGEgc2hhcmVkIElQdjQvSVB2NiBJbnRl cm5ldCBhbmQgcHJvdmlkZXMgb3BlcmF0aW9uYWw8YnI+DQpndWlkYW5jZSBvbiBob3cgdG8gZGVw bG95IElQdjYgaW50byBleGlzdGluZyBJUHY0LW9ubHkgbmV0d29ya3MsPGJyPg0KYXMgd2VsbCBh cyBpbnRvIG5ldyBuZXR3b3JrIGluc3RhbGxhdGlvbnMuPGJyPg0KPGJyPg0KVGhlIG1haW4gZm9j dXMgb2YgdGhlIHY2b3BzIFdHIGlzIHRvIGxvb2sgYXQgdGhlIGltbWVkaWF0ZTxicj4NCmRlcGxv eW1lbnQgaXNzdWVzOyBtb3JlIGFkdmFuY2VkIHN0YWdlcyBvZiBkZXBsb3ltZW50IGFuZCB0cmFu c2l0aW9uPGJyPg0KYXJlIGEgbG93ZXIgcHJpb3JpdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWN0dWFsbHksIGl0IGlzbid0LCByZWFsbHkuIFRoZSBjaGFydGVyIGlzIG9wZXJhdGlvbmFs IGd1aWRhbmNlIGZvciB0aGUgSVB2NC9JUHY2IEludGVybmV0LiBOb3QgaG9zdCByZXF1aXJlbWVu dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSHVt bW3igKYgSSBzdWdnZXN0IHlvdSBoYXZlIGEgcXVpY2sgbG9vayBhdCB0aGlzIHBhZ2UmbmJzcDs6 DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3Y2b3BzL2RvY3VtZW50 cy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdjZvcHMvZG9jdW1lbnRzLzwvYT4g KGhpbnQ6IHNlYXJjaCBmb3Ig4oCYaG9zdOKAmSBvciDigJhDUEXigJkpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGZhY3QsIGlmIHlvdSBsb29r IGF0IHRoZSBudW1iZXJlZCBsaXN0IGluIHRoZSBjaGFydGVyLCB0aGUgaXRlbXMgYXJlICZxdW90 O2lkZW50aWZ5IG9wZXJhdGlvbmFsIGlzc3VlcyBhbmQgZGV0ZXJtaW5lIHNvbHV0aW9ucyZxdW90 OywgJnF1b3Q7aWRlbnRpZnkgcG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzJnF1b3Q7LCAmcXVvdDtp ZGVudGlmeSBwb3J0aW9ucyBvZiB0aGUgc3BlY3MgdGhhdCBjYW4gY2F1c2Ugb3BlcmF0aW9uYWwN CiBjb25jZXJucyZxdW90OywgYW5kICZxdW90O2FuYWx5emUgc29sdXRpb25zIGZvciBkZXBsb3lp bmcgSVB2NiB3aXRoaW4gbmV0d29yayBlbnZpcm9ubWVudHMmcXVvdDsuDQo8L3NwYW4+Tm9uZSBv ZiB0aG9zZSBjb3ZlciB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+W01lZF0gSXMgdGhpcyBhIGpva2U/IFlvdXIgYXNzZXJ0aW9uIGlzIGVycm9uZW91cy4gSSB3 aWxsIHRha2Ugb25lIGl0ZW0gcmFuZG9tbHkgZnJvbSB0aGUgSS1EIHRvIGlsbHVzdHJhdGUgdGhl IGZpcnN0IGl0ZW0gaW4geW91ciBsaXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ19SRUMjNzombmJzcDsgQmVjYXVzZSBvZiBwb3RlbnRpYWwg b3BlcmF0aW9uYWwgZGVmaWNpZW5jaWVzIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZXhwZXJpZW5jZWQgaW4gc29tZSByb2FtaW5nIHNpdHVhdGlvbnMsIHRoZSBjZWxsdWxhciBob3N0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVzdCBiZSBhYmxlIHRvIGJlIGNvbmZpZ3VyZWQg d2l0aCBhIGhvbWUgUERQLUNvbnRleHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlKHMp IGFuZCBhIHJvYW1pbmcgUERQLUNvbnRleHQgdHlwZShzKS4mbmJzcDsgVGhlIHB1cnBvc2Ugb2Y8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgb2YgdGhlIHJvYW1pbmcgcHJvZmlsZSBpcyB0 byBsaW1pdCB0aGUgUERQIHR5cGUocyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1ZXN0 ZWQgYnkgdGhlIGNlbGx1bGFyIGhvc3Qgd2hlbiBvdXQgb2YgdGhlIGhvbWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBuZXR3b3JrLiZuYnNwOyBOb3RlIHRoYXQgZGlzdGluY3QgUERQIHR5cGUo cykgYW5kIEFQTihzKSBjYW4gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmVk IGZvciBob21lIGFuZCByb2FtaW5nIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300490E580OPEXCLILM23corp_-- From nobody Thu Feb 19 05:11:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121E11A9047 for ; Thu, 19 Feb 2015 05:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99uYGIdpuUTn for ; Thu, 19 Feb 2015 05:10:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057701A6F2A for ; Thu, 19 Feb 2015 05:10:55 -0800 (PST) Received: from DM2PR0401MB1069.namprd04.prod.outlook.com (25.160.98.20) by DM2PR0401MB1069.namprd04.prod.outlook.com (25.160.98.20) with Microsoft SMTP Server (TLS) id 15.1.87.18; Thu, 19 Feb 2015 13:10:34 +0000 Received: from DM2PR0401MB1069.namprd04.prod.outlook.com ([25.160.98.20]) by DM2PR0401MB1069.namprd04.prod.outlook.com ([25.160.98.20]) with mapi id 15.01.0087.013; Thu, 19 Feb 2015 13:10:34 +0000 From: Dave Michaud To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAbl5AwAAGrn8AACK8HgAAAYbbgAAShBCAACm1R4AAE1sVAAAleKCAAAOCioD//7EhAIAAV9wA//+zKQA= Date: Thu, 19 Feb 2015 13:10:33 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [99.234.22.8] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0401MB1069; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0401MB1069; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(377454003)(199003)(15975445007)(101416001)(92566002)(106356001)(102836002)(46102003)(16236675004)(87936001)(68736005)(19580395003)(230783001)(2656002)(97736003)(86362001)(74826001)(93886004)(19580405001)(64706001)(110136001)(66066001)(19617315012)(122556002)(40100003)(1720100001)(50986999)(76176999)(99286002)(54356999)(83506001)(19273905006)(62966003)(77156002)(2900100001)(2950100001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1069; H:DM2PR0401MB1069.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D10B47D61A74Edavemichaudrcirogerscom_" MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2015 13:10:33.8420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1069 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:11:00 -0000 --_000_D10B47D61A74Edavemichaudrcirogerscom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does the charter specifically exclude hosts requirements? Enabling dual-stack on a cellular network serves no mean if it can't be use= d. Transitionning to IPv6-only requires further support from the host side to = form a complete solution. The documents published under v6ops should "serve as useful guides to netwo= rk operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations." This is exactly what this is. As a LAN administrator, it wouldn't cross my = mind to look for an RFC for host requirements because I would have little c= ontrol anyway. As a cellular operator, the hosts are part of my network and= I do have a say on how they operate and it forms part of the overall solut= ion (bullet 4 of the charter). Same would apply from a Cable MSO where the = CPEs are integral part of the network. Dave Michaud Sr. Architect Mobility - Access Networks & IP Network Services Network Technology | Rogers Communications dave.michaud@rci.rogers.com | tel: +1 6= 47.747.9442 | mobile: +1 416.219.5531 From: Lorenzo Colitti > Date: Thursday, February 19, 2015 at 07:45 To: Dave Michaud > Cc: "mohamed.boucadair@orange.com" >, BINET IMT= /OLN >, IPv6 WG > Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "har= mfully broad"? On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud > wrote: This is directly in line with the v6ops charter: The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. Actually, it isn't, really. The charter is operational guidance for the IPv= 4/IPv6 Internet. Not host requirements. In fact, if you look at the numbered list in the charter, the items are "id= entify operational issues and determine solutions", "identify potential sec= urity risks", "identify portions of the specs that can cause operational co= ncerns", and "analyze solutions for deploying IPv6 within network environme= nts". None of those cover this document. ________________________________ This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l'avis publi= =E9 =E0 www.rogers.com/aviscourriel ________________________________ --_000_D10B47D61A74Edavemichaudrcirogerscom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0973B89CBE53B243843A93EBCB6D3F9B@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Does the charter specifically exclude hosts requirements?

Enabling dual-stack on a cellular network serves no mean if it can’t = be used.

Transitionning to IPv6-only requires further support from the host side to = form a complete solution.

The documents published under v6ops should "serve as useful guides to network
operators and users on poss= ible ways how to deploy IPv6 within their
existing IPv4 networks, as = well as in new network installations.”= ;

This is exactly what this is. As a LAN administrator, it wouldn’t cro= ss my mind to look for an RFC for host requirements because I would have li= ttle control anyway. As a cellular operator, the hosts are part of my netwo= rk and I do have a say on how they operate and it forms part of the overall solution (bullet 4 of the charter). Same = would apply from a Cable MSO where the CPEs are integral part of the networ= k.

Dave Michaud
Sr. Architect Mobility – Access Networks & IP Network Services=
Network Technology | Rogers Communications&= nbsp;
dave.michaud@rci.rogers.c= om | tel: +1 647.747.9442 | mobile: +1 416.219.5531=


From: Lorenzo Colitti <lorenzo@google.com>
Date: Thursday, February 19, 2015 a= t 07:45
To: Dave Michaud <dave.michaud@rci.rogers.com>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;, BINET IMT/OLN <david.binet= @orange.com>, IPv6 WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6o= ps-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud <Dave.M= ichaud@rci.rogers.com> wrote:
This is directly in line with the v6ops charter:

The IPv6 Operations Working Group (v6ops) d= evelops guidelines for the
operation of a shared IPv4/IPv6 Internet and pro= vides operational
guidance on how to deploy IPv6 into existing IPv= 4-only networks,
as well as into new network installations.

The main focus of the v6ops WG is to look at the= immediate
deployment issues; more advanced stages of deplo= yment and transition
are a lower priority.

Actually, it isn't, really. The charter is operational guidance for th= e IPv4/IPv6 Internet. Not host requirements.

In fact, if you look at the numbered list in the charter, the items ar= e "identify operational issues and determine solutions", "id= entify potential security risks", "identify portions of the specs= that can cause operational concerns", and "analyze solutions for deploying IPv6 within network environments". None of those cover = this document.




This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/we= b/content/emailnotice



Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l’avis= publi=E9 =E0 www.rogers.com/aviscourriel
--_000_D10B47D61A74Edavemichaudrcirogerscom_-- From nobody Thu Feb 19 05:17:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3331A9046 for ; Thu, 19 Feb 2015 05:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgtrowHuoU1a for ; Thu, 19 Feb 2015 05:17:36 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDF51A904D for ; Thu, 19 Feb 2015 05:17:36 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so43840477igd.4 for ; Thu, 19 Feb 2015 05:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eRrOgG1Xe7C2CMzQGBMBcpKmVmiySJUhKqV1pS+JJuM=; b=QZN+9z5erbKb4HBZkdpBDbuTI7O8hpLGCAZIW22O3Hc9u2nHq4uK1ZAELzRGuI3rRt w9TMimCpXf9qKUc+GpPNAAcIKQw6Nan2GBlD4+0TtueUzt155KMdBS/JMb7oqJEe8xUe VZiqJVvyYItHndvvPNnx9PVM7stlZD7PC48lGWunES43ysdIii/KcEGyzZ6tva4y+dvc 2+3iI6JNZ6uqhMoeOJR1W8JJZRx2tmqkn6SQRh/brMbpApLEbpyJob6CUNxKUy2HDouU uJc216jEA7F6Kwib74xfdi8ZPfOta6dcaq6/EFRPubiC9gzd9xDvIZ525mlwP47TPSOw Xi1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eRrOgG1Xe7C2CMzQGBMBcpKmVmiySJUhKqV1pS+JJuM=; b=IxGqcBMV64LcjQ74jvQsDsCU10nnF/emAvJ/3ZQy2SgviAhEB9jVSL8spYBwyj3JM1 ULjUW1HggHbRnOpg+ez2cpbNagdjNEVvsEyFvufAI1Y0K3GVDNFqgmuozI/EGWO36CVS i18+qH40nHpbHDba+Rfq6e8jDGpQ/GMR2rNk2P8jhTffGiBmqqRmj7wEalnt2Kdl9quH Mq/2q6tHcRl8kXPgPAKnj6cwvrmnv2ulvxu/lRjuJ4/sxBm45tTcNMJUWxJ14CqsQBel a3hmNvfYyz9YBaooxNNnhaXKvB8AXkb6v2dPyi6/3taLWtkim8y+bYYeaD32IcZycb8I Cqhw== X-Gm-Message-State: ALoCoQm6rmnXuxVzmBuWxUUH6jt1fdg8cQfM1vJndatN/zubzJMjyErm6aJsilT0dVTrlD3tK2Pt X-Received: by 10.107.151.80 with SMTP id z77mr5959813iod.51.1424351855521; Thu, 19 Feb 2015 05:17:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 05:17:14 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 22:17:14 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1140f5ee626a39050f70c213 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:17:38 -0000 --001a1140f5ee626a39050f70c213 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 10:03 PM, wrote: > > [Med] Hummm=E2=80=A6 I suggest you have a quick look at this page : > https://datatracker.ietf.org/wg/v6ops/documents/ (hint: search for =E2=80= =98host=E2=80=99 > or =E2=80=98CPE=E2=80=99). > The search says that a single-digit percentage of the documents contain the word "host" or "CPE" in the title. What point are you trying to make? That the charter is inappropriate, because it doesn't mention hosts, but the WG has published a few documents that talk about hosts? > In fact, if you look at the numbered list in the charter, the items are > "identify operational issues and determine solutions", "identify potentia= l > security risks", "identify portions of the specs that can cause operation= al > concerns", and "analyze solutions for deploying IPv6 within network > environments". None of those cover this document. > > > > [Med] Is this a joke? Your assertion is erroneous. I will take one item > randomly from the I-D to illustrate the first item in your list: > > > > C_REC#7: Because of potential operational deficiencies to be > > experienced in some roaming situations, the cellular host > > must be able to be configured with a home PDP-Context > > type(s) and a roaming PDP-Context type(s). > That's a great example to pick, because the WG is about to produce an RFC on precisely this topic - https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ . That document is a good example of what *is* in charter of the WG: an in-depth, detailed discussion of the operational issues. 8 lines of text saying "devices must support different PDP types for home and roaming" is not. --001a1140f5ee626a39050f70c213 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 10:03 PM, <mohamed.boucadair@orange.com> wrote:

The search says that a single-dig= it percentage of the documents contain the word "host" or "C= PE" in the title. What point are you trying to make? That the charter = is inappropriate, because it doesn't mention hosts, but the WG has publ= ished a few documents that talk about hosts?
=C2=A0

In fact, if you look at the num= bered list in the charter, the items are "identify operational issues = and determine solutions", "identify potential security risks"= ;, "identify portions of the specs that can cause operational concerns", and "analyze solutions for deploying IPv6 within netw= ork environments". None of those cover this document.

=C2=A0

[Med] Is this a joke? Your a= ssertion is erroneous. I will take one item randomly from the I-D to illust= rate the first item in your list:

=C2=A0

=C2=A0=C2=A0 C_REC#7:=C2=A0 Because of potentia= l operational deficiencies to be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 experienced in some roaming situations, the cel= lular host

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 must be able to be configured with a home PDP-C= ontext

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 type(s) and a roaming PDP-Context type(s).


That's a great= example to pick, because the WG is about to produce an RFC on precisely th= is topic - https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6= -roaming-analysis/ .

That document is a good e= xample of what *is* in charter of the WG: an in-depth, detailed discussion = of the operational issues. 8 lines of text saying "devices must suppor= t different PDP types for home and roaming" is not.
<= /div> --001a1140f5ee626a39050f70c213-- From nobody Thu Feb 19 05:20:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03901A906A for ; Thu, 19 Feb 2015 05:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXWUupftEZbL for ; Thu, 19 Feb 2015 05:20:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F0E1A906B for ; Thu, 19 Feb 2015 05:20:09 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5DF033B43DA; Thu, 19 Feb 2015 14:20:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 22BCD23808F; Thu, 19 Feb 2015 14:20:07 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 14:20:06 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEJGixBJZ1L350WogIuKXDMPO5z38OtA Date: Thu, 19 Feb 2015 13:20:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490E5EE@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490E5EEOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.124820 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:20:12 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490E5EEOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDE5 IGbDqXZyaWVyIDIwMTUgMTM6NDgNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2Mg OiBIZWF0bGV5LCBOaWNrOyBDYSBCeTsgSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnKQ0KT2Jq ZXQgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBs YXN0IGNhbGwtICJoYXJtZnVsbHkgYnJvYWQiPw0KDQpPbiBUaHUsIEZlYiAxOSwgMjAxNSBhdCA5 OjMyIFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSXQgaXMgb2J2aW91cyB0aGVyZSBpcyBhIHZvaWQg ZmlsbGVkIGJ5IHRoaXMgZHJhZnQuIEl0IGlzIGJ1aWx0IG9uIGV4aXN0aW5nIFJGQ3MgYWxyZWFk eSBwdWJsaXNoZWQgaW4gdGhpcyBhcmVhLiBUaGlzIGRvY3VtZW50IGlzIG5vdCBvcmlnaW5hbCBp biBpdHMgYW1iaXRpb24gbm9yIGl0IGlzIGRpZmZlcmVudCBpbiBpdHMgc3RydWN0dXJlLg0KDQpB Y3R1YWxseSwgSSBkb24ndCBzZWUgYSB2b2lkLg0KW01lZF0NCg0KU2hvcnQgYW5zd2VyIDoNCg0K VGhlIHZvaWQgaXMgKGF0IGxlYXN0KToNCg0KwrcgICAgICAgICBFeGlzdGluZyBwcm9maWxlIFJG QyBkb2VzIG5vdCBjb3ZlciBJUHY0IHNlcnZpY2UgY29udGludWl0eSBmZWF0dXJlcywgZGV2aWNl cyB3aXRoIGxhbiBjYXBhYmlsaXRpZXMsIGV0Yy4NCg0KwrcgICAgICAgICBFeGlzdGluZyBwcm9m aWxlIFJGQ3MgY29uZmxpY3RzIHdpdGggb3RoZXIgb3RoZXJzLg0KDQrCtyAgICAgICAgIFRoZXJl IGFyZSBzdGlsbCBicm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbnMuIERldGVybWluaXN0aWMgYmVo YXZpb3JzIGlzIGVuY291cmFnZWQuIFNheWluZyBhIGRldmljZSBzdXBwb3J0cyBJUHY2IGlzIG1l YW5pbmdsZXNzLg0KDQpMb25nIHZlcnNpb246IGlzIGRvY3VtZW50ZWQgaW4gdGhlIEktRCB0aGF0 IEkgc3VwcG9zZSB5b3UgYWxyZWFkeSByZWFkOg0KDQpUaGlzIHByb2ZpbGUgaXMgYSBzdXBlcnNl dCBvZiB0aGF0IG9mIHRoZSBJUHY2IHByb2ZpbGUgZm9yIDNHUFANCiAgIENlbGx1bGFyIEhvc3Rz IFtSRkM3MDY2XSwgd2hpY2ggaXMgaW4gdHVybiBhIHN1cGVyc2V0IG9mIElQdjYgTm9kZQ0KICAg UmVxdWlyZW1lbnRzIFtSRkM2NDM0XS4gIEl0IHRhcmdldHMgY2VsbHVsYXIgbm9kZXMsIGluY2x1 ZGluZyBHUFJTIGFuZA0KICAgRVBDIChFdm9sdmVkIFBhY2tldCBDb3JlKSwgdGhhdCByZXF1aXJl DQogICBmZWF0dXJlcyB0byBlbnN1cmUgSVB2NCBzZXJ2aWNlIGRlbGl2ZXJ5IG92ZXIgYW4gSVB2 Ni1vbmx5IHRyYW5zcG9ydA0KICAgaW4gYWRkaXRpb24gdG8gdGhlIGJhc2UgSVB2NiBzZXJ2aWNl LiAgTW9yZW92ZXIsIHRoaXMgcHJvZmlsZSBjb3ZlcnMNCiAgIGNlbGx1bGFyIENQRXMgdGhhdCBh cmUgdXNlZCBpbiB2YXJpb3VzIGRlcGxveW1lbnRzIHRvIG9mZmVyIGZpeGVkLQ0KICAgbGlrZSBz ZXJ2aWNlcy4gIFJlY29tbWVuZGF0aW9ucyBpbnNwaXJlZCBmcm9tIHJlYWwgZGVwbG95bWVudA0K ICAgZXhwZXJpZW5jZXMgKGUuZy4sIHJvYW1pbmcpIGFyZSBpbmNsdWRlZCBpbiB0aGlzIHByb2Zp bGUuICBBbHNvLCB0aGlzDQogICBwcm9maWxlIHNrZXRjaGVzIHJlY29tbWVuZGF0aW9ucyBmb3Ig dGhlIHNha2Ugb2YgZGV0ZXJtaW5pc3RpYw0KICAgYmVoYXZpb3JzIG9mIGNlbGx1bGFyIGRldmlj ZXMgd2hlbiB0aGUgc2FtZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQogICBpcyByZWNlaXZl ZCBvdmVyIHNldmVyYWwgY2hhbm5lbHMuDQoNCiAgIEZvciBjb25mbGljdGluZyByZWNvbW1lbmRh dGlvbnMgaW4gW1JGQzcwNjZdIGFuZCBbUkZDNjQzNF0gKGUuZy4sDQogICBOZWlnaGJvciBEaXNj b3ZlcnkgUHJvdG9jb2wpLCB0aGlzIHByb2ZpbGUgYWRoZXJlcyB0byBbUkZDNzA2Nl0uDQogICBJ bmRlZWQsIHRoZSBzdXBwb3J0IG9mIE5laWdoYm9yIERpc2NvdmVyeSBQcm90b2NvbCBpcyBtYW5k YXRvcnkgaW4NCiAgIDNHUFAgY2VsbHVsYXIgZW52aXJvbm1lbnQgYXMgaXQgaXMgdGhlIG9ubHkg d2F5IHRvIGNvbnZleSBJUHY2IHByZWZpeA0KICAgdG93YXJkcyB0aGUgM0dQUCBjZWxsdWxhciBk ZXZpY2UuICBJbiBwYXJ0aWN1bGFyLCBNVFUgKE1heGltdW0NCiAgIFRyYW5zbWlzc2lvbiBVbml0 KSBjb21tdW5pY2F0aW9uIHZpYSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtdXN0IGJlDQogICBzdXBw b3J0ZWQgc2luY2UgbWFueSAzR1BQIG5ldHdvcmtzIGRvIG5vdCBoYXZlIGEgc3RhbmRhcmQgTVRV DQogICBzZXR0aW5nLg0KDQogICBUaGlzIHByb2ZpbGUgdXNlcyBhIHN0cm9uZ2VyIGxhbmd1YWdl IGZvciB0aGUgc3VwcG9ydCBvZiBQcmVmaXgNCiAgIERlbGVnYXRpb24gY29tcGFyZWQgdG8gW1JG QzcwNjZdLiAgVGhlIG1haW4gbW90aXZhdGlvbiBpcyB0aGF0DQogICBjZWxsdWxhciBuZXR3b3Jr cyBhcmUgbW9yZSBhbmQgbW9yZSBwZXJjZWl2ZWQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8NCiAgIGZp eGVkIG5ldHdvcmtzIGZvciBob21lIElQLWJhc2VkIHNlcnZpY2VzIGRlbGl2ZXJ5OyBlc3BlY2lh bGx5IHdpdGgNCiAgIHRoZSBhZHZlbnQgb2Ygc21hcnRwaG9uZXMgYW5kIDNHUFAgZGF0YSBkb25n bGVzLiAgVGhlcmUgaXMgYSBuZWVkIGZvcg0KICAgYW4gZWZmaWNpZW50IG1lY2hhbmlzbSB0byBh c3NpZ24gc2hvcnRlciBwcmVmaXggdGhhbiAvNjQgdG8gY2VsbHVsYXINCiAgIGhvc3RzIHNvIHRo YXQgZWFjaCBMQU4gc2VnbWVudCBjYW4gZ2V0IGl0cyBvd24gLzY0IHByZWZpeCBhbmQgbXVsdGkt DQogICBsaW5rIHN1Ym5ldCBpc3N1ZXMgdG8gYmUgYXZvaWRlZC4gIFRoZSBzdXBwb3J0IG9mIHRo aXMgZnVuY3Rpb25hbGl0eQ0KICAgaW4gYm90aCBjZWxsdWxhciBhbmQgZml4ZWQgbmV0d29ya3Mg aXMga2V5IGZvciBmaXhlZC1tb2JpbGUNCiAgIGNvbnZlcmdlbmNlLg0KDQoNCklQdjYgZGVwbG95 bWVudCBvbiBtb2JpbGUgbmV0d29ya3MgKG9rLCBwZXJoYXBzIG5vdCB0aG9zZSBvZiB0aGUgYXV0 aG9ycykNCg0KW01lZF0gSSB0aG91Z2h0IHlvdSBhbHJlYWR5IG1lbnRpb25lZCBPcmFuZ2UgaW4g b25lIG9mIHlvdXIgYW5zd2VyIGFzIGFuIGV4YW1wbGUgb2YgdGhvc2UgZGVwbG95aW5nIElQdjYg KGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cy MTM5OS5odG1sKS4gQW55d2F5LCBhbGwgdGhlIG9wZXJhdG9ycyBjby1hdXRob3JpbmcgdGhpcyBk cmFmdCBhcmUgYWN0aXZlIGluIElQdjYgZGVwbG95bWVudC4NCg0KaXMgaGFwcGVuaW5nIG5vdy4g VGVucyBvZiBtaWxsaW9ucyBvZiBtb2JpbGUgZGV2aWNlcyBhcmUgcnVubmluZyBJUHY2IHRvZGF5 LiBBbmQgYSBsb3Qgb2YgaXQgaGFwcGVuZWQgYmVmb3JlIHRoaXMgZHJhZnQgd2FzIGV2ZW4gd3Jp dHRlbi4NCg0KW01lZF0gVGhpcyBkcmFmdCB3YXMgZWRpdGVkIGJlY2F1c2Ugb3BlcmF0b3JzIGhh dmluZyBJUHY2IGRlcGxveW1lbnQgcHJvamVjdCBhcmUgc2Vla2luZyBmb3IgYSByZWZlcmVuY2Ug ZG9jdW1lbnQgZm9yIHRoZSBkZXZpY2UgcGFydC4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490E5EEOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQpzcGFuLm1mdHINCgl7bXNvLXN0eWxlLW5hbWU6bV9mdHI7fQ0Kc3Bhbi5taGRyDQoJ e21zby1zdHlsZS1uYW1lOm1faGRyO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc2MDI0ODQ5NzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5NDEyNzU5MjIgMTEzMTg0MTc2 OCA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2 Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNl ZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAxOSBmw6l2cmllciAy MDE1IDEzOjQ4PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBIZWF0bGV5LCBOaWNrOyBDYSBCeTsgSVB2NiBPcHMgV0cg KHY2b3BzQGlldGYub3JnKTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJt ZnVsbHkgYnJvYWQmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMTksIDIwMTUgYXQgOToz MiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5JdCBpcyBvYnZpb3VzIHRoZXJlIGlzIGEgdm9pZCBmaWxsZWQg YnkgdGhpcyBkcmFmdC4gSXQgaXMgYnVpbHQgb24gZXhpc3RpbmcgUkZDcyBhbHJlYWR5IHB1Ymxp c2hlZCBpbiB0aGlzIGFyZWEuDQogVGhpcyBkb2N1bWVudCBpcyBub3Qgb3JpZ2luYWwgaW4gaXRz IGFtYml0aW9uIG5vciBpdCBpcyBkaWZmZXJlbnQgaW4gaXRzIHN0cnVjdHVyZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWN0dWFsbHksIEkgZG9uJ3Qgc2VlIGEgdm9pZC48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TaG9ydCBhbnN3ZXImbmJzcDs6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIHZvaWQgaXMgKGF0 IGxlYXN0KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkV4aXN0aW5nIHByb2ZpbGUgUkZDIGRvZXMgbm90IGNvdmVyIElQdjQgc2Vydmlj ZSBjb250aW51aXR5IGZlYXR1cmVzLCBkZXZpY2VzIHdpdGggbGFuIGNhcGFiaWxpdGllcywgZXRj Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5FeGlzdGluZyBwcm9maWxlIFJGQ3MgY29uZmxpY3RzIHdpdGggb3RoZXIgb3RoZXJzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ VGhlcmUgYXJlIHN0aWxsIGJyb2tlbiBJUHY2IGltcGxlbWVudGF0aW9ucy4gRGV0ZXJtaW5pc3Rp YyBiZWhhdmlvcnMgaXMgZW5jb3VyYWdlZC4gU2F5aW5nIGEgZGV2aWNlIHN1cHBvcnRzIElQdjYg aXMgbWVhbmluZ2xlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkxvbmcgdmVyc2lvbjogaXMgZG9jdW1lbnRlZCBpbiB0aGUgSS1EIHRoYXQgSSBz dXBwb3NlIHlvdSBhbHJlYWR5IHJlYWQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+VGhpcyBwcm9maWxlIGlzIGEgc3VwZXJzZXQgb2YgdGhhdCBvZiB0aGUgSVB2NiBw cm9maWxlIGZvciAzR1BQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ2VsbHVsYXIgSG9zdHMgW1JG QzcwNjZdLCB3aGljaCBpcyBpbiB0dXJuIGEgc3VwZXJzZXQgb2YgSVB2NiBOb2RlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgUmVxdWlyZW1lbnRzIFtSRkM2NDM0XS4mbmJzcDsgSXQgdGFyZ2V0cyBj ZWxsdWxhciBub2RlcywgaW5jbHVkaW5nIEdQUlMgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg RVBDIChFdm9sdmVkIFBhY2tldCBDb3JlKSwgdGhhdCByZXF1aXJlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgZmVhdHVyZXMgdG8gZW5zdXJlIElQdjQgc2VydmljZSBkZWxpdmVyeSBvdmVyIGFuIElQ djYtb25seSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbiBhZGRpdGlvbiB0byB0 aGUgYmFzZSBJUHY2IHNlcnZpY2UuJm5ic3A7IE1vcmVvdmVyLCB0aGlzIHByb2ZpbGUgY292ZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY2VsbHVsYXIgQ1BFcyB0aGF0IGFyZSB1c2VkIGluIHZh cmlvdXMgZGVwbG95bWVudHMgdG8gb2ZmZXIgZml4ZWQtPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg bGlrZSBzZXJ2aWNlcy4mbmJzcDsgUmVjb21tZW5kYXRpb25zIGluc3BpcmVkIGZyb20gcmVhbCBk ZXBsb3ltZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhwZXJpZW5jZXMgKGUuZy4sIHJvYW1p bmcpIGFyZSBpbmNsdWRlZCBpbiB0aGlzIHByb2ZpbGUuJm5ic3A7IEFsc28sIHRoaXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBwcm9maWxlIHNrZXRjaGVzIHJlY29tbWVuZGF0aW9ucyBmb3IgdGhl IHNha2Ugb2YgZGV0ZXJtaW5pc3RpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGJlaGF2aW9ycyBv ZiBjZWxsdWxhciBkZXZpY2VzIHdoZW4gdGhlIHNhbWUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGlzIHJlY2VpdmVkIG92ZXIgc2V2ZXJhbCBjaGFubmVs cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEZvciBjb25mbGljdGlu ZyByZWNvbW1lbmRhdGlvbnMgaW4gW1JGQzcwNjZdIGFuZCBbUkZDNjQzNF0gKGUuZy4sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgTmVpZ2hib3IgRGlzY292ZXJ5IFByb3RvY29sKSwgdGhpcyBwcm9m aWxlIGFkaGVyZXMgdG8gW1JGQzcwNjZdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluZGVlZCwg dGhlIHN1cHBvcnQgb2YgTmVpZ2hib3IgRGlzY292ZXJ5IFByb3RvY29sIGlzIG1hbmRhdG9yeSBp bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IDNHUFAgY2VsbHVsYXIgZW52aXJvbm1lbnQgYXMgaXQg aXMgdGhlIG9ubHkgd2F5IHRvIGNvbnZleSBJUHY2IHByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwO3Rvd2FyZHMgdGhlIDNHUFAgY2VsbHVsYXIgZGV2aWNlLiZuYnNwOyBJbiBwYXJ0aWN1bGFy LCBNVFUgKE1heGltdW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUcmFuc21pc3Npb24gVW5pdCkg Y29tbXVuaWNhdGlvbiB2aWEgUm91dGVyIEFkdmVydGlzZW1lbnQgbXVzdCBiZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCBzaW5jZSBtYW55IDNHUFAgbmV0d29ya3MgZG8gbm90IGhh dmUgYSBzdGFuZGFyZCBNVFU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzZXR0aW5nLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhpcyBwcm9maWxlIHVzZXMgYSBzdHJv bmdlciBsYW5ndWFnZSBmb3IgdGhlIHN1cHBvcnQgb2YgUHJlZml4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgRGVsZWdhdGlvbiBjb21wYXJlZCB0byBbUkZDNzA2Nl0uJm5ic3A7IFRoZSBtYWluIG1v dGl2YXRpb24gaXMgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNlbGx1bGFyIG5ldHdvcmtz IGFyZSBtb3JlIGFuZCBtb3JlIHBlcmNlaXZlZCBhcyBhbiBhbHRlcm5hdGl2ZSB0bzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGZpeGVkIG5ldHdvcmtzIGZvciBob21lIElQLWJhc2VkIHNlcnZpY2Vz IGRlbGl2ZXJ5OyBlc3BlY2lhbGx5IHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgYWR2 ZW50IG9mIHNtYXJ0cGhvbmVzIGFuZCAzR1BQIGRhdGEgZG9uZ2xlcy4mbmJzcDsgVGhlcmUgaXMg YSBuZWVkIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFuIGVmZmljaWVudCBtZWNoYW5pc20g dG8gYXNzaWduIHNob3J0ZXIgcHJlZml4IHRoYW4gLzY0IHRvIGNlbGx1bGFyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgaG9zdHMgc28gdGhhdCBlYWNoIExBTiBzZWdtZW50IGNhbiBnZXQgaXRzIG93 biAvNjQgcHJlZml4IGFuZCBtdWx0aS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBsaW5rIHN1Ym5l dCBpc3N1ZXMgdG8gYmUgYXZvaWRlZC4mbmJzcDsgVGhlIHN1cHBvcnQgb2YgdGhpcyBmdW5jdGlv bmFsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW4gYm90aCBjZWxsdWxhciBhbmQgZml4ZWQg bmV0d29ya3MgaXMga2V5IGZvciBmaXhlZC1tb2JpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5jb252ZXJnZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklQdjYgZGVwbG95bWVudCBvbiBt b2JpbGUgbmV0d29ya3MgKG9rLCBwZXJoYXBzIG5vdCB0aG9zZSBvZiB0aGUgYXV0aG9ycykNCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJIHRob3VnaHQgeW91IGFscmVhZHkgbWVu dGlvbmVkIE9yYW5nZSBpbiBvbmUgb2YgeW91ciBhbnN3ZXIgYXMgYW4gZXhhbXBsZSBvZiB0aG9z ZSBkZXBsb3lpbmcgSVB2NiAoPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzIxMzk5Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cyMTM5OS5odG1sPC9hPikuDQogQW55 d2F5LCBhbGwgdGhlIG9wZXJhdG9ycyBjby1hdXRob3JpbmcgdGhpcyBkcmFmdCBhcmUgYWN0aXZl IGluIElQdjYgZGVwbG95bWVudC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+aXMgaGFwcGVuaW5nIG5vdy4gVGVucyBvZiBtaWxsaW9ucyBvZiBtb2JpbGUgZGV2aWNl cyBhcmUgcnVubmluZyBJUHY2IHRvZGF5LiBBbmQgYSBsb3Qgb2YgaXQgaGFwcGVuZWQgYmVmb3Jl IHRoaXMgZHJhZnQgd2FzIGV2ZW4gd3JpdHRlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhpcyBkcmFmdCB3YXMgZWRpdGVkIGJlY2F1 c2Ugb3BlcmF0b3JzIGhhdmluZyBJUHY2IGRlcGxveW1lbnQgcHJvamVjdCBhcmUgc2Vla2luZyBm b3IgYSByZWZlcmVuY2UgZG9jdW1lbnQgZm9yIHRoZSBkZXZpY2UgcGFydC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490E5EEOPEXCLILM23corp_-- From nobody Thu Feb 19 05:23:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E1A1A9075 for ; Thu, 19 Feb 2015 05:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L9MTpevlOjG for ; Thu, 19 Feb 2015 05:23:02 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9AA1A86EA for ; Thu, 19 Feb 2015 05:23:01 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so44064617igk.1 for ; Thu, 19 Feb 2015 05:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rnDBv6BWzuiZwi4oVlG1JFFV7g/oWcrTtdtvKF/VzLE=; b=bGCwKnIynVycaF41dE+nKz8EpX5y5bMs1t2gJKcaaQllqX5WHnSnKvB/vx7ZTbdsdj PsP98EgNi5ZsjwllfggjrMnUal6WHHut/y+bkKGkjE/n6nL0DR8kTc+AF6oyDQniDqFO PNxlGpH9YDpjToSXliJnVY8M3O0mpHcGnapjFj4g1BRJ1ItXkhUv2VA7JXesAxBHN+sJ 9L3WH0ymyrWJj8hyhl0j0MFiL6R5hli7VL00AuPxa+0J6Je10K60ByKpkKLM3rZQFrhY 67FIhACTzdv/PndP9b30fNQC0XvQ4oIA3de4E4SgWL/8usdtBMMoshuKMa0qAq9o0GNQ YzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rnDBv6BWzuiZwi4oVlG1JFFV7g/oWcrTtdtvKF/VzLE=; b=RzqN/DBmRWbTmz6VIDUnFXYms3nsGacaN0ki55nVNYukx0CSAtodfP/5YohssWRpXP wjHrUSDqTfIPRzMt+Zbsfi9KBwHwuNJV1DJuJhXI2Dwd75GyRiSCjGT+CEArCM2OtK0H GGn5kmO6ALhzOsvHVOGBgz4hUW53/V1/MWDIvxVkzzRv6zoVgtIrCxWpKYaNLSnW80zO EZVVUcgtJsCUfYA1wR+dBMthTCapHz8QcFQVZCYYX1Mv0BLDKfYhHdyirYhtFFbWBODz r/ZgBwyjolNtTuMXA43MnyVY4D7noE0WwlHvHlAPY16XwOBfbo4BbHu30OIGYCfLi8b2 Wkgw== X-Gm-Message-State: ALoCoQn2JtLYXLJasgSMYhJP285qXEyC4g1cR8LcteDmeIzlfHqtU4KnZEuNGVCTcsDblqKy2WfR X-Received: by 10.50.32.71 with SMTP id g7mr9979887igi.4.1424352180684; Thu, 19 Feb 2015 05:23:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 05:22:39 -0800 (PST) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 22:22:39 +0900 Message-ID: To: Dave Michaud Content-Type: multipart/alternative; boundary=047d7b10cb2dc3fc29050f70d554 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:23:03 -0000 --047d7b10cb2dc3fc29050f70d554 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 10:10 PM, Dave Michaud wrote: > The documents published under v6ops should "serve as useful guides to > network > operators and users on possible ways how to deploy IPv6 within their > existing IPv4 networks, as well as in new network installations.=E2=80=9D > Guides on how to deploy, yes. Not lists of features. Example: a document describing a single-stack deployment using IPv6-only and 464xlat, explaining what is required of the network, what infrastructural pieces need to be deployed, how things need to work, and how hosts need to behave - that's a guide on how to deploy. A list of lots of (some important, some optional) features of mobile devices is not a guide on how to deploy. --047d7b10cb2dc3fc29050f70d554 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 10:10 PM, Dave Michaud <Dave.Michaud@rci.rog= ers.com> wrote:
The documents published under v6ops should "serve= as useful guides to network
operators and users on possible ways how= to deploy IPv6 within their
existing IPv4 networks, as well as in ne= w network installations.=E2=80=9D=

Guides on how to deploy, yes. = Not lists of features.

Example: a document describ= ing a single-stack deployment using IPv6-only and 464xlat, explaining what = is required of the network, what infrastructural pieces need to be deployed= , how things need to work, and how hosts need to behave - that's a guid= e on how to deploy.

A list of lots of (some import= ant, some optional) features of mobile devices is not a guide on how to dep= loy.
--047d7b10cb2dc3fc29050f70d554-- From nobody Thu Feb 19 05:27:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8B1A9045 for ; Thu, 19 Feb 2015 05:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd8_4Nlx3rQ5 for ; Thu, 19 Feb 2015 05:27:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8876A1A906C for ; Thu, 19 Feb 2015 05:27:41 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id AB5DC3B40FF; Thu, 19 Feb 2015 14:27:39 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 878A9C80AF; Thu, 19 Feb 2015 14:27:39 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 14:27:34 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEZgixBJZ1L350WogIuKXDMPO5z39TkQ Date: Thu, 19 Feb 2015 13:27:34 +0000 Message-ID: <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9ee5ae8c95664e50afae38e96e1247fcOPEXCLILH01corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.124820 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:27:44 -0000 --_000_9ee5ae8c95664e50afae38e96e1247fcOPEXCLILH01corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDE5 IGbDqXZyaWVyIDIwMTUgMTQ6MTcNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2Mg OiBEYXZlIE1pY2hhdWQ7IEJJTkVUIERhdmlkIElNVC9PTE47IElQdjYgT3BzIFdHICh2Nm9wc0Bp ZXRmLm9yZykNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24gVGh1LCBGZWIg MTksIDIwMTUgYXQgMTA6MDMgUE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCltNZWRdIEh1bW1t4oCm IEkgc3VnZ2VzdCB5b3UgaGF2ZSBhIHF1aWNrIGxvb2sgYXQgdGhpcyBwYWdlIDogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy92Nm9wcy9kb2N1bWVudHMvIChoaW50OiBzZWFyY2ggZm9y IOKAmGhvc3TigJkgb3Ig4oCYQ1BF4oCZKS4NCg0KVGhlIHNlYXJjaCBzYXlzIHRoYXQgYSBzaW5n bGUtZGlnaXQgcGVyY2VudGFnZSBvZiB0aGUgZG9jdW1lbnRzIGNvbnRhaW4gdGhlIHdvcmQgImhv c3QiIG9yICJDUEUiIGluIHRoZSB0aXRsZS4gV2hhdCBwb2ludCBhcmUgeW91IHRyeWluZyB0byBt YWtlPyBUaGF0IHRoZSBjaGFydGVyIGlzIGluYXBwcm9wcmlhdGUsIGJlY2F1c2UgaXQgZG9lc24n dCBtZW50aW9uIGhvc3RzLCBidXQgdGhlIFdHIGhhcyBwdWJsaXNoZWQgYSBmZXcgZG9jdW1lbnRz IHRoYXQgdGFsayBhYm91dCBob3N0cz8NCg0KW01lZF0gVGhlIGFuc3dlciBpcyBvYnZpb3VzIDog dGhlIFdHIGhhcyBubyBwcm9ibGVtIHRvIHB1Ymxpc2ggc3VjaCBkb2N1bWVudHMuDQoNCkluIGZh Y3QsIGlmIHlvdSBsb29rIGF0IHRoZSBudW1iZXJlZCBsaXN0IGluIHRoZSBjaGFydGVyLCB0aGUg aXRlbXMgYXJlICJpZGVudGlmeSBvcGVyYXRpb25hbCBpc3N1ZXMgYW5kIGRldGVybWluZSBzb2x1 dGlvbnMiLCAiaWRlbnRpZnkgcG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzIiwgImlkZW50aWZ5IHBv cnRpb25zIG9mIHRoZSBzcGVjcyB0aGF0IGNhbiBjYXVzZSBvcGVyYXRpb25hbCBjb25jZXJucyIs IGFuZCAiYW5hbHl6ZSBzb2x1dGlvbnMgZm9yIGRlcGxveWluZyBJUHY2IHdpdGhpbiBuZXR3b3Jr IGVudmlyb25tZW50cyIuIE5vbmUgb2YgdGhvc2UgY292ZXIgdGhpcyBkb2N1bWVudC4NCg0KW01l ZF0gSXMgdGhpcyBhIGpva2U/IFlvdXIgYXNzZXJ0aW9uIGlzIGVycm9uZW91cy4gSSB3aWxsIHRh a2Ugb25lIGl0ZW0gcmFuZG9tbHkgZnJvbSB0aGUgSS1EIHRvIGlsbHVzdHJhdGUgdGhlIGZpcnN0 IGl0ZW0gaW4geW91ciBsaXN0Og0KDQogICBDX1JFQyM3OiAgQmVjYXVzZSBvZiBwb3RlbnRpYWwg b3BlcmF0aW9uYWwgZGVmaWNpZW5jaWVzIHRvIGJlDQogICAgICAgICAgICAgZXhwZXJpZW5jZWQg aW4gc29tZSByb2FtaW5nIHNpdHVhdGlvbnMsIHRoZSBjZWxsdWxhciBob3N0DQogICAgICAgICAg ICAgbXVzdCBiZSBhYmxlIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIGhvbWUgUERQLUNvbnRleHQN CiAgICAgICAgICAgICB0eXBlKHMpIGFuZCBhIHJvYW1pbmcgUERQLUNvbnRleHQgdHlwZShzKS4N Cg0KVGhhdCdzIGEgZ3JlYXQgZXhhbXBsZSB0byBwaWNrLCBiZWNhdXNlIHRoZSBXRyBpcyBhYm91 dCB0byBwcm9kdWNlIGFuIFJGQyBvbiBwcmVjaXNlbHkgdGhpcyB0b3BpYyAtIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtaXB2Ni1yb2FtaW5nLWFuYWx5 c2lzLyAuDQoNCltNZWRdIEkgY2FuIGluZm9ybSB5b3UgdGhpcyB3aWxsIGJlIHB1Ymxpc2hlZCBh cyBSRkM3NDQ1LiBJdCBoYXBwZW5zIEnigJltIGNvLWF1dGhvciB0aGF0IGRvY3VtZW50LCBzbyBJ 4oCZbSBub3QgZGlzY292ZXJpbmcgaXQuIEZ1cnRoZXJtb3JlLCB0aGlzIGlzIGNpdGVkIGluIHRo ZSBtb2JpbGUgcHJvZmlsZSBkcmFmdDoNCg0KICAgICAgICAgICAgICAgIEEgZGV0YWlsZWQgYW5h bHlzaXMgb2Ygcm9hbWluZyBmYWlsdXJlIGNhc2VzIGlzIGluY2x1ZGVkDQogICAgICAgICAgICAg ICAgaW4gW1JGQzc0NDVdLg0KDQpUaGF0IGRvY3VtZW50IGlzIGEgZ29vZCBleGFtcGxlIG9mIHdo YXQgKmlzKiBpbiBjaGFydGVyIG9mIHRoZSBXRzogYW4gaW4tZGVwdGgsIGRldGFpbGVkIGRpc2N1 c3Npb24gb2YgdGhlIG9wZXJhdGlvbmFsIGlzc3Vlcy4gOCBsaW5lcyBvZiB0ZXh0IHNheWluZyAi ZGV2aWNlcyBtdXN0IHN1cHBvcnQgZGlmZmVyZW50IFBEUCB0eXBlcyBmb3IgaG9tZSBhbmQgcm9h bWluZyIgaXMgbm90Lg0KDQpbTWVkXSBUaGVyZSBpcyBubyByZWNvbW1lbmRhdGlvbiBpbiB0aGUg cm9hbWluZyBhbmFseXNpcyBkcmFmdC4gVGhlIHByb2ZpbGUgZG9jdW1lbnQgaW5jbHVkZXMgYSBj bGVhciByZWNvbW1lbmRhdGlvbiBvbiB0aGUgY3VycmVudCBwbGFuIG9mIG1vc3Qgb3BlcmF0b3Jz IHRvIGhhbmRsZSB0aGUgcm9hbWluZyBpc3N1ZS4gV2UgZG9u4oCZdCBuZWVkIGh1bmRyZWRzIG9m IHBhZ2VzIGZvciB0aGF0Lg0K --_000_9ee5ae8c95664e50afae38e96e1247fcOPEXCLILH01corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUtLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56byBD b2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNw Ozo8L2I+IGpldWRpIDE5IGbDqXZyaWVyIDIwMTUgMTQ6MTc8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+ IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IERhdmUgTWlj aGF1ZDsgQklORVQgRGF2aWQgSU1UL09MTjsgSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnKTxi cj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2Jp bGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMTksIDIwMTUgYXQgMTA6MDMgUE0sICZsdDs8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KW01l ZF0gSHVtbW3igKYgSSBzdWdnZXN0IHlvdSBoYXZlIGEgcXVpY2sgbG9vayBhdCB0aGlzIHBhZ2Um bmJzcDs6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdjZvcHMvZG9j dW1lbnRzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy92Nm9wcy9kb2N1bWVudHMvPC9hPiAoaGludDogc2VhcmNoIGZvciDigJhob3N04oCZIG9yIOKA mENQReKAmSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2VhcmNoIHNheXMgdGhh dCBhIHNpbmdsZS1kaWdpdCBwZXJjZW50YWdlIG9mIHRoZSBkb2N1bWVudHMgY29udGFpbiB0aGUg d29yZCAmcXVvdDtob3N0JnF1b3Q7IG9yICZxdW90O0NQRSZxdW90OyBpbiB0aGUgdGl0bGUuIFdo YXQgcG9pbnQgYXJlIHlvdSB0cnlpbmcgdG8gbWFrZT8gVGhhdCB0aGUgY2hhcnRlciBpcyBpbmFw cHJvcHJpYXRlLCBiZWNhdXNlIGl0IGRvZXNuJ3QgbWVudGlvbiBob3N0cywgYnV0IHRoZSBXRyBo YXMgcHVibGlzaGVkDQogYSBmZXcgZG9jdW1lbnRzIHRoYXQgdGFsayBhYm91dCBob3N0cz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFRoZSBhbnN3ZXIgaXMgb2J2aW91cyZu YnNwOzogdGhlIFdHIGhhcyBubyBwcm9ibGVtIHRvIHB1Ymxpc2ggc3VjaCBkb2N1bWVudHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGZhY3QsIGlmIHlvdSBsb29rIGF0IHRoZSBudW1iZXJl ZCBsaXN0IGluIHRoZSBjaGFydGVyLCB0aGUgaXRlbXMgYXJlICZxdW90O2lkZW50aWZ5IG9wZXJh dGlvbmFsIGlzc3VlcyBhbmQgZGV0ZXJtaW5lIHNvbHV0aW9ucyZxdW90OywgJnF1b3Q7aWRlbnRp ZnkgcG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzJnF1b3Q7LA0KICZxdW90O2lkZW50aWZ5IHBvcnRp b25zIG9mIHRoZSBzcGVjcyB0aGF0IGNhbiBjYXVzZSBvcGVyYXRpb25hbCBjb25jZXJucyZxdW90 OywgYW5kICZxdW90O2FuYWx5emUgc29sdXRpb25zIGZvciBkZXBsb3lpbmcgSVB2NiB3aXRoaW4g bmV0d29yayBlbnZpcm9ubWVudHMmcXVvdDsuDQo8L3NwYW4+Tm9uZSBvZiB0aG9zZSBjb3ZlciB0 aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIElz IHRoaXMgYSBqb2tlPyBZb3VyIGFzc2VydGlvbiBpcyBlcnJvbmVvdXMuIEkgd2lsbCB0YWtlIG9u ZSBpdGVtIHJhbmRvbWx5IGZyb20gdGhlIEktRCB0bw0KIGlsbHVzdHJhdGUgdGhlIGZpcnN0IGl0 ZW0gaW4geW91ciBsaXN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IENfUkVDIzc6Jm5ic3A7IEJlY2F1c2Ugb2YgcG90ZW50aWFsIG9wZXJh dGlvbmFsIGRlZmljaWVuY2llcyB0byBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhw ZXJpZW5jZWQgaW4gc29tZSByb2FtaW5nIHNpdHVhdGlvbnMsIHRoZSBjZWxsdWxhciBob3N0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdXN0IGJlIGFibGUgdG8gYmUgY29uZmlndXJlZCB3 aXRoIGEgaG9tZSBQRFAtQ29udGV4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZShz KSBhbmQgYSByb2FtaW5nIFBEUC1Db250ZXh0IHR5cGUocykuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCdzIGEgZ3JlYXQgZXhhbXBsZSB0byBwaWNrLCBiZWNhdXNlIHRo ZSBXRyBpcyBhYm91dCB0byBwcm9kdWNlIGFuIFJGQyBvbiBwcmVjaXNlbHkgdGhpcyB0b3BpYyAt DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2 b3BzLWlwdjYtcm9hbWluZy1hbmFseXNpcy8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMvPC9hPiAuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBjYW4gaW5mb3Jt IHlvdSB0aGlzIHdpbGwgYmUgcHVibGlzaGVkIGFzIFJGQzc0NDUuIEl0IGhhcHBlbnMgSeKAmW0g Y28tYXV0aG9yIHRoYXQgZG9jdW1lbnQsIHNvIEnigJltIG5vdCBkaXNjb3ZlcmluZyBpdC4gRnVy dGhlcm1vcmUsIHRoaXMgaXMgY2l0ZWQgaW4NCiB0aGUgbW9iaWxlIHByb2ZpbGUgZHJhZnQ6IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQSBkZXRhaWxlZCBhbmFseXNpcyBvZiByb2FtaW5nIGZhaWx1cmUgY2Fz ZXMgaXMgaW5jbHVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpbiBbUkZDNzQ0NV0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhhdCBkb2N1bWVudCBpcyBhIGdvb2QgZXhhbXBsZSBvZiB3aGF0ICppcyogaW4g Y2hhcnRlciBvZiB0aGUgV0c6IGFuIGluLWRlcHRoLCBkZXRhaWxlZCBkaXNjdXNzaW9uIG9mIHRo ZSBvcGVyYXRpb25hbCBpc3N1ZXMuDQo8L3NwYW4+OCBsaW5lcyBvZiB0ZXh0IHNheWluZyAmcXVv dDtkZXZpY2VzIG11c3Qgc3VwcG9ydCBkaWZmZXJlbnQgUERQIHR5cGVzIGZvciBob21lIGFuZCBy b2FtaW5nJnF1b3Q7IGlzIG5vdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRd IFRoZXJlIGlzIG5vIHJlY29tbWVuZGF0aW9uIGluIHRoZSByb2FtaW5nIGFuYWx5c2lzIGRyYWZ0 LiBUaGUgcHJvZmlsZSBkb2N1bWVudCBpbmNsdWRlcyBhIGNsZWFyIHJlY29tbWVuZGF0aW9uIG9u IHRoZSBjdXJyZW50IHBsYW4gb2YgbW9zdCBvcGVyYXRvcnMNCiB0byBoYW5kbGUgdGhlIHJvYW1p bmcgaXNzdWUuIFdlIGRvbuKAmXQgbmVlZCBodW5kcmVkcyBvZiBwYWdlcyBmb3IgdGhhdC4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9ee5ae8c95664e50afae38e96e1247fcOPEXCLILH01corporateadr_-- From nobody Thu Feb 19 05:36:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63881A8786 for ; Thu, 19 Feb 2015 05:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwTeEJJ7frxv for ; Thu, 19 Feb 2015 05:36:14 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6251A8033 for ; Thu, 19 Feb 2015 05:36:14 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so43952036igd.4 for ; Thu, 19 Feb 2015 05:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qLS+k0ysvi20vEg0zCsjzRDX+tIROYh0fGB3gn9IX5Y=; b=em4UYFuKCaWTNae2niBhS87uJ37Leqkk62dBXsa/rzEe9+5NAyQj7IcyE2ZyDCpbF8 VbjvGKxWMDJG4aIRE3otIpSr558z8GzDo5GAIEloTe8yFVC9NyJ8YwtRZwM11uvBmSpn GDiAQETpKknu5Xh1KHFbhdwxqePcJr1PlvLUfug+mwRLtFAv6TFkCmujnpBqFVYAyvad ASxLsSdxX/WTuAdOdcyOh9r7k8JCXPQOlekrQhXPvD4jS5ohFQBWCPwg8cL9MgeqMumx IPGr4mB1POJkbYWeFPcC+KfzZiXxv8W+zoXyJXwbc6lEjQBII30u6K2XvzNSDFHw23DU 6kWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qLS+k0ysvi20vEg0zCsjzRDX+tIROYh0fGB3gn9IX5Y=; b=b4GWfxK1cbhBkEKGjCVn2IHvsVTGmr7kxb4MVG3RjBRhD3yZ6s7gD16MysD92Am6kz MLzkgf4ByYkYaHwp69HQWfiVGvbCl170g2ZLlxGzKTbNmyETto0mP0novr1hxVkt6/5F acjy+8DKV1AmzAKEIGj+DB5FPNXANFmROO2p3ZcAD5WzrQxhz94TIdrsuq+14wdtNnFN +6curFj1nns6ltZha52BNGx1lKbPVUC6RE+XMF2N9ELzygck9Qfk2lJN1VQhe96fCCRt qp1+nsrde8lVMxOQe3YXEm8D3IyLS+fEoRaWSsVZ/OZ6cyOJJ9i4ov4THEANt5o2Awg/ iUmQ== X-Gm-Message-State: ALoCoQklqEiq1rpyiDKDyL+weaEDAqLwFL0uVy99ct5yNsSNMzjaoMux3hRuV3zDkjQJ/6B55NQG X-Received: by 10.107.134.103 with SMTP id i100mr6013566iod.90.1424352973710; Thu, 19 Feb 2015 05:36:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 05:35:53 -0800 (PST) In-Reply-To: <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 22:35:53 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113ece62089f39050f7105ff Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:36:16 -0000 --001a113ece62089f39050f7105ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 10:27 PM, wrote: > > [Med] Hummm=E2=80=A6 I suggest you have a quick look at this page : > https://datatracker.ietf.org/wg/v6ops/documents/ (hint: search for =E2=80= =98host=E2=80=99 > or =E2=80=98CPE=E2=80=99). > > > > The search says that a single-digit percentage of the documents contain > the word "host" or "CPE" in the title. What point are you trying to make? > That the charter is inappropriate, because it doesn't mention hosts, but > the WG has published a few documents that talk about hosts? > > > > [Med] The answer is obvious : the WG has no problem to publish such > documents. > Not really. If you go and read those documents, you'll see none of them is on host requirements. And in any case, the discussion was whether this document is "directly in line with the v6ops charter", as Dave said. Just because the WG happens to have published a few documents that talk about hosts doesn't mean that host requirements are directly in line with the charter. > In fact, if you look at the numbered list in the charter, the items are > "identify operational issues and determine solutions", "identify potentia= l > security risks", "identify portions of the specs that can cause operation= al > concerns", and "analyze solutions for deploying IPv6 within network > environments". None of those cover this document. > > That's a great example to pick, because the WG is about to produce an > RFC on precisely this topic - > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ = . > > > > [Med] I can inform you this will be published as RFC7445. It happens I=E2= =80=99m > co-author that document, so I=E2=80=99m not discovering it. > That's why I picked it, yes. > That document is a good example of what *is* in charter of the WG: an > in-depth, detailed discussion of the operational issues. 8 lines of text > saying "devices must support different PDP types for home and roaming" is > not. > > > > [Med] There is no recommendation in the roaming analysis draft. The > profile document includes a clear recommendation on the current plan of > most operators to handle the roaming issue. > But it's not the role of the IETF or of this working group to make statements about operator plans. It's the IETF's role to discuss technical standards, and this group's role to provide operational guidance. "Operators X, Y, and Z are handling the roaming issue like this" is not operational guidance. An in-depth discussion of the problem, such as draft-ietf-v6ops-ipv6-roaming-analysis, is. --001a113ece62089f39050f7105ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 19, 2015 at 10:27 PM, <mohamed.boucadai= r@orange.com> wrote:


[Med] Hummm=E2=80=A6 I suggest you ha= ve a quick look at this page=C2=A0: https://datatracker.ietf.org/wg/v6ops/documents/ (hint: search for =E2= =80=98host=E2=80=99 or =E2=80=98CPE=E2=80=99).

=C2=A0

The search says that a single-digit percentage of th= e documents contain the word "host" or "CPE" in the tit= le. What point are you trying to make? That the charter is inappropriate, b= ecause it doesn't mention hosts, but the WG has published a few documents that talk about hosts?

=C2=A0

[Med] The answer is obvious= =C2=A0: the WG has no problem to publish such documents.


Not real= ly. If you go and read those documents, you'll see none of them is on h= ost requirements. And in any case, the discussion was whether this document= is "directly in line with the v6ops charter", as Dave said. Just= because the WG happens to have published a few documents that talk about h= osts doesn't mean that host requirements are directly in line with the = charter.
=C2=A0

In fact, if you look at the num= bered list in the charter, the items are "identify operational issues = and determine solutions", "identify potential security risks"= ;, "identify portions of the specs that can cause operational concerns&q= uot;, and "analyze solutions for deploying IPv6 within network environ= ments". None of those cover this document.

That's a great example to pick, because the WG i= s about to produce an RFC on precisely this topic - https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ .


B= ut it's not the role of the IETF or of this working group to make state= ments about operator plans. It's the IETF's role to discuss technic= al standards, and this group's role to provide operational guidance. &q= uot;Operators X, Y, and Z are handling the roaming issue like this" is= not operational guidance. An in-depth discussion of the problem, such as d= raft-ietf-v6ops-ipv6-roaming-analysis, is.
--001a113ece62089f39050f7105ff-- From nobody Thu Feb 19 05:46:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C481A8839 for ; Thu, 19 Feb 2015 05:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpExiouUkvQa for ; Thu, 19 Feb 2015 05:46:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5AC1A8795 for ; Thu, 19 Feb 2015 05:46:35 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id AE28E2AC1B5; Thu, 19 Feb 2015 14:46:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7F891158134; Thu, 19 Feb 2015 14:46:33 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 14:46:29 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEj7ixBJZ1L350WogIuKXDMPO5z3+p7w Date: Thu, 19 Feb 2015 13:46:29 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_e81d9ae26b054880b489ffb116e8e11cOPEXCLILH03corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.19.124820 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:46:38 -0000 --_000_e81d9ae26b054880b489ffb116e8e11cOPEXCLILH03corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtICwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IExvcmVu em8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCkVudm95w6kgOiBqZXVkaSAx OSBmw6l2cmllciAyMDE1IDE0OjM2DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNj IDogRGF2ZSBNaWNoYXVkOyBCSU5FVCBEYXZpZCBJTVQvT0xOOyBJUHY2IE9wcyBXRyAodjZvcHNA aWV0Zi5vcmcpDQpPYmpldCA6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoNCg0KT24gVGh1LCBG ZWIgMTksIDIwMTUgYXQgMTA6MjcgUE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCltNZWRdIEh1bW1t 4oCmIEkgc3VnZ2VzdCB5b3UgaGF2ZSBhIHF1aWNrIGxvb2sgYXQgdGhpcyBwYWdlIDogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy92Nm9wcy9kb2N1bWVudHMvIChoaW50OiBzZWFyY2gg Zm9yIOKAmGhvc3TigJkgb3Ig4oCYQ1BF4oCZKS4NCg0KVGhlIHNlYXJjaCBzYXlzIHRoYXQgYSBz aW5nbGUtZGlnaXQgcGVyY2VudGFnZSBvZiB0aGUgZG9jdW1lbnRzIGNvbnRhaW4gdGhlIHdvcmQg Imhvc3QiIG9yICJDUEUiIGluIHRoZSB0aXRsZS4gV2hhdCBwb2ludCBhcmUgeW91IHRyeWluZyB0 byBtYWtlPyBUaGF0IHRoZSBjaGFydGVyIGlzIGluYXBwcm9wcmlhdGUsIGJlY2F1c2UgaXQgZG9l c24ndCBtZW50aW9uIGhvc3RzLCBidXQgdGhlIFdHIGhhcyBwdWJsaXNoZWQgYSBmZXcgZG9jdW1l bnRzIHRoYXQgdGFsayBhYm91dCBob3N0cz8NCg0KW01lZF0gVGhlIGFuc3dlciBpcyBvYnZpb3Vz IDogdGhlIFdHIGhhcyBubyBwcm9ibGVtIHRvIHB1Ymxpc2ggc3VjaCBkb2N1bWVudHMuDQoNCk5v dCByZWFsbHkuIElmIHlvdSBnbyBhbmQgcmVhZCB0aG9zZSBkb2N1bWVudHMsIHlvdSdsbCBzZWUg bm9uZSBvZiB0aGVtIGlzIG9uIGhvc3QgcmVxdWlyZW1lbnRzLg0KDQpbTWVkXSBXaXRoIGFsbCBk dWUgcmVzcGVjdCwgdGhpcyBpcyBub3QgdHJ1ZS4gUkZDNzA2NiBpcyBhbiBleGFtcGxlIG9mIGhv c3QgcmVxdWlyZW1lbnRzLg0KDQpBbmQgaW4gYW55IGNhc2UsIHRoZSBkaXNjdXNzaW9uIHdhcyB3 aGV0aGVyIHRoaXMgZG9jdW1lbnQgaXMgImRpcmVjdGx5IGluIGxpbmUgd2l0aCB0aGUgdjZvcHMg Y2hhcnRlciIsIGFzIERhdmUgc2FpZC4gSnVzdCBiZWNhdXNlIHRoZSBXRyBoYXBwZW5zIHRvIGhh dmUgcHVibGlzaGVkIGEgZmV3IGRvY3VtZW50cyB0aGF0IHRhbGsgYWJvdXQgaG9zdHMgZG9lc24n dCBtZWFuIHRoYXQgaG9zdCByZXF1aXJlbWVudHMgYXJlIGRpcmVjdGx5IGluIGxpbmUgd2l0aCB0 aGUgY2hhcnRlci4NCg0KW01lZF0gV2hhdCBJIGtub3cgaXMgdGhhdCB0aGlzIGRvY3VtZW50IHdh cyBhZG9wdGVkIGJ5IHRoZSBXRyBhbmQgcGFzc2VkIHRoZSBJRVRGIExDIG9uY2UuIFRoZSBxdWVz dGlvbiBhYm91dCB0aGUgY2hhcnRlciB3YXMgbmV2ZXIgcmFpc2VkLg0KDQpJbiBmYWN0LCBpZiB5 b3UgbG9vayBhdCB0aGUgbnVtYmVyZWQgbGlzdCBpbiB0aGUgY2hhcnRlciwgdGhlIGl0ZW1zIGFy ZSAiaWRlbnRpZnkgb3BlcmF0aW9uYWwgaXNzdWVzIGFuZCBkZXRlcm1pbmUgc29sdXRpb25zIiwg ImlkZW50aWZ5IHBvdGVudGlhbCBzZWN1cml0eSByaXNrcyIsICJpZGVudGlmeSBwb3J0aW9ucyBv ZiB0aGUgc3BlY3MgdGhhdCBjYW4gY2F1c2Ugb3BlcmF0aW9uYWwgY29uY2VybnMiLCBhbmQgImFu YWx5emUgc29sdXRpb25zIGZvciBkZXBsb3lpbmcgSVB2NiB3aXRoaW4gbmV0d29yayBlbnZpcm9u bWVudHMiLiBOb25lIG9mIHRob3NlIGNvdmVyIHRoaXMgZG9jdW1lbnQuDQpUaGF0J3MgYSBncmVh dCBleGFtcGxlIHRvIHBpY2ssIGJlY2F1c2UgdGhlIFdHIGlzIGFib3V0IHRvIHByb2R1Y2UgYW4g UkZDIG9uIHByZWNpc2VseSB0aGlzIHRvcGljIC0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMvIC4NCg0KW01lZF0g SSBjYW4gaW5mb3JtIHlvdSB0aGlzIHdpbGwgYmUgcHVibGlzaGVkIGFzIFJGQzc0NDUuIEl0IGhh cHBlbnMgSeKAmW0gY28tYXV0aG9yIHRoYXQgZG9jdW1lbnQsIHNvIEnigJltIG5vdCBkaXNjb3Zl cmluZyBpdC4NCg0KVGhhdCdzIHdoeSBJIHBpY2tlZCBpdCwgeWVzLg0KDQpUaGF0IGRvY3VtZW50 IGlzIGEgZ29vZCBleGFtcGxlIG9mIHdoYXQgKmlzKiBpbiBjaGFydGVyIG9mIHRoZSBXRzogYW4g aW4tZGVwdGgsIGRldGFpbGVkIGRpc2N1c3Npb24gb2YgdGhlIG9wZXJhdGlvbmFsIGlzc3Vlcy4g OCBsaW5lcyBvZiB0ZXh0IHNheWluZyAiZGV2aWNlcyBtdXN0IHN1cHBvcnQgZGlmZmVyZW50IFBE UCB0eXBlcyBmb3IgaG9tZSBhbmQgcm9hbWluZyIgaXMgbm90Lg0KDQpbTWVkXSBUaGVyZSBpcyBu byByZWNvbW1lbmRhdGlvbiBpbiB0aGUgcm9hbWluZyBhbmFseXNpcyBkcmFmdC4gVGhlIHByb2Zp bGUgZG9jdW1lbnQgaW5jbHVkZXMgYSBjbGVhciByZWNvbW1lbmRhdGlvbiBvbiB0aGUgY3VycmVu dCBwbGFuIG9mIG1vc3Qgb3BlcmF0b3JzIHRvIGhhbmRsZSB0aGUgcm9hbWluZyBpc3N1ZS4NCg0K QnV0IGl0J3Mgbm90IHRoZSByb2xlIG9mIHRoZSBJRVRGIG9yIG9mIHRoaXMgd29ya2luZyBncm91 cCB0byBtYWtlIHN0YXRlbWVudHMgYWJvdXQgb3BlcmF0b3IgcGxhbnMuDQpbTWVkXSBXaG8gaXMg YXNraW5nIGZvciB0aGlzPyEgVGhpcyBpcyB5b3VyIGFzc3VtcHRpb24sIGF0IG1vc3QuDQoNCkl0 J3MgdGhlIElFVEYncyByb2xlIHRvIGRpc2N1c3MgdGVjaG5pY2FsIHN0YW5kYXJkcywgYW5kIHRo aXMgZ3JvdXAncyByb2xlIHRvIHByb3ZpZGUgb3BlcmF0aW9uYWwgZ3VpZGFuY2UuICJPcGVyYXRv cnMgWCwgWSwgYW5kIFogYXJlIGhhbmRsaW5nIHRoZSByb2FtaW5nIGlzc3VlIGxpa2UgdGhpcyIg aXMgbm90IG9wZXJhdGlvbmFsIGd1aWRhbmNlLiBBbiBpbi1kZXB0aCBkaXNjdXNzaW9uIG9mIHRo ZSBwcm9ibGVtLCBzdWNoIGFzIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1yb2FtaW5nLWFuYWx5c2lz LCBpcy4NCg0KW01lZF0gVGhlIHByb2ZpbGUgaW5kaWNhdGUgYSBjbGVhciByZWNvbW1lbmRhdGlv biB0byBzb2x2ZSBhIHByb2JsZW0gZGlzY3Vzc2VkIGluIG1vcmUgZGV0YWlscyBpbiBhbm90aGVy IHY2b3BzIHByb2R1Y2VkIGRvY3VtZW50Lg0K --_000_e81d9ae26b054880b489ffb116e8e11cOPEXCLILH03corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0m bmJzcDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTkgZsOpdnJpZXIgMjAxNSAxNDozNjxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPkNj Jm5ic3A7OjwvYj4gRGF2ZSBNaWNoYXVkOyBCSU5FVCBEYXZpZCBJTVQvT0xOOyBJUHY2IE9wcyBX RyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBk cmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGwtICZxdW90O2hh cm1mdWxseSBicm9hZCZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDE5LCAyMDE1IGF0 IDEwOjI3IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxicj4NCltNZWRdIEh1bW1t4oCmIEkgc3VnZ2VzdCB5b3UgaGF2ZSBh IHF1aWNrIGxvb2sgYXQgdGhpcyBwYWdlJm5ic3A7OiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL3dnL3Y2b3BzL2RvY3VtZW50cy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdjZvcHMvZG9jdW1lbnRzLzwvYT4gKGhpbnQ6IHNl YXJjaCBmb3Ig4oCYaG9zdOKAmSBvciDigJhDUEXigJkpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBzZWFyY2ggc2F5cyB0aGF0IGEgc2luZ2xlLWRpZ2l0IHBlcmNlbnRhZ2Ug b2YgdGhlIGRvY3VtZW50cyBjb250YWluIHRoZSB3b3JkICZxdW90O2hvc3QmcXVvdDsgb3IgJnF1 b3Q7Q1BFJnF1b3Q7IGluIHRoZSB0aXRsZS4gV2hhdCBwb2ludCBhcmUgeW91IHRyeWluZyB0byBt YWtlPyBUaGF0IHRoZSBjaGFydGVyIGlzIGluYXBwcm9wcmlhdGUsDQogYmVjYXVzZSBpdCBkb2Vz bid0IG1lbnRpb24gaG9zdHMsIGJ1dCB0aGUgV0cgaGFzIHB1Ymxpc2hlZCBhIGZldyBkb2N1bWVu dHMgdGhhdCB0YWxrIGFib3V0IGhvc3RzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPltNZWRdIFRoZSBhbnN3ZXIgaXMgb2J2aW91cyZuYnNwOzogdGhlIFdHIGhhcyBubyBwcm9i bGVtIHRvIHB1Ymxpc2ggc3VjaCBkb2N1bWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgcmVhbGx5LiBJZiB5b3UgZ28gYW5kIHJlYWQg dGhvc2UgZG9jdW1lbnRzLCB5b3UnbGwgc2VlIG5vbmUgb2YgdGhlbSBpcyBvbiBob3N0IHJlcXVp cmVtZW50cy48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBXaXRoIGFsbCBkdWUgcmVzcGVjdCwg dGhpcyBpcyBub3QgdHJ1ZS4gUkZDNzA2NiBpcyBhbiBleGFtcGxlIG9mIGhvc3QgcmVxdWlyZW1l bnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5kIGluIGFueSBjYXNl LCB0aGUgZGlzY3Vzc2lvbiB3YXMgd2hldGhlciB0aGlzIGRvY3VtZW50IGlzICZxdW90O2RpcmVj dGx5IGluIGxpbmUgd2l0aCB0aGUgdjZvcHMgY2hhcnRlciZxdW90OywgYXMgRGF2ZSBzYWlkLg0K PC9zcGFuPkp1c3QgYmVjYXVzZSB0aGUgV0cgaGFwcGVucyB0byBoYXZlIHB1Ymxpc2hlZCBhIGZl dyBkb2N1bWVudHMgdGhhdCB0YWxrIGFib3V0IGhvc3RzIGRvZXNuJ3QgbWVhbiB0aGF0IGhvc3Qg cmVxdWlyZW1lbnRzIGFyZSBkaXJlY3RseSBpbiBsaW5lIHdpdGggdGhlIGNoYXJ0ZXIuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2hhdCBJIGtub3cg aXMgdGhhdCB0aGlzIGRvY3VtZW50IHdhcyBhZG9wdGVkIGJ5IHRoZSBXRyBhbmQgcGFzc2VkIHRo ZSBJRVRGIExDIG9uY2UuIFRoZSBxdWVzdGlvbiBhYm91dCB0aGUgY2hhcnRlciB3YXMgbmV2ZXIg cmFpc2VkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGZhY3Qs IGlmIHlvdSBsb29rIGF0IHRoZSBudW1iZXJlZCBsaXN0IGluIHRoZSBjaGFydGVyLCB0aGUgaXRl bXMgYXJlICZxdW90O2lkZW50aWZ5IG9wZXJhdGlvbmFsIGlzc3VlcyBhbmQgZGV0ZXJtaW5lIHNv bHV0aW9ucyZxdW90OywgJnF1b3Q7aWRlbnRpZnkgcG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzJnF1 b3Q7LA0KICZxdW90O2lkZW50aWZ5IHBvcnRpb25zIG9mIHRoZSBzcGVjcyB0aGF0IGNhbiBjYXVz ZSBvcGVyYXRpb25hbCBjb25jZXJucyZxdW90OywgYW5kICZxdW90O2FuYWx5emUgc29sdXRpb25z IGZvciBkZXBsb3lpbmcgSVB2NiB3aXRoaW4gbmV0d29yayBlbnZpcm9ubWVudHMmcXVvdDsuDQo8 L3NwYW4+Tm9uZSBvZiB0aG9zZSBjb3ZlciB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhdCdzIGEgZ3JlYXQgZXhhbXBsZSB0byBwaWNrLCBiZWNhdXNlIHRoZSBXRyBpcyBh Ym91dCB0byBwcm9kdWNlIGFuIFJGQyBvbiBwcmVjaXNlbHkgdGhpcyB0b3BpYyAtDQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWlwdjYt cm9hbWluZy1hbmFseXNpcy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtaXB2Ni1yb2FtaW5nLWFuYWx5c2lzLzwvYT4g LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBjYW4gaW5mb3Jt IHlvdSB0aGlzIHdpbGwgYmUgcHVibGlzaGVkIGFzIFJGQzc0NDUuIEl0IGhhcHBlbnMgSeKAmW0g Y28tYXV0aG9yIHRoYXQgZG9jdW1lbnQsDQogc28gSeKAmW0gbm90IGRpc2NvdmVyaW5nIGl0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyB3aHkgSSBwaWNrZWQgaXQs IHllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYXQgZG9jdW1lbnQgaXMg YSBnb29kIGV4YW1wbGUgb2Ygd2hhdCAqaXMqIGluIGNoYXJ0ZXIgb2YgdGhlIFdHOiBhbiBpbi1k ZXB0aCwgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiB0aGUgb3BlcmF0aW9uYWwgaXNzdWVzLg0KPC9z cGFuPjggbGluZXMgb2YgdGV4dCBzYXlpbmcgJnF1b3Q7ZGV2aWNlcyBtdXN0IHN1cHBvcnQgZGlm ZmVyZW50IFBEUCB0eXBlcyBmb3IgaG9tZSBhbmQgcm9hbWluZyZxdW90OyBpcyBub3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhlcmUg aXMgbm8gcmVjb21tZW5kYXRpb24gaW4gdGhlIHJvYW1pbmcgYW5hbHlzaXMgZHJhZnQuIFRoZSBw cm9maWxlIGRvY3VtZW50IGluY2x1ZGVzIGENCiBjbGVhciByZWNvbW1lbmRhdGlvbiBvbiB0aGUg Y3VycmVudCBwbGFuIG9mIG1vc3Qgb3BlcmF0b3JzIHRvIGhhbmRsZSB0aGUgcm9hbWluZyBpc3N1 ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgaXQncyBub3QgdGhlIHJvbGUgb2YgdGhl IElFVEYgb3Igb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dCBv cGVyYXRvciBwbGFucy48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+W01lZF0gV2hvIGlzIGFza2luZyBmb3IgdGhpcz8hIFRoaXMgaXMgeW91ciBhc3N1bXB0 aW9uLCBhdCBtb3N0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SXQncyB0 aGUgSUVURidzIHJvbGUgdG8gZGlzY3VzcyB0ZWNobmljYWwgc3RhbmRhcmRzLCBhbmQgdGhpcyBn cm91cCdzIHJvbGUgdG8gcHJvdmlkZSBvcGVyYXRpb25hbCBndWlkYW5jZS4NCjwvc3Bhbj4mcXVv dDtPcGVyYXRvcnMgWCwgWSwgYW5kIFogYXJlIGhhbmRsaW5nIHRoZSByb2FtaW5nIGlzc3VlIGxp a2UgdGhpcyZxdW90OyBpcyBub3Qgb3BlcmF0aW9uYWwgZ3VpZGFuY2UuIEFuIGluLWRlcHRoIGRp c2N1c3Npb24gb2YgdGhlIHByb2JsZW0sIHN1Y2ggYXMgZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LXJv YW1pbmctYW5hbHlzaXMsIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g VGhlIHByb2ZpbGUgaW5kaWNhdGUgYSBjbGVhciByZWNvbW1lbmRhdGlvbiB0byBzb2x2ZSBhIHBy b2JsZW0gZGlzY3Vzc2VkIGluIG1vcmUgZGV0YWlscyBpbiBhbm90aGVyIHY2b3BzIHByb2R1Y2Vk IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e81d9ae26b054880b489ffb116e8e11cOPEXCLILH03corporateadr_-- From nobody Thu Feb 19 05:59:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6332D1A906A for ; Thu, 19 Feb 2015 05:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi95rGIJDibU for ; Thu, 19 Feb 2015 05:59:06 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29001A8A96 for ; Thu, 19 Feb 2015 05:59:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1JDx3dW009226 for ; Thu, 19 Feb 2015 14:59:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC8BA2022EB for ; Thu, 19 Feb 2015 15:00:08 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4D4420225D for ; Thu, 19 Feb 2015 15:00:08 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1JDwfmc019721 for ; Thu, 19 Feb 2015 14:59:03 +0100 Message-ID: <54E5EC11.4070002@gmail.com> Date: Thu, 19 Feb 2015 14:58:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:59:11 -0000 Le 19/02/2015 14:10, Dave Michaud a écrit : [...] > Transitionning to IPv6-only requires further support from the host > side to form a complete solution. In this particular respect: no, I think it's very possible to have transition to an IPv6-only access yet the host acts as a pure IPv4 host (no CLAT translation on the Host). I think what you mean is that the cellular operators have a particular solution for migrating to IPv6-only. The method 464xlat/clat is good but not necessarily the best for every context (an IPv4 Host-to-Host app like Push-to-Talk, to mention something new). Among those two (IPv6 and CLAT) one would certainly suggest IPv6 implementation in the terminal, but CLAT should be a "MAY". One wouldn't want others to think that IPv6 is possible only if CLAT is there. Alex > > The documents published under v6ops should "serve as useful guides > to network operators and users on possible ways how to deploy IPv6 > within their existing IPv4 networks, as well as in new network > installations.†> > This is exactly what this is. As a LAN administrator, it wouldn’t > cross my mind to look for an RFC for host requirements because I > would have little control anyway. As a cellular operator, the hosts > are part of my network and I do have a say on how they operate and > it forms part of the overall solution (bullet 4 of the charter). > Same would apply from a Cable MSO where the CPEs are integral part of > the network. > > > > *Dave Michaud* Sr. Architect Mobility – Access Networks & IP Network > Services Network Technology | Rogers Communications > dave.michaud@rci.rogers.com | > tel: +1 647.747.9442 | mobile: +1 416.219.5531 > > > From: Lorenzo Colitti > Date: Thursday, February 19, 2015 at > 07:45 To: Dave Michaud > Cc: > "mohamed.boucadair@orange.com " > >, > BINET IMT/OLN >, IPv6 WG > Subject: Re: [v6ops] > draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? > > On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud > > > wrote: > > This is directly in line with the v6ops charter: > > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides operational > guidance on how to deploy IPv6 into existing IPv4-only networks, as > well as into new network installations. > > The main focus of the v6ops WG is to look at the immediate > deployment issues; more advanced stages of deployment and transition > are a lower priority. > > > Actually, it isn't, really. The charter is operational guidance for > the IPv4/IPv6 Internet. Not host requirements. > > In fact, if you look at the numbered list in the charter, the items > are "identify operational issues and determine solutions", "identify > potential security risks", "identify portions of the specs that can > cause operational concerns", and "analyze solutions for deploying > IPv6 within network environments". None of those cover this > document. > > > > > ------------------------------------------------------------------------ > > > > > > > This communication is confidential. We only send and receive email on > the basis of the terms set out at > www.rogers.com/web/content/emailnotice > > > > > Ce message est confidentiel. Notre transmission et réception de > courriels se fait strictement suivant les modalités énoncées dans > l’avis publié à www.rogers.com/aviscourriel > > ------------------------------------------------------------------------ > > > > > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Feb 19 06:03:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A481A8786 for ; Thu, 19 Feb 2015 06:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtE2bAyywn9p for ; Thu, 19 Feb 2015 06:03:10 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94D01A1AB6 for ; Thu, 19 Feb 2015 06:03:09 -0800 (PST) Received: by iecrd18 with SMTP id rd18so9607012iec.5 for ; Thu, 19 Feb 2015 06:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AzUgBJwTJLmrXzYvj+xXr0Rq5QxNMO3GoGYPMkDIFsQ=; b=K/fk3IgJwhf4dDCa9xFGKeMaJn1n9NqrLiL2w9LVcE2DxnL5ZkYafuXXUEMjlGljcn EdXfWeMsoPqsz14A5OOlrhAKw5+ujM/hrtQvBspHEEaKzgaknxd8zxmXrNzTdOgJEUof VLLhLZs+jodFB8EEyyOKSUcLpJysA27fcJfdIJZF9/7XYu0LMSnI2ZGO6gZrD/9gtrYw ClwAhzigjb0G+GdxChMxeqAJmzUD/A2TcoUzLurojKGoLFjst12DOegnbHhyVKy/bJpP 2K+JdC6b/g/E9l73eVRfZmQUfGpJc0f2BRKMmEfQob1LZ9c9Zs3jXpuAluUxuj2qSW8O d8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AzUgBJwTJLmrXzYvj+xXr0Rq5QxNMO3GoGYPMkDIFsQ=; b=V7qHAUXwGaMkOajg7Ohp+mBDlHo84ZBArdB7eRyDX3g1yTyfX7j/K9xkHvLW0cHCD4 lJklP2ZU3SvM0sly9l8eVVjDAF4v+E7gEcAMUj4MzgHXGX7pNP33pCSeE8KmcDf6P4CS DIkKfM10KDikbRFNndanJ4RS5hTE2KmdAYOzKLGhBUw46ikCjgYMUi8TNzXF18Qp5CRB fyNpD/cp+6v3kXyqlH7uU3NnqAN+Cbgd5F4AIUTXlDn22I4hBBrK0277c71uzBBiyNlD An/dEYOaYYY9GqS64TGTlKSQe8TmjJsFY1e9SlxuMx1tzQNAXc6+j9krGyilJkMk1tYp bvhQ== X-Gm-Message-State: ALoCoQkO69SavyyYCCU1zMPv0/tjMXVPcVdx4eOlOKanBkn0gZCjYKcVs/hM0OBh7VAQnFm4XcmM X-Received: by 10.107.152.211 with SMTP id a202mr6209320ioe.59.1424354589251; Thu, 19 Feb 2015 06:03:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Thu, 19 Feb 2015 06:02:48 -0800 (PST) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 19 Feb 2015 23:02:48 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1140f53853cf31050f71653f Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:03:12 -0000 --001a1140f53853cf31050f71653f Content-Type: text/plain; charset=UTF-8 On Thu, Feb 19, 2015 at 10:46 PM, wrote: > > Not really. If you go and read those documents, you'll see none of them is > on host requirements. > > > > [Med] With all due respect, this is not true. RFC7066 is an example of > host requirements. > The main purpose of RFC 7066 is not to place requirements of its own, but to clarify the requirements that are posed on hosts by the 3GPP standards. > And in any case, the discussion was whether this document is "directly > in line with the v6ops charter", as Dave said. Just because the WG > happens to have published a few documents that talk about hosts doesn't > mean that host requirements are directly in line with the charter. > > > > [Med] What I know is that this document was adopted by the WG and passed > the IETF LC once. The question about the charter was never raised. > I don't see what WG adoption and IETF LC have got do do with this discussion. Dave said the document is "directly in line with the v6ops charter", and I disagreed. > That document is a good example of what *is* in charter of the WG: an > in-depth, detailed discussion of the operational issues. 8 lines of text > saying "devices must support different PDP types for home and roaming" is > not. > > > > [Med] There is no recommendation in the roaming analysis draft. The > profile document includes a clear recommendation on the current plan of > most operators to handle the roaming issue. > > > > But it's not the role of the IETF or of this working group to make > statements about operator plans. > > [Med] Who is asking for this?! This is your assumption, at most. > You're the one who wrote the words "the profile document includes a clear recommendation on the current plan of most operators". All I'm saying is that that's not the IETF's role. --001a1140f53853cf31050f71653f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 19, 2015 at 10:46 PM, <mohamed.boucadair@orange.com> wrote:


Not really. If you go and read those docu= ments, you'll see none of them is on host requirements.

=C2=A0

[Med] With all due respect, = this is not true. RFC7066 is an example of host requirements.


The= main purpose of RFC 7066 is not to place requirements of its own, but to c= larify the requirements that are posed on hosts by the 3GPP standards.
=C2=A0

=C2=A0And in any case, the discussion was whether this document is "di= rectly in line with the v6ops charter", as Dave said. Just because the WG happens to have published a few documents that t= alk about hosts doesn't mean that host requirements are directly in lin= e with the charter.

=C2=A0

[Med] What I know is that th= is document was adopted by the WG and passed the IETF LC once. The question= about the charter was never raised.


I don't see what WG adop= tion and IETF LC have got do do with this discussion. Dave said the documen= t is "directly in line with the v6ops charter", and I disagreed.<= /div>
=C2=A0

That document is a good example= of what *is* in charter of the WG: an in-depth, detailed discussion of the= operational issues. 8 lines of text saying "devices must support different PDP type= s for home and roaming" is not.

=

=C2=A0

[Med] There is no recommendation in= the roaming analysis draft. The profile document includes a clear recommendation on the current plan of most operators to handle the r= oaming issue.

=C2=A0

But it's not the role of the IETF or of this wor= king group to make statements about operator plans.

[Med] Who is asking for this= ?! This is your assumption, at most.


--001a1140f53853cf31050f71653f-- From nobody Thu Feb 19 11:07:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5AD1A005C for ; Thu, 19 Feb 2015 11:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BshbPUqDHvK for ; Thu, 19 Feb 2015 11:07:47 -0800 (PST) Received: from mail-07.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 841C71A1EEF for ; Thu, 19 Feb 2015 11:07:39 -0800 (PST) Received: from [24.114.104.93] (helo=[172.20.10.4]) by mail-07.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YOWRm-0001Rv-7D; Thu, 19 Feb 2015 14:07:38 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <54E5176B.7000404@gmail.com> Date: Thu, 19 Feb 2015 14:07:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8AAD52EA-DB6A-4FA9-950A-D1DAF8D9F138@magma.ca> References: <20150218205728.31470.50859.idtracker@ietfa.amsl.com> <54E5176B.7000404@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.104.93] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:07:49 -0000 Hi Brian: I personally do not know of a way to get a packet to a link-local = address on a different link unless the routers in-between are very very = broken. However, I think the discovery a couple of years ago that most = routers happily forwarded packets with link-local _source_ addresses = surprised people, even though in hindsight it should not have. And = security folk (and researchers!) are always leery of absolute statements = like "This is impossible". So when Jen Lincova requested that we soften = the wording around link-local address security (in her comments at the = mike during the Honolulu session), I was happy to comply. Hence the = text below, and similar changes in a couple of other spots. - Philip On 2015-02-18, at 17:51 , Brian E Carpenter wrote: >> It is very difficult to impossible to ping a link-local address >> from a device that is not on the same subnet. This is a=09 >> troubleshooting disadvantage, though it can also be viewed as a >> security advantage. >=20 > I am puzzled by how it could ever be possible at all. > Link-local addresses are by definition meaningless off > the link in question, and they should never even be known by > any node on another link. (And of course it gets even more > complicated on devices with several interfaces, such as routers, > since a link local address is only meaningful with a ZoneID, > and that is a node-specific value, meaningless to other nodes > on the *same* link.) >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Feb 19 11:53:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236471A011E for ; Thu, 19 Feb 2015 11:53:14 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrUoEGws0PVr for ; Thu, 19 Feb 2015 11:53:12 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C421A877F for ; Thu, 19 Feb 2015 11:53:12 -0800 (PST) Received: by pdev10 with SMTP id v10so2071038pde.7 for ; Thu, 19 Feb 2015 11:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1BjsnPvFcTYibaPdlBhs+wb+NTlg/K8l+2c2q7edh2M=; b=K8mkGkxl0M8f5z5hjjUPguO27r1AKjQf6w7RcnBz6xugqAwLHeTunGceVZCxlXs4CD MOUBfl/UVdZPSpKbhDg0AyflK41BmmRgROsWpm7xKMtRhY9oMhoGI6WZmrZC3f+d8A14 ITxWoYoUvZO+rt5cxBCfMA/dzRorC8kUAya0XbICMwMWTHbz3bvD0LgqPV582W9mc+1+ hn/yXhELcRM8ThF8onjzivksmSObYRNPidmww3ajy9V35DJEzXLp0CTRbxlC5LbeMSDJ XZDaBVQLoMnBeEMb5UjIIAmQ7tc//ygK6BVZ6SKyJ5FkomNfbdXakyfL0QT2Gi/p4SIk TsEA== X-Received: by 10.66.148.161 with SMTP id tt1mr10489485pab.85.1424375591244; Thu, 19 Feb 2015 11:53:11 -0800 (PST) Received: from ?IPv6:2406:e007:652c:1:28cc:dc4c:9703:6781? ([2406:e007:652c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id c9sm24621799pdj.52.2015.02.19.11.53.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 11:53:10 -0800 (PST) Message-ID: <54E63F3C.2070404@gmail.com> Date: Fri, 20 Feb 2015 08:53:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Heatley, Nick" , "mohamed.boucadair@orange.com" , Ca By References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: [v6ops] accountability vs responsibility [draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:53:14 -0000 On 19/02/2015 22:14, Heatley, Nick wrote: > My observation is around accountability vs responsibility (the RACI mat= rix). >=20 > The issue we seem to have is that the IETF expertise is needed, so we n= eed the IETF community to effectively be the responsible agency for the t= echnical content. > Normally SDOs are both accountable and responsible. That isn't clear to me in general. > Accountability, well, clearly some find it uneasy that IETF would have = accountability for the document. The IETF (and the RFC Editor) is not accountable for anything. Our standa= rds and recommendations are all voluntary and they all bear a disclaimer (hid= den in the Trust Legal Provisions for recent RFCs) saying something like: "...DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." The IETF is responsible for the contents in the sense that we require change control over derivative works of IETF Stream documents. > If another body could be accountable for the document, that it represen= ts the views of a suitable collective (mobile operators), but the technic= al content was filtered via IETF, that would be ideal, no? Not if the IETF fails to reach rough consensus on the contents. > I have no idea how to engineer such an outcome, but if it could be done= then this work should not be wasted =E2=80=93 could be a =E2=80=9CGSMA s= ponsored RFC=E2=80=9D? No. If the IETF fails to reach rough consensus, the authors are free to d= o whatever they want. If they believe that the "RFC" label has value, they are free to submit it as an Independent Stream RFC, and the Independent Submissions Editor then gets to decide whether to publish it: http://www.rfc-editor.org/indsubs.html Disclaimer: I am a member of the Independent Submissions editorial board.= Brian From nobody Thu Feb 19 12:30:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D921A0104 for ; Thu, 19 Feb 2015 12:30:42 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK8Nb1Vn8RNL for ; Thu, 19 Feb 2015 12:30:39 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3A01A0AFE for ; Thu, 19 Feb 2015 12:30:39 -0800 (PST) Received: by lbvn10 with SMTP id n10so2297448lbv.4 for ; Thu, 19 Feb 2015 12:30:37 -0800 (PST) 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=vsBXXQyAG1bBjhiMKHQxD/K82jyGNaetVlt1BGO+uw8=; b=duSgiGzr+PlitIxXDoP3GWqiYpAHXVXwfCpLejV69T/398XcrAieBlY+y8k++PPwF5 JbAqEXMNULSqzaYipHlzjMrzrTo5p9T7Ytml4s3ej0kXye5do9nAEagP76F7Q07cTFxy emb6iRiDPjtBpJ3ih5vlTygXEK7s4BOuPSzteQ3a0KwHueZGkRWCID7OPxVsp337gSSi n12THDUyh/wgoN2EDwjjdgS8jkVuYfaLBGsKBTvZ6rebR/jAYPH0CUSWYdTuTMHuRh6j dVMeU5GF/g9uwsmlhMEURB4ajItaR6D1c6KdK4IZAgjQ89BCRh2QG4sFf+SU73xS7YNg 5bMA== MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr5582142lar.33.1424377837840; Thu, 19 Feb 2015 12:30:37 -0800 (PST) Received: by 10.25.212.73 with HTTP; Thu, 19 Feb 2015 12:30:37 -0800 (PST) In-Reply-To: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> Date: Thu, 19 Feb 2015 12:30:37 -0800 Message-ID: From: jouni korhonen To: Ross Chandler Content-Type: multipart/alternative; boundary=089e013d12d60cedb2050f76cfc0 Archived-At: Cc: "v6ops@ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:30:42 -0000 --089e013d12d60cedb2050f76cfc0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I still fail to see how EIT setting relates to IPv6 as a requirement. It is a normal procedure when the UE wants to connect (during the initial attach) to another APN than the default one. - Jouni On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler wrote: > > On 18 Feb 2015, at 16:47, jouni korhonen wrote: > > > > On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > >> Hi, >> >> Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit : >> >>> Hi, >>> >>> Inline comments: >>> >>> Hi, >>> >>> Thank you for the report. It is good to see how good consideration >>> is given to IPv6, and the two separated paths IPv4/IPv6. >>> >>> It is encouraging to see numerous smartphone manufacturers having >>> embraced the CLAT technology. >>> >>> (tk) - this is not only CLAT, (CLAT is in generic Android thanks to >>> Lorenzo, Cameron, Dan & others) each vendor has its own >>> customization based on MCCMNC/region to control "features" per >>> operator. In our case we have : dedicated clatd.conf (not generic >>> one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) >>> >> >> It's good to see these mentioned. >> >> For tethering - is the network offering DHCPv6 Prefix Delegation >> service? Or is the device performing '64share' RFC7278? >> >> There are some advantages on doing the former rather than the latter. >> >> EIT bit =3D1, >>> >> >> What is the EIT bit? >> > > My wild guess is that it is the ESM information transfer flag bit in the = ESM > information transfer flag information element. If it is, it does not real= ly > have anything to do with IPv6 IMHO. > > - Jouni > > > As far as I can tell from a previous answer on v6ops by Orange PL the EIT > bit (think it is ESM info transfer flag IE) has an effect when the HSS ha= s > a default APN different from the one requested by the UE. Without the EI= T > bit set the network doesn=E2=80=99t let the UE requested APN override the= default > from the HSS, so two PDN connections are set up, one with IPv4 (assuming > the default is an IPv4 only APN) and the other IPv6 (assuming that was > requested by the UE). So strictly speaking it does look independent of I= P > version but it is being noticed as operators introduce IPv6. > > Ross > > --089e013d12d60cedb2050f76cfc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I still fail to see how EIT setting relates to IPv6 a= s a requirement.=C2=A0 It is a normal procedure when the UE wants to connec= t (during the initial attach) to another APN than the default one.

=
- Jouni

On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <= ;ross@eircom.net&g= t; wrote:

= On 18 Feb 2015, at 16:47, jouni korhonen <jouni.nospam@gmail.com> wrote:


On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit :
Hi,

Inline comments:

Hi,

Thank you for the report. It is good to see how good consideration
is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to
Lorenzo, Cameron, Dan & others) each vendor has its own
customization based on MCCMNC/region to control "features" per operator. In our case we have :=C2=A0 dedicated clatd.conf (not generic
one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?=C2=A0 Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

EIT bit =3D1,

What is the EIT bit?

My wild guess is t= hat it is the ESM information transfer flag bit i= n the ESM information transfer flag information element. If it is, it does not really have anything to do = with IPv6 IMHO.

- Jouni<= /span>

As far as I can tell from a previous answer on v6ops by Orange PL the EIT = bit (think it is ESM info transfer flag IE) has an effect when the HSS has = a default APN different from the one requested by the UE.=C2=A0 Without the= EIT bit set the network doesn=E2=80=99t let the UE requested APN override = the default from the HSS, so two PDN connections are set up, one with IPv4 = (assuming the default is an IPv4 only APN) and the other IPv6 (assuming tha= t was requested by the UE).=C2=A0 So strictly speaking it does look indepen= dent of IP version but it is being noticed as operators introduce IPv6.

Ross

--089e013d12d60cedb2050f76cfc0-- From nobody Thu Feb 19 12:37:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E32E1A01A8 for ; Thu, 19 Feb 2015 12:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiCewK-3mTkT for ; Thu, 19 Feb 2015 12:37:30 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63B01A0095 for ; Thu, 19 Feb 2015 12:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=188; q=dns/txt; s=iport; t=1424378250; x=1425587850; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rInaMjLvv/rdJvoL6oRCgfBGXA86c+cworiB+xo/S2Y=; b=hcfKJmArICR7mbbetb18rr3D7658H4N8dHA2QAf2aCpTBVG84wHLtIt/ G4rLlDHUOGzGmfWCqxWmC9DS6aISAkReo5QxOOL4WEbdCfLDCa78yHfPr cic6bmrrLd1yZM7OPShfv8IpxeE2PfNSVBOy5zdmoB3KkEKpuO1aoFT/h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQANSeZU/4oNJK1bgwZSXsJqhXECgSNDAQEBAQEBfIQRAQQ6UQEqFEImAQQbiCcNrD2nawEBAQEBBQEBAQEBAQEXBI9Mg06BFAWPS4NcmQcig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.09,610,1418083200"; d="scan'208";a="394449515" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 19 Feb 2015 20:37:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1JKbTjf026485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Feb 2015 20:37:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 14:37:29 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Inviting discussion: draft-sun-v6ops-xlat-multi Thread-Index: AdBMg+BUbLdN5ekmRoyPrUv+ZrmTfg== Date: Thu, 19 Feb 2015 20:37:28 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B0612B33C@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] Inviting discussion: draft-sun-v6ops-xlat-multi X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:37:31 -0000 I'd like to understand working group viewpoints, technical and operational,= on https://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-01. Does it belo= ng on the agenda for IETF 92?= From nobody Thu Feb 19 12:54:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53A11A015F for ; Thu, 19 Feb 2015 12:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfDOaGnt4TzT for ; Thu, 19 Feb 2015 12:54:35 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B0E1A0141 for ; Thu, 19 Feb 2015 12:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=391; q=dns/txt; s=iport; t=1424379275; x=1425588875; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RKNbpceX7R/3O24njFuNbg3vmV/omLhkgdjA4wvmhXc=; b=hAey0AnL82eP5vDYXQnQiugtNbKCICBDNEtxSVBtSbmw3gxrpZYVcbID AgvpKAHqoFJAMdOFC6XW/a8nhhk7gRNvzTOzzjdr9CxUAv1uQ4/e2tH++ UUDBUcTp4bU+IFn2SlCxH/uVdP1IDFEyzRnyShjvmy/2iaFieQMmfiYOw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQBoTOZU/40NJK1bgwZSXsJqhXECgSNDAQEBAQEBfIQRAQQ6UQEqFEImAQQbiCcNrDCnawEBAQEBBQEBAQEBAQEXBI9Mg06BFAWPS4NcmQcig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.09,610,1418083200"; d="scan'208";a="397567443" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2015 20:54:35 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1JKsYBM031104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Feb 2015 20:54:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 14:54:34 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Inviting discussion: draft-chen-v6ops-nfv-ipv6 Thread-Index: AdBMhkOVK+jx9zhxQgW7jsjoc/yHpw== Date: Thu, 19 Feb 2015 20:54:33 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B0612B38A@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] Inviting discussion: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:54:37 -0000 https://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6=0A= "IPv6 Considerations for Network Function Virtualization (NFV)", Gang=0A= Chen, Hui Deng, 2014-10-27=0A= =0A= This draft was prepared for IETF 91, but didn't get discussed in part becau= se a number of Chinese participants didn't make it to Honolulu for a Monday= meeting. Is there interest in discussing it at IETF 92?= From nobody Thu Feb 19 12:54:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F41A0193 for ; Thu, 19 Feb 2015 12:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBxGmD_A3snk for ; Thu, 19 Feb 2015 12:54:48 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650B01A01E7 for ; Thu, 19 Feb 2015 12:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=407; q=dns/txt; s=iport; t=1424379288; x=1425588888; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1l5xqpp2Y1tX+jXT/kGJZTXk54Qr24/Ra/lzQUL1xGo=; b=LAOzoO3nkTGQoehlX3qTl63BN+K9UlWQb2w8ol5iImXOA6XwaPUkyEtS Qei3Fc9T+V3pTLcIG3qNQOrQA5Mrk6uKSEHrZfztiVpkEeGTYeUIfqg97 Dagm9edirwPXXkm06RxybI38KuNB4f2EtHqpKU9pm56bhKeolw+5lZfaB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQCMTOZU/5xdJa1bgwZSXsJqhXECgSNDAQEBAQEBfIQRAQQ6UQEqFEImAQQbiCcNrDCnawEBAQEBBQEBAQEBAQEXBI9Mg06BFAWPS4NcmQcig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.09,610,1418083200"; d="scan'208";a="125126351" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 19 Feb 2015 20:54:47 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1JKslOZ017575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Feb 2015 20:54:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 14:54:47 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: Inviting discussion: draft-liu-v6ops-running-multiple-prefixes Thread-Index: AdBMhkuz1K4mXfjaRUCGq1D03OjIJg== Date: Thu, 19 Feb 2015 20:54:47 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B0612B394@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] Inviting discussion: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:54:50 -0000 https://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes=0A= "Considerations for Running Multiple IPv6 Prefixes", Bing Liu, Sheng=0A= Jiang, Yang Bo, 2014-10-11,=0A= =0A= This draft was prepared for IETF 91, but didn't get discussed in part becau= se a number of Chinese participants didn't make it to Honolulu for a Monday= meeting. Is there interest in discussing it at IETF 92?= From nobody Thu Feb 19 12:59:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EFE1A0195 for ; Thu, 19 Feb 2015 12:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxw1B-gks_Gw for ; Thu, 19 Feb 2015 12:59:43 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FC81A01D6 for ; Thu, 19 Feb 2015 12:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2587; q=dns/txt; s=iport; t=1424379584; x=1425589184; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7rtSMw//Ixhe4RsR1TneeVbJodt/sJltjKl5ZMJmVLk=; b=RCQJFU9J5wF+d2/v88twOAJ8kd5zlg/owKrd6qH9zgmt5x+vBm6QSAgr N1jkACaLC0aYfrrhcrxAzAUioD/u2esOpvcEDcMUHE8w63+Nvm3dbSx9w ph2HXfR3OhF/N01y+YnsiDjBKDYOC5fxGy3asETs2c/G2O4EHzXdcvW+u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQDSTeZU/4UNJK1bgwaBMMhbAoEjQwEBAQEBAXyEEQEEOlEBKhRCJgEEG4gnrEOnagEBAQcCAR+PTINOgRQFj0ucYyKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,610,1418083200"; d="scan'208";a="125200512" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 19 Feb 2015 20:59:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1JKxgQm017709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Feb 2015 20:59:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 14:59:42 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: IETF 92 Agenda Thread-Index: AdBMg/3jJEwhoggeTwOxL16zteLEew== Date: Thu, 19 Feb 2015 20:59:42 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B0612B3B1@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] IETF 92 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:59:49 -0000 As I noted a few weeks ago, Lee and I are starting to plan the agenda for t= he meeting in Dallas. If you have drafts you intend to post, now would be a= n excellent time to do so, so there can be list discussion prior to the eve= nt.=0A= =0A= Where we stand at this instant, according to me:=0A= =0A= IESG:=0A= =0A= Oct 19 draft-ietf-v6ops-ipv6-roaming-analysis (RFC Editor)=0A= Jan 28 draft-ietf-v6ops-6to4-to-historic (On agenda of 2015-03-05 IESG= telechat)=0A= =0A= Exiting WGLC; on its way to IESG:=0A= Feb 13 draft-ietf-v6ops-cidr-prefix (Lee doing writeup)=0A= Feb 18 draft-ietf-v6ops-mobile-device-profile (ongoing discussion from= WGLC requested by IESG)=0A= =0A= Working Group Document updated since IETF:=0A= =0A= Dec 18 draft-ietf-v6ops-siit-dc=0A= Jan 27 draft-ietf-v6ops-siit-dc-2xlat=0A= Feb 18 draft-ietf-v6ops-design-choices=0A= =0A= Individual Submission updated since IETF:=0A= =0A= Dec 31 draft-sun-v6ops-xlat-multi=0A= Jan 8 draft-anderson-v6ops-siit-eam=0A= =0A= Working Group Document NOT updated since IETF:=0A= =0A= Oct 27 draft-ietf-v6ops-dhcpv6-slaac-problem=0A= Oct 27 draft-ietf-v6ops-ula-usage-recommendations=0A= =0A= Individual Submission NOT updated since IETF:=0A= =0A= Aug 24 draft-v6ops-pmtud-ecmp-problem=0A= =0A= Note that we chose to adopt this, but draft-ietf-v6ops-pmtud-ecmp-problem h= as not yet been posted.=0A= =0A= Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world=0A= =0A= Fernando has done a lot of work and discussed it with the chairs. I expect = him to post an updated draft, a report, for discussion in IETF 92 that dist= inguishes clear among the extension headers implicated and whether the drop= occurs in the same AS as the destination or a different one.=0A= =0A= Oct 11 draft-liu-v6ops-running-multiple-prefixes=0A= Oct 27 draft-chen-v6ops-nfv-ipv6=0A= Oct 27 draft-liu-v6ops-dhcpv6-slaac-guidance=0A= =0A= I'll note that these three didn't see discussion in IETF 91, at least in pa= rt, because a number of Chinese participants didn't get to the meeting or d= idn't arrive for a Monday meeting. I have polled for working group interest= .=0A= =0A= Drafts that probably belong in some other working group:=0A= Sep 18 draft-elkins-v6ops-multicast-virtual-nodes=0A= Sep 18 draft-wang-v6ops-xlat-prefix-discovery=0A= Sep 25 draft-ybai-v6ops-ipv6-for-openstack=0A= Oct 27 draft-osamu-v6ops-ipv4-literal-in-url=0A= Oct 27 draft-vyncke-v6ops-happy-eyeballs-cookie= From nobody Thu Feb 19 18:33:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36521A1B71 for ; Thu, 19 Feb 2015 18:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.734 X-Spam-Level: ** X-Spam-Status: No, score=2.734 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSHJ8DMQvxKg for ; Thu, 19 Feb 2015 18:33:45 -0800 (PST) Received: from nm41-vm10.bullet.mail.gq1.yahoo.com (nm41-vm10.bullet.mail.gq1.yahoo.com [67.195.87.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539B71A1B70 for ; Thu, 19 Feb 2015 18:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424399625; bh=aekScytVPMGhVocy2hncTaOTTz9GI9Q+gQc/LJAuCNo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JkPwN+2f1ohA4IwJrEbI2ZlIPWLZDjI6QjxbRLs4ac/Vtfm7IputBfj7ev/QWPfNdxNTeHIoxGbiNDKwgQpS9H9/0gwcR4HiwvJFhVtVbbzaAZq7iyEVAqajYpCg8SAqnIEJFe+tEOz364chu2PO2qL3DiyclgYCNi2HYaAPaVgCq3avIVvcHp2lGtJfOKV5R2zljbC2NPXQ7aQvxouwcZouHur39+BmDKPgXUJ3LY3SdygIo6CKbx3LeKBxXKcxB4aHWE4MBo+rjApOjmiGOHTMWBVsSisW1k9HjmIIL0dk246yndMYo7FpFn9vZG17+I9Wan/wLICIHUiD8cm/wQ== Received: from [127.0.0.1] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:33:45 -0000 Received: from [216.39.60.184] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:31:00 -0000 Received: from [98.139.215.141] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:31:00 -0000 Received: from [98.139.212.245] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 02:30:59 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 02:30:59 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 940075.62130.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: YXxfEt4VM1mVxPcpuvAoSu4CjaO14SGtkGW7PgPHErhSPArM1kzqV2Fx_MUWHPu 8wjEui1bSb8UAsaVwstOP0maTkeT_KXxI9inFWj5YUi5JKQKIZ.GQps0jJ_wS90dr81xJIhtpDE3 VFb2lsXBMO.vZ8mgTx0IR.p75KACNUznTLgqh2RMQhAT071r9JEPQPMhjm33xaDQon2Ec1bh5nNu P9A9CCowv7pyzf7DCP6mSw2FPpCNI8XDGNuk0LmWeAzsmWe5Ja3wAMqn5zf67R_.a87HJl_OFxNJ OiaYjtfjCKEeK3KPfC.pvO4leshZ.8SPsB3_T5vaDINJhZK2pEtI288RRmXNgPd2vVLcSq1LpDby EWeYxM7JWU1po1wM_H6UBT3Kf0t36JrzC9RjqsxOb6zAg6RmvNL4GICT.wX7e59FhxItkW_JzvXo j.cwRuztgWpTHvJYhvSy_zGSQUPhEZ69Tf.ByY9HwBBGPoxKTvWBO46KuNKiCO.EzF2EBrh2xF4M CEUn0B7ptDBZ7V5AlREVKlzGMs7g.Op.ksgTmfqjdaYHNvoCr3CgiFA-- Received: by 66.196.80.118; Fri, 20 Feb 2015 02:30:59 +0000 Date: Fri, 20 Feb 2015 02:30:34 +0000 (UTC) From: Mark ZZZ Smith To: "t. petch" , Mark Andrews Message-ID: <1704611047.3947746.1424399434810.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <034e01d04c30$66fde1c0$4001a8c0@gateway.2wire.net> References: <034e01d04c30$66fde1c0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 02:33:47 -0000 > > Raising RFC5782 and RFC6471 is a Red Herring. Mark Classifying those two RFC as Informational is a subtlety that those reading this e-mail will understand but most will not (as I am reminded of when I have seen manufacturers cite conformance to Internet Drafts:-). I am sure that if I looked hard enough I would find these RFC being cited as if they were Standards, let alone a BCP. And note the title of RFC6471 'overview of Best email dns-based list (DNSBL) Operational Practices ' (my capitalisation). As I recall, the reason why it is not a BCP, when it is a BCP in all but name, is political, that the BCP stream is owned by the IETF and that RFC is not a product of the IETF. So, rightly or wrongly, the IETF has implicitly endorsed a usage of 127.0.0.n, where n is a small number, and it would be foolish, IMHO, to endorse a separate usage. / So it seems now that 127.0.0.1 on loopback interfaces, since 1982, is now incorrect because it is 'separate usage' and needs to be changed. / The IETF has explicitly said those RFCs are Informational. If the IETF then chooses to treat those documents implicitly as standards (by accepting that low 127.0.0.n addresses are only for the purpose of DNSBLs), then there is no value in any of the other more rigorous IETF standards processes. Everything should be published as Informational instead, and there is no need for working groups etc. ... / If some people don't understand or aren't aware of what the categories of RFCs are, that doesn't mean those category labels are useless - they're just useless to people who don't understand them. To some extent it is the IETF's problem, as there should be more education about the IETF process/statues etc. However, the IETF abandoning or ignoring those labels on RFCs doesn't solve the problem for which they exist, it makes the problem worse. (For some reason, the choice of percent for interface identifiers, when percent was already spoken for in URIs, comes to mind). Last I heard, IPv6 is different, that the number of MX is small, the namespace is enormous and so while ::FFFF:7F00:2 was posited, it is unlikely to gain much traction. Tom Petch > Mark > > > Perhaps those RFC should have included an IANA Considerations:-( > > > > Tom Petch > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 19 18:50:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6A1A1BB5 for ; Thu, 19 Feb 2015 18:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.835 X-Spam-Level: X-Spam-Status: No, score=0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olx2GjLUCmu2 for ; Thu, 19 Feb 2015 18:50:29 -0800 (PST) Received: from nm44-vm6.bullet.mail.gq1.yahoo.com (nm44-vm6.bullet.mail.gq1.yahoo.com [67.195.87.29]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331FD1A1B54 for ; Thu, 19 Feb 2015 18:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424400628; bh=mFBmju1qwVwaUZmL8Xt90sbjDkdse431+IRcJy/XdTk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=F2GZFNztKVz3hAQutWx/ideSPcYnGhzMVB2t8FutfX9YOUkzKXJ0JvHcFqsd27/rP2OxhhloeEm9wfOlRqzxEiXwCM2fFb2DXoEGe3DZlvHDioduVoYFtZ4PuRDNRGgeDJpYKtJdfyB/ueiPN1yDaKZuHD4uptoTDAAa/hY2JgGIK9LAQB0mknLhL0fC0rbQP0TF72mI0ubUblonqHUn630DQreoHLrnu5YnYD7NJchC+37RS/fCz6S2cncJXq9Ivxx1VhCs9+WRtVRqRF7BLS9aW3+C5f+6TzG2K8c8CIXwU9mWgOsgadQH9bJ3EsT96bmOMpf6uOTnwNigvc1GCQ== Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:50:28 -0000 Received: from [98.137.12.55] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:47:38 -0000 Received: from [98.139.215.140] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 02:47:37 -0000 Received: from [98.139.212.199] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 02:47:37 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 02:47:37 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 489721.41052.bm@omp1008.mail.bf1.yahoo.com X-YMail-OSG: iz7rXMsVM1k5A.FcsUYy10Fw13YpslhfeOrgKSL2DrZKZpR0jENWOG9z1WV5VRR _1MtTgdnqmDEYDMHZVhCUzc7MXmZGp1cKMeVATU0GWG6azwR7ow1aLa.ssFAwZVv4.jiVY9K1eLo ssqG34aRQ0NC9p_gJk_5yJQraWZ3G2qIEv_dDDEXuluQ4CuACOH63qNLjWAV8YkJxqIzXIXnnyRI TfTxUSxYD0enURPVzsXFrQANp6j9AYBDJIGqFEu.DQYqtgaconob5K8b7zX05iGOZ70G569390L7 OpZaFXLsfT9wlqgTLWjtbK3sFya.MsIJCLnkJ09N7JlSUr6xa8EyVyCTF6NsKJLIs4MhKyLDya8W Hk2ODcHJL95rUnfiCb71L4xNM41vX4epcHRFNwF9r6EK7Z7WyTnYM7JWXJBUSovEufuN2vhZE3SQ kbK4ieuXieyf0010I1BG09ZFxOZWGq46WUijKgsPk0Vz9KjtMy1L77qQt5LwSDswNDN5mU2Bymso XjmRiKt8ropBr0OqmpskfVq1AxZLdgq9mGhjssPEC9pongXJEqwAxlnFJEQDM Received: by 66.196.80.116; Fri, 20 Feb 2015 02:47:37 +0000 Date: Fri, 20 Feb 2015 02:47:09 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews , v6ops list Message-ID: <1478766156.3989413.1424400429533.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> References: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 02:50:31 -0000 Hi, I'd like to see less implication that the choice between a single ULA and a single global prefix on a link is exclusive e.g., "The use of ULAs instead of globally-routed addresses is also not discussed;" "b. Have global (or unique-local) addresses assigned in addition to link-locals?" People really need to get over this (somewhat IPv4) idea that there can only be one prefix on a link (of course, in IPv6 there are always link-locals too, but the limit on link prefixes isn't two either.). "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. Regards, Mark. ----- Original Message ----- From: Philip Matthews To: v6ops list Cc: Sent: Thursday, 19 February 2015, 8:23 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt Hi Everyone: Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. A few highlights: * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. - Philip On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-04.txt > Pages : 17 > Date : 2015-02-18 > > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 19 19:09:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A691A1BBF for ; Thu, 19 Feb 2015 19:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGhkBAiuH0p1 for ; Thu, 19 Feb 2015 19:09:49 -0800 (PST) Received: from mail-07.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F71A1BBC for ; Thu, 19 Feb 2015 19:09:49 -0800 (PST) Received: from bas5-ottawa10-1177910549.dsl.bell.ca ([70.53.125.21] helo=[10.0.1.23]) by mail-07.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YOdyO-0006mh-Q0; Thu, 19 Feb 2015 22:09:49 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <1478766156.3989413.1424400429533.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 19 Feb 2015 22:09:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca> References: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> <1478766156.3989413.1424400429533.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-1177910549.dsl.bell.ca ([10.0.1.23]) [70.53.125.21] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 03:09:52 -0000 Mark: Thanks for your comments. Replies inline. Philip On 2015-02-19, at 21:47 , Mark ZZZ Smith wrote: > Hi, >=20 >=20 > I'd like to see less implication that the choice between a single ULA = and a single global prefix on a link is exclusive e.g., >=20 > "The use of ULAs instead of globally-routed > addresses is also not discussed;" How about I just remove the words "instead of globally-routed addresses" = from the sentence? >=20 > "b. Have global (or unique-local) addresses assigned in addition to > link-locals?" >=20 > People really need to get over this (somewhat IPv4) idea that there = can only be one prefix on a link (of course, in IPv6 there are always = link-locals too, but the limit on link prefixes isn't two either.). Your point is a good one, but I don't see how the quoted sentence = implies that there is just one address GUA (or ULA). It does say = "addresses". I admit I may have written the section thinking of just a single GUA or = ULA (in addition to the LLA), but as I re-read it, I don't see any place = where that is stated or implied. >=20 > "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. I agree, though it is not often I find an situation where I can take = advantage of this. >=20 > Regards, > Mark. >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: Philip Matthews > To: v6ops list > Cc:=20 > Sent: Thursday, 19 February 2015, 8:23 > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >=20 > Hi Everyone: >=20 > Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >=20 > A few highlights: > * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. > * The text around using BGP sessions to link-local addresses has been = updated after some email exchanges with Francis Dupont (co-author of RFC = 2545), who observed that RFC 2545 forbids this (even though most vendors = support it). > * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. > * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. > * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >=20 > There were many other small changes to try to improve document wording = and clarity, and I thank a number of my colleagues at Alcatel-Lucent for = their helpful reviews. >=20 > Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >=20 > - Philip >=20 > On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >>=20 >> Title : Some Design Choices for IPv6 Networks >> Authors : Philip Matthews >> Victor Kuarsingh >> Filename : draft-ietf-v6ops-design-choices-04.txt >> Pages : 17 >> Date : 2015-02-18 >>=20 >> Abstract: >> This document presents advice on certain routing-related design >> choices that arise when designing IPv6 networks (both dual-stack and >> IPv6-only). The intended audience is someone designing an IPv6 >> network who is knowledgeable about best current practices around = IPv4 >> network design, and wishes to learn the corresponding practices for >> IPv6. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Feb 19 19:16:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F71A1BDD for ; Thu, 19 Feb 2015 19:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq3553fMaNtQ for ; Thu, 19 Feb 2015 19:16:17 -0800 (PST) Received: from nm32-vm4.bullet.mail.gq1.yahoo.com (nm32-vm4.bullet.mail.gq1.yahoo.com [98.136.216.227]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB42A1A1BD2 for ; Thu, 19 Feb 2015 19:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424402177; bh=pk3rlLcAnQVJSsJGurhi3NyBj9O49uyOFSHxmjrIZoQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=B4dYdClgI6S+7LVNrO8gsuSwvasb/io8eV1/peUc/Zmuk3THCIx+RzC3a+Jdezr0TPrg6YBupJvQYPvt3dew8iYt8btbwiPAS8VowpFewcUGmaTrj35XM3ageeBcX6UThOoWMWin22IlEtAOW5XqmNCKy+aW6ZzpCO9UQzaHtddqS+1levEB3Ktfvo0YyWjinCZq/Jxxqe5p6Pe10ddw7fwuGfGFp16Uwy3sLjgLK7x/3eQwlbROo4q9v9TxEWKfPrd+ANAorZ79JX0dOeQinSUKJTPrjRGFV+FVHGgN3rxIraHDCDxFcEl7s3AXeQJRWAZRFWy/wmaNQtqSt0olgA== Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 03:16:17 -0000 Received: from [98.137.12.174] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 03:13:33 -0000 Received: from [66.196.81.174] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 03:13:33 -0000 Received: from [98.139.212.214] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 03:13:33 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 03:13:33 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 209350.78240.bm@omp1023.mail.bf1.yahoo.com X-YMail-OSG: sHPHHpkVM1mBs934R0YyPHpLxq1F8WqOmw4NvlZ9FJ.W61Qvti8FmF_x5kpzZb0 k0klIKfoByrqjZR46KNPO77o4hvVNvjywwgCz.jii3VPswl3egdZk81e0WqrGMcDHfandVtJC4al BL53PONL13KLHYCRUrKxa_2orud59iAH3xmyhpqZzDDwA.jeshilCO2uWbB1Xrx4oQyLlBaGaoc5 T.kOIjFXzCjLSIBtN8EF4nu26paoG_toaoB6hRJLDExLOatmKIUPbgYoZzERuKFNUOoSK1g4vAZr uYow8K8pC0Az5yYnY1G7HxokWq9bK2qQcXyajMuCte0gVxnnGPjsZRqWoBj4evRzh6udPsJYG1l5 qFHbZNiLDzEafwmwbYh4C7EnTBz2nnWSsT29NnaQ.oRaW_Gf2qG5UVvQvwHd4eEzLbq3o3Q5XFwZ IjDUwaQ3qmipg15hm.kAWH0BuyKH37Tn_m7AiLxJHZvMtzp7rsAactMNnjOr0TTb2ahj5_nocF10 r8RGqltlIkv_ARgBNLdsJQjKb6hQIyGkh8SwqtM7PN6Hcr8ueISpzJcg8BOsI Received: by 66.196.80.112; Fri, 20 Feb 2015 03:13:32 +0000 Date: Fri, 20 Feb 2015 03:13:31 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews , v6ops list Message-ID: <755422206.3973419.1424402011873.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> References: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 03:16:19 -0000 Regarding these text about link-local only links: "o On some devices, by default the link-layer address of the interface is derived from the MAC address assigned to interface. When this is done, swapping out the interface hardware (e.g. interface card) will cause the link-layer address to change. In some cases (peering config, ACLs, etc) this may require additional changes. However, many devices allow the link-layer address of an interface to be explicitly configured, which avoids this issue." And other similar text about LLs being derived from MAC addresses, I think it is worth referencing RFC7217, "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", as one of the use cases it is intended to address is the case of interface swaps changing SLAAC addresses, which includes link-local addresses, as they're SLAAC addresses. (See Appendix A of RFC7217) Actually, I think it would be better to stop using "Unnumbered Interfaces"/"Unnumbered Links" because factually it is incorrect in IPv6. Something like "Link-Local Only Interfaces" would be better, and encourage people to remembering that link-local addresses are always present in IPv6. (and perhaps start to get people into the mindset that link-locals may also be used for application traffic too, as per RFC4007 and RFC6724) ----- Original Message ----- From: Philip Matthews To: v6ops list Cc: Sent: Thursday, 19 February 2015, 8:23 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt Hi Everyone: Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. A few highlights: * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. - Philip On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-04.txt > Pages : 17 > Date : 2015-02-18 > > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 19 20:15:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5EE1A6EED for ; Thu, 19 Feb 2015 20:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wCConNsBqLb for ; Thu, 19 Feb 2015 20:15:53 -0800 (PST) Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5535B1A1B14 for ; Thu, 19 Feb 2015 20:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424405752; bh=CFWTRqB4ppeRbV3mdKug3eq7AJB9C0JD/vebMLnVzl4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Z/m+6erLwa9phPC+7PugemdGWas2scrrsVPjCM2KqT4tnlzoxMaXxGh7wT2iVKlsknK86krZuEOeEaQy4Z4/2mkkzl/MCQLyfj7WwnxPJ94hoXK23eOl13jeyxKYGR3FlWZzj/78BUIh1FXOAa7XCUDYG/E88+7+bjJtG4h0CVCpiR8BSnGisb7HK6u8oWwN0xh5c0l2nLC7R0HcWMu0uf/H0yZaqzse8/ctUNqOTKkgW3GPxOEgAzyXN0rwThfXDGD20LZZcPrwqTD0EB6x5mYYzX2Dn2wBfcRgiYZbdie9BiQMZJ96T0tj/NBBH71GjKDjC5CSk+5QDMQq7p/zGA== Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:15:52 -0000 Received: from [98.138.226.176] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000 Received: from [66.196.81.173] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000 Received: from [98.139.212.225] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 478310.79554.bm@omp1034.mail.bf1.yahoo.com X-YMail-OSG: LPYfcNEVM1n7wHvM7umt5ujptbmsz4ShZ_Jjivon4PMedxwpCQwuQ9VcFltuWof yWkgjw3BaD.sHWS6JfQ3OVqOhNlgK9xZxvib1C3DkMmmLV6FM5k8cRYCfouHIIRu1mIJqE3bFes2 vnLV5GOO8MHULn3pE_Gph7_XwOtQd7jrbnM7rWGR5f5S7jStcor1rsHK0rbjs7ZleYFONRCBUnmh Xsq5B6uSSAjsTSbF64O_SyJpwjfPHXMaVlqq_4F36t6gad.8OpPdgD0SETNbCMe.37BH8BNgiDbZ WKDnGWv8ZaUpz8r7tHuLwNj2xb.uODNL1K5yBJbMRb.AU22V8NIcq9ihUy04xVcEc1moCpWoSwbt y4P09iIHdQfAZuH.Q0oRpBM.QjsEL8zau7AvkRiOY7DeCA7z6eeZaeIrcXJ9CZArsuUrRLIQca23 p5f0hcIlGqFwLeR2EfM7g.LBooyxVcPawrLLpFPpxFoQwO.JncCYIggQymi__p_CU7wq6gxCy6S2 aH.99CxUNMKJHCgDkIMy.MeXfCtDF7Yu6i6BcD6gzGvdvZ_u0_KqbMch3lQh8 Received: by 66.196.81.106; Fri, 20 Feb 2015 04:13:11 +0000 Date: Fri, 20 Feb 2015 04:13:07 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews Message-ID: <875926930.84506.1424405587971.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca> References: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 04:15:55 -0000 Hi, ----- Original Message ----- From: Philip Matthews To: Mark ZZZ Smith Cc: v6ops list Sent: Friday, 20 February 2015, 14:09 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt Mark: Thanks for your comments. Replies inline. Philip On 2015-02-19, at 21:47 , Mark ZZZ Smith wrote: > Hi, > > > I'd like to see less implication that the choice between a single ULA and a single global prefix on a link is exclusive e.g., > > "The use of ULAs instead of globally-routed > addresses is also not discussed;" How about I just remove the words "instead of globally-routed addresses" from the sentence? /I think that would do it. > > "b. Have global (or unique-local) addresses assigned in addition to > link-locals?" > > People really need to get over this (somewhat IPv4) idea that there can only be one prefix on a link (of course, in IPv6 there are always link-locals too, but the limit on link prefixes isn't two either.). Your point is a good one, but I don't see how the quoted sentence implies that there is just one address GUA (or ULA). It does say "addresses". I admit I may have written the section thinking of just a single GUA or ULA (in addition to the LLA), but as I re-read it, I don't see any place where that is stated or implied. /I think 'or' in most text is interpreted as an exclusive or. I think the brackets around the 'or unique-local' further make it read like it is implying one or the other. /"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better. /One thought about when to use 'addresses' verses 'prefixes'. I and I think a lot of other people think at the level of assigning a prefix to a link, with the assumption and implication that all interfaces attached to the link would normally have addresses from each of the on-link prefixes. The case where link attached interfaces wouldn't have addresses from all of the present prefixes would be an exception (e.g., in IPv4, when the subnet is too small, or in IPv6, perhaps when migrating a prefix off of a link, or when the prefix has been configured on a stateful DHCPv6 server, but not all hosts have asked for addresses from it.) / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be written from with the unstated assumption that all interfaces will have addresses from all on-link prefixes. As that isn't an IPv6 requirement, I think it would be best to state that assumption, and that there may be situations where that is not the case. / More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implicitly all link-attached interfaces), rather than to individual interfaces or not. So I wonder if it might be a bit clearer if the perspective was changed slightly from addresses assigned to interfaces (implicitly all interfaces on a link) to prefixes assigned to links, and then stating the assumption that in most cases all interfaces will get addresses from all on-link prefixes. > > "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. I agree, though it is not often I find an situation where I can take advantage of this. / I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses. Regards, Mark. > > Regards, > Mark. > > > > > > ----- Original Message ----- > From: Philip Matthews > To: v6ops list > Cc: > Sent: Thursday, 19 February 2015, 8:23 > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt > > Hi Everyone: > > Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. > > A few highlights: > * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. > * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). > * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. > * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. > * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. > > There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. > > Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. > > - Philip > > On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : Some Design Choices for IPv6 Networks >> Authors : Philip Matthews >> Victor Kuarsingh >> Filename : draft-ietf-v6ops-design-choices-04.txt >> Pages : 17 >> Date : 2015-02-18 >> >> Abstract: >> This document presents advice on certain routing-related design >> choices that arise when designing IPv6 networks (both dual-stack and >> IPv6-only). The intended audience is someone designing an IPv6 >> network who is knowledgeable about best current practices around IPv4 >> network design, and wishes to learn the corresponding practices for >> IPv6. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Feb 19 22:54:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38D91A03AB for ; Thu, 19 Feb 2015 22:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqJ8WP_OtV20 for ; Thu, 19 Feb 2015 22:54:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98D11A6ED9 for ; Thu, 19 Feb 2015 22:54:40 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D37741B851A; Fri, 20 Feb 2015 07:54:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A1ADA158113; Fri, 20 Feb 2015 07:54:38 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 07:54:36 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEy9ixBJZ1L350WogIuKXDMPO5z5FkZQ Date: Fri, 20 Feb 2015 06:54:35 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300490E580@OPEXCLILM23.corporate.adroot.infra.ftgroup> <9ee5ae8c-9566-4e50-afae-38e96e1247fc@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_dd61f16593284454aa38ff9d6e9cf162OPEXCLILH04corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 06:54:44 -0000 --_000_dd61f16593284454aa38ff9d6e9cf162OPEXCLILH04corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KSXRlbXMgaW5jbHVkZWQgaW4gdGhlIEktRCBhcmUgc3BlY2lmaWVkIGluIGV4 aXN0aW5nIFJGQ3MsIDNHR1Agb3IgR1NNQSBzcGVjaWZpY2F0aW9ucy4gV2UgYXJlIG5vdCDigJxp bnZlbnRpbmfigJ0gbmV3IGZlYXR1cmVzIQ0KDQpBY3R1YWxseSwgSSBkb27igJl0IHNlZSB0aGUg cG9pbnQgb2YgdGhpcyBkaXNjdXNzaW9uIHRoYXQgc3RhcnRlZCB3aXRoIGEgY29uY2VybiBhYm91 dCAiaGFybWZ1bGx5IGJyb2FkIiBidXQgZW5kcyBub3cgd2l0aDogdGhpcyBpcyBub3Qgd2l0aGlu IHRoZSBjaGFydGVyIG9mIHY2b3BzIQ0KDQpJZiB0aGUgcG9pbnQgaXMgdG8gcmFpc2UgYW4gb2Jq ZWN0aW9uIHRoZW4geW91IGNhbiBmaW5kIG1vcmUgc2VyaW91cyBvbmVzIGJ1dCBub3QgdGhpcyBv bmUuIEl0IGlzIGluY29uZ3J1ZW50IHRvIGRpc2N1c3MgdGhpcyBwb2ludCBhYm91dCB0aGUgY2hh cnRlciBhdCB0aGlzIHN0YWdlOiBlc3BlY2lhbGx5IGdpdmVuIHRoZSBkb2N1bWVudCB3YXMgYWxy ZWFkeSBhY2NlcHRlZCBieSB0aGUgV0csIHBhc3NlZCB0aGUgV0dMQyB0d2ljZSwgYW5kIGFuIElF VEYgY29uc2Vuc3VzIHdhcyBkZWNsYXJlZCBmb3IgaXQgb25jZS4NCg0KQXMgYSByZW1pbmRlciwg YmVsb3cgd2hhdCB3ZSBoYXZlIGltcGxlbWVudGVkIHRvIGFkZHJlc3MgeW91ciBjb25jZXJuczoN Cg0KwrcgICAgICAgICBXZSBpbnRlZ3JhdGVkIHRoZSB0ZXh0IGNoYW5nZSB5b3UgYXNrZWQgZm9y IHdoZW4gdGhlIFdHTEMgd2FzIGltbWVkaWF0ZWx5IGluaXRpYXRlZCwNCg0KwrcgICAgICAgICBX ZSBjbGFyaWZpZWQgeW91ciBjb25jZXJuIGFib3V0IG5vbiBwcmlvcml0aXppbmcgdGhlIHJlY29t bWVuZGF0aW9ucywNCg0KwrcgICAgICAgICBXZSBjbGFyaWZpZWQgdGhlIHBvaW50IHRoYXQgdGhl IGNvbXBsaWFuY3kgd2l0aCB0aGUgZG9jdW1lbnQgZG9lcyBub3QgbWVhbiBhbGwgaXRlbXMgbXVz dCBiZSBzdXBwb3J0ZWQsDQoNCsK3ICAgICAgICAgV2UgcmVkdWNlZCB0aGUgc2NvcGUgb2YgdGhl IGRvY3VtZW50IGFuZCBsaXN0ZWQgaXRlbXMgZnJvbSAzNCB0byAxOCAoNSBvZiB0aGVzZSBpdGVt cyBhcmUgZm9yIGRldmljZSB3aXRoIExBTiBjYXBhYmlsaXRpZXMsIHdoaWxlIDUgYXJlIGFkdmFu Y2VkIGZlYXR1cmVzKS4NCg0KSSBzdGlsbCBoYXZlIGVuZXJneSB0byBhZGRyZXNzIGFueSBzZXJp b3VzIGNvbmNlcm4geW91IHdvdWxkIGhhdmUuIElmIHlvdSBjYW4gcHJvdmlkZSB0ZXh0IHRoaXMg d291bGQgZXZlbiBiZSBiZXR0ZXIuDQoNClRoaXMgZG9jdW1lbnQgaXMgYWxzbyB5b3Vycy4gQXMg ZWRpdG9ycywgd2UgYXJlIHJlY29yZGluZyB3aGF0IHdlIGhlYXIgZnJvbSB0aGUgV0cuDQoNClRo YW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56byBDb2xpdHRpIFttYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDE5IGbDqXZyaWVyIDIwMTUgMTU6 MDMNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBEYXZlIE1pY2hhdWQ7IEJJ TkVUIERhdmlkIElNVC9PTE47IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9yZykNCk9iamV0IDog UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBj YWxsLSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24gVGh1LCBGZWIgMTksIDIwMTUgYXQgMTA6NDYg UE0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCk5vdCByZWFsbHkuIElmIHlvdSBnbyBhbmQgcmVhZCB0 aG9zZSBkb2N1bWVudHMsIHlvdSdsbCBzZWUgbm9uZSBvZiB0aGVtIGlzIG9uIGhvc3QgcmVxdWly ZW1lbnRzLg0KDQpbTWVkXSBXaXRoIGFsbCBkdWUgcmVzcGVjdCwgdGhpcyBpcyBub3QgdHJ1ZS4g UkZDNzA2NiBpcyBhbiBleGFtcGxlIG9mIGhvc3QgcmVxdWlyZW1lbnRzLg0KDQpUaGUgbWFpbiBw dXJwb3NlIG9mIFJGQyA3MDY2IGlzIG5vdCB0byBwbGFjZSByZXF1aXJlbWVudHMgb2YgaXRzIG93 biwgYnV0IHRvIGNsYXJpZnkgdGhlIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBwb3NlZCBvbiBob3N0 cyBieSB0aGUgM0dQUCBzdGFuZGFyZHMuDQoNCiBBbmQgaW4gYW55IGNhc2UsIHRoZSBkaXNjdXNz aW9uIHdhcyB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgaXMgImRpcmVjdGx5IGluIGxpbmUgd2l0aCB0 aGUgdjZvcHMgY2hhcnRlciIsIGFzIERhdmUgc2FpZC4gSnVzdCBiZWNhdXNlIHRoZSBXRyBoYXBw ZW5zIHRvIGhhdmUgcHVibGlzaGVkIGEgZmV3IGRvY3VtZW50cyB0aGF0IHRhbGsgYWJvdXQgaG9z dHMgZG9lc24ndCBtZWFuIHRoYXQgaG9zdCByZXF1aXJlbWVudHMgYXJlIGRpcmVjdGx5IGluIGxp bmUgd2l0aCB0aGUgY2hhcnRlci4NCg0KW01lZF0gV2hhdCBJIGtub3cgaXMgdGhhdCB0aGlzIGRv Y3VtZW50IHdhcyBhZG9wdGVkIGJ5IHRoZSBXRyBhbmQgcGFzc2VkIHRoZSBJRVRGIExDIG9uY2Uu IFRoZSBxdWVzdGlvbiBhYm91dCB0aGUgY2hhcnRlciB3YXMgbmV2ZXIgcmFpc2VkLg0KDQpJIGRv bid0IHNlZSB3aGF0IFdHIGFkb3B0aW9uIGFuZCBJRVRGIExDIGhhdmUgZ290IGRvIGRvIHdpdGgg dGhpcyBkaXNjdXNzaW9uLiBEYXZlIHNhaWQgdGhlIGRvY3VtZW50IGlzICJkaXJlY3RseSBpbiBs aW5lIHdpdGggdGhlIHY2b3BzIGNoYXJ0ZXIiLCBhbmQgSSBkaXNhZ3JlZWQuDQoNClRoYXQgZG9j dW1lbnQgaXMgYSBnb29kIGV4YW1wbGUgb2Ygd2hhdCAqaXMqIGluIGNoYXJ0ZXIgb2YgdGhlIFdH OiBhbiBpbi1kZXB0aCwgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiB0aGUgb3BlcmF0aW9uYWwgaXNz dWVzLiA4IGxpbmVzIG9mIHRleHQgc2F5aW5nICJkZXZpY2VzIG11c3Qgc3VwcG9ydCBkaWZmZXJl bnQgUERQIHR5cGVzIGZvciBob21lIGFuZCByb2FtaW5nIiBpcyBub3QuDQoNCltNZWRdIFRoZXJl IGlzIG5vIHJlY29tbWVuZGF0aW9uIGluIHRoZSByb2FtaW5nIGFuYWx5c2lzIGRyYWZ0LiBUaGUg cHJvZmlsZSBkb2N1bWVudCBpbmNsdWRlcyBhIGNsZWFyIHJlY29tbWVuZGF0aW9uIG9uIHRoZSBj dXJyZW50IHBsYW4gb2YgbW9zdCBvcGVyYXRvcnMgdG8gaGFuZGxlIHRoZSByb2FtaW5nIGlzc3Vl Lg0KDQpCdXQgaXQncyBub3QgdGhlIHJvbGUgb2YgdGhlIElFVEYgb3Igb2YgdGhpcyB3b3JraW5n IGdyb3VwIHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dCBvcGVyYXRvciBwbGFucy4NCltNZWRdIFdo byBpcyBhc2tpbmcgZm9yIHRoaXM/ISBUaGlzIGlzIHlvdXIgYXNzdW1wdGlvbiwgYXQgbW9zdC4N Cg0KWW91J3JlIHRoZSBvbmUgd2hvIHdyb3RlIHRoZSB3b3JkcyAidGhlIHByb2ZpbGUgZG9jdW1l bnQgaW5jbHVkZXMgYSBjbGVhciByZWNvbW1lbmRhdGlvbiBvbiB0aGUgY3VycmVudCBwbGFuIG9m IG1vc3Qgb3BlcmF0b3JzIi4gQWxsIEknbSBzYXlpbmcgaXMgdGhhdCB0aGF0J3Mgbm90IHRoZSBJ RVRGJ3Mgcm9sZS4NCg== --_000_dd61f16593284454aa38ff9d6e9cf162OPEXCLILH04corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo1OTI5MzQ3NDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjEyNzExNDYwNjQgNjg2MTkzMDY4IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+TG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+SXRlbXMgaW5jbHVkZWQgaW4gdGhlIEktRCBhcmUgc3BlY2lmaWVkIGluIGV4aXN0 aW5nIFJGQ3MsIDNHR1Agb3IgR1NNQSBzcGVjaWZpY2F0aW9ucy4gV2UgYXJlIG5vdCDigJxpbnZl bnRpbmfigJ0gbmV3IGZlYXR1cmVzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5BY3R1YWxseSwgSSBkb27igJl0IHNlZSB0aGUgcG9pbnQgb2YgdGhp cyBkaXNjdXNzaW9uIHRoYXQgc3RhcnRlZCB3aXRoIGEgY29uY2VybiBhYm91dCAmcXVvdDtoYXJt ZnVsbHkgYnJvYWQmcXVvdDsgYnV0IGVuZHMgbm93IHdpdGg6IHRoaXMgaXMgbm90IHdpdGhpbiB0 aGUgY2hhcnRlciBvZg0KIHY2b3BzISA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SWYgdGhlIHBvaW50IGlzIHRvIHJhaXNlIGFuIG9iamVjdGlvbiB0 aGVuIHlvdSBjYW4gZmluZCBtb3JlIHNlcmlvdXMgb25lcyBidXQgbm90IHRoaXMgb25lLiBJdCBp cyBpbmNvbmdydWVudCB0byBkaXNjdXNzIHRoaXMgcG9pbnQgYWJvdXQgdGhlIGNoYXJ0ZXIgYXQg dGhpcw0KIHN0YWdlOiBlc3BlY2lhbGx5IGdpdmVuIHRoZSBkb2N1bWVudCB3YXMgYWxyZWFkeSBh Y2NlcHRlZCBieSB0aGUgV0csIHBhc3NlZCB0aGUgV0dMQyB0d2ljZSwgYW5kIGFuIElFVEYgY29u c2Vuc3VzIHdhcyBkZWNsYXJlZCBmb3IgaXQgb25jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyBhIHJlbWluZGVyLCBiZWxvdyB3aGF0IHdl IGhhdmUgaW1wbGVtZW50ZWQgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5zOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2UgaW50ZWdyYXRl ZCB0aGUgdGV4dCBjaGFuZ2UgeW91IGFza2VkIGZvciB3aGVuIHRoZSBXR0xDIHdhcyBpbW1lZGlh dGVseSBpbml0aWF0ZWQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPldlIGNsYXJpZmllZCB5b3VyIGNvbmNlcm4gYWJvdXQgbm9uIHBy aW9yaXRpemluZyB0aGUgcmVjb21tZW5kYXRpb25zLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJs YWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBjbGFyaWZpZWQgdGhlIHBvaW50 IHRoYXQgdGhlIGNvbXBsaWFuY3kgd2l0aCB0aGUgZG9jdW1lbnQgZG9lcyBub3QgbWVhbiBhbGwg aXRlbXMgbXVzdCBiZSBzdXBwb3J0ZWQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldlIHJlZHVjZWQgdGhlIHNjb3BlIG9mIHRoZSBk b2N1bWVudCBhbmQgbGlzdGVkIGl0ZW1zIGZyb20gMzQgdG8gMTggKDUgb2YgdGhlc2UgaXRlbXMg YXJlIGZvciBkZXZpY2Ugd2l0aCBMQU4gY2FwYWJpbGl0aWVzLCB3aGlsZSA1IGFyZSBhZHZhbmNl ZA0KIGZlYXR1cmVzKS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkkgc3RpbGwgaGF2ZSBlbmVyZ3kgdG8gYWRkcmVzcyBhbnkgc2VyaW91 cyBjb25jZXJuIHlvdSB3b3VsZCBoYXZlLiBJZiB5b3UgY2FuIHByb3ZpZGUgdGV4dCB0aGlzIHdv dWxkIGV2ZW4gYmUgYmV0dGVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoaXMgZG9jdW1lbnQgaXMgYWxzbyB5b3Vycy4gQXMgZWRpdG9ycywg d2UgYXJlIHJlY29yZGluZyB3aGF0IHdlIGhlYXIgZnJvbSB0aGUgV0cuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDE5IGbDqXZyaWVyIDIwMTUgMTU6MDM8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IERhdmUgTWljaGF1ZDsgQklORVQgRGF2aWQgSU1UL09MTjsgSVB2NiBPcHMgV0cgKHY2b3Bz QGlldGYub3JnKTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0 Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkg YnJvYWQmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMTksIDIwMTUgYXQgMTA6NDYgUE0s ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk5vdCBy ZWFsbHkuIElmIHlvdSBnbyBhbmQgcmVhZCB0aG9zZSBkb2N1bWVudHMsIHlvdSdsbCBzZWUgbm9u ZSBvZiB0aGVtIGlzIG9uIGhvc3QgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBXaXRoIGFsbCBkdWUgcmVzcGVjdCwgdGhp cyBpcyBub3QgdHJ1ZS4gUkZDNzA2NiBpcyBhbiBleGFtcGxlIG9mIGhvc3QgcmVxdWlyZW1lbnRz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IG1haW4gcHVycG9zZSBvZiBSRkMgNzA2NiBpcyBub3QgdG8gcGxhY2UgcmVxdWlyZW1lbnRzIG9m IGl0cyBvd24sIGJ1dCB0byBjbGFyaWZ5IHRoZSByZXF1aXJlbWVudHMgdGhhdCBhcmUgcG9zZWQg b24gaG9zdHMgYnkgdGhlIDNHUFAgc3RhbmRhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ QW5kIGluIGFueSBjYXNlLCB0aGUgZGlzY3Vzc2lvbiB3YXMgd2hldGhlciB0aGlzIGRvY3VtZW50 IGlzICZxdW90O2RpcmVjdGx5DQogaW4gbGluZSB3aXRoIHRoZSB2Nm9wcyBjaGFydGVyJnF1b3Q7 LCBhcyBEYXZlIHNhaWQuIDwvc3Bhbj5KdXN0IGJlY2F1c2UgdGhlIFdHIGhhcHBlbnMgdG8gaGF2 ZSBwdWJsaXNoZWQgYSBmZXcgZG9jdW1lbnRzIHRoYXQgdGFsayBhYm91dCBob3N0cyBkb2Vzbid0 IG1lYW4gdGhhdCBob3N0IHJlcXVpcmVtZW50cyBhcmUgZGlyZWN0bHkgaW4gbGluZSB3aXRoIHRo ZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5bTWVkXSBXaGF0IEkga25vdyBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQgYnkg dGhlIFdHIGFuZCBwYXNzZWQgdGhlIElFVEYgTEMgb25jZS4gVGhlDQogcXVlc3Rpb24gYWJvdXQg dGhlIGNoYXJ0ZXIgd2FzIG5ldmVyIHJhaXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qgc2VlIHdoYXQg V0cgYWRvcHRpb24gYW5kIElFVEYgTEMgaGF2ZSBnb3QgZG8gZG8gd2l0aCB0aGlzIGRpc2N1c3Np b24uIERhdmUgc2FpZCB0aGUgZG9jdW1lbnQgaXMgJnF1b3Q7ZGlyZWN0bHkgaW4gbGluZSB3aXRo IHRoZSB2Nm9wcyBjaGFydGVyJnF1b3Q7LCBhbmQgSSBkaXNhZ3JlZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhdCBkb2N1bWVu dCBpcyBhIGdvb2QgZXhhbXBsZSBvZiB3aGF0ICppcyogaW4gY2hhcnRlciBvZiB0aGUgV0c6IGFu IGluLWRlcHRoLCBkZXRhaWxlZCBkaXNjdXNzaW9uIG9mIHRoZSBvcGVyYXRpb25hbCBpc3N1ZXMu DQo8L3NwYW4+OCBsaW5lcyBvZiB0ZXh0IHNheWluZyAmcXVvdDtkZXZpY2VzIG11c3Qgc3VwcG9y dCBkaWZmZXJlbnQgUERQIHR5cGVzIGZvciBob21lIGFuZCByb2FtaW5nJnF1b3Q7IGlzIG5vdC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGVyZSBpcyBubyByZWNvbW1lbmRhdGlvbiBpbiB0 aGUgcm9hbWluZyBhbmFseXNpcyBkcmFmdC4gVGhlIHByb2ZpbGUgZG9jdW1lbnQgaW5jbHVkZXMg YQ0KIGNsZWFyIHJlY29tbWVuZGF0aW9uIG9uIHRoZSBjdXJyZW50IHBsYW4gb2YgbW9zdCBvcGVy YXRvcnMgdG8gaGFuZGxlIHRoZSByb2FtaW5nIGlzc3VlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5CdXQgaXQncyBub3QgdGhlIHJvbGUgb2YgdGhlIElFVEYgb3Igb2YgdGhpcyB3b3Jr aW5nIGdyb3VwIHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dCBvcGVyYXRvciBwbGFucy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5bTWVkXSBXaG8gaXMgYXNraW5nIGZvciB0aGlzPyEgVGhpcyBpcyB5b3VyIGFz c3VtcHRpb24sIGF0IG1vc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdSdyZSB0aGUgb25lIHdobyB3cm90ZSB0aGUgd29yZHMgJnF1b3Q7dGhl IHByb2ZpbGUgZG9jdW1lbnQgaW5jbHVkZXMgYSBjbGVhciByZWNvbW1lbmRhdGlvbiBvbiB0aGUg Y3VycmVudCBwbGFuIG9mIG1vc3Qgb3BlcmF0b3JzJnF1b3Q7LiBBbGwgSSdtIHNheWluZyBpcyB0 aGF0IHRoYXQncyBub3QgdGhlIElFVEYncyByb2xlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dd61f16593284454aa38ff9d6e9cf162OPEXCLILH04corporateadr_-- From nobody Fri Feb 20 03:09:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1FF1A8848 for ; Fri, 20 Feb 2015 03:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.386 X-Spam-Level: *** X-Spam-Status: No, score=3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqZYvziS2Y9l for ; Fri, 20 Feb 2015 03:09:44 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C061A87DB for ; Fri, 20 Feb 2015 03:09:42 -0800 (PST) Received: from 10.236.62.138 (EHLO OPE10HT04.tp.gk.corp.tepenet) ([10.236.62.138]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DCM37174; Fri, 20 Feb 2015 12:09:30 +0100 (CET) From: Kossut Tomasz - Hurt To: jouni korhonen , Ross Chandler Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD Thread-Index: AQHQS3pwxyPvcAyf6kiWrcbrZFHqrJz2jVSAgABDWgCAAY1wgIAA3M+w Date: Fri, 20 Feb 2015 11:09:29 +0000 Message-ID: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.1] Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B28512185OPE10MB06tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.2.20.100022:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __HIGHBITS, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __HTML_FONT_RED, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0202.54E715EB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.54E715EB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: abfd206a7c7b8f55533f98d860d4129c Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:09:47 -0000 --_000_A0BB7AD89EA705449C486BDB5FDCBC7B28512185OPE10MB06tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJTUhPIEVJVCBzZXR0aW5ncyBzaG91bGQgYmUgcGFydCBvZiBjdXN0b21pemF0aW9uIOKA kyB2ZW5kb3ImZ2VuZXJpYyAgY29udHJvbGxlZCBieSAoTUNDTU5DKSBqdXN0IGxpa2UgQVBOIHNl dHRpbmdzIGl0IGhhcyBkaXJlY3QgaW1wYWN0IGluIEhQTE1OIG9uIElQIChJUHY0KSBhbGxvY2F0 aW9uLg0KDQpJZiBuZXR3b3JrIGhhcyBJUHY0IGRlZmF1bHQgYmVhcmVyIGFuZCBFSVQgYml0IGlz IG5vdCBlbmFibGVkIGluIElQdjYgdGVybWluYWxzIGl0IHJlc3VsdHMgaW4gZGVmYXVsdCBiZWFy ZXIgYWN0aXZhdGlvbiBhbmQg4oCcc2VsZWN0ZWTigJ0oSVB2NikgYmVhcmVyIGFjdGl2YXRpb24s IElQdjYgdGVybWluYWwgaW4gYSBuZXR3b3JrIHdpdGggSVB2NCBkZWZhdWx0IGJlYXJlciB3aWxs IGFsd2F5cyBlc3RhYmxpc2ggMiBiZWFyZXJzLiBJdOKAmXMgb2JzZXJ2ZWQgaW4gSFBMTU4gZm9y IGdlbmVyaWMgR29vZ2xlIGRldmljZXMgaW4gb3VyIG5ldHdvcms6DQp2dnZ2dnYgQ0FMTElEICAg TVNJRCAgICAgICAgICAgIFVTRVJOQU1FICAgICAgICAgICAgICAgSVAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBUSU1FLUlETEUNCi0tLS0tLSAtLS0tLS0tLSAtLS0tLS0tLS0tLS0t LS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAt LS0tLS0tLS0NCnhUQy5BVCAwYzNhMDY5YyAyNjAwMzAwMDAwMDAwMCBuL2EgICAgICAgICAgICAg ICAgICAgIDJhMDA6ZjQxOlhYWFg6WFhYOjo0ZDFkOjcwMDEgMDBoMDBtMDJzDQp4VEMuQUkgMGMz YTA2OWMgMjYwMDMwMDAwMDAwMDAgbi9hICAgICAgICAgICAgICAgICAgICAxMC4wMDAuMDAwLjAw MCAgMDBoMDBtMDJzDQoNCklQdjYgc3Vic2NyaWJlciBpcyBhbGxvY2F0aW5nIHVud2FudGVkIElQ djQgcmVzb3VyY2UgaGVyZSAtIHRoaXMgYXBwbHkgdG8gSFBMTU4gb25seS4NCg0KRm9yIFZQTE1O IChyb2FtaW5nIExURSkgc2l0dWF0aW9uICBnZXRzIGNvbXBsaWNhdGVkIGlmIHlvdSBjaG9vc2Ug dG8gdXNlIElQdjQgZm9yIFZQTE1OIChBUE4gc2V0dGluZ3MgLSB1c2UgSVB2NCB3aGVuIHJvYW1p bmcpDQpUZXJtaW5hbCBpbiBMVEUgd2l0aCBFSVQgYml0PTEgbG9jYXRlZCBpbiBWUExNTiB3aWxs IGFsd2F5cyByZXF1ZXN0IOKAnHNlbGVjdGVk4oCdIElQdjYgYmVhcmVyIGZvciBhdHRhY2ggKHRl cm1pbmFsIGF0dGFjaGluZyBpbiBMVEUgaGFzIG5vIGlkZWEgd2hldGhlciB0aGlzIGlzIEhQTE1O IG9yIFZQTE1OKSBvbmNlIHRlcm1pbmFsIGxlYXJuZWQg4oCdSeKAmW0gaW4gcm9hbWluZ+KAnSBh Y2NvcmRpbmcgdG8gQVBOIHNldHRpbmdzKHVzZSBJUHY0IHdoZW4gcm9hbWluZykgdGVybWluYWwg d2lsbCBlc3RhYmxpc2ggc2Vjb25kYXJ5IElQdjQgYmVhcmVyIOKAk2l0IHJlc3VsdHMgaW4gbXVs dGlwbGUgYmVhcmVyIGFjdGl2YXRpb27igKYNCg0KQ2hlZXJzLA0KVEsNCg0KDQoNCkZyb206IGpv dW5pIGtvcmhvbmVuIFttYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAxOSwgMjAxNSA5OjMxIFBNDQpUbzogUm9zcyBDaGFuZGxlcg0KQ2M6IEFs ZXhhbmRydSBQZXRyZXNjdTsgdjZvcHNAaWV0Zi5vcmc7IEtvc3N1dCBUb21hc3ogLSBIdXJ0DQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1k ZXZpY2UtcHJvZmlsZS0xNy50eHQgLSBESENQLVBEDQoNCkkgc3RpbGwgZmFpbCB0byBzZWUgaG93 IEVJVCBzZXR0aW5nIHJlbGF0ZXMgdG8gSVB2NiBhcyBhIHJlcXVpcmVtZW50LiAgSXQgaXMgYSBu b3JtYWwgcHJvY2VkdXJlIHdoZW4gdGhlIFVFIHdhbnRzIHRvIGNvbm5lY3QgKGR1cmluZyB0aGUg aW5pdGlhbCBhdHRhY2gpIHRvIGFub3RoZXIgQVBOIHRoYW4gdGhlIGRlZmF1bHQgb25lLg0KLSBK b3VuaQ0KDQpPbiBXZWQsIEZlYiAxOCwgMjAxNSBhdCAxMjo0OCBQTSwgUm9zcyBDaGFuZGxlciA8 cm9zc0BlaXJjb20ubmV0PG1haWx0bzpyb3NzQGVpcmNvbS5uZXQ+PiB3cm90ZToNCg0KT24gMTgg RmViIDIwMTUsIGF0IDE2OjQ3LCBqb3VuaSBrb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNv bTxtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gV2VkLCBG ZWIgMTgsIDIwMTUgYXQgNDo1NyBBTSwgQWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0 cmVzY3VAZ21haWwuY29tPG1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPj4gd3Jv dGU6DQpIaSwNCg0KTGUgMTgvMDIvMjAxNSAxMjoxMywgS29zc3V0IFRvbWFzeiAtIEh1cnQgYSDD qWNyaXQgOg0KSGksDQoNCklubGluZSBjb21tZW50czoNCg0KSGksDQoNClRoYW5rIHlvdSBmb3Ig dGhlIHJlcG9ydC4gSXQgaXMgZ29vZCB0byBzZWUgaG93IGdvb2QgY29uc2lkZXJhdGlvbg0KaXMg Z2l2ZW4gdG8gSVB2NiwgYW5kIHRoZSB0d28gc2VwYXJhdGVkIHBhdGhzIElQdjQvSVB2Ni4NCg0K SXQgaXMgZW5jb3VyYWdpbmcgdG8gc2VlIG51bWVyb3VzIHNtYXJ0cGhvbmUgbWFudWZhY3R1cmVy cyBoYXZpbmcNCmVtYnJhY2VkIHRoZSBDTEFUIHRlY2hub2xvZ3kuDQoNCih0aykgLSB0aGlzIGlz IG5vdCBvbmx5IENMQVQsIChDTEFUIGlzIGluIGdlbmVyaWMgQW5kcm9pZCB0aGFua3MgdG8NCkxv cmVuem8sIENhbWVyb24sIERhbiAmIG90aGVycykgZWFjaCB2ZW5kb3IgaGFzIGl0cyBvd24NCmN1 c3RvbWl6YXRpb24gYmFzZWQgb24gTUNDTU5DL3JlZ2lvbiB0byBjb250cm9sICJmZWF0dXJlcyIg cGVyDQpvcGVyYXRvci4gSW4gb3VyIGNhc2Ugd2UgaGF2ZSA6ICBkZWRpY2F0ZWQgY2xhdGQuY29u ZiAobm90IGdlbmVyaWMNCm9uZSksIElQdjYgdGV0aGVyaW5nKERIQ1B2NiwgUkEsIFJlbGF5IElQ djYgRE5TKQ0KDQpJdCdzIGdvb2QgdG8gc2VlIHRoZXNlIG1lbnRpb25lZC4NCg0KRm9yIHRldGhl cmluZyAtIGlzIHRoZSBuZXR3b3JrIG9mZmVyaW5nIERIQ1B2NiBQcmVmaXggRGVsZWdhdGlvbg0K c2VydmljZT8gIE9yIGlzIHRoZSBkZXZpY2UgcGVyZm9ybWluZyAnNjRzaGFyZScgUkZDNzI3OD8N Cg0KVGhlcmUgYXJlIHNvbWUgYWR2YW50YWdlcyBvbiBkb2luZyB0aGUgZm9ybWVyIHJhdGhlciB0 aGFuIHRoZSBsYXR0ZXIuDQpFSVQgYml0ID0xLA0KDQpXaGF0IGlzIHRoZSBFSVQgYml0Pw0KDQpN eSB3aWxkIGd1ZXNzIGlzIHRoYXQgaXQgaXMgdGhlIEVTTSBpbmZvcm1hdGlvbiB0cmFuc2ZlciBm bGFnIGJpdCBpbiB0aGUgRVNNIGluZm9ybWF0aW9uIHRyYW5zZmVyIGZsYWcgaW5mb3JtYXRpb24g ZWxlbWVudC4gSWYgaXQgaXMsIGl0IGRvZXMgbm90IHJlYWxseSBoYXZlIGFueXRoaW5nIHRvIGRv IHdpdGggSVB2NiBJTUhPLg0KLSBKb3VuaQ0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCBmcm9tIGEg cHJldmlvdXMgYW5zd2VyIG9uIHY2b3BzIGJ5IE9yYW5nZSBQTCB0aGUgRUlUIGJpdCAodGhpbmsg aXQgaXMgRVNNIGluZm8gdHJhbnNmZXIgZmxhZyBJRSkgaGFzIGFuIGVmZmVjdCB3aGVuIHRoZSBI U1MgaGFzIGEgZGVmYXVsdCBBUE4gZGlmZmVyZW50IGZyb20gdGhlIG9uZSByZXF1ZXN0ZWQgYnkg dGhlIFVFLiAgV2l0aG91dCB0aGUgRUlUIGJpdCBzZXQgdGhlIG5ldHdvcmsgZG9lc27igJl0IGxl dCB0aGUgVUUgcmVxdWVzdGVkIEFQTiBvdmVycmlkZSB0aGUgZGVmYXVsdCBmcm9tIHRoZSBIU1Ms IHNvIHR3byBQRE4gY29ubmVjdGlvbnMgYXJlIHNldCB1cCwgb25lIHdpdGggSVB2NCAoYXNzdW1p bmcgdGhlIGRlZmF1bHQgaXMgYW4gSVB2NCBvbmx5IEFQTikgYW5kIHRoZSBvdGhlciBJUHY2IChh c3N1bWluZyB0aGF0IHdhcyByZXF1ZXN0ZWQgYnkgdGhlIFVFKS4gIFNvIHN0cmljdGx5IHNwZWFr aW5nIGl0IGRvZXMgbG9vayBpbmRlcGVuZGVudCBvZiBJUCB2ZXJzaW9uIGJ1dCBpdCBpcyBiZWlu ZyBub3RpY2VkIGFzIG9wZXJhdG9ycyBpbnRyb2R1Y2UgSVB2Ni4NCg0KUm9zcw0KDQoNCg== --_000_A0BB7AD89EA705449C486BDB5FDCBC7B28512185OPE10MB06tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uU3R5 bHdpYWRvbW9jaWUtbWFpbDE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LlRla3N0ZHlta2FabmFrDQoJe21zby1zdHlsZS1uYW1lOiJUZWtzdCBkeW1rYSBabmFrIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNSE8gRUlUIHNldHRpbmdz IHNob3VsZCBiZSBwYXJ0IG9mIGN1c3RvbWl6YXRpb24g4oCTIHZlbmRvciZhbXA7Z2VuZXJpYyAm bmJzcDtjb250cm9sbGVkIGJ5IChNQ0NNTkMpIGp1c3QgbGlrZSBBUE4gc2V0dGluZ3MgaXQgaGFz IGRpcmVjdCBpbXBhY3QgaW4gSFBMTU4gb24gSVAgKElQdjQpDQogYWxsb2NhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIG5ldHdvcmsgaGFzIElQdjQgZGVmYXVsdCBiZWFyZXIgYW5kIEVJVCBiaXQgaXMgbm90 IGVuYWJsZWQgaW4gSVB2NiB0ZXJtaW5hbHMgaXQgcmVzdWx0cyBpbiBkZWZhdWx0IGJlYXJlciBh Y3RpdmF0aW9uIGFuZCDigJxzZWxlY3RlZOKAnShJUHY2KSBiZWFyZXIgYWN0aXZhdGlvbiwNCiBJ UHY2IHRlcm1pbmFsIGluIGEgbmV0d29yayB3aXRoIElQdjQgZGVmYXVsdCBiZWFyZXIgd2lsbCBh bHdheXMgZXN0YWJsaXNoIDIgYmVhcmVycy4gSXTigJlzIG9ic2VydmVkIGluIEhQTE1OIGZvciBn ZW5lcmljIEdvb2dsZSBkZXZpY2VzIGluIG91ciBuZXR3b3JrOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnZ2dnZ2 diBDQUxMSUQmbmJzcDsmbmJzcDsgTVNJRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVU0VSTkFNRSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUSU1FLUlETEU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLS0tLSAtLS0tLS0tLSAtLS0tLS0tLS0t LS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAtLS0tLS0tLS08L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnhUQy5B VCAwYzNhMDY5YyAyNjAwMzAwMDAwMDAwMCBuL2EmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMmEwMDpmNDE6WFhYWDpYWFg6OjRkMWQ6NzAw MSAwMGgwMG0wMnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 cmVkIj54VEMuQUkgMGMzYTA2OWMgMjYwMDMwMDAwMDAwMDAgbi9hJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwLjAwMC4wMDAuMDAwJm5i c3A7IDAwaDAwbTAyczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklQdjYgc3Vic2NyaWJlciBpcyBhbGxvY2F0aW5nIHVud2FudGVk IElQdjQgcmVzb3VyY2UgaGVyZSAtIHRoaXMgYXBwbHkgdG8gSFBMTU4gb25seS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFZQTE1OIChyb2FtaW5nIExURSkgc2l0dWF0 aW9uICZuYnNwO2dldHMgY29tcGxpY2F0ZWQgaWYgeW91IGNob29zZSB0byB1c2UgSVB2NCBmb3Ig VlBMTU4gKEFQTiBzZXR0aW5ncyAtIHVzZSBJUHY0IHdoZW4gcm9hbWluZyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRlcm1pbmFsIGluIExURSB3aXRoIEVJVCBi aXQ9MSBsb2NhdGVkIGluIFZQTE1OIHdpbGwgYWx3YXlzIHJlcXVlc3Qg4oCcc2VsZWN0ZWTigJ0g SVB2NiBiZWFyZXIgZm9yIGF0dGFjaCAodGVybWluYWwgYXR0YWNoaW5nIGluIExURSBoYXMgbm8g aWRlYSB3aGV0aGVyDQogdGhpcyBpcyBIUExNTiBvciBWUExNTikgb25jZSB0ZXJtaW5hbCBsZWFy bmVkIOKAnUnigJltIGluIHJvYW1pbmfigJ0gYWNjb3JkaW5nIHRvIEFQTiBzZXR0aW5ncyh1c2Ug SVB2NCB3aGVuIHJvYW1pbmcpIHRlcm1pbmFsIHdpbGwgZXN0YWJsaXNoIHNlY29uZGFyeSBJUHY0 IGJlYXJlciDigJNpdCByZXN1bHRzIGluIG11bHRpcGxlIGJlYXJlciBhY3RpdmF0aW9u4oCmPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGpvdW5pIGtvcmhvbmVuIFttYWlsdG86 am91bmkubm9zcGFtQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVi cnVhcnkgMTksIDIwMTUgOTozMSBQTTxicj4NCjxiPlRvOjwvYj4gUm9zcyBDaGFuZGxlcjxicj4N CjxiPkNjOjwvYj4gQWxleGFuZHJ1IFBldHJlc2N1OyB2Nm9wc0BpZXRmLm9yZzsgS29zc3V0IFRv bWFzeiAtIEh1cnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gREhDUC1QRDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkkgc3RpbGwgZmFpbCB0byBzZWUgaG93IEVJVCBzZXR0aW5nIHJlbGF0 ZXMgdG8gSVB2NiBhcyBhIHJlcXVpcmVtZW50LiZuYnNwOyBJdCBpcyBhIG5vcm1hbCBwcm9jZWR1 cmUgd2hlbiB0aGUgVUUgd2FudHMgdG8gY29ubmVjdCAoZHVyaW5nIHRoZSBpbml0aWFsIGF0dGFj aCkgdG8gYW5vdGhlciBBUE4gdGhhbiB0aGUgZGVmYXVsdCBvbmUuDQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBKb3VuaTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTgsIDIwMTUgYXQgMTI6NDgg UE0sIFJvc3MgQ2hhbmRsZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpyb3NzQGVpcmNvbS5uZXQiIHRh cmdldD0iX2JsYW5rIj5yb3NzQGVpcmNvbS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE4IEZl YiAyMDE1LCBhdCAxNjo0Nywgam91bmkga29yaG9uZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqb3Vu aS5ub3NwYW1AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+am91bmkubm9zcGFtQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBGZWIgMTgsIDIwMTUgYXQgNDo1NyBBTSwgQWxleGFuZHJ1IFBldHJlc2N1ICZsdDs8YSBocmVm PSJtYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFs ZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCkxlIDE4LzAyLzIwMTUgMTI6MTMs IEtvc3N1dCBUb21hc3ogLSBIdXJ0IGEgw6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCklubGluZSBjb21tZW50czo8YnI+DQo8YnI+DQpI aSw8YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSByZXBvcnQuIEl0IGlzIGdvb2QgdG8gc2Vl IGhvdyBnb29kIGNvbnNpZGVyYXRpb248YnI+DQppcyBnaXZlbiB0byBJUHY2LCBhbmQgdGhlIHR3 byBzZXBhcmF0ZWQgcGF0aHMgSVB2NC9JUHY2Ljxicj4NCjxicj4NCkl0IGlzIGVuY291cmFnaW5n IHRvIHNlZSBudW1lcm91cyBzbWFydHBob25lIG1hbnVmYWN0dXJlcnMgaGF2aW5nPGJyPg0KZW1i cmFjZWQgdGhlIENMQVQgdGVjaG5vbG9neS48YnI+DQo8YnI+DQoodGspIC0gdGhpcyBpcyBub3Qg b25seSBDTEFULCAoQ0xBVCBpcyBpbiBnZW5lcmljIEFuZHJvaWQgdGhhbmtzIHRvPGJyPg0KTG9y ZW56bywgQ2FtZXJvbiwgRGFuICZhbXA7IG90aGVycykgZWFjaCB2ZW5kb3IgaGFzIGl0cyBvd248 YnI+DQpjdXN0b21pemF0aW9uIGJhc2VkIG9uIE1DQ01OQy9yZWdpb24gdG8gY29udHJvbCAmcXVv dDtmZWF0dXJlcyZxdW90OyBwZXI8YnI+DQpvcGVyYXRvci4gSW4gb3VyIGNhc2Ugd2UgaGF2ZSA6 Jm5ic3A7IGRlZGljYXRlZCBjbGF0ZC5jb25mIChub3QgZ2VuZXJpYzxicj4NCm9uZSksIElQdjYg dGV0aGVyaW5nKERIQ1B2NiwgUkEsIFJlbGF5IElQdjYgRE5TKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJdCdz IGdvb2QgdG8gc2VlIHRoZXNlIG1lbnRpb25lZC48YnI+DQo8YnI+DQpGb3IgdGV0aGVyaW5nIC0g aXMgdGhlIG5ldHdvcmsgb2ZmZXJpbmcgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uPGJyPg0Kc2Vy dmljZT8mbmJzcDsgT3IgaXMgdGhlIGRldmljZSBwZXJmb3JtaW5nICc2NHNoYXJlJyBSRkM3Mjc4 Pzxicj4NCjxicj4NClRoZXJlIGFyZSBzb21lIGFkdmFudGFnZXMgb24gZG9pbmcgdGhlIGZvcm1l ciByYXRoZXIgdGhhbiB0aGUgbGF0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RUlUIGJpdCA9MSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCldoYXQgaXMgdGhlIEVJVCBiaXQ/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk15IHdpbGQgZ3Vlc3Mg aXMgdGhhdCBpdCBpcyB0aGUNCjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+RVNNIGluZm9ybWF0aW9uIHRyYW5zZmVyIGZsYWcgYml0IGluIHRoZSBFU00gaW5mb3JtYXRp b24gdHJhbnNmZXIgZmxhZyBpbmZvcm1hdGlvbiBlbGVtZW50LiBJZiBpdCBpcywgaXQgZG9lcyBu b3QgcmVhbGx5IGhhdmUgYW55dGhpbmcgdG8gZG8gd2l0aCBJUHY2IElNSE8uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tIEpvdW5pPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZhciBhcyBJIGNh biB0ZWxsIGZyb20gYSBwcmV2aW91cyBhbnN3ZXIgb24gdjZvcHMgYnkgT3JhbmdlIFBMIHRoZSBF SVQgYml0ICh0aGluayBpdCBpcyBFU00gaW5mbyB0cmFuc2ZlciBmbGFnIElFKSBoYXMgYW4gZWZm ZWN0IHdoZW4gdGhlIEhTUyBoYXMgYSBkZWZhdWx0IEFQTiBkaWZmZXJlbnQgZnJvbSB0aGUgb25l IHJlcXVlc3RlZCBieSB0aGUgVUUuJm5ic3A7IFdpdGhvdXQgdGhlIEVJVCBiaXQgc2V0IHRoZQ0K IG5ldHdvcmsgZG9lc27igJl0IGxldCB0aGUgVUUgcmVxdWVzdGVkIEFQTiBvdmVycmlkZSB0aGUg ZGVmYXVsdCBmcm9tIHRoZSBIU1MsIHNvIHR3byBQRE4gY29ubmVjdGlvbnMgYXJlIHNldCB1cCwg b25lIHdpdGggSVB2NCAoYXNzdW1pbmcgdGhlIGRlZmF1bHQgaXMgYW4gSVB2NCBvbmx5IEFQTikg YW5kIHRoZSBvdGhlciBJUHY2IChhc3N1bWluZyB0aGF0IHdhcyByZXF1ZXN0ZWQgYnkgdGhlIFVF KS4mbmJzcDsgU28gc3RyaWN0bHkgc3BlYWtpbmcgaXQgZG9lcw0KIGxvb2sgaW5kZXBlbmRlbnQg b2YgSVAgdmVyc2lvbiBidXQgaXQgaXMgYmVpbmcgbm90aWNlZCBhcyBvcGVyYXRvcnMgaW50cm9k dWNlIElQdjYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPlJvc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_A0BB7AD89EA705449C486BDB5FDCBC7B28512185OPE10MB06tpgkco_-- From nobody Fri Feb 20 04:22:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A21A1E10 for ; Fri, 20 Feb 2015 04:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.992 X-Spam-Level: X-Spam-Status: No, score=0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuCpI1p3nI1K for ; Fri, 20 Feb 2015 04:22:02 -0800 (PST) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id BBC2E1A19F7 for ; Fri, 20 Feb 2015 04:13:28 -0800 (PST) Received: (qmail 42881 messnum 12642051 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 20 Feb 2015 12:13:27 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail06.svc.cra.dublin.eircom.net (qp 42881) with SMTP; 20 Feb 2015 12:13:27 -0000 Received: from [IPv6:2a01:b340:20:1e59:2866:ce57:ba06:4a8a] ([185.51.73.206]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id ucDP1p00G4T2iB501cDT1K; Fri, 20 Feb 2015 12:13:27 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_BDDD3050-C962-4A32-8B1E-69D9D100484E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: Date: Fri, 20 Feb 2015 12:13:24 +0000 Message-Id: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> To: Kossut Tomasz - Hurt X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:22:05 -0000 --Apple-Mail=_BDDD3050-C962-4A32-8B1E-69D9D100484E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s unfortunate this wasn=E2=80=99t captured in the = roaming-analysis I-D. IMHO it looks like that operators must try harder = to sort out their networks and billing mediation systems so IPv6 roaming = is allowed. Ross > On 20 Feb 2015, at 11:09, Kossut Tomasz - Hurt = wrote: >=20 > Hi, > IMHO EIT settings should be part of customization =E2=80=93 = vendor&generic controlled by (MCCMNC) just like APN settings it has = direct impact in HPLMN on IP (IPv4) allocation. > =20 > If network has IPv4 default bearer and EIT bit is not enabled in IPv6 = terminals it results in default bearer activation and = =E2=80=9Cselected=E2=80=9D(IPv6) bearer activation, IPv6 terminal in a = network with IPv4 default bearer will always establish 2 bearers. It=E2=80= =99s observed in HPLMN for generic Google devices in our network: > vvvvvv CALLID MSID USERNAME IP = TIME-IDLE > ------ -------- --------------- ---------------------- = ----------------------------- --------- > xTC.AT 0c3a069c 26003000000000 n/a = 2a00:f41:XXXX:XXX::4d1d:7001 00h00m02s > xTC.AI 0c3a069c 26003000000000 n/a 10.000.000.000 = 00h00m02s > =20 > IPv6 subscriber is allocating unwanted IPv4 resource here - this apply = to HPLMN only. > =20 > For VPLMN (roaming LTE) situation gets complicated if you choose to = use IPv4 for VPLMN (APN settings - use IPv4 when roaming) > Terminal in LTE with EIT bit=3D1 located in VPLMN will always request = =E2=80=9Cselected=E2=80=9D IPv6 bearer for attach (terminal attaching in = LTE has no idea whether this is HPLMN or VPLMN) once terminal learned = =E2=80=9DI=E2=80=99m in roaming=E2=80=9D according to APN settings(use = IPv4 when roaming) terminal will establish secondary IPv4 bearer =E2=80=93= it results in multiple bearer activation=E2=80=A6 > =20 > Cheers, > TK > =20 > =20 > =20 > From: jouni korhonen [mailto:jouni.nospam@gmail.com = ]=20 > Sent: Thursday, February 19, 2015 9:31 PM > To: Ross Chandler > Cc: Alexandru Petrescu; v6ops@ietf.org ; Kossut = Tomasz - Hurt > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD > =20 > I still fail to see how EIT setting relates to IPv6 as a requirement. = It is a normal procedure when the UE wants to connect (during the = initial attach) to another APN than the default one. >=20 > - Jouni > =20 > On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler > wrote: > =20 > On 18 Feb 2015, at 16:47, jouni korhonen > wrote: > =20 > =20 > =20 > On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu = > = wrote: > Hi, >=20 > Le 18/02/2015 12:13, Kossut Tomasz - Hurt a =C3=A9crit : > Hi, >=20 > Inline comments: >=20 > Hi, >=20 > Thank you for the report. It is good to see how good consideration > is given to IPv6, and the two separated paths IPv4/IPv6. >=20 > It is encouraging to see numerous smartphone manufacturers having > embraced the CLAT technology. >=20 > (tk) - this is not only CLAT, (CLAT is in generic Android thanks to > Lorenzo, Cameron, Dan & others) each vendor has its own > customization based on MCCMNC/region to control "features" per > operator. In our case we have : dedicated clatd.conf (not generic > one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) >=20 > It's good to see these mentioned. >=20 > For tethering - is the network offering DHCPv6 Prefix Delegation > service? Or is the device performing '64share' RFC7278? >=20 > There are some advantages on doing the former rather than the latter. >=20 > EIT bit =3D1, >=20 > What is the EIT bit? > =20 > My wild guess is that it is the ESM information transfer flag bit in = the ESM information transfer flag information element. If it is, it does = not really have anything to do with IPv6 IMHO. >=20 > - Jouni > =20 > As far as I can tell from a previous answer on v6ops by Orange PL the = EIT bit (think it is ESM info transfer flag IE) has an effect when the = HSS has a default APN different from the one requested by the UE. = Without the EIT bit set the network doesn=E2=80=99t let the UE requested = APN override the default from the HSS, so two PDN connections are set = up, one with IPv4 (assuming the default is an IPv4 only APN) and the = other IPv6 (assuming that was requested by the UE). So strictly = speaking it does look independent of IP version but it is being noticed = as operators introduce IPv6. > =20 > Ross --Apple-Mail=_BDDD3050-C962-4A32-8B1E-69D9D100484E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s unfortunate this wasn=E2=80=99t captured in the = roaming-analysis I-D. IMHO it looks like that operators must try harder = to sort out their networks and billing mediation systems so IPv6 roaming = is allowed.

Ross


On 20 Feb 2015, at 11:09, Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com> wrote:

Hi,
IMHO EIT settings should be part of customization =E2=80=93 = vendor&generic  controlled by (MCCMNC) just like APN settings = it has direct impact in HPLMN on IP (IPv4) allocation.
 
If network has IPv4 = default bearer and EIT bit is not enabled in IPv6 terminals it results = in default bearer activation and =E2=80=9Cselected=E2=80=9D(IPv6) bearer = activation, IPv6 terminal in a network with IPv4 default bearer will = always establish 2 bearers. It=E2=80=99s observed in HPLMN for generic = Google devices in our network:
vvvvvv CALLID   = MSID            = USERNAME           =     = IP            =             &n= bsp;        TIME-IDLE
------ -------- = --------------- ---------------------- ----------------------------- = ---------
xTC.AT 0c3a069c 26003000000000 = n/a            = ;        2a00:f41:XXXX:XXX::4d1d:7001 = 00h00m02s
xTC.AI 0c3a069c 26003000000000 = n/a            = ;        10.000.000.000  = 00h00m02s
 
IPv6 subscriber is allocating unwanted IPv4 resource here - = this apply to HPLMN only.
 
For VPLMN (roaming LTE) = situation  gets complicated if you choose to use IPv4 for VPLMN = (APN settings - use IPv4 when roaming)
Terminal in LTE with = EIT bit=3D1 located in VPLMN will always request =E2=80=9Cselected=E2=80=9D= IPv6 bearer for attach (terminal attaching in LTE has no idea whether = this is HPLMN or VPLMN) once terminal learned =E2=80=9DI=E2=80=99m in = roaming=E2=80=9D according to APN settings(use IPv4 when roaming) = terminal will establish secondary IPv4 bearer =E2=80=93it results in = multiple bearer activation=E2=80=A6
 
Cheers,
TK
 
 
 
From: jouni korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Thursday, February 19, 2015 = 9:31 PM
To: Ross Chandler
Cc: Alexandru Petrescu; v6ops@ietf.org; Kossut Tomasz - Hurt
Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD
 

I still fail to see how EIT = setting relates to IPv6 as a requirement.  It is a normal procedure = when the UE wants to connect (during the initial attach) to another APN = than the default one.

- Jouni
 
On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <ross@eircom.net> = wrote:
 
On 18 Feb 2015, at = 16:47, jouni korhonen <jouni.nospam@gmail.com> wrote:
 
 
 
On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Hi,
Le 18/02/2015 12:13, Kossut Tomasz - Hurt a = =C3=A9crit :
Hi,

Inline comments:

Hi,

Thank you for = the report. It is good to see how good consideration
is = given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers = having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android = thanks to
Lorenzo, Cameron, Dan & others) each vendor = has its own
customization based on MCCMNC/region to = control "features" per
operator. In our case we have = :  dedicated clatd.conf (not generic
one), IPv6 = tethering(DHCPv6, RA, Relay IPv6 DNS)


It's good to see = these mentioned.

For tethering - is the = network offering DHCPv6 Prefix Delegation
service?  = Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the = latter.

EIT = bit =3D1,

What is the EIT bit?
 

My wild guess is that it is = the ESM information transfer flag bit = in the ESM information transfer flag information element. If it is, it = does not really have anything to do with IPv6 IMHO.

- = Jouni
 
As far as I can tell from a previous = answer on v6ops by Orange PL the EIT bit (think it is ESM info transfer = flag IE) has an effect when the HSS has a default APN different from the = one requested by the UE.  Without the EIT bit set the network = doesn=E2=80=99t let the UE requested APN override the default from the = HSS, so two PDN connections are set up, one with IPv4 (assuming the = default is an IPv4 only APN) and the other IPv6 (assuming that was = requested by the UE).  So strictly speaking it does look = independent of IP version but it is being noticed as operators introduce = IPv6.
 
Ross

= --Apple-Mail=_BDDD3050-C962-4A32-8B1E-69D9D100484E-- From nobody Fri Feb 20 04:24:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269981A036E for ; Fri, 20 Feb 2015 04:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPp2x_j-Xyca for ; Fri, 20 Feb 2015 04:24:05 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196041A8963 for ; Fri, 20 Feb 2015 04:17:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1KCHIxA020436; Fri, 20 Feb 2015 13:17:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A783202B58; Fri, 20 Feb 2015 13:18:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 146F7202B54; Fri, 20 Feb 2015 13:18:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1KCHHPU021286; Fri, 20 Feb 2015 13:17:18 +0100 Message-ID: <54E725CD.1080005@gmail.com> Date: Fri, 20 Feb 2015 13:17:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kossut Tomasz - Hurt , jouni korhonen , Ross Chandler References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E1D42C.5040605@gmail.com> <54E48C2E.2020703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:24:07 -0000 I find the description of the EIT bit (allow multiple APNs, IPv4 and/or IPv6) a tempting feature. Can the EIT bit be set by using open-source software tools? For example, when I connect a linux computer to a 4G network I use ModemManager and mmcli open source software, on a cheap USB 4G key. Or is the EIT bit proprietary to one operator and smartphone manufacturer? Alex Le 20/02/2015 12:09, Kossut Tomasz - Hurt a écrit : > Hi, > > IMHO EIT settings should be part of customization – vendor&generic > controlled by (MCCMNC) just like APN settings it has direct impact > in HPLMN on IP (IPv4) allocation. > > If network has IPv4 default bearer and EIT bit is not enabled in > IPv6 terminals it results in default bearer activation and > “selectedâ€(IPv6) bearer activation, IPv6 terminal in a network with > IPv4 default bearer will always establish 2 bearers. It’s observed > in HPLMN for generic Google devices in our network: > > vvvvvv CALLID MSID USERNAME IP TIME-IDLE > > ------ -------- --------------- ---------------------- > ----------------------------- --------- > > xTC.AT 0c3a069c 26003000000000 n/a 2a00:f41:XXXX:XXX::4d1d:7001 > 00h00m02s > > xTC.AI 0c3a069c 26003000000000 n/a 10.000.000.000 > 00h00m02s > > IPv6 subscriber is allocating unwanted IPv4 resource here - this > apply to HPLMN only. > > For VPLMN (roaming LTE) situation gets complicated if you choose to > use IPv4 for VPLMN (APN settings - use IPv4 when roaming) > > Terminal in LTE with EIT bit=1 located in VPLMN will always request > “selected†IPv6 bearer for attach (terminal attaching in LTE has no > idea whether this is HPLMN or VPLMN) once terminal learned â€I’m in > roaming†according to APN settings(use IPv4 when roaming) terminal > will establish secondary IPv4 bearer –it results in multiple bearer > activation… > > Cheers, > > TK > > *From:*jouni korhonen [mailto:jouni.nospam@gmail.com] *Sent:* > Thursday, February 19, 2015 9:31 PM *To:* Ross Chandler *Cc:* > Alexandru Petrescu; v6ops@ietf.org; Kossut Tomasz - Hurt *Subject:* > Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD > > I still fail to see how EIT setting relates to IPv6 as a > requirement. It is a normal procedure when the UE wants to connect > (during the initial attach) to another APN than the default one. > > - Jouni > > On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler > wrote: > > On 18 Feb 2015, at 16:47, jouni korhonen > wrote: > > On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu > > > wrote: > > Hi, > > Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit : > > Hi, > > Inline comments: > > Hi, > > Thank you for the report. It is good to see how good consideration > is given to IPv6, and the two separated paths IPv4/IPv6. > > It is encouraging to see numerous smartphone manufacturers having > embraced the CLAT technology. > > (tk) - this is not only CLAT, (CLAT is in generic Android thanks to > Lorenzo, Cameron, Dan & others) each vendor has its own > customization based on MCCMNC/region to control "features" per > operator. In our case we have : dedicated clatd.conf (not generic > one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) > > > It's good to see these mentioned. > > For tethering - is the network offering DHCPv6 Prefix Delegation > service? Or is the device performing '64share' RFC7278? > > There are some advantages on doing the former rather than the > latter. > > EIT bit =1, > > > What is the EIT bit? > > My wild guess is that it is the ESM information transfer flag bit in > the ESM information transfer flag information element. If it is, it > does not really have anything to do with IPv6 IMHO. > > - Jouni > > As far as I can tell from a previous answer on v6ops by Orange PL > the EIT bit (think it is ESM info transfer flag IE) has an effect > when the HSS has a default APN different from the one requested by > the UE. Without the EIT bit set the network doesn’t let the UE > requested APN override the default from the HSS, so two PDN > connections are set up, one with IPv4 (assuming the default is an > IPv4 only APN) and the other IPv6 (assuming that was requested by the > UE). So strictly speaking it does look independent of IP version but > it is being noticed as operators introduce IPv6. > > Ross > From nobody Fri Feb 20 04:39:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2C1A8AD0 for ; Fri, 20 Feb 2015 04:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwVlcbTGb13b for ; Fri, 20 Feb 2015 04:39:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7AB1A8A3C for ; Fri, 20 Feb 2015 04:39:18 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D959F1B863E; Fri, 20 Feb 2015 13:39:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id BE253C809B; Fri, 20 Feb 2015 13:39:16 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 13:39:16 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTEwqixBJZ1L350WogIuKXDMPO5z5edvA Date: Fri, 20 Feb 2015 12:39:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300491144D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E5EC11.4070002@gmail.com> In-Reply-To: <54E5EC11.4070002@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.20.20027 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:39:20 -0000 SGkgQWxleCwNCg0KSXQgaXMgb2J2aW91cyB0aGF0IENMQVQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0 aCBuYXRpdmUgSVB2NiBjb21tdW5pY2F0aW9ucyAoaS5lLiwgY29tbXVuaWNhdGlvbnMgYmV0d2Vl biBJUHY2LWVuYWJsZWQgbm9kZXMgb3ZlciBhbiBJUHY2LWVuYWJsZWQgbmV0d29yaykuDQoNClRo ZSBDTEFUIHJlY29tbWVuZGF0aW9uIGluIHRoZSBwcm9maWxlIEktRCBzdGFydHMgd2l0aDogIklu IG9yZGVyIHRvIGVuc3VyZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSBpbiBhbiBJUHY2LW9ubHkg ZGVwbG95bWVudCBjb250ZXh0LCINCg0KVGhhdCdzIElNSE8gY2xlYXIgZW5vdWdoIHRvIGF2b2lk ICJvdGhlcnMgdG8gdGhpbmsgdGhhdCBJUHY2IGlzIHBvc3NpYmxlIG9ubHkgaWYgQ0xBVCBpcyB0 aGVyZS4iLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIEFsZXhhbmRydQ0KPiBQZXRyZXNjdQ0KPiBFbnZvecOpwqA6IGpldWRpIDE5IGbDqXZyaWVy IDIwMTUgMTQ6NTkNCj4gw4DCoDogdjZvcHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFt2Nm9w c10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUgbGFzdCBjYWxsLQ0KPiAi aGFybWZ1bGx5IGJyb2FkIj8NCj4gDQo+IA0KPiBBbW9uZyB0aG9zZSB0d28gKElQdjYgYW5kIENM QVQpIG9uZSB3b3VsZCBjZXJ0YWlubHkgc3VnZ2VzdCBJUHY2DQo+IGltcGxlbWVudGF0aW9uIGlu IHRoZSB0ZXJtaW5hbCwgYnV0IENMQVQgc2hvdWxkIGJlIGEgIk1BWSIuICBPbmUNCj4gd291bGRu J3Qgd2FudCBvdGhlcnMgdG8gdGhpbmsgdGhhdCBJUHY2IGlzIHBvc3NpYmxlIG9ubHkgaWYgQ0xB VCBpcyB0aGVyZS4NCj4gDQo+IEFsZXgNCg== From nobody Fri Feb 20 04:57:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7F1A8AEA for ; Fri, 20 Feb 2015 04:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9tmv3u5VN0i for ; Fri, 20 Feb 2015 04:57:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60E41A8AEB for ; Fri, 20 Feb 2015 04:57:27 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1KCvPGV021862; Fri, 20 Feb 2015 13:57:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C3EE202B5C; Fri, 20 Feb 2015 13:58:32 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 00B8F202AE3; Fri, 20 Feb 2015 13:58:32 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1KCvLRx020861; Fri, 20 Feb 2015 13:57:25 +0100 Message-ID: <54E72F31.5030703@gmail.com> Date: Fri, 20 Feb 2015 13:57:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E5EC11.4070002@gmail.com> <787AE7BB302AE849A7480A190F8B93300491144D@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300491144D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:57:30 -0000 Le 20/02/2015 13:39, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > It is obvious that CLAT has nothing to do with native IPv6 > communications (i.e., communications between IPv6-enabled nodes over > an IPv6-enabled network). > > The CLAT recommendation in the profile I-D starts with: "In order to > ensure IPv4 service continuity in an IPv6-only deployment context," > > That's IMHO clear enough to avoid "others to think that IPv6 is > possible only if CLAT is there.". YEs, I agree. That text is sufficient. As a side note, I would be doubtful naming an IPv6-only access network something that uses IPv4 as well (464xlat, dns64). I would rather call it a "mostly" IPv6 access network, with a little of IPv4 however. This is just a matter of terminology. Also, since we last discussed we went trying eliminate the IPv4 stack from a linux kernel. That is not possible. So any 'pure' IPv6 machine that would connect to an IPv6-only access network is just a speculation at this point, years away from any deployment. Alex > > Cheers, Med > >> -----Message d'origine----- De : v6ops >> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoyé : jeudi 19 février 2015 14:59 À : v6ops@ietf.org Objet : >> Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- >> "harmfully broad"? >> >> >> Among those two (IPv6 and CLAT) one would certainly suggest IPv6 >> implementation in the terminal, but CLAT should be a "MAY". One >> wouldn't want others to think that IPv6 is possible only if CLAT >> is there. >> >> Alex From nobody Fri Feb 20 05:05:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52111A8AED for ; Fri, 20 Feb 2015 05:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OHpDRPimZvI for ; Fri, 20 Feb 2015 05:05:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720DF1A8A16 for ; Fri, 20 Feb 2015 05:05:10 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 44E2E3243E9; Fri, 20 Feb 2015 14:05:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 265074C12D; Fri, 20 Feb 2015 14:05:08 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 14:05:08 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AQHQTQzDixBJZ1L350WogIuKXDMPO5z5gK1A Date: Fri, 20 Feb 2015 13:05:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049114CA@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E5EC11.4070002@gmail.com> <787AE7BB302AE849A7480A190F8B93300491144D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54E72F31.5030703@gmail.com> In-Reply-To: <54E72F31.5030703@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.20.124219 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:05:12 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBBbGV4YW5kcnUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcnUucGV0cmVz Y3VAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDIwIGbDqXZyaWVyIDIwMTUgMTM6 NTcNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8KgOiB2Nm9wc0BpZXRm Lm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZp Y2UtcHJvZmlsZSBsYXN0IGNhbGwtDQo+ICJoYXJtZnVsbHkgYnJvYWQiPw0KPiANCj4gTGUgMjAv MDIvMjAxNSAxMzozOSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBhIMOpY3JpdCA6DQo+ ID4gSGkgQWxleCwNCj4gPg0KPiA+IEl0IGlzIG9idmlvdXMgdGhhdCBDTEFUIGhhcyBub3RoaW5n IHRvIGRvIHdpdGggbmF0aXZlIElQdjYNCj4gPiBjb21tdW5pY2F0aW9ucyAoaS5lLiwgY29tbXVu aWNhdGlvbnMgYmV0d2VlbiBJUHY2LWVuYWJsZWQgbm9kZXMgb3Zlcg0KPiA+IGFuIElQdjYtZW5h YmxlZCBuZXR3b3JrKS4NCj4gPg0KPiA+IFRoZSBDTEFUIHJlY29tbWVuZGF0aW9uIGluIHRoZSBw cm9maWxlIEktRCBzdGFydHMgd2l0aDogIkluIG9yZGVyIHRvDQo+ID4gZW5zdXJlIElQdjQgc2Vy dmljZSBjb250aW51aXR5IGluIGFuIElQdjYtb25seSBkZXBsb3ltZW50IGNvbnRleHQsIg0KPiA+ DQo+ID4gVGhhdCdzIElNSE8gY2xlYXIgZW5vdWdoIHRvIGF2b2lkICJvdGhlcnMgdG8gdGhpbmsg dGhhdCBJUHY2IGlzDQo+ID4gcG9zc2libGUgb25seSBpZiBDTEFUIGlzIHRoZXJlLiIuDQo+IA0K PiBZRXMsIEkgYWdyZWUuICBUaGF0IHRleHQgaXMgc3VmZmljaWVudC4NCg0KQ29vbCEgVGhhbmsg eW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KPiANCj4gQXMgYSBzaWRlIG5vdGUsIEkgd291bGQgYmUg ZG91YnRmdWwgbmFtaW5nIGFuIElQdjYtb25seSBhY2Nlc3MgbmV0d29yaw0KPiBzb21ldGhpbmcg dGhhdCB1c2VzIElQdjQgYXMgd2VsbCAoNDY0eGxhdCwgZG5zNjQpLiAgSSB3b3VsZCByYXRoZXIg Y2FsbA0KPiBpdCBhICJtb3N0bHkiIElQdjYgYWNjZXNzIG5ldHdvcmssIHdpdGggYSBsaXR0bGUg b2YgSVB2NCBob3dldmVyLg0KPiANCj4gVGhpcyBpcyBqdXN0IGEgbWF0dGVyIG9mIHRlcm1pbm9s b2d5Lg0KPiANCj4gQWxzbywgc2luY2Ugd2UgbGFzdCBkaXNjdXNzZWQgd2Ugd2VudCB0cnlpbmcg ZWxpbWluYXRlIHRoZSBJUHY0IHN0YWNrDQo+IGZyb20gYSBsaW51eCBrZXJuZWwuICBUaGF0IGlz IG5vdCBwb3NzaWJsZS4gIFNvIGFueSAncHVyZScgSVB2NiBtYWNoaW5lDQo+IHRoYXQgd291bGQg Y29ubmVjdCB0byBhbiBJUHY2LW9ubHkgYWNjZXNzIG5ldHdvcmsgaXMganVzdCBhIHNwZWN1bGF0 aW9uDQo+IGF0IHRoaXMgcG9pbnQsIHllYXJzIGF3YXkgZnJvbSBhbnkgZGVwbG95bWVudC4NCj4g DQo+IEFsZXgNCj4gDQo+ID4NCj4gPiBDaGVlcnMsIE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLSBEZSA6IHY2b3BzDQo+ID4+IFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBBbGV4YW5kcnUgUGV0cmVzY3UNCj4gPj4gRW52b3nDqSA6 IGpldWRpIDE5IGbDqXZyaWVyIDIwMTUgMTQ6NTkgw4AgOiB2Nm9wc0BpZXRmLm9yZyBPYmpldCA6 DQo+ID4+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxl IGxhc3QgY2FsbC0NCj4gPj4gImhhcm1mdWxseSBicm9hZCI/DQo+ID4+DQo+ID4+DQo+ID4+IEFt b25nIHRob3NlIHR3byAoSVB2NiBhbmQgQ0xBVCkgb25lIHdvdWxkIGNlcnRhaW5seSBzdWdnZXN0 IElQdjYNCj4gPj4gaW1wbGVtZW50YXRpb24gaW4gdGhlIHRlcm1pbmFsLCBidXQgQ0xBVCBzaG91 bGQgYmUgYSAiTUFZIi4gIE9uZQ0KPiA+PiB3b3VsZG4ndCB3YW50IG90aGVycyB0byB0aGluayB0 aGF0IElQdjYgaXMgcG9zc2libGUgb25seSBpZiBDTEFUDQo+ID4+IGlzIHRoZXJlLg0KPiA+Pg0K PiA+PiBBbGV4DQo+IA0KDQo= From nobody Fri Feb 20 06:22:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E21A8750 for ; Fri, 20 Feb 2015 06:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOsGeFNo0yqk for ; Fri, 20 Feb 2015 06:22:21 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA631A8759 for ; Fri, 20 Feb 2015 06:22:21 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id d1347e45.2b4bdde62940.2944802.00-2453.8330888.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 20 Feb 2015 14:22:21 +0000 (UTC) X-MXL-Hash: 54e7431d18f2077b-a6ffe0b1fd1800061e2c1bd7ed28263bcbfd40c5 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id c0347e45.0.2944652.00-2182.8330471.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 20 Feb 2015 14:22:07 +0000 (UTC) X-MXL-Hash: 54e7430f21ee46c6-15e5b57a5237e23655f25d34cee11898bfa04d5f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1KEM4Eb000786; Fri, 20 Feb 2015 09:22:04 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1KELw4O000711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Feb 2015 09:21:59 -0500 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 20 Feb 2015 14:21:50 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.126]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 09:21:50 -0500 From: "STARK, BARBARA H" To: "'Fred Baker (fred)'" , "v6ops@ietf.org" Thread-Topic: Inviting discussion: draft-chen-v6ops-nfv-ipv6 Thread-Index: AdBMhkOVK+jx9zhxQgW7jsjoc/yHpwAkNMaQ Date: Fri, 20 Feb 2015 14:21:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F30325@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8C48B86A895913448548E6D15DA7553B0612B38A@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B0612B38A@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=vKzWRVGcsRAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9nkA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=VTtYgNpgYSHxIbz5scsA:9 a=CjuIK1q_8ugA:10 a=HSP8-D6] X-AnalysisOut: [_OhjEB8UZ:21 a=w1dAibhA7juTv4pi:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [v6ops] Inviting discussion: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 14:22:24 -0000 Hi Fred, I did talk to Hui Deng about this draft while in Hawaii. There was off-line= feedback from me and others in my company. My main comment was that drivin= g operator requirements into OpenStack code is best done in OPNFV. I don't = think IETF is the right place to do OpenStack-specific design. If there were to be a presentation in Dallas, I would prefer for there to b= e a new revision that incorporated changes from received comments. Barbara > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Thursday, February 19, 2015 3:55 PM > To: v6ops@ietf.org > Subject: [v6ops] Inviting discussion: draft-chen-v6ops-nfv-ipv6 >=20 > https://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6 > "IPv6 Considerations for Network Function Virtualization (NFV)", Gang > Chen, Hui Deng, 2014-10-27 >=20 > This draft was prepared for IETF 91, but didn't get discussed in part bec= ause a > number of Chinese participants didn't make it to Honolulu for a Monday > meeting. Is there interest in discussing it at IETF 92? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 20 10:30:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7761A6F21 for ; Fri, 20 Feb 2015 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18i35qoE6l0d for ; Fri, 20 Feb 2015 10:30:38 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537391A020D for ; Fri, 20 Feb 2015 10:30:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3BA0AA2; Fri, 20 Feb 2015 19:30:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424457017; bh=Gl0MRNe2BAVxmS2hsmrVRSURAFPukUq0Dc9vlHoZt6U=; h=Date:From:To:Subject:In-Reply-To:References:From; b=bfbjnhOVZr9zKEqUUv3FfuzPksAetcIMZB3S4xTLoNwnphGezKHpnD2ZPs/YG9v2t OFsiziF3E9Nq673Za4Ot2TxH8Ym47HBqwAWZcelZ/CzgYY3OPu02wLZtCZ6zqA0Ub7 LZWpQCzVZBmffdeUKm+NDg1rt/Zs51R5Ww1NAoIc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 34129A1 for ; Fri, 20 Feb 2015 19:30:17 +0100 (CET) Date: Fri, 20 Feb 2015 19:30:17 +0100 (CET) From: Mikael Abrahamsson To: V6 Ops List In-Reply-To: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:30:40 -0000 On Wed, 28 Jan 2015, Fred Baker (fred) wrote: > Please read it now, and comment. This WGLC will run until 15 February. I have re-read the latest incarnation just now. I am going to treat it as if I never read it before: 1.2. I know what a "shorter prefix than /64" is. A lot of readers might not, so I would like to insert at "(larger)" in there, or similar text. C_REC#2: Second paragraph, suggest text to clarify that adding the second PDP context is to achieve dual stack connectivity by means of these two PDP contexts. C_REC#6: "restarts the ongoing applications". I don't like this wording, "will interrupt existing network connections" or similar text would be better. C_REC#7: typo: "The purpose of the of the roaming profile is" C_REC#8: I don't understand the reference to 6052. Is this a referral to networks with NAT64 and/or 464XLAT? Then I think this should be clearer. L_REC#4: Isn't this a duplication of one of the C_RECs? Summary: I think this kind of document is valuable. Many operators do not have staff with right skill level to put in the requirements towards equipment manufacturers, and in some markets, the equipment manufacturers are selling directly to consumers without discussing details with operators. I also feel that the vendors of mobile equipment would benefit from having a more unified set of requirements from the operators. Either these requirements can be gathered within the IETF for IP related matters, or operators can try to do it in another venue. I don't see why the IETF can't be the venue for this. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 20 18:25:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A061A19E3 for ; Fri, 20 Feb 2015 18:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, EMPTY_MESSAGE=2.32, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H62MY2w3F9bD for ; Fri, 20 Feb 2015 18:25:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B414D1A005D for ; Fri, 20 Feb 2015 18:25:06 -0800 (PST) Received: from BY1PR0501MB1191.namprd05.prod.outlook.com (25.160.104.143) by BY1PR0501MB1192.namprd05.prod.outlook.com (25.160.104.144) with Microsoft SMTP Server (TLS) id 15.1.87.18; Sat, 21 Feb 2015 02:24:42 +0000 Received: from BY1PR0501MB1191.namprd05.prod.outlook.com ([25.160.104.143]) by BY1PR0501MB1191.namprd05.prod.outlook.com ([25.160.104.143]) with mapi id 15.01.0087.013; Sat, 21 Feb 2015 02:24:42 +0000 From: "Merlin Owens" To: "v6ops@ietf.org" Thread-Index: AdBNfYxm+h0EGbCSSo+lP56vFL+BiA== Date: Sat, 21 Feb 2015 02:24:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.210.23.53] authentication-results: spf=none (sender IP is ) smtp.mailfrom=merlinowens@ewtmi.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1192; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(309900001)(619001)(199003)(189002)(54356999)(16236675004)(50986999)(25636003)(19300405004)(5406001)(76576001)(122556002)(40100003)(97736003)(92566002)(74316001)(77156002)(62966003)(450100001)(86362001)(66066001)(64706001)(46102003)(110136001)(19580395003)(2351001)(19609705001)(33656002)(102836002)(19625215002)(101416001)(2656002)(87936001)(73894003)(68736005)(2900100001)(107886001)(2501002)(15975445007)(106356001)(99286002)(105586002)(5416002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1192; H:BY1PR0501MB1191.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:; received-spf: None (protection.outlook.com: ewtmi.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1191EE976F1342312C2F7D61A62B0BY1PR0501MB1191_" MIME-Version: 1.0 X-OriginatorOrg: ewtmi.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2015 02:24:41.8648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3560ec41-c01c-40e1-bb19-7f1d9266ad17 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1192 Archived-At: Subject: [v6ops] (no subject) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 02:25:09 -0000 --_000_BY1PR0501MB1191EE976F1342312C2F7D61A62B0BY1PR0501MB1191_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_BY1PR0501MB1191EE976F1342312C2F7D61A62B0BY1PR0501MB1191_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_BY1PR0501MB1191EE976F1342312C2F7D61A62B0BY1PR0501MB1191_-- From nobody Sat Feb 21 19:40:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873601A0E10 for ; Sat, 21 Feb 2015 19:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpWkcZF-0utf for ; Sat, 21 Feb 2015 19:40:54 -0800 (PST) Received: from mail-07.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4FA1A19E5 for ; Sat, 21 Feb 2015 19:40:41 -0800 (PST) Received: from [24.114.75.169] (helo=[172.20.10.4]) by mail-07.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YPNPN-00053a-0A; Sat, 21 Feb 2015 22:40:41 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <875926930.84506.1424405587971.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 21 Feb 2015 22:40:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53DB2211-946B-4C0C-AB8D-50398E25CFAA@magma.ca> References: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca> <875926930.84506.1424405587971.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.75.169] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 03:40:57 -0000 On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote: > Hi, >=20 >=20 > ----- Original Message ----- > From: Philip Matthews > To: Mark ZZZ Smith > Cc: v6ops list > Sent: Friday, 20 February 2015, 14:09 > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >=20 > Mark: >=20 > Thanks for your comments. Replies inline. >=20 > Philip >=20 > On 2015-02-19, at 21:47 , Mark ZZZ Smith wrote: >=20 >> Hi, >>=20 >>=20 >> I'd like to see less implication that the choice between a single ULA = and a single global prefix on a link is exclusive e.g., >>=20 >> "The use of ULAs instead of globally-routed >> addresses is also not discussed;" >=20 > How about I just remove the words "instead of globally-routed = addresses" from the sentence? >=20 > /I think that would do it. It now reads: The details of ULA usage is also not discussed; for this the = reader is referred to ... >=20 >>=20 >> "b. Have global (or unique-local) addresses assigned in addition to >> link-locals?" >>=20 >> People really need to get over this (somewhat IPv4) idea that there = can only be one prefix on a link (of course, in IPv6 there are always = link-locals too, but the limit on link prefixes isn't two either.). >=20 > Your point is a good one, but I don't see how the quoted sentence = implies that there is just one address GUA (or ULA). It does say = "addresses". > I admit I may have written the section thinking of just a single GUA = or ULA (in addition to the LLA), but as I re-read it, I don't see any = place where that is stated or implied. >=20 >=20 > /I think 'or' in most text is interpreted as an exclusive or. I think = the brackets around the 'or unique-local' further make it read like it = is implying one or the other. >=20 > /"Have global and/or unique-local addresses assigned in addition to = link-locals" would probably read better. DONE >=20 > /One thought about when to use 'addresses' verses 'prefixes'. I and I = think a lot of other people think at the level of assigning a prefix to = a link, with the assumption and implication that all interfaces attached = to the link would normally have addresses from each of the on-link = prefixes. The case where link attached interfaces wouldn't have = addresses from all of the present prefixes would be an exception (e.g., = in IPv4, when the subnet is too small, or in IPv6, perhaps when = migrating a prefix off of a link, or when the prefix has been configured = on a stateful DHCPv6 server, but not all hosts have asked for addresses = from it.) >=20 > / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be = written from with the unstated assumption that all interfaces will have = addresses from all on-link prefixes. As that isn't an IPv6 requirement, = I think it would be best to state that assumption, and that there may be = situations where that is not the case.=20 >=20 > / More broadly, it seems that although interfaces are where addresses = are assigned, this whole topic is really about whether to assign certain = types of prefix to a link or not (and therefore implicitly all = link-attached interfaces), rather than to individual interfaces or not. = So I wonder if it might be a bit clearer if the perspective was changed = slightly from addresses assigned to interfaces (implicitly all = interfaces on a link) to prefixes assigned to links, and then stating = the assumption that in most cases all interfaces will get addresses from = all on-link prefixes.=20 Interesting comment. However, I confess that I am not seeing how this = section might be rewritten. Note that this section is just trying to = contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss = one vs two vs ... GUAs/ULAs. Perhaps you could give an example or two of rewritten sentences? >=20 >=20 >=20 >>=20 >> "Proper" support for multiple prefixes on a link is one of IPv6's = enhanced capabilities over IPv4's. People should be encouraged to take = advantage of it if it would be useful to them. >=20 > I agree, though it is not often I find an situation where I can take = advantage of this. >=20 > / I think the case for ULAs is when link-local reachability is too = small, and global scope reachability is too large, because it reduces = security. For example, addressing internal only servers/services (e.g., = network printers), or network equipment management addresses. >=20 >=20 >=20 > Regards, > Mark. >=20 >>=20 >> Regards, >> Mark. >>=20 >>=20 >>=20 >>=20 >>=20 >> ----- Original Message ----- >> From: Philip Matthews >> To: v6ops list >> Cc:=20 >> Sent: Thursday, 19 February 2015, 8:23 >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-design-choices-04.txt >>=20 >> Hi Everyone: >>=20 >> Victor and I just posted this update, which addresses the comments = raised in Honolulu, and generally cleans up the draft. No really big = changes, but lots of little changes. =20 >>=20 >> A few highlights: >> * The wording in the title, abstract and introduction has been = modified to narrow the scope of the document. The document no longer = claims to cover all choices around designing IPv6 network, but just = certain choices that are routing-related. This always been the de-facto = situation, but now the introduction etc reflect this. Some additional = sentences saying "X is not covered here, see doc Y" have also been = added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this = area. >> * The text around using BGP sessions to link-local addresses has been = updated after some email exchanges with Francis Dupont (co-author of RFC = 2545), who observed that RFC 2545 forbids this (even though most vendors = support it). >> * The text around security of link-local addresses has been modified = since some routers forward packets containing link-local source = addresses. Thanks to Jen Lincova for pointing this out. >> * The initial few sentences in a number of sections has been changed = in an attempt to improve the document flow. >> * The document now has a security considerations section. There is = nothing earth-shaking here; Victor and I elected to just point to some = existing documents that are relevant to the choices discussed in the = document. >>=20 >> There were many other small changes to try to improve document = wording and clarity, and I thank a number of my colleagues at = Alcatel-Lucent for their helpful reviews. >>=20 >> Overall, Victor and I feel this new version is much improved, and we = hope you guys will too. As always, we welcome further comments. >>=20 >> - Philip >>=20 >> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>=20 >>> Title : Some Design Choices for IPv6 Networks >>> Authors : Philip Matthews >>> Victor Kuarsingh >>> Filename : draft-ietf-v6ops-design-choices-04.txt >>> Pages : 17 >>> Date : 2015-02-18 >>>=20 >>> Abstract: >>> This document presents advice on certain routing-related design >>> choices that arise when designing IPv6 networks (both dual-stack and >>> IPv6-only). The intended audience is someone designing an IPv6 >>> network who is knowledgeable about best current practices around = IPv4 >>> network design, and wishes to learn the corresponding practices for >>> IPv6. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Feb 22 11:10:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6996E1A6EF2 for ; Sun, 22 Feb 2015 11:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6I3nGBU4l57 for ; Sun, 22 Feb 2015 11:10:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DCB1A6EF9 for ; Sun, 22 Feb 2015 11:10:04 -0800 (PST) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:4a5:16f:dbc8:c25]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1MJA0LJ014727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Feb 2015 19:10:02 GMT (envelope-from joelja@bogus.com) Message-ID: <54EA1CD1.1010204@bogus.com> Date: Sun, 22 Feb 2015 10:15:45 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Dave Michaud , Lorenzo Colitti References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqF7fK0l8CW3wiEPbE3iq0ksRx1Lqoud0" Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 19:10:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DqF7fK0l8CW3wiEPbE3iq0ksRx1Lqoud0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RE: charter put the charter discussion to bed please. we accepted this as a wg document in 2013 with full knowledge of the contents. On 2/19/15 5:10 AM, Dave Michaud wrote: > Does the charter specifically exclude hosts requirements? >=20 > Enabling dual-stack on a cellular network serves no mean if it can=92t = be > used. >=20 > Transitionning to IPv6-only requires further support from the host side= > to form a complete solution. >=20 > The documents published under v6ops should "serve as useful guides to > network > operators and users on possible ways how to deploy IPv6 within their > existing IPv4 networks, as well as in new network installations.=94 >=20 > This is exactly what this is. As a LAN administrator, it wouldn=92t cro= ss > my mind to look for an RFC for host requirements because I would have > little control anyway. As a cellular operator, the hosts are part of my= > network and I do have a say on how they operate and it forms part of th= e > overall solution (bullet 4 of the charter). Same would apply from a > Cable MSO where the CPEs are integral part of the network. >=20 >=20 >=20 > *Dave Michaud* > Sr. Architect Mobility =96 Access Networks & IP Network Services > Network Technology | Rogers Communications=20 > dave.michaud@rci.rogers.com | tel:= > +1 647.747.9442 | mobile: +1 416.219.5531 >=20 >=20 > From: Lorenzo Colitti > > Date: Thursday, February 19, 2015 at 07:45 > To: Dave Michaud > > Cc: "mohamed.boucadair@orange.com = " > >, > BINET IMT/OLN >,= > IPv6 WG > > Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- > "harmfully broad"? >=20 > On Thu, Feb 19, 2015 at 9:31 PM, Dave Michaud > > wrot= e: >=20 > This is directly in line with the v6ops charter: >=20 > The IPv6 Operations Working Group (v6ops) develops guidelines > for the > operation of a shared IPv4/IPv6 Internet and provides operation= al > guidance on how to deploy IPv6 into existing IPv4-only networks= , > as well as into new network installations. >=20 > The main focus of the v6ops WG is to look at the immediate > deployment issues; more advanced stages of deployment and trans= ition > are a lower priority. >=20 >=20 > Actually, it isn't, really. The charter is operational guidance for the= > IPv4/IPv6 Internet. Not host requirements. >=20 > In fact, if you look at the numbered list in the charter, the items are= > "identify operational issues and determine solutions", "identify > potential security risks", "identify portions of the specs that can > cause operational concerns", and "analyze solutions for deploying IPv6 > within network environments". None of those cover this document. >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - > This communication is confidential. We only send and receive email on > the basis of the terms set out at www.rogers.com/web/content/emailnotic= e > >=20 >=20 >=20 > Ce message est confidentiel. Notre transmission et r=E9ception de > courriels se fait strictement suivant les modalit=E9s =E9nonc=E9es dans= l=92avis > publi=E9 =E0 www.rogers.com/aviscourriel > -----------------------------------------------------------------------= - >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --DqF7fK0l8CW3wiEPbE3iq0ksRx1Lqoud0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTqHNEACgkQ8AA1q7Z/VrIUPwCfbm1aYvtwVGCTWT5hzLGdfOOV rTgAniRW9GUESmpMjqehVS2zGkrRknx6 =ECuY -----END PGP SIGNATURE----- --DqF7fK0l8CW3wiEPbE3iq0ksRx1Lqoud0-- From nobody Sun Feb 22 15:12:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E33F1A0092 for ; Sun, 22 Feb 2015 15:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mro_aqwceurK for ; Sun, 22 Feb 2015 15:12:50 -0800 (PST) Received: from mail-09.primus.ca (mail23.primus.ca [216.254.141.190]) by ietfa.amsl.com (Postfix) with ESMTP id 90CC01A008B for ; Sun, 22 Feb 2015 15:12:50 -0800 (PST) Received: from [189.42.248.178] (helo=[10.125.131.70]) by mail-09.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YPfhh-0005wp-Ac; Sun, 22 Feb 2015 18:12:49 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <755422206.3973419.1424402011873.JavaMail.yahoo@mail.yahoo.com> Date: Sun, 22 Feb 2015 18:12:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <51C8F3F0-3C72-492E-9A82-5902AD6ECC08@magma.ca> References: <56465175-B62A-49F6-9CF5-64F6E71AF24F@magma.ca> <755422206.3973419.1424402011873.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([10.125.131.70]) [189.42.248.178] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 23:12:52 -0000 Mark: I agree with you that, with the publication of RFC 7217, we are likely = to see the "swapping-out" issue fade from importance as the years go on. = However, I feel that today it is definitely an issue and something that = is important to point out, even if not all routers today suffer from it = (hence the wording "On some devices ..." in the bullet point). To point out that RFC 7217 has addressed this problem, I have added the = following sentence to the end of the bullet point: This problem should fade away over time as more and more routers select interface identifiers according to = the rules in [RFC7217]. Regarding the term "unnumbered". In my opinion, the use of this term for = a link or interface that has only a link-local IPv6 address is pretty = established by now. I am hesitant to try to introduce a new term in this = document, considering that any such new term would only be a very minor = little aside. In case the reader is not familiar with this term, the document tries to = make this usage pretty obvious with the following wording: Should the interface: a. Use only link-local addresses ("unnumbered"), OR b. Have global and/or unique-local) addresses assigned in addition to link-locals? There are two advantages of unnumbered interfaces. On 2015-02-19, at 22:13 , Mark ZZZ Smith wrote: > Regarding these text about link-local only links: >=20 >=20 > "o On some devices, by default the link-layer address of the > interface is derived from the MAC address assigned to interface. > When this is done, swapping out the interface hardware (e.g. > interface card) will cause the link-layer address to change. In > some cases (peering config, ACLs, etc) this may require additional > changes. However, many devices allow the link-layer address of an > interface to be explicitly configured, which avoids this issue." >=20 > And other similar text about LLs being derived from MAC addresses, >=20 >=20 > I think it is worth referencing RFC7217, "A Method for Generating = Semantically Opaque Interface Identifiers > with IPv6 Stateless Address Autoconfiguration (SLAAC)", as one of the = use cases it is intended to address is the case of interface swaps = changing SLAAC addresses, which includes link-local addresses, as = they're SLAAC addresses. (See Appendix A of RFC7217) > Actually, I think it would be better to stop using "Unnumbered = Interfaces"/"Unnumbered Links" because factually it is incorrect in = IPv6. Something like "Link-Local Only Interfaces" would be better, and = encourage people to remembering that link-local addresses are always = present in IPv6. (and perhaps start to get people into the mindset that = link-locals may also be used for application traffic too, as per RFC4007 = and RFC6724) >=20 >=20 >=20 >=20 From nobody Sun Feb 22 15:22:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2711A00AE; Sun, 22 Feb 2015 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvAMZaFtsjWe; Sun, 22 Feb 2015 15:22:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40791A00B6; Sun, 22 Feb 2015 15:22:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222232252.21690.24134.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 15:22:52 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 23:22:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-05.txt Pages : 17 Date : 2015-02-22 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 22 15:31:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29CD1A00BB for ; Sun, 22 Feb 2015 15:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAM4JKtFUkvu for ; Sun, 22 Feb 2015 15:31:25 -0800 (PST) Received: from mail-05.primus.ca (mail23.primus.ca [216.254.141.190]) by ietfa.amsl.com (Postfix) with ESMTP id 500911A00B2 for ; Sun, 22 Feb 2015 15:31:25 -0800 (PST) Received: from [189.42.248.178] (helo=[10.125.131.70]) by mail-05.primus.ca with esmtpa (Exim 4.72) (envelope-from ) id 1YPfzf-0006ou-WC for v6ops@ietf.org; Sun, 22 Feb 2015 18:31:24 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Philip Matthews In-Reply-To: <20150222232252.21690.24134.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 18:31:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150222232252.21690.24134.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([10.125.131.70]) [189.42.248.178] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 23:31:27 -0000 Folks: I am waiting for some examples from Mark Smith on how he suggests the = draft be modified to reflect the difference between "addresses" and = "prefixes" (see our email exchange over the last few days). However, = in the meantime I have decided to post an update to the draft to show = all the other changes that have been made in response to his comments, = as it can be hard to see what the full set of changes are from my = comments. You can also see these changes in context using the following URL = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-design-choices-04&url2= =3Ddraft-ietf-v6ops-design-choices-05 - Philip On 2015-02-22, at 18:22 , Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-05.txt > Pages : 17 > Date : 2015-02-22 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Feb 22 17:07:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC161A00F6 for ; Sun, 22 Feb 2015 17:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg4Udtg1DVtV for ; Sun, 22 Feb 2015 17:07:22 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D0B1A00F1 for ; Sun, 22 Feb 2015 17:07:22 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so14839566igq.0 for ; Sun, 22 Feb 2015 17:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PjhyDV+vQklZ03ongMqubJZbBMoeSxS9Dt5oi3HjYbM=; b=nWwEeO7oIHl7XHn+AaGT9B9KmlocWCxoP3ARIdKk3Mq6/cUKpUanZFMqAFnOFu/gKu iS9mcNNOAS61QDw8ywB3xlNZ1JcExJeqgrAIAzQgGd6LfPxcmbWwwS7u91e51hBWt5EQ WH2iEgcjXk3RJYbMbrlovbrHpWhJnRpSjF3l08DeutrHAxMnZnegs+NOCCSmFsyXvN7M a5If+togM25hoZacmNhkqKPe+Rp68gPdZnhUoZaqvsA4OxU5IXxPe1stzxM/rQlClLP+ 2ViTLtFlU+gqhL9/9eyoJvSXGvQFhaCeT8PBAW8M3+4dWbM4gj7tNliA4spTJtj5Luqv yZUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PjhyDV+vQklZ03ongMqubJZbBMoeSxS9Dt5oi3HjYbM=; b=ZDvy0yiusJJ7enHMPTPIvhhitmkL8dHLf1aygvI2e6AaWFvThDtKUq3M/Qyt34Q/c0 97YsIOJfHxkSnpUHE4hkflNcDCH9oRqfp2muvZLPgEVeTOIC8IT0anh/ax/WZP+TqsHg 8fgWp2BKWNnVnNY7xfojIBamUYhbA4/6A3osdWLrddn984jHJ05nbrskn+aqxLNEbM8u tsgdDj/Zae0tiEg4JTJvTUG975ursrxmhPkwIzDSQz/8JK8OXAAskZRIWWhD0GjruRNO a3UEIZgCHK06rCE4f3O+Je/mNWcSrBI8EM7P5y8ZlfiBz5nSj4ucwGTU6d5pJ3yQmh3P aSqg== X-Gm-Message-State: ALoCoQlOtAkEWl3EKyuluDB00bLgLcO7Kz+WviDhdUzsu1zKg9yZRwFLADJ2AOlh5hWqZYQeqKCv X-Received: by 10.50.49.43 with SMTP id r11mr10156829ign.18.1424653641450; Sun, 22 Feb 2015 17:07:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Sun, 22 Feb 2015 17:07:00 -0800 (PST) In-Reply-To: <54EA1CD1.1010204@bogus.com> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <26150_1424277597_54E4C05D_26150_800_1_A729C0B3952BEE45A1AA136ADD556BE80493F147@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EA1CD1.1010204@bogus.com> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 10:07:00 +0900 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7bdca5b63a4ade050fb706c0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 01:07:23 -0000 --047d7bdca5b63a4ade050fb706c0 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 3:15 AM, joel jaeggli wrote: > RE: charter > > put the charter discussion to bed please. we accepted this as a wg > document in 2013 with full knowledge of the contents. > I'm not trying to open a debate about that. I was just objecting to the statement that this document is "directly in line with the charter". As I see it, at best it's on the fringes. --047d7bdca5b63a4ade050fb706c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 3:15 AM, joel jaeggli <joelja@bogus.com> = wrote:
RE: charter

put the charter discussion to bed please. we accepted this as a wg
document in 2013 with full knowledge of the contents.
=
I'm not trying to open a debate about that. I was just o= bjecting to the statement that this document is "directly in line with= the charter". As I see it, at best it's on the fringes.
--047d7bdca5b63a4ade050fb706c0-- From nobody Sun Feb 22 17:21:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAC41A00E9; Sun, 22 Feb 2015 16:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGta6X9sUwLJ; Sun, 22 Feb 2015 16:33:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D30251A00E7; Sun, 22 Feb 2015 16:33:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223003358.4468.15951.idtracker@ietfa.amsl.com> Date: Sun, 22 Feb 2015 16:33:58 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 17:21:28 -0800 Subject: [v6ops] Telechat update notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 00:34:00 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/status-change-rfc-3068-anycast-prefix-for-6to4-to-historic/ From nobody Sun Feb 22 23:59:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AFE1A0275 for ; Sun, 22 Feb 2015 23:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYUteLNbjzHe for ; Sun, 22 Feb 2015 23:59:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5801A026F for ; Sun, 22 Feb 2015 23:59:26 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 85C522AC0F6; Mon, 23 Feb 2015 08:59:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 368B0180073; Mon, 23 Feb 2015 08:59:24 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%35]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 08:59:24 +0100 From: To: Mikael Abrahamsson , V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQTTthIBd3RGtSR02IrTMsDHyUSpz93h0g Date: Mon, 23 Feb 2015 07:59:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 07:59:28 -0000 Hi Mikael, Thank you for the review.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Mikael > Abrahamsson > Envoy=E9=A0: vendredi 20 f=E9vrier 2015 19:30 > =C0=A0: V6 Ops List > Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call >=20 > On Wed, 28 Jan 2015, Fred Baker (fred) wrote: >=20 > > Please read it now, and comment. This WGLC will run until 15 February. >=20 > I have re-read the latest incarnation just now. I am going to treat it as > if I never read it before: >=20 > 1.2. >=20 > I know what a "shorter prefix than /64" is. A lot of readers might not, s= o > I would like to insert at "(larger)" in there, or similar text. [Med] Fixed in 2 occurrences in the I-D: s/shorter prefix than /64/larger p= refixes. >=20 > C_REC#2: >=20 > Second paragraph, suggest text to clarify that adding the second PDP > context is to achieve dual stack connectivity by means of these two PDP > contexts. [Med] I made this change: OLD: * If the requested IPv4v6 PDP-Context is not supported by the network, but IPv4 and IPv6 PDP types are allowed, then the cellular host will be configured with an IPv4 address or an IPv6 prefix by the network. It must initiate another PDP-Context activation in addition to the one already activated for a given APN (Access Point Name). =20 NEW: * If the requested IPv4v6 PDP-Context is not supported by the network, but IPv4 and IPv6 PDP types are allowed, then the cellular host will be configured with an IPv4 address or an IPv6 prefix by the network. It must initiate another PDP-Context activation in addition to the one already activated for a given APN (Access Point Name). The purpose of initiating a second PDP-Context is to achieve dual-stack connectivity by means of two PDP-Contexts. >=20 > C_REC#6: >=20 > "restarts the ongoing applications". I don't like this wording, "will > interrupt existing network connections" or similar text would be better. [Med] I made this change: OLD: Note, a cellular host changing its connection between an IPv6-specific APN and an IPv4-specific APN restarts the ongoing applications. This may be considered as a brokenness situation. NEW: Note, a cellular host changing its connection between an IPv6-specific APN and an IPv4-specific APN will interrupt associated network connections. This may be considered as a brokenness situation for some applications. To Alex: Can you please review this text (because you are the one who asked= to have the OLD version) >=20 > C_REC#7: >=20 > typo: >=20 > "The purpose of the of the roaming profile is" [Med] Fixed. Thank you. >=20 > C_REC#8: >=20 > I don't understand the reference to 6052. Is this a referral to networks > with NAT64 and/or 464XLAT? Then I think this should be clearer. [Med] This feature is for NAT64 context in general, but without requiring a= ny packet translation feature. OLD: This solves the issue when applications use IPv4 referrals on IPv6-only access networks. NEW: In the context of NAT64, applications relying on address referrals will fail because an IPv6-only client won't be able to make use of an IPv4 address received in a referral. This feature allows to solve this referral problem and, also, to distinguish between IPv4-converted IPv6 addresses [RFC6052] and native IPv6 addresses.=20 Better? >=20 > L_REC#4: Isn't this a duplication of one of the C_RECs? [Med] This one is for IPv4 devices connected via the cellular device throug= h an IPv6-only network. The one in C_REC#8 is about local applications runn= ing on the cellular host. =20 >=20 > Summary: >=20 > I think this kind of document is valuable. Many operators do not have > staff with right skill level to put in the requirements towards equipment > manufacturers, and in some markets, the equipment manufacturers are > selling directly to consumers without discussing details with operators. = I > also feel that the vendors of mobile equipment would benefit from having = a > more unified set of requirements from the operators. >=20 > Either these requirements can be gathered within the IETF for IP related > matters, or operators can try to do it in another venue. I don't see why > the IETF can't be the venue for this. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 23 00:10:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E9A1A0277 for ; Mon, 23 Feb 2015 00:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNB-JTKCoY7Z for ; Mon, 23 Feb 2015 00:09:59 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC611A0302 for ; Mon, 23 Feb 2015 00:09:51 -0800 (PST) Received: by iecvy18 with SMTP id vy18so21449757iec.6 for ; Mon, 23 Feb 2015 00:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tEyeUngqhJQlofHLznbcfVudN6nvLAdN1sJq16x6/cw=; b=mxajqiVMwhomNa0Oh8nRAouPBzdQ3eYDNr2L24SXelBJ6CKwjbnQRvaE3ydArRk1qY xoz0gciBkvZIJBjzbhPY2i1sw6v26exkixGlaoEYU2Rnf5SRBJNHPg+OqOf20bOQFiLB eENHcnq5NlgLPxu2ZIIlrH0V45lqNBjUS25C7DnCg+ri6cUTkd0pBGdAg797pRGcxpjy eBIYlWPgsvka4yWQ/kuhDVHTlvWJA/bI20hs0TpfgsMcOJCZ9PeGGIuN7ZFehbsohcdN XPfXnapc8XnFgHM/2PzUdLRGHbDX3H0asM7k2KC0TrN6L9jVN4M7d29EIo03aHpNjOZv xbTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tEyeUngqhJQlofHLznbcfVudN6nvLAdN1sJq16x6/cw=; b=Iflpv/zLtoSe5JIgXUpjgQJEVkZ7WXEDUThkqc5u86gFDBOBEvGJe24wmgoMj3n+Jv pHEBvwo8JJpGJJUBdXp1DEGXE/zUKNLWDT4WKT+gN7yXUcDzkt+KYPXyHfVnNMHAa8DE SkHnFlWNjFj89xocuKGFfi4ukr/o0zrw0Jz8wuDDmj0C8XEcZ9Bn8AH3QPTkqZoDd4ND r3J9tSR+gqsvju1878GeGjk+YjQYcEO4s6VcMnLQH75OhBM1H3BVDcMo0WbPYbZLsUlA q2tebaXnZoy/UV0NHICxjNnkF3UfRx0fquc9W63ExJA5tECuWMvWaam6db/+7yoVrwGh 7tRQ== X-Gm-Message-State: ALoCoQnXbY9OUpt88kvoHoxcW9JGNnrizmPyBvNCtluy/DLwH5dK+oR/PSb6aJ1uVQ84c5A1y/Bv X-Received: by 10.42.138.199 with SMTP id d7mr10074002icu.3.1424678990989; Mon, 23 Feb 2015 00:09:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 00:09:29 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 17:09:29 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=90e6ba1efc122d70f6050fbcedcf Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:10:00 -0000 --90e6ba1efc122d70f6050fbcedcf Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 4:59 PM, wrote: > NEW: > > * If the requested IPv4v6 PDP-Context is not supported by > the network, but IPv4 and IPv6 PDP types are allowed, > then the cellular host will be configured with an IPv4 > address or an IPv6 prefix by the network. It must > initiate another PDP-Context activation in addition to > the one already activated for a given APN (Access Point > Name). The purpose of initiating a second PDP-Context > is to achieve dual-stack connectivity by means of two > PDP-Contexts. > Operators who have deployed IPv6 report that running dual-stack over two PDP contexts is a very bad idea because it consumes 2x the network resources. Please don't recommend this unless you have evidence that this works well in production (not in testing). > NEW: > Note, a cellular host changing its connection between an > IPv6-specific APN and an IPv4-specific APN will > interrupt associated network connections. This may be > considered as a brokenness situation for some > applications. > What is the purpose of this text? Mobile nodes change IP addresses all the time (e.g., when switching from 4G to wifi). How is this different? --90e6ba1efc122d70f6050fbcedcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 4:59 PM, <mohamed.boucadair@orange.com= > wrote:
NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If the requested IP= v4v6 PDP-Context is not supported by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the network, but IP= v4 and IPv6 PDP types are allowed,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the cellular h= ost will be configured with an IPv4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address or an IPv6 = prefix by the network.=C2=A0 It must
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 initiate another PD= P-Context activation in addition to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the one already act= ivated for a given APN (Access Point
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name).=C2=A0 The pu= rpose of initiating a second PDP-Context
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is to achieve dual-= stack connectivity by means of two
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PDP-Contexts.

Operators who have deployed IPv6 report that= running dual-stack over two PDP contexts is a very bad idea because it con= sumes 2x the network resources. Please don't recommend this unless you = have evidence that this works well in production (not in testing).
=C2=A0
NEW:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note, a cellular ho= st changing its connection between an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-specific APN a= nd an IPv4-specific APN will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interrupt associate= d network connections.=C2=A0 This may be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considered as a bro= kenness situation for some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications.

What is the purpose of this text? Mobile nod= es change IP addresses all the time (e.g., when switching from 4G to wifi).= How is this different?
--90e6ba1efc122d70f6050fbcedcf-- From nobody Mon Feb 23 00:39:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CE21A037E for ; Mon, 23 Feb 2015 00:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asuy3W4PwqHH for ; Mon, 23 Feb 2015 00:39:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622421A00B8 for ; Mon, 23 Feb 2015 00:39:06 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BBEE826418D; Mon, 23 Feb 2015 09:39:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 891D435C110; Mon, 23 Feb 2015 09:39:04 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%35]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 09:39:03 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQT0AawS1TrvK5xEGzvJUswqnHoJz954Ww Date: Mon, 23 Feb 2015 08:39:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049122B6OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:39:09 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049122B6OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGx1bmRpIDIz IGbDqXZyaWVyIDIwMTUgMDk6MDkNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2Mg OiBNaWthZWwgQWJyYWhhbXNzb247IFY2IE9wcyBMaXN0DQpPYmpldCA6IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbA0KDQpPbiBNb24s IEZlYiAyMywgMjAxNSBhdCA0OjU5IFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KTkVXOg0KDQogICAg ICAgICAgICAgKiAgSWYgdGhlIHJlcXVlc3RlZCBJUHY0djYgUERQLUNvbnRleHQgaXMgbm90IHN1 cHBvcnRlZCBieQ0KICAgICAgICAgICAgICAgIHRoZSBuZXR3b3JrLCBidXQgSVB2NCBhbmQgSVB2 NiBQRFAgdHlwZXMgYXJlIGFsbG93ZWQsDQogICAgICAgICAgICAgICAgdGhlbiB0aGUgY2VsbHVs YXIgaG9zdCB3aWxsIGJlIGNvbmZpZ3VyZWQgd2l0aCBhbiBJUHY0DQogICAgICAgICAgICAgICAg YWRkcmVzcyBvciBhbiBJUHY2IHByZWZpeCBieSB0aGUgbmV0d29yay4gIEl0IG11c3QNCiAgICAg ICAgICAgICAgICBpbml0aWF0ZSBhbm90aGVyIFBEUC1Db250ZXh0IGFjdGl2YXRpb24gaW4gYWRk aXRpb24gdG8NCiAgICAgICAgICAgICAgICB0aGUgb25lIGFscmVhZHkgYWN0aXZhdGVkIGZvciBh IGdpdmVuIEFQTiAoQWNjZXNzIFBvaW50DQogICAgICAgICAgICAgICAgTmFtZSkuICBUaGUgcHVy cG9zZSBvZiBpbml0aWF0aW5nIGEgc2Vjb25kIFBEUC1Db250ZXh0DQogICAgICAgICAgICAgICAg aXMgdG8gYWNoaWV2ZSBkdWFsLXN0YWNrIGNvbm5lY3Rpdml0eSBieSBtZWFucyBvZiB0d28NCiAg ICAgICAgICAgICAgICBQRFAtQ29udGV4dHMuDQoNCk9wZXJhdG9ycyB3aG8gaGF2ZSBkZXBsb3ll ZCBJUHY2IHJlcG9ydCB0aGF0IHJ1bm5pbmcgZHVhbC1zdGFjayBvdmVyIHR3byBQRFAgY29udGV4 dHMgaXMgYSB2ZXJ5IGJhZCBpZGVhIGJlY2F1c2UgaXQgY29uc3VtZXMgMnggdGhlIG5ldHdvcmsg cmVzb3VyY2VzLiBQbGVhc2UgZG9uJ3QgcmVjb21tZW5kIHRoaXMgdW5sZXNzIHlvdSBoYXZlIGV2 aWRlbmNlIHRoYXQgdGhpcyB3b3JrcyB3ZWxsIGluIHByb2R1Y3Rpb24gKG5vdCBpbiB0ZXN0aW5n KS4NCg0KW01lZF0gV2UgYXJlIG5vdCByZWNvbW1lbmRpbmcgZXN0YWJsaXNoaW5nIHN5c3RlbWF0 aWNhbGx5IHR3byBQRFAgY29udGV4dHMuIFBsZWFzZSBjaGVjayB0aGUgZnVsbCByZWNvbW1lbmRh dGlvbiBwcm92aWRlZCBiZWxvdyBmb3IgeW91ciBjb252ZW5pZW5jZS4NCg0KICAgQ19SRUMjMjog IFRoZSBjZWxsdWxhciBob3N0IG11c3QgY29tcGx5IHdpdGggdGhlIGJlaGF2aW9yIGRlZmluZWQg aW4NCiAgICAgICAgICAgICBbVFMuMjMwNjBdIFtUUy4yMzQwMV0gW1RTLjI0MDA4XSBmb3IgcmVx dWVzdGluZyBhIFBEUC0NCiAgICAgICAgICAgICBDb250ZXh0IHR5cGUuICBJbiBwYXJ0aWN1bGFy LCB0aGUgY2VsbHVsYXIgaG9zdCBtdXN0DQogICAgICAgICAgICAgcmVxdWVzdCBieSBkZWZhdWx0 IGFuIElQdjYgUERQLUNvbnRleHQgaWYgdGhlIGNlbGx1bGFyIGhvc3QNCiAgICAgICAgICAgICBp cyBJUHY2LW9ubHkgYW5kIHJlcXVlc3QgYW4gSVB2NHY2IFBEUC1Db250ZXh0IGlmIHRoZQ0KICAg ICAgICAgICAgIGNlbGx1bGFyIGhvc3QgaXMgZHVhbC1zdGFjayBvciB3aGVuIHRoZSBjZWxsdWxh ciBob3N0IGlzDQogICAgICAgICAgICAgbm90IGF3YXJlIG9mIGNvbm5lY3Rpdml0eSB0eXBlcyBy ZXF1ZXN0ZWQgYnkgZGV2aWNlcw0KICAgICAgICAgICAgIGNvbm5lY3RlZCB0byBpdCAoZS5nLiwg Y2VsbHVsYXIgaG9zdCB3aXRoIExBTiBjYXBhYmlsaXRpZXMNCiAgICAgICAgICAgICBhcyBkaXNj dXNzZWQgaW4gU2VjdGlvbiAzKToNCg0KICAgICAgICAgICAgICogIElmIHRoZSByZXF1ZXN0ZWQg SVB2NHY2IFBEUC1Db250ZXh0IGlzIG5vdCBzdXBwb3J0ZWQgYnkNCiAgICAgICAgICAgICAgICB0 aGUgbmV0d29yaywgYnV0IElQdjQgYW5kIElQdjYgUERQIHR5cGVzIGFyZSBhbGxvd2VkLA0KICAg ICAgICAgICAgICAgIHRoZW4gdGhlIGNlbGx1bGFyIGhvc3Qgd2lsbCBiZSBjb25maWd1cmVkIHdp dGggYW4gSVB2NA0KICAgICAgICAgICAgICAgIGFkZHJlc3Mgb3IgYW4gSVB2NiBwcmVmaXggYnkg dGhlIG5ldHdvcmsuICBJdCBtdXN0DQogICAgICAgICAgICAgICAgaW5pdGlhdGUgYW5vdGhlciBQ RFAtQ29udGV4dCBhY3RpdmF0aW9uIGluIGFkZGl0aW9uIHRvDQogICAgICAgICAgICAgICAgdGhl IG9uZSBhbHJlYWR5IGFjdGl2YXRlZCBmb3IgYSBnaXZlbiBBUE4gKEFjY2VzcyBQb2ludA0KICAg ICAgICAgICAgICAgIE5hbWUpLiAgVGhlIHB1cnBvc2Ugb2YgaW5pdGlhdGluZyBhIHNlY29uZCBQ RFAtQ29udGV4dA0KICAgICAgICAgICAgICAgIGlzIHRvIGFjaGlldmUgZHVhbC0gc3RhY2sgY29u bmVjdGl2aXR5IGJ5IG1lYW5zIG9mIHR3bw0KICAgICAgICAgICAgICAgIFBEUC1Db250ZXh0cy4N Cg0KICAgICAgICAgICAgICogIElmIHRoZSBzdWJzY3JpcHRpb24gZGF0YSBvciBuZXR3b3JrIGNv bmZpZ3VyYXRpb24gYWxsb3dzDQogICAgICAgICAgICAgICAgb25seSBvbmUgSVAgYWRkcmVzcyBm YW1pbHkgKElQdjQgb3IgSVB2NiksIHRoZSBjZWxsdWxhcg0KICAgICAgICAgICAgICAgIGhvc3Qg bXVzdCBub3QgcmVxdWVzdCBhIHNlY29uZCBQRFAtQ29udGV4dCB0byB0aGUgc2FtZQ0KICAgICAg ICAgICAgICAgIEFQTiBmb3IgdGhlIG90aGVyIElQIGFkZHJlc3MgZmFtaWx5Lg0KDQogICAgICAg ICAgICAgVGhlIHRleHQgYWJvdmUgZm9jdXNlcyBvbiB0aGUgc3BlY2lmaWNhdGlvbiBwYXJ0IHdo aWNoDQogICAgICAgICAgICAgZXhwbGFpbnMgdGhlIGJlaGF2aW9yIGZvciByZXF1ZXN0aW5nIElQ djYtcmVsYXRlZCBQRFAtDQogICAgICAgICAgICAgQ29udGV4dChzKS4gIFVuZGVyc3RhbmRpbmcg dGhpcyBiZWhhdmlvciBpcyBpbXBvcnRhbnQgdG8NCiAgICAgICAgICAgICBhdm9pZCBoYXZpbmcg YnJva2VuIElQdjYgaW1wbGVtZW50YXRpb25zIGluIGNlbGx1bGFyDQogICAgICAgICAgICAgZGV2 aWNlcy4NCg0KDQoNCk5FVzoNCiAgICAgICAgICAgICAgICBOb3RlLCBhIGNlbGx1bGFyIGhvc3Qg Y2hhbmdpbmcgaXRzIGNvbm5lY3Rpb24gYmV0d2VlbiBhbg0KICAgICAgICAgICAgICAgIElQdjYt c3BlY2lmaWMgQVBOIGFuZCBhbiBJUHY0LXNwZWNpZmljIEFQTiB3aWxsDQogICAgICAgICAgICAg ICAgaW50ZXJydXB0IGFzc29jaWF0ZWQgbmV0d29yayBjb25uZWN0aW9ucy4gIFRoaXMgbWF5IGJl DQogICAgICAgICAgICAgICAgY29uc2lkZXJlZCBhcyBhIGJyb2tlbm5lc3Mgc2l0dWF0aW9uIGZv ciBzb21lDQogICAgICAgICAgICAgICAgYXBwbGljYXRpb25zLg0KDQpXaGF0IGlzIHRoZSBwdXJw b3NlIG9mIHRoaXMgdGV4dD8gTW9iaWxlIG5vZGVzIGNoYW5nZSBJUCBhZGRyZXNzZXMgYWxsIHRo ZSB0aW1lIChlLmcuLCB3aGVuIHN3aXRjaGluZyBmcm9tIDRHIHRvIHdpZmkpLiBIb3cgaXMgdGhp cyBkaWZmZXJlbnQ/DQoNCltNZWRdIFRoaXMgdGV4dCB3YXMgYWRkZWQgdG8gYWRkcmVzcyBhIGNv bW1lbnQgZnJvbSBBbGV4LiBJIHdpbGwgbGV0IGhpbSBmdXJ0aGVyIGNsYXJpZnksIGJ1dCBBbGV4 IGlzIGFza2luZyBmb3IgQVBOcyB0aGF0IGFyZSBub3Qgc3BlY2lmaWMgdG8gYSBnaXZlbiBhZGRy ZXNzIGZhbWlseSwgaGVuY2UgdGhpcyBub3RlLg0K --_000_787AE7BB302AE849A7480A190F8B9330049122B6OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNl IHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAyMyBmw6l2cmll ciAyMDE1IDA5OjA5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBNaWthZWwgQWJyYWhhbXNzb247IFY2IE9wcyBMaXN0 PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLW1v YmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAyMywg MjAxNSBhdCA0OjU5IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ORVc6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 KiZuYnNwOyBJZiB0aGUgcmVxdWVzdGVkIElQdjR2NiBQRFAtQ29udGV4dCBpcyBub3Qgc3VwcG9y dGVkIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0aGUgbmV0d29yaywgYnV0IElQdjQgYW5kIElQdjYgUERQIHR5cGVzIGFyZSBh bGxvd2VkLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhlbiB0aGUgY2VsbHVsYXIgaG9zdCB3aWxsIGJlIGNvbmZpZ3VyZWQgd2l0 aCBhbiBJUHY0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBhZGRyZXNzIG9yIGFuIElQdjYgcHJlZml4IGJ5IHRoZSBuZXR3b3JrLiZu YnNwOyBJdCBtdXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBpbml0aWF0ZSBhbm90aGVyIFBEUC1Db250ZXh0IGFjdGl2YXRpb24g aW4gYWRkaXRpb24gdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBvbmUgYWxyZWFkeSBhY3RpdmF0ZWQgZm9yIGEgZ2l2ZW4g QVBOIChBY2Nlc3MgUG9pbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5hbWUpLiZuYnNwOyBUaGUgcHVycG9zZSBvZiBpbml0aWF0 aW5nIGEgc2Vjb25kIFBEUC1Db250ZXh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB0byBhY2hpZXZlIGR1YWwtc3RhY2sgY29u bmVjdGl2aXR5IGJ5IG1lYW5zIG9mIHR3bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUERQLUNvbnRleHRzLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3BlcmF0b3JzIHdobyBoYXZlIGRlcGxv eWVkIElQdjYgcmVwb3J0IHRoYXQgcnVubmluZyBkdWFsLXN0YWNrIG92ZXIgdHdvIFBEUCBjb250 ZXh0cyBpcyBhIHZlcnkgYmFkIGlkZWEgYmVjYXVzZSBpdCBjb25zdW1lcyAyeCB0aGUgbmV0d29y ayByZXNvdXJjZXMuIFBsZWFzZSBkb24ndCByZWNvbW1lbmQgdGhpcyB1bmxlc3MgeW91IGhhdmUg ZXZpZGVuY2UgdGhhdCB0aGlzIHdvcmtzIHdlbGwgaW4gcHJvZHVjdGlvbg0KIChub3QgaW4gdGVz dGluZykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g V2UgYXJlIG5vdCByZWNvbW1lbmRpbmcgZXN0YWJsaXNoaW5nIHN5c3RlbWF0aWNhbGx5IHR3byBQ RFAgY29udGV4dHMuIFBsZWFzZSBjaGVjayB0aGUgZnVsbCByZWNvbW1lbmRhdGlvbiBwcm92aWRl ZCBiZWxvdyBmb3IgeW91ciBjb252ZW5pZW5jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ19SRUMjMjombmJzcDsgVGhlIGNlbGx1bGFyIGhv c3QgbXVzdCBjb21wbHkgd2l0aCB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFtUUy4yMzA2MF0gW1RTLjIzNDAxXSBbVFMuMjQwMDhdIGZvciByZXF1ZXN0 aW5nIGEgUERQLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnRleHQgdHlwZS4mbmJzcDsg SW4gcGFydGljdWxhciwgdGhlIGNlbGx1bGFyIGhvc3QgbXVzdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlcXVlc3QgYnkgZGVmYXVsdCBhbiBJUHY2IFBEUC1Db250ZXh0IGlmIHRoZSBjZWxs dWxhciBob3N0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7aXMgSVB2Ni1vbmx5IGFuZCByZXF1 ZXN0IGFuIElQdjR2NiBQRFAtQ29udGV4dCBpZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjZWxsdWxhciBob3N0IGlzIGR1YWwtc3RhY2sgb3Igd2hlbiB0aGUgY2VsbHVsYXIgaG9zdCBp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vdCBhd2FyZSBvZiBjb25uZWN0aXZpdHkgdHlw ZXMgcmVxdWVzdGVkIGJ5IGRldmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0 ZWQgdG8gaXQgKGUuZy4sIGNlbGx1bGFyIGhvc3Qgd2l0aCBMQU4gY2FwYWJpbGl0aWVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMyk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IElmIHRoZSByZXF1ZXN0 ZWQgSVB2NHY2IFBEUC1Db250ZXh0IGlzIG5vdCBzdXBwb3J0ZWQgYnk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV0d29yaywgYnV0IElQdjQgYW5kIElQ djYgUERQIHR5cGVzIGFyZSBhbGxvd2VkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZW4gdGhlIGNlbGx1bGFyIGhvc3Qgd2lsbCBiZSBjb25maWd1cmVkIHdp dGggYW4gSVB2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFk ZHJlc3Mgb3IgYW4gSVB2NiBwcmVmaXggYnkgdGhlIG5ldHdvcmsuJm5ic3A7IEl0IG11c3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbml0aWF0ZSBhbm90aGVy IFBEUC1Db250ZXh0IGFjdGl2YXRpb24gaW4gYWRkaXRpb24gdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgb25lIGFscmVhZHkgYWN0aXZhdGVkIGZvciBh IGdpdmVuIEFQTiAoQWNjZXNzIFBvaW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTmFtZSkuJm5ic3A7IFRoZSBwdXJwb3NlIG9mIGluaXRpYXRpbmcgYSBzZWNv bmQgUERQLUNvbnRleHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpcyB0byBhY2hpZXZlIGR1YWwtIHN0YWNrIGNvbm5lY3Rpdml0eSBieSBtZWFucyBvZiB0d288 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQRFAtQ29udGV4dHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IElmIHRo ZSBzdWJzY3JpcHRpb24gZGF0YSBvciBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gYWxsb3dzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb25seSBvbmUgSVAgYWRkcmVz cyBmYW1pbHkgKElQdjQgb3IgSVB2NiksIHRoZSBjZWxsdWxhcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhvc3QgbXVzdCBub3QgcmVxdWVzdCBhIHNlY29uZCBQ RFAtQ29udGV4dCB0byB0aGUgc2FtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFQTiBmb3IgdGhlIG90aGVyIElQIGFkZHJlc3MgZmFtaWx5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHRleHQgYWJvdmUgZm9jdXNlcyBv biB0aGUgc3BlY2lmaWNhdGlvbiBwYXJ0IHdoaWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZXhwbGFpbnMgdGhlIGJlaGF2aW9yIGZvciByZXF1ZXN0aW5nIElQdjYtcmVsYXRlZCBQRFAtPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGV4dChzKS4mbmJzcDsgVW5kZXJzdGFuZGluZyB0 aGlzIGJlaGF2aW9yIGlzIGltcG9ydGFudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF2 b2lkIGhhdmluZyBicm9rZW4gSVB2NiBpbXBsZW1lbnRhdGlvbnMgaW4gY2VsbHVsYXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5kZXZpY2VzLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc6PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOb3RlLCBhIGNlbGx1 bGFyIGhvc3QgY2hhbmdpbmcgaXRzIGNvbm5lY3Rpb24gYmV0d2VlbiBhbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSVB2Ni1zcGVj aWZpYyBBUE4gYW5kIGFuIElQdjQtc3BlY2lmaWMgQVBOIHdpbGw8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGludGVycnVwdCBhc3Nv Y2lhdGVkIG5ldHdvcmsgY29ubmVjdGlvbnMuJm5ic3A7IDwvc3Bhbj5UaGlzIG1heSBiZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Y29uc2lkZXJlZCBhcyBhIGJyb2tlbm5lc3Mgc2l0dWF0aW9uIGZvciBzb21lPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhcHBsaWNh dGlvbnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoaXMgdGV4dD8gTW9iaWxlIG5vZGVz IGNoYW5nZSBJUCBhZGRyZXNzZXMgYWxsIHRoZSB0aW1lIChlLmcuLCB3aGVuIHN3aXRjaGluZyBm cm9tIDRHIHRvIHdpZmkpLiBIb3cgaXMgdGhpcyBkaWZmZXJlbnQ/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGlzIHRleHQgd2FzIGFkZGVkIHRvIGFkZHJlc3MgYSBjb21t ZW50IGZyb20gQWxleC4gSSB3aWxsIGxldCBoaW0gZnVydGhlciBjbGFyaWZ5LCBidXQgQWxleCBp cyBhc2tpbmcgZm9yIEFQTnMgdGhhdCBhcmUgbm90IHNwZWNpZmljIHRvIGEgZ2l2ZW4gYWRkcmVz cw0KIGZhbWlseSwgaGVuY2UgdGhpcyBub3RlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B9330049122B6OPEXCLILM23corp_-- From nobody Mon Feb 23 01:04:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7DD1A0358 for ; Mon, 23 Feb 2015 01:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx20ywYo3b8Z for ; Mon, 23 Feb 2015 01:04:38 -0800 (PST) Received: from nm33-vm7.bullet.mail.gq1.yahoo.com (nm33-vm7.bullet.mail.gq1.yahoo.com [98.136.216.246]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10201A038A for ; Mon, 23 Feb 2015 01:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424682277; bh=hEKh1hEOtL1rlkC5ZG9Dhwv1Og5Xfi2kZsF4ayQnm6k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=iJ/FxMDZ8S3RV/JILszfuj9imZ9Q4hOAFlONVOP915pXc6bgBHLJOsBRcfCZrRrf+QJPFooRZk3YRo/huSMHo7xTOuc/bfSZ7Xfa5atE/U6MU7mtwfbpNXcTQHUaFtwclGtIBXKn9aiw3IDDfiC3lj1LG9GJGCzAeGwLkCjn5x60C7nLwd07q1wj0fUtzJWmYpbySqxDjGPOfAx4VdZevkUZDyamQcaK/ZGEuLtBHWxq2O8q1MX+TH5PMMhVQDeIxdoMWM16D3jbF8bWiAePt1wS94jiSrrkcw3mIrqzBtc11ggfjHJfet27OUwkt3oMXHrPxqQmaxBNH2DlUrvn9A== Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 09:04:37 -0000 Received: from [216.39.60.182] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 09:01:47 -0000 Received: from [98.139.214.32] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 23 Feb 2015 09:01:47 -0000 Received: from [98.139.215.229] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2015 09:01:47 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 23 Feb 2015 09:01:47 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 348216.58116.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: WS0iaj8VM1k1smSzlvgG95SKwfDxlEhJ24WgJspIXJnq2obYl0sbKBnQI41WuwP iIu8gsj2YZFi9KPlAmdnDmQH1z68s8HBQONUcB7WyaWCRMy8HV0ON7oAIQ0Rm6z9k9lgLca7C5VZ iaZhjwlu4OLODE2nTQA6BcRzbrQN7SN8fL.QeKYzLW3yDein0Wtx_NPUQzb7s.AtX1ZMeu6lW_8Q EUpJOQ0c1q0UQJzoAqbaTsM4i3YDtoeaXOCd9co.51x3hvNlLyLfIpS4W._tVvekFWJbMcleBduH 8vzdynoTyeWbpuRUrtge10kE1KCvzqWbAWF0gqFpPrjoLQyVXk5Z.eFFbaH0k_HT1tYi3mFhByUb Rv9ud3ByDSd3FZYqM2b93TTwJmt61SG.yFa94yeRgkLd5rY2.M92ZMlCIclUwt0CLD_X55gjr.E3 fS4hkzc7Q5nFnGQqOy.KW8hh3htEBc.FyiG4xI76lFfsUvwfki.pmq5GdDEIhv.4ioRIs3jZbe4k bHJ9IjRcjH7blCw0o4Dwd0DoED5HC2LIIHiyjWXFGjjhSRM34LySx Received: by 66.196.80.114; Mon, 23 Feb 2015 09:01:46 +0000 Date: Mon, 23 Feb 2015 09:01:39 +0000 (UTC) From: Mark ZZZ Smith To: Philip Matthews Message-ID: <1184650378.7552509.1424682099969.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <53DB2211-946B-4C0C-AB8D-50398E25CFAA@magma.ca> References: <53DB2211-946B-4C0C-AB8D-50398E25CFAA@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 09:04:40 -0000 Hi Philip, ----- Original Message ----- From: Philip Matthews To: Mark ZZZ Smith Cc: v6ops list Sent: Sunday, 22 February 2015, 14:40 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote: > Hi, > > > ----- Original Message ----- > From: Philip Matthews > To: Mark ZZZ Smith > Cc: v6ops list > Sent: Friday, 20 February 2015, 14:09 > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt > > Mark: > > Thanks for your comments. Replies inline. > > Philip > > /"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better. DONE /There is a loose ')' in there though ;-) > > /One thought about when to use 'addresses' verses 'prefixes'. I and I think a lot of other people think at the level of assigning a prefix to a link, with the assumption and implication that all interfaces attached to the link would normally have addresses from each of the on-link prefixes. The case where link attached interfaces wouldn't have addresses from all of the present prefixes would be an exception (e.g., in IPv4, when the subnet is too small, or in IPv6, perhaps when migrating a prefix off of a link, or when the prefix has been configured on a stateful DHCPv6 server, but not all hosts have asked for addresses from it.) > > / "2.1.2. Interfaces with Only Link-Local Addresses?" seems to be written from with the unstated assumption that all interfaces will have addresses from all on-link prefixes. As that isn't an IPv6 requirement, I think it would be best to state that assumption, and that there may be situations where that is not the case. > > / More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implicitly all link-attached interfaces), rather than to individual interfaces or not. So I wonder if it might be a bit clearer if the perspective was changed slightly from addresses assigned to interfaces (implicitly all interfaces on a link) to prefixes assigned to links, and then stating the assumption that in most cases all interfaces will get addresses from all on-link prefixes. Interesting comment. However, I confess that I am not seeing how this section might be rewritten. Note that this section is just trying to contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss one vs two vs ... GUAs/ULAs. / I understand what it is trying to contrast, and I'd describe it as contrasting whether to have just a link-local prefix on the link, or whether to add one or more GUA and/or ULA prefixes to the link. / If that description is correct, then it is assuming that all interfaces attached to the link will get addresses from what ever prefixes are present on the link. Yet the text, by being 'Interface' oriented', rather than 'link oriented' implies that it is a decision that would be made on a per-interface rather than a per-link basis. Technically it can be made on a per-Interface basis, but commonly isn't. Perhaps you could give an example or two of rewritten sentences? / How about something like this: 2.1.2. Link-local prefix only links? The Link-local prefix is automatically present on links on which IPv6 is operating over, as all IPv6 interfaces are required to have a Link-Local address [RFC4291]. Link-local addresses are or can be used for IPv6 operation or applications when the source and destination are on-link [RFC4007][RFC5942][RFC6724] To provide on-link nodes with the ability to reach off-link destinations, or for off-link sources to reach on-link destinations, one or more GUA and/or ULA prefixes need to be present on the link. Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols. There are two advantages of interfaces that only have Link-Local addresses. The first advantage is ease of configuration. In a network with a large number of Link-Local only interfaces, the operator can just enable an IGP on each router, without going through the tedious process of assigning and tracking the addresses for each interface. The second advantage is security. Since packets with Link-Local destination addresses should not be routed, it is very difficult to attack the associated nodes from an off-link device. This implies less effort around maintaining security ACLs. (etc.) Regards, Mark. > > > >> >> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. > > I agree, though it is not often I find an situation where I can take advantage of this. > > / I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses. > > > > Regards, > Mark. > >> >> Regards, >> Mark. >> >> >> >> >> >> ----- Original Message ----- >> From: Philip Matthews >> To: v6ops list >> Cc: >> Sent: Thursday, 19 February 2015, 8:23 >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt >> >> Hi Everyone: >> >> Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. >> >> A few highlights: >> * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. >> * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). >> * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. >> * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. >> * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. >> >> There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. >> >> Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. >> >> - Philip >> >> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>> >>> Title : Some Design Choices for IPv6 Networks >>> Authors : Philip Matthews >>> Victor Kuarsingh >>> Filename : draft-ietf-v6ops-design-choices-04.txt >>> Pages : 17 >>> Date : 2015-02-18 >>> >>> Abstract: >>> This document presents advice on certain routing-related design >>> choices that arise when designing IPv6 networks (both dual-stack and >>> IPv6-only). The intended audience is someone designing an IPv6 >>> network who is knowledgeable about best current practices around IPv4 >>> network design, and wishes to learn the corresponding practices for >>> IPv6. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > >> >> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them. > > I agree, though it is not often I find an situation where I can take advantage of this. > > / I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses. > > > > Regards, > Mark. > >> >> Regards, >> Mark. >> >> >> >> >> >> ----- Original Message ----- >> From: Philip Matthews >> To: v6ops list >> Cc: >> Sent: Thursday, 19 February 2015, 8:23 >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt >> >> Hi Everyone: >> >> Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes. >> >> A few highlights: >> * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this. Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area. >> * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it). >> * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out. >> * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow. >> * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document. >> >> There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews. >> >> Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments. >> >> - Philip >> >> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the IPv6 Operations Working Group of the IETF. >>> >>> Title : Some Design Choices for IPv6 Networks >>> Authors : Philip Matthews >>> Victor Kuarsingh >>> Filename : draft-ietf-v6ops-design-choices-04.txt >>> Pages : 17 >>> Date : 2015-02-18 >>> >>> Abstract: >>> This document presents advice on certain routing-related design >>> choices that arise when designing IPv6 networks (both dual-stack and >>> IPv6-only). The intended audience is someone designing an IPv6 >>> network who is knowledgeable about best current practices around IPv4 >>> network design, and wishes to learn the corresponding practices for >>> IPv6. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 23 02:49:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE11A1A15 for ; Mon, 23 Feb 2015 02:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6NGt0z86HCk for ; Mon, 23 Feb 2015 02:49:28 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BF61A0013 for ; Mon, 23 Feb 2015 02:49:28 -0800 (PST) Received: by iecar1 with SMTP id ar1so22264375iec.11 for ; Mon, 23 Feb 2015 02:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AXI9eAa0ZzAb4Ek22gcOsj8Nnf+ig0K0WhA0Bnlfm+A=; b=eLDh/nKOmI4LWDQzsTtj2Tqkykfe8QZgXUSY38xL57kGC4jccFu1UfVREdIXVKXVu/ niCxG6aO7cxavJIw+w5EZCc9Z5oZZU/kAFYjpa9d40hlI/zbGGTXDnjwbp+6x8x95iOQ DjIbBYNv+mABSkdfP2o/ib8zvuYCuLGJ4JVMyT/ms42sMbN+dVktcKLNmnz1W79Bm485 llbBY0+F56cK5ratlhGzxMbIjSkL2Q+0mHXckrJjI+wPcGHyQzlAN62aDTTdR7J3JS8N wmxnEI4gmGC74fLnhKDEjAlnqo5GnMXoAfUBgbAabXtrHpBcE+aAWcjZ6gMRQh883+oo aDVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AXI9eAa0ZzAb4Ek22gcOsj8Nnf+ig0K0WhA0Bnlfm+A=; b=X/RgrOXOsUrOBDYS0tXDnOQNAmmRPJdc4A94QQzglxGZqe5OO7SkY4RLw6l88X0nup MQL3cfigUqFYKqCBgLGPAqWuy4X4/sQJPog6KxeGI4VwlvFjRnSU/aDTmtzcs+DbkF+0 1CoNR9514+b5UdLcmN0cED6gptXauoN7KV5pHwnC7vanAh/4Agk36dfQ44XKa/uxR/9N eW572MiywBiZ3n0d+jfD1oGnScwK1Ld+smvcwA3c5DFvsrTugLQR/JwSvS6ZTNJfPbe3 lIPyBsEeis4pIh0BOhbvEgWDlU+jliG/HnojHJTVpvgUIs/MBqsy96ZmWXEiHyNe+eG/ XMWQ== X-Gm-Message-State: ALoCoQnFgqONohS8S7RcxddEIWYyB+wYl5GiMDKOsfUiIzwXcZ3BI4Vf40fKVOOK9v2Js0JQtyyr X-Received: by 10.107.170.220 with SMTP id g89mr12673270ioj.31.1424688567310; Mon, 23 Feb 2015 02:49:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 02:49:07 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 19:49:07 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a114159b8f8823d050fbf27d4 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 10:49:29 -0000 --001a114159b8f8823d050fbf27d4 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 5:39 PM, wrote: > Operators who have deployed IPv6 report that running dual-stack over two > PDP contexts is a very bad idea because it consumes 2x the network > resources. Please don't recommend this unless you have evidence that this > works well in production (not in testing). > > > > [Med] We are not recommending establishing systematically two PDP > contexts. Please check the full recommendation provided below for your > convenience. > > > > C_REC#2: The cellular host must comply with the behavior defined in > > [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- > > Context type. In particular, the cellular host must > > request by default an IPv6 PDP-Context if the cellular host > > is IPv6-only and request an IPv4v6 PDP-Context if the > > cellular host is dual-stack or when the cellular host is > > not aware of connectivity types requested by devices > > connected to it (e.g., cellular host with LAN capabilities > > as discussed in Section 3): > > > > * If the requested IPv4v6 PDP-Context is not supported by > > the network, but IPv4 and IPv6 PDP types are allowed, > > then the cellular host will be configured with an IPv4 > > address or an IPv6 prefix by the network. It must > > initiate another PDP-Context activation in addition to > > the one already activated for a given APN (Access Point > > Name). The purpose of initiating a second PDP-Context > > is to achieve dual- stack connectivity by means of two > > PDP-Contexts. > How are you "not recommending" this behaviour, if the text says that the device "must initiate another PDP-Context activation"? > * If the subscription data or network configuration allows > > only one IP address family (IPv4 or IPv6), the cellular > > host must not request a second PDP-Context to the same > > APN for the other IP address family. > > > > The text above focuses on the specification part which > > explains the behavior for requesting IPv6-related PDP- > > Context(s). Understanding this behavior is important to > > avoid having broken IPv6 implementations in cellular > > devices. > I find this last paragraph meaningless. What is it intended to convey? --001a114159b8f8823d050fbf27d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 5:39 PM, <mohamed.boucadair@orange.com= > wrote:

Operators who have = deployed IPv6 report that running dual-stack over two PDP contexts is a ver= y bad idea because it consumes 2x the network resources. Please don't r= ecommend this unless you have evidence that this works well in production (not in testing).

=C2=A0

[Med] We are not recomme= nding establishing systematically two PDP contexts. Please check the full r= ecommendation provided below for your convenience.

=C2=A0

=C2=A0=C2=A0 C_REC#2:=C2=A0 The cellular ho= st must comply with the behavior defined in

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [TS.23060] [TS.23401] [TS.24008] for request= ing a PDP-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Context type.=C2=A0 In particular, the cellu= lar host must

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request by default an IPv6 PDP-Context if th= e cellular host

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0is IPv6-only and request an IPv4v6 PDP-Conte= xt if the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cellular host is dual-stack or when the cell= ular host is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 not aware of connectivity types requested by= devices

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connected to it (e.g., cellular host with LA= N capabilities

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as discussed in Section 3):

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 If the requested IPv4v6 PDP-Context = is not supported by

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the network, but IPv4 and = IPv6 PDP types are allowed,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then the cellular host wil= l be configured with an IPv4

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address or an IPv6 prefix = by the network.=C2=A0 It must

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 initiate another PDP-Conte= xt activation in addition to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the one already activated = for a given APN (Access Point

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Name).=C2=A0 The purpose o= f initiating a second PDP-Context

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is to achieve dual- = stack connectivity by means of two

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PDP-Contexts.


Ho= w are you "not recommending" this behaviour, if the text says tha= t the device "must initiate another PDP-Context activation"?
=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 If the subscription data or network = configuration allows

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 only one IP address family= (IPv4 or IPv6), the cellular

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 host must not request a se= cond PDP-Context to the same

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 APN for the other IP addre= ss family.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The text above focuses on the specification = part which

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explains the behavior for requesting IPv6-re= lated PDP-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Context(s).=C2=A0 Understanding this behavio= r is important to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 avoid having broken IPv6 implementations in = cellular

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 devices.


I find thi= s last paragraph meaningless. What is it intended to convey?
--001a114159b8f8823d050fbf27d4-- From nobody Mon Feb 23 03:58:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF711A1A5D for ; Mon, 23 Feb 2015 03:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZGAH4zfG00W for ; Mon, 23 Feb 2015 03:58:09 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366D01A1A5A for ; Mon, 23 Feb 2015 03:58:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NBw7Ep026437 for ; Mon, 23 Feb 2015 12:58:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3E31202798 for ; Mon, 23 Feb 2015 12:59:17 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC4EE2032CF for ; Mon, 23 Feb 2015 12:59:17 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NBw5N7028149 for ; Mon, 23 Feb 2015 12:58:06 +0100 Message-ID: <54EB15CD.4010706@gmail.com> Date: Mon, 23 Feb 2015 12:58:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 11:58:11 -0000 Le 23/02/2015 08:59, mohamed.boucadair@orange.com a écrit : [...] >> C_REC#6: >> >> "restarts the ongoing applications". I don't like this wording, >> "will interrupt existing network connections" or similar text >> would be better. > > [Med] I made this change: > > OLD: > > Note, a cellular host changing its connection between an > IPv6-specific APN and an IPv4-specific APN restarts the ongoing > applications. This may be considered as a brokenness situation. > > NEW: > > Note, a cellular host changing its connection between an > IPv6-specific APN and an IPv4-specific APN will interrupt associated > network connections. This may be considered as a brokenness > situation for some applications. > > To Alex: Can you please review this text (because you are the one > who asked to have the OLD version) Yes, thanks for asking. It looks good, except it would be better to say "by some applications" instead of "for some applications". And "bound" or "ongoing" or "related" would be better than "associated" (because this latter may make think of WiFi). Alex > >> >> C_REC#7: >> >> typo: >> >> "The purpose of the of the roaming profile is" > > [Med] Fixed. Thank you. > >> >> C_REC#8: >> >> I don't understand the reference to 6052. Is this a referral to >> networks with NAT64 and/or 464XLAT? Then I think this should be >> clearer. > > [Med] This feature is for NAT64 context in general, but without > requiring any packet translation feature. > > OLD: This solves the issue when applications use IPv4 referrals on > IPv6-only access networks. > > NEW: > > In the context of NAT64, applications relying on address referrals > will fail because an IPv6-only client won't be able to make use of > an IPv4 address received in a referral. This feature allows to > solve this referral problem and, also, to distinguish between > IPv4-converted IPv6 addresses [RFC6052] and native IPv6 addresses. > > Better? > >> >> L_REC#4: Isn't this a duplication of one of the C_RECs? > > [Med] This one is for IPv4 devices connected via the cellular device > through an IPv6-only network. The one in C_REC#8 is about local > applications running on the cellular host. > >> >> Summary: >> >> I think this kind of document is valuable. Many operators do not >> have staff with right skill level to put in the requirements >> towards equipment manufacturers, and in some markets, the >> equipment manufacturers are selling directly to consumers without >> discussing details with operators. I also feel that the vendors of >> mobile equipment would benefit from having a more unified set of >> requirements from the operators. >> >> Either these requirements can be gathered within the IETF for IP >> related matters, or operators can try to do it in another venue. I >> don't see why the IETF can't be the venue for this. >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 23 04:10:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3181A1A6A for ; Mon, 23 Feb 2015 04:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eejOnO6L3KZI for ; Mon, 23 Feb 2015 04:10:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149741A1A65 for ; Mon, 23 Feb 2015 04:10:21 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 588C21B82DC; Mon, 23 Feb 2015 13:10:19 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id ED1D4180104; Mon, 23 Feb 2015 13:10:18 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 13:10:18 +0100 From: To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQT1Zm5Ax3nzpG/0OJ6Y4TQVbtUJz+IFhw Date: Mon, 23 Feb 2015 12:10:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049124F0OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.23.103920 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:10:24 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049124F0OPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGx1bmRpIDIz IGbDqXZyaWVyIDIwMTUgMTE6NDkNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2Mg OiBNaWthZWwgQWJyYWhhbXNzb247IFY2IE9wcyBMaXN0DQpPYmpldCA6IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbA0KDQpPbiBNb24s IEZlYiAyMywgMjAxNSBhdCA1OjM5IFBNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KT3BlcmF0b3JzIHdo byBoYXZlIGRlcGxveWVkIElQdjYgcmVwb3J0IHRoYXQgcnVubmluZyBkdWFsLXN0YWNrIG92ZXIg dHdvIFBEUCBjb250ZXh0cyBpcyBhIHZlcnkgYmFkIGlkZWEgYmVjYXVzZSBpdCBjb25zdW1lcyAy eCB0aGUgbmV0d29yayByZXNvdXJjZXMuIFBsZWFzZSBkb24ndCByZWNvbW1lbmQgdGhpcyB1bmxl c3MgeW91IGhhdmUgZXZpZGVuY2UgdGhhdCB0aGlzIHdvcmtzIHdlbGwgaW4gcHJvZHVjdGlvbiAo bm90IGluIHRlc3RpbmcpLg0KDQpbTWVkXSBXZSBhcmUgbm90IHJlY29tbWVuZGluZyBlc3RhYmxp c2hpbmcgc3lzdGVtYXRpY2FsbHkgdHdvIFBEUCBjb250ZXh0cy4gUGxlYXNlIGNoZWNrIHRoZSBm dWxsIHJlY29tbWVuZGF0aW9uIHByb3ZpZGVkIGJlbG93IGZvciB5b3VyIGNvbnZlbmllbmNlLg0K DQogICBDX1JFQyMyOiAgVGhlIGNlbGx1bGFyIGhvc3QgbXVzdCBjb21wbHkgd2l0aCB0aGUgYmVo YXZpb3IgZGVmaW5lZCBpbg0KICAgICAgICAgICAgIFtUUy4yMzA2MF0gW1RTLjIzNDAxXSBbVFMu MjQwMDhdIGZvciByZXF1ZXN0aW5nIGEgUERQLQ0KICAgICAgICAgICAgIENvbnRleHQgdHlwZS4g IEluIHBhcnRpY3VsYXIsIHRoZSBjZWxsdWxhciBob3N0IG11c3QNCiAgICAgICAgICAgICByZXF1 ZXN0IGJ5IGRlZmF1bHQgYW4gSVB2NiBQRFAtQ29udGV4dCBpZiB0aGUgY2VsbHVsYXIgaG9zdA0K ICAgICAgICAgICAgIGlzIElQdjYtb25seSBhbmQgcmVxdWVzdCBhbiBJUHY0djYgUERQLUNvbnRl eHQgaWYgdGhlDQogICAgICAgICAgICAgY2VsbHVsYXIgaG9zdCBpcyBkdWFsLXN0YWNrIG9yIHdo ZW4gdGhlIGNlbGx1bGFyIGhvc3QgaXMNCiAgICAgICAgICAgICBub3QgYXdhcmUgb2YgY29ubmVj dGl2aXR5IHR5cGVzIHJlcXVlc3RlZCBieSBkZXZpY2VzDQogICAgICAgICAgICAgY29ubmVjdGVk IHRvIGl0IChlLmcuLCBjZWxsdWxhciBob3N0IHdpdGggTEFOIGNhcGFiaWxpdGllcw0KICAgICAg ICAgICAgIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMpOg0KDQogICAgICAgICAgICAgKiAgSWYg dGhlIHJlcXVlc3RlZCBJUHY0djYgUERQLUNvbnRleHQgaXMgbm90IHN1cHBvcnRlZCBieQ0KICAg ICAgICAgICAgICAgIHRoZSBuZXR3b3JrLCBidXQgSVB2NCBhbmQgSVB2NiBQRFAgdHlwZXMgYXJl IGFsbG93ZWQsDQogICAgICAgICAgICAgICAgdGhlbiB0aGUgY2VsbHVsYXIgaG9zdCB3aWxsIGJl IGNvbmZpZ3VyZWQgd2l0aCBhbiBJUHY0DQogICAgICAgICAgICAgICAgYWRkcmVzcyBvciBhbiBJ UHY2IHByZWZpeCBieSB0aGUgbmV0d29yay4gIEl0IG11c3QNCiAgICAgICAgICAgICAgICBpbml0 aWF0ZSBhbm90aGVyIFBEUC1Db250ZXh0IGFjdGl2YXRpb24gaW4gYWRkaXRpb24gdG8NCiAgICAg ICAgICAgICAgICB0aGUgb25lIGFscmVhZHkgYWN0aXZhdGVkIGZvciBhIGdpdmVuIEFQTiAoQWNj ZXNzIFBvaW50DQogICAgICAgICAgICAgICAgTmFtZSkuICBUaGUgcHVycG9zZSBvZiBpbml0aWF0 aW5nIGEgc2Vjb25kIFBEUC1Db250ZXh0DQogICAgICAgICAgICAgICAgaXMgdG8gYWNoaWV2ZSBk dWFsLSBzdGFjayBjb25uZWN0aXZpdHkgYnkgbWVhbnMgb2YgdHdvDQogICAgICAgICAgICAgICAg UERQLUNvbnRleHRzLg0KDQpIb3cgYXJlIHlvdSAibm90IHJlY29tbWVuZGluZyIgdGhpcyBiZWhh dmlvdXIsIGlmIHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgZGV2aWNlICJtdXN0IGluaXRpYXRlIGFu b3RoZXIgUERQLUNvbnRleHQgYWN0aXZhdGlvbiI/DQoNCltNZWRdIEl0IHNlZW1zIHlvdSBza2lw cGVkIOKAnHN5c3RlbWF0aWNhbGx54oCdIGluIG15IGFuc3dlciA7LSkuIFNvLCBJIGNvbmZpcm0g 4oCcd2UgYXJlIG5vdCByZWNvbW1lbmRpbmcgZXN0YWJsaXNoaW5nIHN5c3RlbWF0aWNhbGx5IHR3 byBQRFAgY29udGV4dHPigJ0uIFRoZSBkZWZhdWx0IGJlaGF2aW9yIGlzIHRvIGFzayBmb3IgYSBJ UHY0djYgUERQLUNvbnRleHQsIGJ1dCAoMSkgaWYgdGhlIElQdjR2NiBQRFAtQ29udGV4dCBpcyBu b3Qgc3VwcG9ydGVkLCBhbmQgKDIpIGlmIElQdjQgYW5kIElQdjYgUERQIHR5cGVzIGFyZSBhbGxv d2VkLCB0d28gUERQIGNvbnRleHRzIGNhbiBiZSByZXF1ZXN0ZWQuIFRoZSBuZXR3b3JrIGlzIGZy ZWUgdG8gYWNjZXB0IHRob3NlIG9yIG5vdC4gQXMgeW91IGNhbiBzZWUgdGhlcmUgYXJlIOKAnGlm 4oCdcyBpbiB0aGlzIGJlaGF2aW9yLiBTbyB0byBiZSBhY2N1cmF0ZSwgdGhpcyB0ZXh0IGRvZXMg bm90IHJlY29tbWVuZCByZXF1ZXN0aW5nIHR3byBzZXBhcmF0ZSBQRFAgY29udGV4dHMgYXMgZGVm YXVsdCBiZWhhdmlvciwgYnV0IGl0IGRvZXMgbm90IGZvcmJpZCBpdCBlaXRoZXIuDQoNCiAgICAg ICAgICAgICAqICBJZiB0aGUgc3Vic2NyaXB0aW9uIGRhdGEgb3IgbmV0d29yayBjb25maWd1cmF0 aW9uIGFsbG93cw0KICAgICAgICAgICAgICAgIG9ubHkgb25lIElQIGFkZHJlc3MgZmFtaWx5IChJ UHY0IG9yIElQdjYpLCB0aGUgY2VsbHVsYXINCiAgICAgICAgICAgICAgICBob3N0IG11c3Qgbm90 IHJlcXVlc3QgYSBzZWNvbmQgUERQLUNvbnRleHQgdG8gdGhlIHNhbWUNCiAgICAgICAgICAgICAg ICBBUE4gZm9yIHRoZSBvdGhlciBJUCBhZGRyZXNzIGZhbWlseS4NCg0KICAgICAgICAgICAgIFRo ZSB0ZXh0IGFib3ZlIGZvY3VzZXMgb24gdGhlIHNwZWNpZmljYXRpb24gcGFydCB3aGljaA0KICAg ICAgICAgICAgIGV4cGxhaW5zIHRoZSBiZWhhdmlvciBmb3IgcmVxdWVzdGluZyBJUHY2LXJlbGF0 ZWQgUERQLQ0KICAgICAgICAgICAgIENvbnRleHQocykuICBVbmRlcnN0YW5kaW5nIHRoaXMgYmVo YXZpb3IgaXMgaW1wb3J0YW50IHRvDQogICAgICAgICAgICAgYXZvaWQgaGF2aW5nIGJyb2tlbiBJ UHY2IGltcGxlbWVudGF0aW9ucyBpbiBjZWxsdWxhcg0KICAgICAgICAgICAgIGRldmljZXMuDQoN CkkgZmluZCB0aGlzIGxhc3QgcGFyYWdyYXBoIG1lYW5pbmdsZXNzLiBXaGF0IGlzIGl0IGludGVu ZGVkIHRvIGNvbnZleT8NCg0KW01lZF0gRldJVywgdGhlIGxhc3QgcGFyYWdyYXBoIHdhcyBhZGRl ZCBhcyBwZXIgYSBjb21tZW50IHJlY2VpdmVkIGZyb20gdGhlIG1haWxpbmcgbGlzdDogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzE0NzE2Lmh0 bWwuIFRoZSBwb2ludCBpcyB0aGF0IHRoZSBzZXQgb2YgY2l0ZWQgc3BlY2lmaWNhdGlvbnMgY29u dGFpbnMgbW9yZSBkZXRhaWxzIGFib3V0IGhvdyBQRFAgY29udGV4dHMgYXJlIHRvIGJlIGhhbmRs ZWQgY29tcGFyZWQgdG8gd2hhdCBpcyBkZXNjcmliZWQgaW4gaGVyZSAodGhhdCBpcyBJUHY2LXNl cGNpZmljKS4NCg== --_000_787AE7BB302AE849A7480A190F8B9330049124F0OPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJz cDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0 aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9i PiBsdW5kaSAyMyBmw6l2cmllciAyMDE1IDExOjQ5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VD QURBSVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBNaWthZWwgQWJyYWhh bXNzb247IFY2IE9wcyBMaXN0PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Y2b3BzXSBk cmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZSBsYXN0IGNhbGw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEZlYiAyMywgMjAxNSBhdCA1OjM5IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PcGVyYXRvcnMgd2hvIGhhdmUgZGVwbG95ZWQgSVB2NiBy ZXBvcnQgdGhhdCBydW5uaW5nIGR1YWwtc3RhY2sgb3ZlciB0d28gUERQIGNvbnRleHRzIGlzIGEg dmVyeSBiYWQgaWRlYSBiZWNhdXNlIGl0IGNvbnN1bWVzIDJ4IHRoZSBuZXR3b3JrIHJlc291cmNl cy4gUGxlYXNlIGRvbid0IHJlY29tbWVuZCB0aGlzDQogdW5sZXNzIHlvdSBoYXZlIGV2aWRlbmNl IHRoYXQgdGhpcyB3b3JrcyB3ZWxsIGluIHByb2R1Y3Rpb24gKG5vdCBpbiB0ZXN0aW5nKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2UgYXJl IG5vdCByZWNvbW1lbmRpbmcgZXN0YWJsaXNoaW5nIHN5c3RlbWF0aWNhbGx5IHR3byBQRFAgY29u dGV4dHMuIFBsZWFzZSBjaGVjayB0aGUgZnVsbA0KIHJlY29tbWVuZGF0aW9uIHByb3ZpZGVkIGJl bG93IGZvciB5b3VyIGNvbnZlbmllbmNlLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBDX1JFQyMyOiZuYnNwOyBUaGUgY2VsbHVsYXIgaG9z dCBtdXN0IGNvbXBseSB3aXRoIHRoZSBiZWhhdmlvciBkZWZpbmVkIGluPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBbVFMuMjMwNjBdIFtUUy4yMzQwMV0gW1RTLjI0MDA4XSBmb3IgcmVxdWVz dGluZyBhIFBEUC08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnRleHQgdHlwZS4mbmJz cDsgSW4gcGFydGljdWxhciwgdGhlIGNlbGx1bGFyIGhvc3QgbXVzdDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVxdWVzdCBieSBkZWZhdWx0IGFuIElQdjYgUERQLUNvbnRleHQgaWYgdGhl IGNlbGx1bGFyIGhvc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2lzIElQdjYtb25seSBh bmQgcmVxdWVzdCBhbiBJUHY0djYgUERQLUNvbnRleHQgaWYgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjZWxsdWxhciBob3N0IGlzIGR1YWwtc3RhY2sgb3Igd2hlbiB0aGUgY2VsbHVs YXIgaG9zdCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm90IGF3YXJlIG9mIGNvbm5l Y3Rpdml0eSB0eXBlcyByZXF1ZXN0ZWQgYnkgZGV2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY29ubmVjdGVkIHRvIGl0IChlLmcuLCBjZWxsdWxhciBob3N0IHdpdGggTEFOIGNhcGFi aWxpdGllczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgZGlzY3Vzc2VkIGluIFNlY3Rp b24gMyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZu YnNwOyBJZiB0aGUgcmVxdWVzdGVkIElQdjR2NiBQRFAtQ29udGV4dCBpcyBub3Qgc3VwcG9ydGVk IGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV0 d29yaywgYnV0IElQdjQgYW5kIElQdjYgUERQIHR5cGVzIGFyZSBhbGxvd2VkLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiB0aGUgY2VsbHVsYXIgaG9z dCB3aWxsIGJlIGNvbmZpZ3VyZWQgd2l0aCBhbiBJUHY0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzIG9yIGFuIElQdjYgcHJlZml4IGJ5IHRoZSBu ZXR3b3JrLiZuYnNwOyBJdCBtdXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpbml0aWF0ZSBhbm90aGVyIFBEUC1Db250ZXh0IGFjdGl2YXRpb24gaW4gYWRk aXRpb24gdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBvbmUgYWxyZWFkeSBhY3RpdmF0ZWQgZm9yIGEgZ2l2ZW4gQVBOIChBY2Nlc3MgUG9pbnQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbWUpLiZuYnNwOyBU aGUgcHVycG9zZSBvZiBpbml0aWF0aW5nIGEgc2Vjb25kIFBEUC1Db250ZXh0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyB0byBhY2hpZXZlIGR1YWwtIHN0 YWNrIGNvbm5lY3Rpdml0eSBieSBtZWFucyBvZiB0d288L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBEUC1Db250ZXh0cy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhcmUgeW91ICZxdW90O25vdCByZWNv bW1lbmRpbmcmcXVvdDsgdGhpcyBiZWhhdmlvdXIsIGlmIHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUg ZGV2aWNlICZxdW90O211c3QgaW5pdGlhdGUgYW5vdGhlciBQRFAtQ29udGV4dCBhY3RpdmF0aW9u JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRd IEl0IHNlZW1zIHlvdSBza2lwcGVkIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPnN5c3RlbWF0aWNhbGx5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+4oCdDQogaW4gbXkgYW5zd2VyIDstKS4gU28sIEkgY29uZmlybSDigJw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj53ZSBhcmUgbm90IHJlY29tbWVuZGlu ZyBlc3RhYmxpc2hpbmcgc3lzdGVtYXRpY2FsbHkgdHdvIFBEUCBjb250ZXh0c+KAnS4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkZWZhdWx0IGJlaGF2aW9y IGlzIHRvIGFzayBmb3IgYQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SVB2NHY2IFBE UC1Db250ZXh0LCBidXQgKDEpIGlmIHRoZSBJUHY0djYgUERQLUNvbnRleHQgaXMgbm90IHN1cHBv cnRlZCwgYW5kICgyKSBpZiBJUHY0IGFuZCBJUHY2IFBEUCB0eXBlcyBhcmUgYWxsb3dlZCwgdHdv IFBEUCBjb250ZXh0cyBjYW4gYmUgcmVxdWVzdGVkLiBUaGUgbmV0d29yayBpcyBmcmVlIHRvIGFj Y2VwdA0KIHRob3NlIG9yIG5vdC4gQXMgeW91IGNhbiBzZWUgdGhlcmUgYXJlIOKAnGlm4oCdcyBp biB0aGlzIGJlaGF2aW9yLiBTbyB0byBiZSBhY2N1cmF0ZSwgdGhpcyB0ZXh0IGRvZXMgbm90IHJl Y29tbWVuZCByZXF1ZXN0aW5nIHR3byBzZXBhcmF0ZSBQRFAgY29udGV4dHMgYXMgZGVmYXVsdCBi ZWhhdmlvciwgYnV0IGl0IGRvZXMgbm90IGZvcmJpZCBpdCBlaXRoZXIuICZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBJZiB0aGUgc3Vic2NyaXB0aW9u IGRhdGEgb3IgbmV0d29yayBjb25maWd1cmF0aW9uIGFsbG93czwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb25seSBvbmUgSVAgYWRkcmVzcyBmYW1pbHkgKElQ djQgb3IgSVB2NiksIHRoZSBjZWxsdWxhcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaG9zdCBtdXN0IG5vdCByZXF1ZXN0IGEgc2Vjb25kIFBEUC1Db250ZXh0 IHRvIHRoZSBzYW1lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBUE4gZm9yIHRoZSBvdGhlciBJUCBhZGRyZXNzIGZhbWlseS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdGV4dCBhYm92ZSBmb2N1c2VzIG9uIHRo ZSBzcGVjaWZpY2F0aW9uIHBhcnQgd2hpY2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4 cGxhaW5zIHRoZSBiZWhhdmlvciBmb3IgcmVxdWVzdGluZyBJUHY2LXJlbGF0ZWQgUERQLTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGV4dChzKS4mbmJzcDsgVW5kZXJzdGFuZGluZyB0 aGlzIGJlaGF2aW9yIGlzIGltcG9ydGFudCB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXZvaWQgaGF2aW5nIGJyb2tlbiBJUHY2IGltcGxlbWVudGF0aW9ucyBpbiBjZWxsdWxhcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZGV2aWNlcy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBmaW5kIHRoaXMgbGFzdCBwYXJhZ3JhcGggbWVhbmluZ2xl c3MuIFdoYXQgaXMgaXQgaW50ZW5kZWQgdG8gY29udmV5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEZXSVcsIHRoZSBsYXN0IHBhcmFncmFwaCB3YXMg YWRkZWQgYXMgcGVyIGEgY29tbWVudCByZWNlaXZlZCBmcm9tIHRoZSBtYWlsaW5nIGxpc3Q6DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJl bnQvbXNnMTQ3MTYuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92 Nm9wcy9jdXJyZW50L21zZzE0NzE2Lmh0bWw8L2E+LiBUaGUgcG9pbnQgaXMgdGhhdCB0aGUgc2V0 IG9mIGNpdGVkIHNwZWNpZmljYXRpb25zIGNvbnRhaW5zIG1vcmUgZGV0YWlscyBhYm91dCBob3cg UERQIGNvbnRleHRzIGFyZSB0byBiZSBoYW5kbGVkDQogY29tcGFyZWQgdG8gd2hhdCBpcyBkZXNj cmliZWQgaW4gaGVyZSAodGhhdCBpcyBJUHY2LXNlcGNpZmljKS4gJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B9330049124F0OPEXCLILM23corp_-- From nobody Mon Feb 23 04:17:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA63B1A1A73 for ; Mon, 23 Feb 2015 04:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oqaDsLAjFOI for ; Mon, 23 Feb 2015 04:17:02 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAA21A1A72 for ; Mon, 23 Feb 2015 04:17:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NCGx3O006588 for ; Mon, 23 Feb 2015 13:16:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CC3E3202CEF for ; Mon, 23 Feb 2015 13:18:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C4AD1200CF8 for ; Mon, 23 Feb 2015 13:18:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NCGwDU011440 for ; Mon, 23 Feb 2015 13:16:59 +0100 Message-ID: <54EB1A3A.1030607@gmail.com> Date: Mon, 23 Feb 2015 13:16:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:17:04 -0000 Le 23/02/2015 09:09, Lorenzo Colitti a écrit : > On Mon, Feb 23, 2015 at 4:59 PM, > wrote: > > NEW: > > * If the requested IPv4v6 PDP-Context is not supported by the > network, but IPv4 and IPv6 PDP types are allowed, then the cellular > host will be configured with an IPv4 address or an IPv6 prefix by the > network. It must initiate another PDP-Context activation in addition > to the one already activated for a given APN (Access Point Name). The > purpose of initiating a second PDP-Context is to achieve dual-stack > connectivity by means of two PDP-Contexts. > > > Operators who have deployed IPv6 report that running dual-stack over > two PDP contexts is a very bad idea because it consumes 2x the > network resources. So this means it would be good to rather recommend one PDP context with two types on at the same time? (v4v6). If so, I would agree. > Please don't recommend this unless you have evidence that this works > well in production (not in testing). I don't think it is possible to have two PDP connections with two APNs up at the same time, in the same smartphone. I have never seen it, is it there somewhere? > NEW: Note, a cellular host changing its connection between an > IPv6-specific APN and an IPv4-specific APN will interrupt associated > network connections. This may be considered as a brokenness > situation for some applications. > > > What is the purpose of this text? Mobile nodes change IP addresses > all the time (e.g., when switching from 4G to wifi). How is this > different? The switching between two interfaces (4G and wifi) is smoother than switching a single interface from one APN to another. For the former, there are many operations taking place simultaneously (associate, set up PDP, acquire address, establish def route). Because of this simultaneity, and because overlapping coverage of 4G/wifi deployments, very often the end user does not notice any interruption in the ongoing applications; especially those buffered, or relying on brief http requests, or restartable TCP sessions, or those perioridally heartbeating: a youtube session will advance on green line (buffer) instead of red (live), HTTP HTML pages will display more or less, FTP transfers will restart by themselves somehow, and the skype check will re-green. On another hand, a skype ongoing call _will_ be interrupted. For the latter, the switching is more brutal: the smartphone must put interface down and delete routes before putting it up again, new address, new routes. There is no simultaneity. In this case the socket data structures proper often vanish, and lead to popping up messages like "you have been disconnected, try again". Switching between APNs is more brutal even than 'roaming' between two networks. Beside this app continuity factor, there are more reasons to _not_ recommend switching between APNs, that we could discuss separately. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 23 04:19:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4621A1A76 for ; Mon, 23 Feb 2015 04:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rktpA2iYqeb4 for ; Mon, 23 Feb 2015 04:19:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2701A1A7B for ; Mon, 23 Feb 2015 04:19:49 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id EF0B8C039D; Mon, 23 Feb 2015 13:19:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C90AD158078; Mon, 23 Feb 2015 13:19:47 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 13:19:47 +0100 From: To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQT2AHde+SG7mlHkeuZVyJyot6Y5z+JUcA Date: Mon, 23 Feb 2015 12:19:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004912519@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB15CD.4010706@gmail.com> In-Reply-To: <54EB15CD.4010706@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.23.112419 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:19:51 -0000 Hi Alex,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandru > Petrescu > Envoy=E9=A0: lundi 23 f=E9vrier 2015 12:58 > =C0=A0: v6ops@ietf.org > Objet=A0: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call >=20 > Le 23/02/2015 08:59, mohamed.boucadair@orange.com a =E9crit : > [...] >=20 > >> C_REC#6: > >> > >> "restarts the ongoing applications". I don't like this wording, > >> "will interrupt existing network connections" or similar text > >> would be better. > > > > [Med] I made this change: > > > > OLD: > > > > Note, a cellular host changing its connection between an > > IPv6-specific APN and an IPv4-specific APN restarts the ongoing > > applications. This may be considered as a brokenness situation. > > > > NEW: > > > > Note, a cellular host changing its connection between an > > IPv6-specific APN and an IPv4-specific APN will interrupt associated > > network connections. This may be considered as a brokenness > > situation for some applications. > > > > To Alex: Can you please review this text (because you are the one > > who asked to have the OLD version) >=20 > Yes, thanks for asking. It looks good, except it would be better to say > "by some applications" instead of "for some applications". >=20 > And "bound" or "ongoing" or "related" would be better than "associated" > (because this latter may make think of WiFi). >=20 [Med] Works for me. The NEW text is now: Note, a cellular host changing its connection between an IPv6-specific APN and an IPv4-specific APN will interrupt related network connections. This may be considered as a brokenness situation by some applications. > Alex >=20 > > > >> > >> C_REC#7: > >> > >> typo: > >> > >> "The purpose of the of the roaming profile is" > > > > [Med] Fixed. Thank you. > > > >> > >> C_REC#8: > >> > >> I don't understand the reference to 6052. Is this a referral to > >> networks with NAT64 and/or 464XLAT? Then I think this should be > >> clearer. > > > > [Med] This feature is for NAT64 context in general, but without > > requiring any packet translation feature. > > > > OLD: This solves the issue when applications use IPv4 referrals on > > IPv6-only access networks. > > > > NEW: > > > > In the context of NAT64, applications relying on address referrals > > will fail because an IPv6-only client won't be able to make use of > > an IPv4 address received in a referral. This feature allows to > > solve this referral problem and, also, to distinguish between > > IPv4-converted IPv6 addresses [RFC6052] and native IPv6 addresses. > > > > Better? > > > >> > >> L_REC#4: Isn't this a duplication of one of the C_RECs? > > > > [Med] This one is for IPv4 devices connected via the cellular device > > through an IPv6-only network. The one in C_REC#8 is about local > > applications running on the cellular host. > > > >> > >> Summary: > >> > >> I think this kind of document is valuable. Many operators do not > >> have staff with right skill level to put in the requirements > >> towards equipment manufacturers, and in some markets, the > >> equipment manufacturers are selling directly to consumers without > >> discussing details with operators. I also feel that the vendors of > >> mobile equipment would benefit from having a more unified set of > >> requirements from the operators. > >> > >> Either these requirements can be gathered within the IETF for IP > >> related matters, or operators can try to do it in another venue. I > >> don't see why the IETF can't be the venue for this. > >> > >> -- Mikael Abrahamsson email: swmike@swm.pp.se > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 23 04:38:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138EF1A1A70 for ; Mon, 23 Feb 2015 04:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxMhRrWvDJE5 for ; Mon, 23 Feb 2015 04:38:12 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F15B1A03A1 for ; Mon, 23 Feb 2015 04:38:11 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NCc9Al013574 for ; Mon, 23 Feb 2015 13:38:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7ABC8202CEF for ; Mon, 23 Feb 2015 13:39:20 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 68A012032F9 for ; Mon, 23 Feb 2015 13:39:20 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NCc8Hw006222 for ; Mon, 23 Feb 2015 13:38:09 +0100 Message-ID: <54EB1F2F.4000604@gmail.com> Date: Mon, 23 Feb 2015 13:38:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:38:13 -0000 Hello participants to v6ops WG, What is the status of a CLAT implementation on iPhone? Any hint in that direction? I am asking because in private conversation I have noticed doubts about this being done. Or, since the iPhone relies on a bsd derivative, it would be technically feasible to implement CLAT on it; it is nothing more than some iptables address translation plus a bit of python scripting in case. (CLAT is needed by some IPv4 apps to continue working on a smartphone connected solely with an IPv6-only PDP type). Alex From nobody Mon Feb 23 04:46:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CA61A1A90 for ; Mon, 23 Feb 2015 04:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxn1r4NnBemu for ; Mon, 23 Feb 2015 04:46:51 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31231A1A9F for ; Mon, 23 Feb 2015 04:46:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6018A2; Mon, 23 Feb 2015 13:46:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424695600; bh=L2zgOFBU9XR7eqkVs/DFDdvcfetF9B03NHAUeRf+ZiM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oUuuvvEsl9A31MbdwfF1vLWbaw6Kvt2z3xxrlHuJZ3neOf73eR/8OUjl8VaQ4marc EKA3xxXczOTvVTTyorFvhvcZyYtOiMS32U+NKR+Ux14M6gkyv8T26eq+t/paQGRiDs +9ZVtIlZA0ciq12KcdLw4Z4YYT22e7m0u5vZasjo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CEBCCA1; Mon, 23 Feb 2015 13:46:40 +0100 (CET) Date: Mon, 23 Feb 2015 13:46:40 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <54EB1F2F.4000604@gmail.com> Message-ID: References: <54EB1F2F.4000604@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:46:53 -0000 On Mon, 23 Feb 2015, Alexandru Petrescu wrote: > What is the status of a CLAT implementation on iPhone? Any hint in that > direction? There is no official news that iPhone will support this. This is not surprising since Apple rarely talks about these things. So until you hear something officially, people are not going to post on this list about it because if it's not official (and I have heard nothing official), then people would be violating NDAs if they talked about it if something was happening. Apple has been asked to implement it by several different people and entities. So far I have not heard anything official that they will support it. Otoh if it just arrived in the next version of iOS I wouldn't be surprised either, sometimes they work on things and you just get them without any prior notice at all. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 04:54:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8781A1A57 for ; Mon, 23 Feb 2015 04:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44NBPy5G0OW5 for ; Mon, 23 Feb 2015 04:54:49 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493C81A03A1 for ; Mon, 23 Feb 2015 04:54:49 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=54611 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YPsX9-0000Xa-K4; Mon, 23 Feb 2015 13:54:47 +0100 Date: Mon, 23 Feb 2015 13:54:21 +0100 From: Tore Anderson To: Alexandru Petrescu Message-ID: <20150223135421.4efe73ea@echo.ms.redpill-linpro.com> In-Reply-To: <54EB1F2F.4000604@gmail.com> References: <54EB1F2F.4000604@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:54:51 -0000 * Alexandru Petrescu > Hello participants to v6ops WG, >=20 > What is the status of a CLAT implementation on iPhone? Any hint in that > direction? No idea. It wouldn't surprise me if they'll just assume operators will eventually start supporting IPV4V6 though, which doesn't seem too far fetched now that LTE is rolling out in several economies. > I am asking because in private conversation I have noticed doubts > about this being done. Or, since the iPhone relies on a bsd > derivative, it would be technically feasible to implement CLAT on it; > it is nothing more than some iptables address translation plus a bit > of python scripting in case. You can'=E1=BA=97 implement a CLAT using iptables, since the IPv4 and IPv6 versions of iptables don't really mix. So you can't take an IPv4 packet as input and output and IPv6 packet or vice versa. You can do it with a user space daemon like TAYGA though. You'll find an CLAT implementation for Linux using Perl/TAYGA on my Github page, it's probably not too hard to adapt it to work on *BSD if you want to. That said, I've always wondered if it couldn't simply be implemented as an app. In principle a CLAT doesn't operate much differently than a regular VPN client, and there are plenty of VPN apps AFAIK. Tore From nobody Mon Feb 23 04:55:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31BA1A1A91 for ; Mon, 23 Feb 2015 04:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR_giRjRBkXp for ; Mon, 23 Feb 2015 04:55:21 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30D01A03A1 for ; Mon, 23 Feb 2015 04:55:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NCtIso014594; Mon, 23 Feb 2015 13:55:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A61302032AA; Mon, 23 Feb 2015 13:56:29 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9142B2032FF; Mon, 23 Feb 2015 13:56:29 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NCtHR8022467; Mon, 23 Feb 2015 13:55:18 +0100 Message-ID: <54EB2335.6050306@gmail.com> Date: Mon, 23 Feb 2015 13:55:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <54EB1F2F.4000604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:55:22 -0000 Le 23/02/2015 13:46, Mikael Abrahamsson a écrit : > On Mon, 23 Feb 2015, Alexandru Petrescu wrote: > >> What is the status of a CLAT implementation on iPhone? Any hint in >> that direction? > > There is no official news that iPhone will support this. This is not > surprising since Apple rarely talks about these things. Well, I can understand the explanation below with NDAs. But CLAT would not be a hardware spec like e.g. a 5G feature. CLAT would be an app that can be written and upload in a *store. Alex > > So until you hear something officially, people are not going to post > on this list about it because if it's not official (and I have heard > nothing official), then people would be violating NDAs if they > talked about it if something was happening. > > Apple has been asked to implement it by several different people and > entities. So far I have not heard anything official that they will > support it. > > Otoh if it just arrived in the next version of iOS I wouldn't be > surprised either, sometimes they work on things and you just get them > without any prior notice at all. > From nobody Mon Feb 23 05:25:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A71A1A9F for ; Mon, 23 Feb 2015 05:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQLcYdG1oOhh for ; Mon, 23 Feb 2015 05:25:53 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0D91A0021 for ; Mon, 23 Feb 2015 05:25:53 -0800 (PST) Received: from CY1PR0401MB1065.namprd04.prod.outlook.com (25.160.161.145) by CY1PR0401MB1067.namprd04.prod.outlook.com (25.160.161.147) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 13:25:51 +0000 Received: from CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) by CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 13:25:51 +0000 From: Dave Michaud To: "mohamed.boucadair@orange.com" , "Lorenzo Colitti" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZz6AFWAgAQGuYCAAALSgIAACEIAgAAkWICAABavAP//wUeA Date: Mon, 23 Feb 2015 13:25:51 +0000 Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [162.208.80.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1067; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1067; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(24454002)(377454003)(19273905006)(19300405004)(101416001)(19625215002)(92566002)(77156002)(62966003)(2900100001)(16236675004)(19617315012)(2950100001)(86362001)(66066001)(1720100001)(87936001)(40100003)(102836002)(15975445007)(122556002)(68736005)(2656002)(93886004)(83506001)(19580405001)(19580395003)(46102003)(54356999)(99286002)(97736003)(76176999)(230783001)(106116001)(2501002)(106356001)(64706001)(105586002)(50986999)(74826001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1067; H:CY1PR0401MB1065.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D11092F81AD6Edavemichaudrcirogerscom_" MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 13:25:51.4997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1067 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 13:25:56 -0000 --_000_D11092F81AD6Edavemichaudrcirogerscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To further clarify the comment below, this is not a recommendation but it i= s the expected behaviour as per the 3GPP spec. Upon receiving a request for a dual-stack PDP, the network operator can ret= urn one of the following cause codes (there are a lot more options but thes= e are the relevant ones for discussion): Cause code 50: PDP Type IPv4 only allowed Cause code 51: PDP Type IPv6 only allowed Cause code 52: Single address bearers only allowed In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type selec= ted by the network (IPv4 or IPv6) and not proceed further. Cause code 52 is= the mean by which the network signals that it will allow two distincts PDP= of different address type. In that case only is the UE suppose to go back = and request a second PDP with the alternate type not offered by the network= at the same time cause code 52 was returned. "If the requested IPv4v6 PDP-Context is not supported by the network, but IPv4 and IPv6 PDP types are allowed=85=94 =97> This is sig= nalled with cause code 52. Dave Michaud Sr. Architect Mobility =96 Access Networks & IP Network Services Network Technology | Rogers Communications dave.michaud@rci.rogers.com | tel: +1 6= 47.747.9442 | mobile: +1 416.219.5531 From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Monday, February 23, 2015 at 07:10 To: Lorenzo Colitti > Cc: IPv6 WG > Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : lundi 23 f=E9vrier 2015 11:49 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Mikael Abrahamsson; V6 Ops List Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call On Mon, Feb 23, 2015 at 5:39 PM, > wrote: Operators who have deployed IPv6 report that running dual-stack over two PD= P contexts is a very bad idea because it consumes 2x the network resources.= Please don't recommend this unless you have evidence that this works well = in production (not in testing). [Med] We are not recommending establishing systematically two PDP contexts.= Please check the full recommendation provided below for your convenience. C_REC#2: The cellular host must comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- Context type. In particular, the cellular host must request by default an IPv6 PDP-Context if the cellular host is IPv6-only and request an IPv4v6 PDP-Context if the cellular host is dual-stack or when the cellular host is not aware of connectivity types requested by devices connected to it (e.g., cellular host with LAN capabilities as discussed in Section 3): * If the requested IPv4v6 PDP-Context is not supported by the network, but IPv4 and IPv6 PDP types are allowed, then the cellular host will be configured with an IPv4 address or an IPv6 prefix by the network. It must initiate another PDP-Context activation in addition to the one already activated for a given APN (Access Point Name). The purpose of initiating a second PDP-Context is to achieve dual- stack connectivity by means of two PDP-Contexts. How are you "not recommending" this behaviour, if the text says that the de= vice "must initiate another PDP-Context activation"? [Med] It seems you skipped =93systematically=94 in my answer ;-). So, I con= firm =93we are not recommending establishing systematically two PDP context= s=94. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if t= he IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 PDP types = are allowed, two PDP contexts can be requested. The network is free to acce= pt those or not. As you can see there are =93if=94s in this behavior. So to= be accurate, this text does not recommend requesting two separate PDP cont= exts as default behavior, but it does not forbid it either. * If the subscription data or network configuration allows only one IP address family (IPv4 or IPv6), the cellular host must not request a second PDP-Context to the same APN for the other IP address family. The text above focuses on the specification part which explains the behavior for requesting IPv6-related PDP- Context(s). Understanding this behavior is important to avoid having broken IPv6 implementations in cellular devices. I find this last paragraph meaningless. What is it intended to convey? [Med] FWIW, the last paragraph was added as per a comment received from the= mailing list: https://www.ietf.org/mail-archive/web/v6ops/current/msg14716= .html. The point is that the set of cited specifications contains more deta= ils about how PDP contexts are to be handled compared to what is described = in here (that is IPv6-sepcific). ________________________________ This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l=92avis pub= li=E9 =E0 www.rogers.com/aviscourriel ________________________________ --_000_D11092F81AD6Edavemichaudrcirogerscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <79E32D575473A144A512D35462309321@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
To further clarify the comment below, this is not a recommendation but it i= s the expected behaviour as per the 3GPP spec.

Upon receiving a request for a dual-stack PDP, the network operator can ret= urn one of the following cause codes (there are a lot more options but thes= e are the relevant ones for discussion):

Cause code 50: PDP Type IPv4 only allowed
Cause code 51: PDP Type IPv6 only allowed
Cause code 52: Single address bearers only allowed

In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type s= elected by the network (IPv4 or IPv6) and not proceed further. Cause code 5= 2 is the mean by which the network signals that it will allow two distincts= PDP of different address type. In that case only is the UE suppose to go back and request a second PDP with the a= lternate type not offered by the network at the same time cause code 52 was= returned.

"If the r= equested IPv4v6 PDP-Context is not supported by

the network, but IPv4 and IPv6 PDP types are allowed=85=94 =97> This is signalled with cause code 52.




Dave Michaud
Sr. Architect Mobility =96 Access Networks & IP Network Services
Network Technology | Rogers Communications&= nbsp;
dave.michaud@rci.rogers.c= om | tel: +1 647.747.9442 | mobile: +1 416.219.5531=


From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Monday, February 23, 2015 at = 07:10
To: Lorenzo Colitti <lorenzo@google.com>
Cc: IPv6 WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6o= ps-mobile-device-profile last call

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoy=E9 : lundi 23 f=E9vrier 2015 11:49
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc : Mikael Abrahamsson; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last= call

 

On Mon, Feb 23, 2015 at 5:39 PM, <mohamed.boucadair@orange= .com> wrote:

Operators who have deployed IPv6 report that running dual-stack ov= er two PDP contexts is a very bad idea because it consumes 2x the network r= esources. Please don't recommend this unless you have evidence that this works well in production (not in testin= g).

 

[Med] We are not recommending establishing systemat= ically two PDP contexts. Please check the full recommendation provided below for your convenience.

 

   C_REC#2:  The cellular host must comply with th= e behavior defined in

           = ;  [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-<= /o:p>

           = ;  Context type.  In particular, the cellular host must

           = ;  request by default an IPv6 PDP-Context if the cellular host<= o:p>

           = ;  is IPv6-only and request an IPv4v6 PDP-Context if the

           = ;  cellular host is dual-stack or when the cellular host is

           = ;  not aware of connectivity types requested by devices

           = ;  connected to it (e.g., cellular host with LAN capabilities

           = ;  as discussed in Section 3):

 

           = ;  *  If the requested IPv4v6 PDP-Context is not supported by

           = ;     the network, but IPv4 and IPv6 PDP types are allo= wed,

           = ;     then the cellular host will be configured with an= IPv4

           = ;     address or an IPv6 prefix by the network.  I= t must

           = ;     initiate another PDP-Context activation in additi= on to

           = ;     the one already activated for a given APN (Access= Point

           = ;     Name).  The purpose of initiating a second P= DP-Context

           = ;     is to achieve dual- stack connectivity by means o= f two

           = ;     PDP-Contexts.

 

How are you "not recommending" this behavi= our, if the text says that the device "must initiate another PDP-Conte= xt activation"?

 

[Med] It seems you skipped =93= systematically=94 in my answer ;-). So, I confirm =93we are not recomm= ending establishing systematically two PDP contexts=94. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if the IPv4v6 PDP-Context is not suppor= ted, and (2) if IPv4 and IPv6 PDP types are allowed, two PDP contexts can b= e requested. The network is free to accept those or not. As you can see there are =93if=94s in this behavior. = So to be accurate, this text does not recommend requesting two separate PDP= contexts as default behavior, but it does not forbid it either.             = ;  *  If the subscription data or network configuration allows

           = ;     only one IP address family (IPv4 or IPv6), the ce= llular

           = ;     host must not request a second PDP-Context to the= same

           = ;     APN for the other IP address family.<= /o:p>

 

           = ;  The text above focuses on the specification part which<= /o:p>

           = ;  explains the behavior for requesting IPv6-related PDP-<= /o:p>

           = ;  Context(s).  Understanding this behavior is important to

           = ;  avoid having broken IPv6 implementations in cellular

           = ;  devices= .

 

I find this last paragraph meaningless. What is it i= ntended to convey?

 

[Med] FWIW, the last paragraph was ad= ded as per a comment received from the mailing list: https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. T= he point is that the set of cited specifications contains more details abou= t how PDP contexts are to be handled compared to what is described in here (that is IPv6-sepcific).   = ;  





This communication is confidential. We only send and receive email on the b= asis of the terms set out at www.rogers.com/we= b/content/emailnotice



Ce message est confidentiel. Notre transmission et r=E9ception de courriels= se fait strictement suivant les modalit=E9s =E9nonc=E9es dans l=92avis pub= li=E9 =E0 www.rogers.com/aviscourriel
--_000_D11092F81AD6Edavemichaudrcirogerscom_-- From nobody Mon Feb 23 05:49:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802291A1B9E for ; Mon, 23 Feb 2015 05:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVZKBV0srs9E for ; Mon, 23 Feb 2015 05:49:17 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F50B1A1B5A for ; Mon, 23 Feb 2015 05:49:17 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hn18so18106078igb.2 for ; Mon, 23 Feb 2015 05:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=w/QZb2um1Io5fJ0Ny8hinzVBsHTXrmt6IznRXbau+gE=; b=gzXm4C5RBqcVkLrAImnqQWpELVS+DqiALMoh7CiIC1quYu7WFmiBol+Dbz7X/ws8Qa gOTEeJt2KZl61dXkzwAzgL8gewQaP5gHrnh/1J+FaoUdDmSXAjjdssEOHfgQ52Vc9ueG olBy7E/XhbMNrrwBP8K32mDXyvYvQ6EhPN9FEYcpeGNQBbp8iRIGqutq0NzgHvLCN3y9 +Y4Cd+MF3aGxixBUNrUW0G0l/IjOsbkUq2rplTPfh0awG6g8ecYmBTcgqV5n70NklhJj tOKFEx6oS4LA0WksXYitQTsNduvN1DyGuT8YnBSoQ8aY7E+zbzAZ47tBMinCF/fqBxB/ UiGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w/QZb2um1Io5fJ0Ny8hinzVBsHTXrmt6IznRXbau+gE=; b=l9LFZcd8lNpobbwgHzhRuS0UOXjI43yXevjSRqOLRSB02/odBn5E4+5hZA3vaEELdb ZMKpyVJGP2MgVVCJYNbCh9XTZuFMnJE4NC6VPVt0tDBqcEiouTKz3mjqtl1ZSg69Vio/ 9gYWE9AFhzSun3mtn4qcSN7kjI522afNRpYqr5QGQvFnW6cp/T2Xeud4tS8m1u1/kSg3 WkICMjdMVHcPXFdgBPYMsEbqhyMdKLT5P+MvCUqLc0wRQlF31OXKQ6mWfuAiaYqnN7dW XY0kVZCRti2exYCXFRpZn+PAFfu/qtvuaWHKtMYeMw0JcB6cq7hMUPOjXqIdEZZMva1I PeaQ== X-Gm-Message-State: ALoCoQmrENnlv51HGHG5oHne4grEQ4UlnLJmm7N4tr6Xtd+t5E09goEBYQgR4yfgyavnpzIUKirT X-Received: by 10.50.49.43 with SMTP id r11mr13226538ign.18.1424699356364; Mon, 23 Feb 2015 05:49:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 05:48:56 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 22:48:56 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdca5b60ca1a1050fc1ab6b Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 13:49:22 -0000 --047d7bdca5b60ca1a1050fc1ab6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2015 at 9:10 PM, wrote: > [Med] It seems you skipped =E2=80=9Csystematically=E2=80=9D in my answer= ;-). So, I > confirm =E2=80=9Cwe are not recommending establishing systematically two = PDP > contexts=E2=80=9D. The default behavior is to ask for a IPv4v6 PDP-Contex= t, but > (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 > PDP types are allowed, two PDP contexts can be requested. The network is > free to accept those or not. As you can see there are =E2=80=9Cif=E2=80= =9Ds in this > behavior. So to be accurate, this text does not recommend requesting two > separate PDP contexts as default behavior, but it does not forbid it > either. > Ok, so you're saying that in this case, the recommendation is that the device establishes two PDP contexts? If so, then as I said before: "Please don't recommend this unless you have evidence that this works well in production (not in testing)." To make myself more clear: please either provide evidence that this works well in production, or please remove the mention of two parallel PDP contexts. > The text above focuses on the specification part which > > explains the behavior for requesting IPv6-related PDP- > > Context(s). Understanding this behavior is important to > > avoid having broken IPv6 implementations in cellular > > devices. > > > > I find this last paragraph meaningless. What is it intended to convey? > > > > [Med] FWIW, the last paragraph was added as per a comment received from > the mailing list: > https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. The > point is that the set of cited specifications contains more details about > how PDP contexts are to be handled compared to what is described in here > (that is IPv6-sepcific). > Let me try again. You say "The text above focuses on the specification part". What is the "specification part"? Part of what? --047d7bdca5b60ca1a1050fc1ab6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 9:10 PM, <mohamed.boucadair@orange.com= > wrote:

[Med] It seems you skipped =E2=80=9Csystematically=E2=80=9D in my answer ;-). So, I confirm =E2=80=9Cwe are no= t recommending establishing systematically two PDP contexts=E2=80=9D. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if the IPv4v6 PDP-Context is not su= pported, and (2) if IPv4 and IPv6 PDP types are allowed, two PDP contexts c= an be requested. The network is free to accept those or not. As you can see there are =E2=80=9Cif=E2=80=9Ds in this behav= ior. So to be accurate, this text does not recommend requesting two separat= e PDP contexts as default behavior, but it does not forbid it either. =C2= =A0


Ok, so you're saying that in this case, the recommendation is that the= device establishes two PDP contexts? If so, then as I said before: "P= lease don't recommend this unless you have evidence that this works wel= l in production (not in testing)."

To make my= self more clear: please either provide evidence that this works well in pro= duction, or please remove the mention of two parallel PDP contexts.
=C2=A0
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e text above focuses on the specification part which

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 explains the behavior for requesting IPv6-relat= ed PDP-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Context(s).=C2=A0 Understanding this behavior i= s important to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 avoid having broken IPv6 implementations in cel= lular

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 dev= ices.

=C2=A0

I find this last paragraph meaningless. What is it i= ntended to convey?

=C2=A0

[Med] FWIW, the last paragra= ph was added as per a comment received from the mailing list: https://www.ietf.org/mail-archive/web/v6ops/current/ms= g14716.html. The point is that the set of cited specifications contains= more details about how PDP contexts are to be handled compared to what is described in here (that is IPv6-sepcific). =C2=A0=C2= =A0=C2=A0=C2=A0


Let me try again. Y= ou say "The text above focuses on the specification part". What i= s the "specification part"? Part of what?
--047d7bdca5b60ca1a1050fc1ab6b-- From nobody Mon Feb 23 05:58:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18A1A1A32 for ; Mon, 23 Feb 2015 05:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlX2pKuWbjM9 for ; Mon, 23 Feb 2015 05:58:10 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633741A0021 for ; Mon, 23 Feb 2015 05:58:10 -0800 (PST) Received: by iecrp18 with SMTP id rp18so23309369iec.9 for ; Mon, 23 Feb 2015 05:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rK5Ew6N9eB9JIXhbkdrz2ivI8/gmaAhHGObWyfNs2kQ=; b=VGklfa0zTyPzqqgeuvvOPfCOcoG/4KSsse7uk+A8fGcISQLINVUmrwDsADMA3IlcDv xa79GPJMJHDTmaJUeavh5cKDF5FoACWer1MUpN8i9E4wPUM7vKpBg6DwrKamMTIe1mzm eYwNTWzYpvOjro2aIUxJO/+XopkLMLGcUVn/5/t/QtoFRRmpZi+siJatQzZ0kUkNgbPw 1796LYmV+h4js69U9qalP9ejI+aVcley7+yNRywYbkSDgB9I5PAIzHtBZTIBOyRbkdWI 1cxV2l0SgY+M6AY6LrIuCakzFtEWVUhqzzIPtOFfhMU+HCiWkv65Ut3cTuvIYvMOOcUa nZqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rK5Ew6N9eB9JIXhbkdrz2ivI8/gmaAhHGObWyfNs2kQ=; b=hCjZ71gTyG3ucpnV0Nq24+KQ+6LkTr3m6q4O7oLy2pU2JST03LCoyO9HfpU2dRHJMG b78uMoyswW4uakPAkiosJYA+JPie3XIx/RT+HjG0YeR8mI36IzoK1KsHvgj0twv//F8h GOVH1Mafin5mUhRCS/QbIaGSWKjOQS2CUtWp95pnopMhhhGwap91p6jN7SN36tniGjxh 8Esd+KG0exIb+44+xGUdugFtt2uGYO1Peg4pEmTTnmbrRS/7ZS53sle6f0zorAcfvIGJ TMU8UemMwjBfoMgT8SGrDwUMoUF3i5DUMi2bn2sYjMIrQQq8wbfdRFDN8WW99ktCfHyY ZYcQ== X-Gm-Message-State: ALoCoQn11Y3N7ddzXAeJ4Z9HjVfhFpVOUijfdwO0xR2atA4xdsDOk9SetDU+fl7ev0DshWyfhzXs X-Received: by 10.107.36.9 with SMTP id k9mr14161157iok.2.1424699889551; Mon, 23 Feb 2015 05:58:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 05:57:48 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 22:57:48 +0900 Message-ID: To: Dave Michaud Content-Type: multipart/alternative; boundary=001a1140fe8ad46450050fc1caed Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 13:58:11 -0000 --001a1140fe8ad46450050fc1caed Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 10:25 PM, Dave Michaud wrote: > In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type > selected by the network (IPv4 or IPv6) and not proceed further. Cause code > 52 is the mean by which the network signals that it will allow two > distincts PDP of different address type. In that case only is the UE > suppose to go back and request a second PDP with the alternate type not > offered by the network at the same time cause code 52 was returned. > Actually the behaviour depends on the release. Release 8 says the MS "MAY request another PDP context for the other PDP type". In any case, I think we agree that this is not something that we want to recommend? --001a1140fe8ad46450050fc1caed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 10:25 PM, Dave Michaud <Dave.Michaud@rci.rog= ers.com> wrote:
In the first 2 causes (CC50 & CC51), the UE is to accept the PDP typ= e selected by the network (IPv4 or IPv6) and not proceed further. Cause cod= e 52 is the mean by which the network signals that it will allow two distin= cts PDP of different address type. In that case only is the UE suppose to go back and request a second PDP with the a= lternate type not offered by the network at the same time cause code 52 was= returned.

Actually t= he behaviour depends on the release. Release 8 says the MS "MAY reques= t another PDP context for the other PDP type".

In any case, I think we agree that this is not something that we want to = recommend?
--001a1140fe8ad46450050fc1caed-- From nobody Mon Feb 23 06:01:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F031A1A9E for ; Mon, 23 Feb 2015 06:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syRLzvkCij0J for ; Mon, 23 Feb 2015 06:01:45 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B7D1A1AA0 for ; Mon, 23 Feb 2015 06:01:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 85DC4A2; Mon, 23 Feb 2015 15:01:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424700103; bh=Yr4gHusFv8iIH+Q/QDY7uHozeKqYNRyNoe3WasAeJ1M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mrNrjZw39H/XMFpJd0LLRsS0oZzg3ykxlWnQ8nTdm1srEJpTj4BOqL2q8Rxhizhp0 J2drxDxY0GguvpAlVGL3HvmeT4uVRVlBF1k6MPhoOTcszgnGu3FDnQsPOApGf8CuDL zLyLsErc44KxOdYibFQLlFxA1HStjXZlV2CquxcQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7E7BFA1; Mon, 23 Feb 2015 15:01:43 +0100 (CET) Date: Mon, 23 Feb 2015 15:01:43 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:01:48 -0000 On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > On Mon, Feb 23, 2015 at 10:25 PM, Dave Michaud > wrote: > >> In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type >> selected by the network (IPv4 or IPv6) and not proceed further. Cause code >> 52 is the mean by which the network signals that it will allow two >> distincts PDP of different address type. In that case only is the UE >> suppose to go back and request a second PDP with the alternate type not >> offered by the network at the same time cause code 52 was returned. > > Actually the behaviour depends on the release. Release 8 says the MS "MAY > request another PDP context for the other PDP type". > > In any case, I think we agree that this is not something that we want to > recommend? I don't agree. I agree with the above description of the CC52 code, and I definitely want (and expect) the UE to set up a second PDP context in case it gets CC52. How else should the network signal to the UE that it should bring up a second PDP context? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 06:05:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B655A1A1AA9 for ; Mon, 23 Feb 2015 06:05:46 -0800 (PST) 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=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00kyEedjH4YU for ; Mon, 23 Feb 2015 06:05:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2921A1A81 for ; Mon, 23 Feb 2015 06:05:44 -0800 (PST) Received: from CY1PR0401MB1065.namprd04.prod.outlook.com (25.160.161.145) by CY1PR0401MB1068.namprd04.prod.outlook.com (25.160.161.148) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 14:05:23 +0000 Received: from CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) by CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 14:05:23 +0000 From: Dave Michaud To: Mikael Abrahamsson , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZz6AFWAgAQGuYCAAALSgIAACEIAgAAkWICAABavAP//wUeAgABcwgCAAAEYgP//rS8A Date: Mon, 23 Feb 2015 14:05:22 +0000 Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [162.208.80.3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1068; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1068; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(377424004)(51704005)(377454003)(189002)(199003)(2656002)(106116001)(19580405001)(68736005)(2950100001)(2900100001)(87936001)(105586002)(66066001)(99286002)(106356001)(15975445007)(77156002)(62966003)(101416001)(54356999)(83506001)(46102003)(50986999)(76176999)(93886004)(97736003)(15974865002)(64706001)(19580395003)(40100003)(122556002)(92566002)(102836002)(86362001)(74826001)(19273905006)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1068; H:CY1PR0401MB1065.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <54F564DA4173714EBCA0D899BF6BD5EA@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 14:05:22.8254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1068 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:05:46 -0000 SSBhbSBvZiB0aGUgc2FtZSBvcGluaW9uLg0KDQpJIGFtIG5vdCBzYXlpbmcgdGhhdCBvcGVyYXRv cnMgc2hvdWxkIG9yIHNob3VsZCBub3QgZG8gdGhhdCAoaXTCuXMgdXAgdG8NCnRoZW0gdG8gZGVj aWRlKSBidXQgaWYgdGhleSBzZW5kIGEgQ0M1MiwgSSBleHBlY3QgdGhlIFVFcyB0byByZXF1ZXN0 DQphbm90aGVyIHByaW1hcnkgUERQLg0KDQpJZiB0aGUgb3BlcmF0b3IgZG9lcyBub3Qgd2FudCB0 aGlzIGJlaGF2aW9yLCBDQzUwIGFuZCBDQzUxIGFyZSBhdmFpbGFibGUNCmZvciB0aGF0IHB1cnBv c2UuDQoNCg0KRGF2ZSBNaWNoYXVkDQpTci4gQXJjaGl0ZWN0IE1vYmlsaXR5IMKtIEFjY2VzcyBO ZXR3b3JrcyAmIElQIE5ldHdvcmsgU2VydmljZXMNCk5ldHdvcmsgVGVjaG5vbG9neSB8IFJvZ2Vy cyBDb21tdW5pY2F0aW9ucw0KZGF2ZS5taWNoYXVkQHJjaS5yb2dlcnMuY29tIHwgdGVsOiArMSA2 NDcuNzQ3Ljk0NDIgfCBtb2JpbGU6ICsxDQo0MTYuMjE5LjU1MzENCg0KDQoNCg0KDQoNCk9uIDIw MTUtMDItMjMsIDA5OjAxLCAiTWlrYWVsIEFicmFoYW1zc29uIiA8c3dtaWtlQHN3bS5wcC5zZT4g d3JvdGU6DQoNCj5PbiBNb24sIDIzIEZlYiAyMDE1LCBMb3JlbnpvIENvbGl0dGkgd3JvdGU6DQo+ DQo+PiBPbiBNb24sIEZlYiAyMywgMjAxNSBhdCAxMDoyNSBQTSwgRGF2ZSBNaWNoYXVkDQo+PjxE YXZlLk1pY2hhdWRAcmNpLnJvZ2Vycy5jb20+DQo+PiB3cm90ZToNCj4+DQo+Pj4gIEluIHRoZSBm aXJzdCAyIGNhdXNlcyAoQ0M1MCAmIENDNTEpLCB0aGUgVUUgaXMgdG8gYWNjZXB0IHRoZSBQRFAg dHlwZQ0KPj4+IHNlbGVjdGVkIGJ5IHRoZSBuZXR3b3JrIChJUHY0IG9yIElQdjYpIGFuZCBub3Qg cHJvY2VlZCBmdXJ0aGVyLiBDYXVzZQ0KPj4+Y29kZQ0KPj4+IDUyIGlzIHRoZSBtZWFuIGJ5IHdo aWNoIHRoZSBuZXR3b3JrIHNpZ25hbHMgdGhhdCBpdCB3aWxsIGFsbG93IHR3bw0KPj4+IGRpc3Rp bmN0cyBQRFAgb2YgZGlmZmVyZW50IGFkZHJlc3MgdHlwZS4gSW4gdGhhdCBjYXNlIG9ubHkgaXMg dGhlIFVFDQo+Pj4gc3VwcG9zZSB0byBnbyBiYWNrIGFuZCByZXF1ZXN0IGEgc2Vjb25kIFBEUCB3 aXRoIHRoZSBhbHRlcm5hdGUgdHlwZSBub3QNCj4+PiBvZmZlcmVkIGJ5IHRoZSBuZXR3b3JrIGF0 IHRoZSBzYW1lIHRpbWUgY2F1c2UgY29kZSA1MiB3YXMgcmV0dXJuZWQuDQo+Pg0KPj4gQWN0dWFs bHkgdGhlIGJlaGF2aW91ciBkZXBlbmRzIG9uIHRoZSByZWxlYXNlLiBSZWxlYXNlIDggc2F5cyB0 aGUgTVMNCj4+Ik1BWQ0KPj4gcmVxdWVzdCBhbm90aGVyIFBEUCBjb250ZXh0IGZvciB0aGUgb3Ro ZXIgUERQIHR5cGUiLg0KPj4NCj4+IEluIGFueSBjYXNlLCBJIHRoaW5rIHdlIGFncmVlIHRoYXQg dGhpcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgd2Ugd2FudCB0bw0KPj4gcmVjb21tZW5kPw0KPg0K PkkgZG9uJ3QgYWdyZWUuIEkgYWdyZWUgd2l0aCB0aGUgYWJvdmUgZGVzY3JpcHRpb24gb2YgdGhl IENDNTIgY29kZSwgYW5kIEkNCj5kZWZpbml0ZWx5IHdhbnQgKGFuZCBleHBlY3QpIHRoZSBVRSB0 byBzZXQgdXAgYSBzZWNvbmQgUERQIGNvbnRleHQgaW4NCj5jYXNlDQo+aXQgZ2V0cyBDQzUyLg0K Pg0KPkhvdyBlbHNlIHNob3VsZCB0aGUgbmV0d29yayBzaWduYWwgdG8gdGhlIFVFIHRoYXQgaXQg c2hvdWxkIGJyaW5nIHVwIGENCj5zZWNvbmQgUERQIGNvbnRleHQ/DQo+DQo+LS0NCj5NaWthZWwg QWJyYWhhbXNzb24gICAgZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdCB3d3cucm9nZXJzLmNvbS93ZWIvY29udGVudC9lbWFpbG5vdGljZTxo dHRwOi8vd3d3LnJvZ2Vycy5jb20vd2ViL2NvbnRlbnQvZW1haWxub3RpY2U+DQoNCg0KDQpDZSBt ZXNzYWdlIGVzdCBjb25maWRlbnRpZWwuIE5vdHJlIHRyYW5zbWlzc2lvbiBldCByw6ljZXB0aW9u IGRlIGNvdXJyaWVscyBzZSBmYWl0IHN0cmljdGVtZW50IHN1aXZhbnQgbGVzIG1vZGFsaXTDqXMg w6lub25jw6llcyBkYW5zIGzigJlhdmlzIHB1Ymxpw6kgw6Agd3d3LnJvZ2Vycy5jb20vYXZpc2Nv dXJyaWVsIDxodHRwOi8vd3d3LnJvZ2Vycy5jb20vYXZpc2NvdXJyaWVsPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg== From nobody Mon Feb 23 06:06:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693E91A1AD0 for ; Mon, 23 Feb 2015 06:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaRc6bdPhVah for ; Mon, 23 Feb 2015 06:06:20 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC3E1A1AC6 for ; Mon, 23 Feb 2015 06:06:20 -0800 (PST) Received: by iecar1 with SMTP id ar1so23428388iec.11 for ; Mon, 23 Feb 2015 06:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V2+leubhub6aOS+zJC4w+HqZuG/3TEFoMYQ0dPC6nj0=; b=FORMEv5zLeMCgufHlztu/FYnNITHVCDTvaWoz+khhQAq0eVLn6ZIDRXAr4yTGDKj6m WyYbG5XvJDb1s7gQsLb7IMNnj6kYIMbCsVxGu0PLaxGXeIWYjhynqU6M5l6Y/uW2A0iT lKnDz2AKyvbdLXyGtjDOgg59TetD5i9LteWsCJMdFT0Oc+lxRFVz76aJZa93zMiMkJDn 5Lbdfp8NpZlxD+Sse7yd9bfge9YqUFuJhL+7lX7/iQU9t8rU67hagJNYIi2wUusEukaj +BALr5jaJvT+zAGgH0mmdwFevBJHrUbNy5hvYz5JTKLLHZ9csuipiwq47tzgPbT6yXP+ oNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V2+leubhub6aOS+zJC4w+HqZuG/3TEFoMYQ0dPC6nj0=; b=dvhyfLXLxtWy42Jc1fjO4Bliqgis3j2ShU4OSRS3xsaznZFVtDazKmEEkjajnaanaU LfakrN/G3MXZ7xFkdhHp6Hae+VnLhIpKIS+ba9wIR5JDl5xJJvedJ+sPEASQUnVrcFic nJM+8nLVtvZZpyaTdyfb1wS5rceO0YagIIY2jI3c9S6NDCPcKNXE6Drfg/ulflyvMAuO /g+OLPSy8QaTIgP1YDf8cmwVSXQaNvx8iJygFp0o2bzT3nvLQQBLjmLZAQNI/6Tt4vwQ aPmgB7MqD7ducObtVWBxEmtRzB6UOvgJNDpNeT9j6F/29trtAv+D5s4/0vnCaS/9vfUH O5kw== X-Gm-Message-State: ALoCoQmVgrqW9Xj0ASB2tRQR5VvphHBkkZ2hO7Qs1PtTHf70Vpwl6xAu0+e6/ZwZ8akkUngauvAZ X-Received: by 10.50.78.232 with SMTP id e8mr13027106igx.5.1424700379510; Mon, 23 Feb 2015 06:06:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 06:05:59 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 23:05:59 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013c6a20085c6f050fc1e83c Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:06:21 -0000 --089e013c6a20085c6f050fc1e83c Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 11:01 PM, Mikael Abrahamsson wrote: > Actually the behaviour depends on the release. Release 8 says the MS "MAY >> request another PDP context for the other PDP type". >> >> In any case, I think we agree that this is not something that we want to >> recommend? >> > > I don't agree. I agree with the above description of the CC52 code, and I > definitely want (and expect) the UE to set up a second PDP context in case > it gets CC52. Then you should read TS 23.060 release 8, which says "may". > How else should the network signal to the UE that it should bring up a > second PDP context? Why would you ever want to do this? It has terrible scaling properties and no fate sharing. --089e013c6a20085c6f050fc1e83c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 11:01 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
Actually the behaviour depends on the release. Release 8 says the= MS "MAY
request another PDP context for the other PDP type".

In any case, I think we agree that this is not something that we want to recommend?

I don't agree. I agree with the above description of the CC52 code, and= I definitely want (and expect) the UE to set up a second PDP context in ca= se it gets CC52.

Then you should read TS 23= .060 release 8, which says "may".
=C2=A0
How else should the network signal to the UE that it should bring u= p a second PDP context?

Why would you ever = want to do this? It has terrible scaling properties and no fate sharing.
--089e013c6a20085c6f050fc1e83c-- From nobody Mon Feb 23 06:10:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24951A003B for ; Mon, 23 Feb 2015 06:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA3z5MMD1S7C for ; Mon, 23 Feb 2015 06:10:32 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9451A1A9E for ; Mon, 23 Feb 2015 06:10:28 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so18336083igk.1 for ; Mon, 23 Feb 2015 06:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KXXp/0SITFqZfxOI221ZvYBKLZNuMgPhVQ6M2QDw+o8=; b=QQVmcqIHLLL7IW3p02MsB42gwMfWRbsv0NFQR3ofpDU6aeQ1u+IClmhUUSvnCxXydY xc9WcIZmySxvs/X5tdla/WFuXllou5JAnzwU3FCdXnHEboLEeNY9do2dlWEK70kY0KW/ 800ECuZ0BtFn+IiwkNUCzYdEBUktino8uVo//AH2emPYJLIrdhuf2ed5dfvumaaawghq wOi2SAHZP/CNlWx0TR6N7NpfkuzMbtUrEnBQ8AjU1IgbYBQw9iQim1LIateoKGmOWAf4 fVvGByzcj9Xj0ExI/71jJTUJ3z95SSNTj8GWVfTK3snA1iZrlBt8dPmHfVFUb3ZKVXtC Y6eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KXXp/0SITFqZfxOI221ZvYBKLZNuMgPhVQ6M2QDw+o8=; b=l7/t9YxMYFmgKptO6lda5f/KGhqB/yoh0WyW1kGXkjAvetRMSS6DzLLX8FB+oeu4Pr nhbT/ljXPadCCfuBoggaY1khJb3PsZ7ufB7BHCwxjgx6qDhCdPB5QMdJ2P7YzKbd+5Vr j7ph+oy7dbaOWWT5cfTJRu1RNDP8RjWmyy5nRj6RaV3UJ9w2P6UqqYNk9EctlXF93cIU yQcaqu5ufe8CDhxepG1CrNf07Xl4oH3wqRJ3cXdSZemjjeICotMHLhQflesbRu4wcF0E wFHPMh2Ulh4ECX4/jA/zctd1R8c49P+Y5gzi3ips2Qu+ge6zsblLy6+fnIuu1GKu7VJJ EWlA== X-Gm-Message-State: ALoCoQlhj9KG3/FZte6NnnPvvMaT3wmI0TLRc7N6xUijCGuLVyJcafeQwdnBUeiyLzbLBOoxHACP X-Received: by 10.107.161.200 with SMTP id k191mr13664062ioe.51.1424700628006; Mon, 23 Feb 2015 06:10:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 06:10:04 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 23:10:04 +0900 Message-ID: To: Dave Michaud Content-Type: multipart/alternative; boundary=001a1140ed1ad82106050fc1f64f Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:10:32 -0000 --001a1140ed1ad82106050fc1f64f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2015 at 11:05 PM, Dave Michaud wrote: > I am not saying that operators should or should not do that (it=C2=B9s up= to > them to decide) but if they send a CC52, I expect the UEs to request > another primary PDP. > > If the operator does not want this behavior, CC50 and CC51 are available > for that purpose. > But this group is in the business of providing operational guidance. It's not in the business of rubberstamping operator requirements. And it's not in the business of re-specifying behaviour that is already specified in standards written by other standards bodies. --001a1140ed1ad82106050fc1f64f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 11:05 PM, Dave Michaud <Dave.Michaud@rci.rog= ers.com> wrote:
I am not sa= ying that operators should or should not do that (it=C2=B9s up to
them to decide) but if they send a CC52, I expect the UEs to request
another primary PDP.

If the operator does not want this behavior, CC50 and CC51 are available for that purpose.

But this group is in = the business of providing operational guidance. It's not in the busines= s of rubberstamping operator requirements. And it's not in the business= of re-specifying behaviour that is already specified in standards written = by other standards bodies.
--001a1140ed1ad82106050fc1f64f-- From nobody Mon Feb 23 06:12:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2E71A003B for ; Mon, 23 Feb 2015 06:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXbGT5P5qEwP for ; Mon, 23 Feb 2015 06:12:07 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550D01A0065 for ; Mon, 23 Feb 2015 06:12:06 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B066C60352 for ; Mon, 23 Feb 2015 15:12:04 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 76F5E6004F for ; Mon, 23 Feb 2015 15:12:04 +0100 (CET) Received: (qmail 54514 invoked by uid 1007); 23 Feb 2015 15:12:04 +0100 Date: Mon, 23 Feb 2015 15:12:04 +0100 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20150223141204.GU34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:12:09 -0000 Hi, On Mon, Feb 23, 2015 at 03:01:43PM +0100, Mikael Abrahamsson wrote: > I don't agree. I agree with the above description of the CC52 code, and I > definitely want (and expect) the UE to set up a second PDP context in case > it gets CC52. > > How else should the network signal to the UE that it should bring up a > second PDP context? Actually I read CC52 as "no, we do not have IPv4IPv6, but you are free to bring up either IPv4 or IPv6 PDP!" (as opposed to CC50 and CC51 that are telling specifically which one to use). Is that not what is intended? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 23 06:12:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2B61A1AC6 for ; Mon, 23 Feb 2015 06:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TSlErT7_boL for ; Mon, 23 Feb 2015 06:12:14 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F221A1AB9 for ; Mon, 23 Feb 2015 06:12:14 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id h15so18379319igd.3 for ; Mon, 23 Feb 2015 06:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nIIWGBBG2tK/4Na4mEzNe6n4rLBDIGoMpx2i/k4pxi4=; b=oagbaNkKgpIL81XA42OIkktTntw+T2b6g/CH9GDJZ8j3KlMhnSh1coR7pQA2+IQy8/ CNuy25xyoN4Ua1DbjSZTdyScehNjIJ2Omj97UkqBqe4xegUDREataevGyVTe6BlHH2fx c4mjkJB0jLuB9c2iEkglGd5UkaYAHZZxplbDVQGgyY1OF1EG1/35f67LBmE+X64st81W AxZuOf4Lse/T9qMF3Uxn3C2VosEsx3i/NLrRBh/m3kjxZ24Dc9KMa/ShBB98SoYYWVsb s3IW23K0Iy4Yky7qxecd9+A6TB7TvIlaUHUMo6E/9ans7kOxPKwT1cw3BnZotY8MvdjD ZG4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nIIWGBBG2tK/4Na4mEzNe6n4rLBDIGoMpx2i/k4pxi4=; b=ai7M3TcDhOy4AiAa+1RKWIVQOwdx5p5GpB3LXIB+ifB65kFSmHruTZ6l2KVT37Yd2F HB0/word2wyF6gNnhfPncopg20Tvpfq1NL231SvEpGuZKeK0xjiLda5D55GgGJp2CbhF 84koG18PRMW6c5OeEFX0rEFLcW5duTJDVShaTNWZxsvDUYT22lVRl201C5oo9IH8xtu4 qfBemhgmO3Q02dtewnxtSCT+GMy+55a/9UGTcIzaUBOgaGqNJQUQ7PlrJKxd2JfbWdtK HR5MOjLhkX48VEAOINtl/gnNxN2A5yt5H3ToTMLyLpAH3IHkfsxurOVDp7eCjkUmrmmm hn9g== X-Gm-Message-State: ALoCoQmTUBaWfekUsNLCvMgWuTA7aYEcNwMfh41QEc5vGbUegQ8Wn6K7jF1Lom1r9r2qJXku/EYn X-Received: by 10.50.50.140 with SMTP id c12mr13060921igo.5.1424700733474; Mon, 23 Feb 2015 06:12:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 06:11:53 -0800 (PST) In-Reply-To: <54EB1F2F.4000604@gmail.com> References: <54EB1F2F.4000604@gmail.com> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 23:11:53 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7bdc117e218d97050fc1fd18 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:12:15 -0000 --047d7bdc117e218d97050fc1fd18 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I am asking because in private conversation I have noticed doubts about > this being done. Or, since the iPhone relies on a bsd derivative, > it would be technically feasible to implement CLAT on it; it is nothing > more than some iptables address translation plus a bit of python > scripting in case. > They are also free to reuse existing implementations of clat, such as the one that Android uses, which is BSD-licensed. --047d7bdc117e218d97050fc1fd18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu <alexandru.petr= escu@gmail.com> wrote:
I am= asking because in private conversation I have noticed doubts about
this being done.=C2=A0 Or, since the iPhone relies on a bsd derivative,
it would be technically feasible to implement CLAT on it; it is nothing
more than some iptables address translation plus a bit of python
scripting in case.

They are also free t= o reuse existing implementations of clat, such as the one that Android uses= , which is BSD-licensed.
--047d7bdc117e218d97050fc1fd18-- From nobody Mon Feb 23 06:16:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5371A1ADF for ; Mon, 23 Feb 2015 06:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8efmbKzkpcn3 for ; Mon, 23 Feb 2015 06:16:31 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F75B1A1AC7 for ; Mon, 23 Feb 2015 06:16:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 644C2A2; Mon, 23 Feb 2015 15:16:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424700989; bh=DgzHkXFKfQpq6KfWIWRhgpZEUgbGHKoiwspH/I2/wco=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=x5mYZdOdAyyUitXet66Bq7bkDwQJ4Qr5s4aMt9kIqzu+mpQiOLym5bG1Ucisl9+W7 RoTB87+6o0f748+3cMSuP9wxYx/rlSGTpumqJwAjv3X5z/63xTFdscUHOd68t0LmP0 xtneyFEXTbpCbC0w2miMTBFSoVjJlWhoPFp70vEA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5CE1DA1; Mon, 23 Feb 2015 15:16:29 +0100 (CET) Date: Mon, 23 Feb 2015 15:16:29 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:16:32 -0000 On Mon, 23 Feb 2015, Lorenzo Colitti wrote: >> How else should the network signal to the UE that it should bring up a >> second PDP context? > > Why would you ever want to do this? It has terrible scaling properties and > no fate sharing. Because that's the way MMS is commonly done as well, as well as VoLTE. It's the basic model how QoS is supposed to work in 3GPP networks. The fact that historically vendors have charged on a per-PDP-context basis doesn't mean it doesn't work. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 06:28:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC94A1A1AC6 for ; Mon, 23 Feb 2015 06:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1r7S0kqotUm for ; Mon, 23 Feb 2015 06:27:57 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C810B1A1ABB for ; Mon, 23 Feb 2015 06:27:57 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so18514679igb.5 for ; Mon, 23 Feb 2015 06:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NDGpHbhvCZ2xY0qVHcZLO/3SK0Piz3l0y5WjJr6u2V8=; b=he+3WB8LSqNWZCU1brKkMwbSPSobKFnYRgmhqQoSgaFVHOBZDlhdU59K0v1UldhQQ2 tzwgUenfOvdQFcp9dxHWx+wmaJbKyww6MqA5LkdNiA5hMtmaR6Yu64a57rUdxu2qR+s/ wYq0nULogytlg4iRJKqW2YYR/wuLJEl2Al/HMKiKhXBPyJfdBEN/NqwvmkY3q1fMXR6M IIENoC1ZBC9ziwJyde3F7yUshJdGDkVjnFIPLbauidp4+FhpcfwXByc8ymorzGoYCagA O1FN2hb3bL5XI1VnLFM2YuMOYP2lrQ7AI7cqSiWu+G6KTPG6QN+UOm4iJoYvd/Y9qYO7 tT9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NDGpHbhvCZ2xY0qVHcZLO/3SK0Piz3l0y5WjJr6u2V8=; b=XJ7S7pNOTtlCEgzRclfeGy5X00M1GzE5vLB5h+8qT7146eqdIkcV+8iTj1g10jTiXQ iyqHK0OqGULnVKQ8b5BTfMtxWOSRAxWqFzUTn9XFFXIpo06+vkGsRD/3Op3BFUgmnGw9 DmfE0Y16QRIzqGmGEyB8cE/W5QYenBpMk9ZeXHgqknYDEeLKOUkfSsLs+TOvUI0GmpFb lRGh2hdsWoEBDVqHfEy2kw0JGGrfmiPXyEbuogh2yPle5hqduTDxjaxJMsH2vU0AIrM/ C4n2+QUefTYBdU4pWIojBq/g+fk9levPZIbtu1cFxyBJFGUCmYGz7Fz7ijBKPXy9rUU/ dhhw== X-Gm-Message-State: ALoCoQnQZajnN5QFMIpS7AAzv/SNym69vQvHH3JKM/8ZWncJtaE+8ZxZmqq5HTghrvNnz0RRKc9i X-Received: by 10.43.34.137 with SMTP id ss9mr11971035icb.11.1424701676982; Mon, 23 Feb 2015 06:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 06:27:36 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 23:27:36 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec518647e5e3490050fc2359d Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:27:58 -0000 --bcaec518647e5e3490050fc2359d Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 11:16 PM, Mikael Abrahamsson wrote: > Why would you ever want to do this? It has terrible scaling properties and >> no fate sharing. >> > > Because that's the way MMS is commonly done as well, as well as VoLTE. > It's the basic model how QoS is supposed to work in 3GPP networks. > Sure, but even if you already have another PDN up for VoLTE, using 2 PDNs for Internet access is still a 50% increase in load. Again - do we have evidence from operators that using IPv4 / IPv6 on two separate APNs works well in production? The only operators I have heard using it said that it was very much something they wanted to avoid. --bcaec518647e5e3490050fc2359d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 11:16 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
Why would you ever want to do this? It has terrible scaling prope= rties and
no fate sharing.

 Because that's the way MMS is commonly done as well, as well as VoLTE. = It's the basic model how QoS is supposed to work in 3GPP networks.
<= /blockquote>

Sure, but even if you already have another = PDN up for VoLTE, using 2 PDNs for Internet access is still a 50% increase = in load. Again - do we have evidence from operators that using IPv4 / IPv6 = on two separate APNs works well in production?

The= only operators I have heard using it said that it was very much something = they wanted to avoid.
--bcaec518647e5e3490050fc2359d-- From nobody Mon Feb 23 06:42:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056781A1AC6 for ; Mon, 23 Feb 2015 06:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZQMMjFGIn6c for ; Mon, 23 Feb 2015 06:42:24 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4DB1A1ABB for ; Mon, 23 Feb 2015 06:42:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E6727A2; Mon, 23 Feb 2015 15:42:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424702531; bh=LBTanb2u4I6eHnXiXas8u4AcPMFcSsnt8dyV65GovIo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MCbcR/+pZveQlxbp/leCuxuWTkDwyLvWDWkGFmHn/I1zID/CSHWcd5H55TtekXXrT q+nVckIquMlW8Fgf9olXJKwaJYDnOhZp+9WH3QRKo5RCl6D7qZCjKS/bf9F79wR/wE LJd7AVI6FghBS4ZfN+UfkBwRbNKaeSS896sVyDes= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF2D5A1; Mon, 23 Feb 2015 15:42:11 +0100 (CET) Date: Mon, 23 Feb 2015 15:42:11 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:42:26 -0000 On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > Sure, but even if you already have another PDN up for VoLTE, using 2 > PDNs for Internet access is still a 50% increase in load. Again - do we > have evidence from operators that using IPv4 / IPv6 on two separate APNs > works well in production? >From 23.401 version 12.6.0: "If the requested PDN type is IPv4v6, and both IPv4 and IPv6 PDN types are allowed by subscription but not IPv4v6, the MME shall set the PDN type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The UE should then initiate the UE requested PDN connectivity procedure to this APN in order to activate a second PDN connection with the other single address PDN type which was not allocated by the network." "should". So as far as I can tell, the current document we're discussion is saying the same thing as 3GPP 23.401. The behaviour is also what I have seen from "all" UEs I did testing with, so I'd say the baseband vendors are doing just this. > The only operators I have heard using it said that it was very much > something they wanted to avoid. Well, because of paying per PDP context (licensing fee). This is a negotiation between them and their equipment vendor. If they do not want the UE to do this, then they have provisioning tools to make this happen (return CC50 or CC51). Even if there is a "may" in release 8, in later versions of 3GPP architecture this seems to have been replaced by a "should". It's my opinion that this "should" makes a lot of sense and that's what I would like to see in the mobile-device-profile document. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 06:45:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0761A1AD0 for ; Mon, 23 Feb 2015 06:45:21 -0800 (PST) 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=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlW0vc0QwRok for ; Mon, 23 Feb 2015 06:45:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930901A1AC6 for ; Mon, 23 Feb 2015 06:45:19 -0800 (PST) Received: from CY1PR0401MB1065.namprd04.prod.outlook.com (25.160.161.145) by CY1PR0401MB1066.namprd04.prod.outlook.com (25.160.161.146) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 14:45:01 +0000 Received: from CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) by CY1PR0401MB1065.namprd04.prod.outlook.com ([25.160.161.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 14:45:01 +0000 From: Dave Michaud To: Gert Doering , Mikael Abrahamsson Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZz6AFWAgAQGuYCAAALSgIAACEIAgAAkWICAABavAP//wUeAgABcwgCAAAEYgIAAAuQA//+1YAA= Date: Mon, 23 Feb 2015 14:45:01 +0000 Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150223141204.GU34798@Space.Net> In-Reply-To: <20150223141204.GU34798@Space.Net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [162.208.80.3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Michaud@rci.rogers.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1066; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1066; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(189002)(51704005)(377424004)(199003)(24454002)(62966003)(2950100001)(92566002)(77156002)(19273905006)(101416001)(2900100001)(87936001)(102836002)(15975445007)(40100003)(122556002)(2656002)(68736005)(93886004)(83506001)(19580395003)(19580405001)(46102003)(15974865002)(230783001)(106116001)(76176999)(106356001)(86362001)(74826001)(97736003)(105586002)(99286002)(66066001)(64706001)(50986999)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1066; H:CY1PR0401MB1065.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: rci.rogers.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rci.rogers.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 14:45:01.3300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ab4cbbf-4bc7-4826-b52c-a14fed5286b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1066 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:45:22 -0000 VGhlIHRlY2huaWNhbGl0eSBoZXJlIGlzIHRoYXQgQ0M1MCwgQ0M1MSBhbmQgQ0M1MiBhcmUgcmV0 dXJuZWQgbm90IGFzIGENCmZhaWx1cmUgYnV0IGFzIGEgc3VjY2VzcyB3aXRoIGFuIElQIGFkZHJl c3MgYWxsb2NhdGVkLg0KDQpTbyBDQzUyIGlzIHJldHVybmVkIHdpdGggZWl0aGVyIGFuIElQdjQg b3IgYW4gSVB2NiBhZGRyZXNzIGFsbG9jYXRlZCBieQ0KdGhlIG5ldHdvcmsgd2l0aCB0aGUgb251 cyBvbiB0aGUgVUUgdG8gcHJvY2VlZCB3aXRoIGEgc3Vic2VxdWVudCByZXF1ZXN0DQp0byBlc3Rh Ymxpc2ggdGhlIGFsdGVybmF0ZSBQRFAgdHlwZS4NCg0KRm9yIENDNTAgYW5kIENDNTEsIHRoZXkg YXJlIGFsc28gcmV0dXJuZWQgd2l0aCB0aGUgc2VsZWN0ZWQgUERQIHR5cGUgKGFuZA0KYWxsb2Nh dGVkIElQIGFkZHJlc3MpIGFuZCBpdCB0ZWxscyB0aGUgVUUgdGhhdCB0aGUgYWx0ZXJuYXRlIFBE UCB0eXBlIHdpbGwNCmJlIHJlamVjdGVkIGJ5IHRoZSBuZXR3b3JrIChzbyB0aGUgVUUgaXMgbm90 IHRvIHByb2NlZWQgZnVydGhlcikuDQoNCg0KRGF2ZSBNaWNoYXVkDQpTci4gQXJjaGl0ZWN0IE1v YmlsaXR5IMKtIEFjY2VzcyBOZXR3b3JrcyAmIElQIE5ldHdvcmsgU2VydmljZXMNCk5ldHdvcmsg VGVjaG5vbG9neSB8IFJvZ2VycyBDb21tdW5pY2F0aW9ucw0KZGF2ZS5taWNoYXVkQHJjaS5yb2dl cnMuY29tIHwgdGVsOiArMSA2NDcuNzQ3Ljk0NDIgfCBtb2JpbGU6ICsxDQo0MTYuMjE5LjU1MzEN Cg0KDQoNCg0KDQoNCk9uIDIwMTUtMDItMjMsIDA5OjEyLCAiR2VydCBEb2VyaW5nIiA8Z2VydEBz cGFjZS5uZXQ+IHdyb3RlOg0KDQo+SGksDQo+DQo+T24gTW9uLCBGZWIgMjMsIDIwMTUgYXQgMDM6 MDE6NDNQTSArMDEwMCwgTWlrYWVsIEFicmFoYW1zc29uIHdyb3RlOg0KPj4gSSBkb24ndCBhZ3Jl ZS4gSSBhZ3JlZSB3aXRoIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiBvZiB0aGUgQ0M1MiBjb2RlLCBh bmQNCj4+SQ0KPj4gZGVmaW5pdGVseSB3YW50IChhbmQgZXhwZWN0KSB0aGUgVUUgdG8gc2V0IHVw IGEgc2Vjb25kIFBEUCBjb250ZXh0IGluDQo+PmNhc2UNCj4+IGl0IGdldHMgQ0M1Mi4NCj4+DQo+ PiBIb3cgZWxzZSBzaG91bGQgdGhlIG5ldHdvcmsgc2lnbmFsIHRvIHRoZSBVRSB0aGF0IGl0IHNo b3VsZCBicmluZyB1cCBhDQo+PiBzZWNvbmQgUERQIGNvbnRleHQ/DQo+DQo+QWN0dWFsbHkgSSBy ZWFkIENDNTIgYXMgIm5vLCB3ZSBkbyBub3QgaGF2ZSBJUHY0SVB2NiwgYnV0IHlvdSBhcmUgZnJl ZQ0KPnRvIGJyaW5nIHVwIGVpdGhlciBJUHY0IG9yIElQdjYgUERQISIgKGFzIG9wcG9zZWQgdG8g Q0M1MCBhbmQgQ0M1MSB0aGF0DQo+YXJlIHRlbGxpbmcgc3BlY2lmaWNhbGx5IHdoaWNoIG9uZSB0 byB1c2UpLiAgSXMgdGhhdCBub3Qgd2hhdCBpcyBpbnRlbmRlZD8NCj4NCj5HZXJ0IERvZXJpbmcN Cj4gICAgICAgIC0tIE5ldE1hc3Rlcg0KPi0tDQo+aGF2ZSB5b3UgZW5hYmxlZCBJUHY2IG9uIHNv bWV0aGluZyB0b2RheS4uLj8NCj4NCj5TcGFjZU5ldCBBRyAgICAgICAgICAgICAgICAgICAgICAg IFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZA0KPkpvc2VwaC1Eb2xsaW5nZXItQm9nZW4g MTQgICAgICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBBLg0KPkdydW5kbmVyLUN1bGVtYW5uDQo+ RC04MDgwNyBNdWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNo ZW4pDQo+VGVsOiArNDkgKDApODkvMzIzNTYtNDQ0ICAgICAgICAgICBVU3QtSWROci46IERFODEz MTg1Mjc5DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhpcyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gV2Ug b25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0 IG91dCBhdCB3d3cucm9nZXJzLmNvbS93ZWIvY29udGVudC9lbWFpbG5vdGljZTxodHRwOi8vd3d3 LnJvZ2Vycy5jb20vd2ViL2NvbnRlbnQvZW1haWxub3RpY2U+DQoNCg0KDQpDZSBtZXNzYWdlIGVz dCBjb25maWRlbnRpZWwuIE5vdHJlIHRyYW5zbWlzc2lvbiBldCByw6ljZXB0aW9uIGRlIGNvdXJy aWVscyBzZSBmYWl0IHN0cmljdGVtZW50IHN1aXZhbnQgbGVzIG1vZGFsaXTDqXMgw6lub25jw6ll cyBkYW5zIGzigJlhdmlzIHB1Ymxpw6kgw6Agd3d3LnJvZ2Vycy5jb20vYXZpc2NvdXJyaWVsIDxo dHRwOi8vd3d3LnJvZ2Vycy5jb20vYXZpc2NvdXJyaWVsPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg== From nobody Mon Feb 23 06:55:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F011A00EC for ; Mon, 23 Feb 2015 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcD89-FbsoFI for ; Mon, 23 Feb 2015 06:55:08 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D431B1A1AA0 for ; Mon, 23 Feb 2015 06:55:00 -0800 (PST) Received: by iecrl12 with SMTP id rl12so23876025iec.2 for ; Mon, 23 Feb 2015 06:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rzxFiCAEYz8qZqZVx95AcgAh+rztwVKdaLo4F7E90dQ=; b=Mn+FLWNt+YFePFYizxPTktSGWmS0ZAwhKVDouyUm+zmAGaeSndcfQWZWRQTHsu+lLt 4oZGstcmt8wDlsvmfwX5NUIJnrZ1RvygIDmHkg8WcXBsaieVgmuEPo10XH8wdWJJNZ03 2CUW1W5S7uVKQG2tP7F1dWTKveCH248yKLVMw5QMMGDaS86ndy8ESC+K3z9tN32+2gyx aSe06wUwwvWB8eANhGEF6hiJgi/NZdFwsT72ZyAHz0p8cXWFNA0ySQIpgmA0ClwASvzj 2N0qxyqNqR4KR+oMZ68e6hRu0taUnCGB4Nkbtf6vIf+WYKd+/KuzH/jEyC2S2QTSUlF1 qoLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rzxFiCAEYz8qZqZVx95AcgAh+rztwVKdaLo4F7E90dQ=; b=kR4y9ZkO8G+PcxUQGaC7p3PZQllDBgiUd0eH/RrG1lswCEhNd/XcrGDx72+9Fp7+/1 zT1Km3ji4PtTWdzT4WP76LhNqSmwulBl8FtgGWflPhHXGfQOn0CLJ3E1H5XZJIWNxSuy KfR9cNohGV8TxKxXATgeI1rBZHQNWQdq3ox5wWT879IoOx2IRDzb+0kI22zSWAnYMCnc ceYSaUJyVuac5gWiuZfW9DpXRvjIjc7jvuhO9ckH8n8mlscoz/rdrQ3LqZm6yp0YJ7yb zBwo3BVldi2Nf48HVLM56v4Mrb7nyMqgPtkAsaTmWrf8ioQ3uKMmIbkSYZbYmkfAeOsZ tO1g== X-Gm-Message-State: ALoCoQlGHDKe0dQCmcfjh2JRjbvDXSvByQv50a4I7QfIlXxhSzaPINjsY6hNPxR6+5gGhjwyXLbq X-Received: by 10.50.78.232 with SMTP id e8mr13346368igx.5.1424703300095; Mon, 23 Feb 2015 06:55:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 06:54:38 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Mon, 23 Feb 2015 23:54:38 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013c6a201d2f57050fc29623 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:55:09 -0000 --089e013c6a201d2f57050fc29623 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 11:42 PM, Mikael Abrahamsson wrote: > "should". So as far as I can tell, the current document we're discussion >> is saying the same thing as 3GPP 23.401. The behaviour is also what I have >> seen from "all" UEs I did testing with, so I'd say the baseband vendors are >> doing just this. >> > I stand by my earlier questions. Do we have evidence that people do this in production? It's not just the money - Dual-PDP is either a 100% increase or a 50% increase in state and signaling load over single-PDP. It also has worse fate-sharing properties (e.g., IPv4 can fail but IPv6 can be working, and vice versa). Is that something we want to recommend? I get it that if you're an operator, the ideal situation is that you have a knob to control every possible aspect of device behaviour, even if you never use it. But forget about that for a moment. Remember, this group is about providing *operational guidance*. Is this really something you would recommend operationally? If so, why? Saying "establishing a second PDP context after code 52 is what the 3GPP standards say the device should do" is all very well. But it's not really very useful for the IETF to say that, first because those standards are already written down in other organizations' documents, and second because (as you yourself point out) the terminals *do* respect the standards and already behave this way. --089e013c6a201d2f57050fc29623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 11:42 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
"s= hould". So as far as I can tell, the current document we're discus= sion is saying the same thing as 3GPP 23.401. The behaviour is also what I = have seen from "all" UEs I did testing with, so I'd say the b= aseband vendors are doing just this.

I stand by my earlier questions. Do we have evidence that= people do this in production? It's not just the money - Dual-PDP is ei= ther a 100% increase or a 50% increase in state and signaling load over sin= gle-PDP. It also has worse fate-sharing properties (e.g., IPv4 can fail but= IPv6 can be working, and vice versa). Is that something we want to recomme= nd?

I get it that if you're an operator, the i= deal situation is that you have a knob to control every possible aspect of = device behaviour, even if you never use it. But forget about that for a mom= ent. Remember, this group is about providing *operational guidance*. Is thi= s really something you would recommend operationally? If so, why?

Saying "establishing a second PDP context after code 5= 2 is what the 3GPP standards say the device should do" is all very wel= l. But it's not really very useful for the IETF to say that, first beca= use those standards are already written down in other organizations' do= cuments, and second because (as you yourself point out) the terminals *do* = respect the standards and already behave this way.
--089e013c6a201d2f57050fc29623-- From nobody Mon Feb 23 06:57:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71F1A0193 for ; Mon, 23 Feb 2015 06:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvx_EQoedbN1 for ; Mon, 23 Feb 2015 06:57:13 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE421A1ADD for ; Mon, 23 Feb 2015 06:57:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NEvBxR022341 for ; Mon, 23 Feb 2015 15:57:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C2E1203547 for ; Mon, 23 Feb 2015 15:58:22 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4449520322D for ; Mon, 23 Feb 2015 15:58:22 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NEvALO018598 for ; Mon, 23 Feb 2015 15:57:11 +0100 Message-ID: <54EB3FC5.4000904@gmail.com> Date: Mon, 23 Feb 2015 15:57:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:57:16 -0000 Le 23/02/2015 14:25, Dave Michaud a écrit : > To further clarify the comment below, this is not a recommendation but > it is the expected behaviour as per the 3GPP spec. > > Upon receiving a request for a dual-stack PDP, the network operator can > return one of the following cause codes (there are a lot more options > but these are the relevant ones for discussion): And what is the Cause code number for "PDP Type IPv4IPv6 allowed"? If there is no such Cause code then it would make sense to add it. Alex > > Cause code 50: PDP Type IPv4 only allowed > Cause code 51: PDP Type IPv6 only allowed > Cause code 52: Single address bearers only allowed > > In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type > selected by the network (IPv4 or IPv6) and not proceed further. Cause > code 52 is the mean by which the network signals that it will allow two > distincts PDP of different address type. In that case only is the UE > suppose to go back and request a second PDP with the alternate type not > offered by the network at the same time cause code 52 was returned. > > "If the requested IPv4v6 PDP-Context is not supported by > > the network, *but IPv4 and IPv6 PDP types are allowed**…*” —> This is > signalled with cause code 52. > > > > * > * > *Dave Michaud* > Sr. Architect Mobility – Access Networks & IP Network Services > Network Technology | Rogers Communications > dave.michaud@rci.rogers.com | tel: > +1 647.747.9442 | mobile: +1 416.219.5531 > > > From: "mohamed.boucadair@orange.com > " > > Date: Monday, February 23, 2015 at 07:10 > To: Lorenzo Colitti > > Cc: IPv6 WG > > Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call > > Re-, > > Please see inline. > > Cheers, > > Med > > *De :*Lorenzo Colitti [mailto:lorenzo@google.com] > *Envoyé :* lundi 23 février 2015 11:49 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* Mikael Abrahamsson; V6 Ops List > *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call > > On Mon, Feb 23, 2015 at 5:39 PM, > wrote: > > Operators who have deployed IPv6 report that running dual-stack over two > PDP contexts is a very bad idea because it consumes 2x the network > resources. Please don't recommend this unless you have evidence that > this works well in production (not in testing). > > [Med] We are not recommending establishing systematically two PDP > contexts. Please check the full recommendation provided below for your > convenience. > > C_REC#2: The cellular host must comply with the behavior defined in > > [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- > > Context type. In particular, the cellular host must > > request by default an IPv6 PDP-Context if the cellular host > > is IPv6-only and request an IPv4v6 PDP-Context if the > > cellular host is dual-stack or when the cellular host is > > not aware of connectivity types requested by devices > > connected to it (e.g., cellular host with LAN capabilities > > as discussed in Section 3): > > * If the requested IPv4v6 PDP-Context is not supported by > > the network, but IPv4 and IPv6 PDP types are allowed, > > then the cellular host will be configured with an IPv4 > > address or an IPv6 prefix by the network. It must > > initiate another PDP-Context activation in addition to > > the one already activated for a given APN (Access Point > > Name). The purpose of initiating a second PDP-Context > > is to achieve dual- stack connectivity by means of two > > PDP-Contexts. > > How are you "not recommending" this behaviour, if the text says that the > device "must initiate another PDP-Context activation"? > > [Med] It seems you skipped “systematically” in my answer ;-). So, I > confirm “we are not recommending establishing systematically two PDP > contexts”. The default behavior is to ask for a IPv4v6 PDP-Context, but > (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 > PDP types are allowed, two PDP contexts can be requested. The network is > free to accept those or not. As you can see there are “if”s in this > behavior. So to be accurate, this text does not recommend requesting two > separate PDP contexts as default behavior, but it does not forbid it > either. > > * If the subscription data or network configuration > allows > > only one IP address family (IPv4 or IPv6), the cellular > > host must not request a second PDP-Context to the same > > APN for the other IP address family. > > The text above focuses on the specification part which > > explains the behavior for requesting IPv6-related PDP- > > Context(s). Understanding this behavior is important to > > avoid having broken IPv6 implementations in cellular > > devices. > > I find this last paragraph meaningless. What is it intended to convey? > > [Med] FWIW, the last paragraph was added as per a comment received from > the mailing list: > https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. The > point is that the set of cited specifications contains more details > about how PDP contexts are to be handled compared to what is described > in here (that is IPv6-sepcific). > > > > > > ------------------------------------------------------------------------ > This communication is confidential. We only send and receive email on > the basis of the terms set out at www.rogers.com/web/content/emailnotice > > > > > Ce message est confidentiel. Notre transmission et réception de > courriels se fait strictement suivant les modalités énoncées dans l’avis > publié à www.rogers.com/aviscourriel > ------------------------------------------------------------------------ > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 23 07:04:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF631A00EC for ; Mon, 23 Feb 2015 07:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EUCMCA_3GCq for ; Mon, 23 Feb 2015 07:04:23 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6653D1A1AA0 for ; Mon, 23 Feb 2015 07:04:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CB9FCA3; Mon, 23 Feb 2015 16:04:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424703849; bh=FEvuGMg1/Pl6t5xWRYo93R3APL8LbOjmrINyYhyf2zs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hqzQzH+8EwVv+sD6YksaL2Ls/qtb9tWPerLPnRJlbald/1S7GekbY8QQDkV9TLLkm Ck4dKJMJgHcFMa/kqdHTZ6Av5kO622fI9pBp5PdAWeoXQtCwmqJGKE25R6iKg+ubql taSem0YRAwEvATJcGOpW4Vw4yUUMsKqF84+M1KZs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C7A35A2; Mon, 23 Feb 2015 16:04:09 +0100 (CET) Date: Mon, 23 Feb 2015 16:04:09 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:04:30 -0000 On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > I stand by my earlier questions. Do we have evidence that people do this > in production? It's not just the money - Dual-PDP is either a 100% > increase or a 50% increase in state and signaling load over single-PDP. > It also has worse fate-sharing properties (e.g., IPv4 can fail but IPv6 > can be working, and vice versa). Is that something we want to recommend? > > I get it that if you're an operator, the ideal situation is that you have a > knob to control every possible aspect of device behaviour, even if you > never use it. But forget about that for a moment. Remember, this group is > about providing *operational guidance*. Is this really something you would > recommend operationally? If so, why? My opinion is the following: We should recommend to run IPv4v6 whereever possible to operators, for the reasons you provide. We should recommend device manufacturers to follow the 3GPP standards and set up a second PDP context when it receives CC#52. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 07:16:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36F11A0470 for ; Mon, 23 Feb 2015 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv4jVrVl-A4h for ; Mon, 23 Feb 2015 07:16:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAB81A1B05 for ; Mon, 23 Feb 2015 07:16:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NFGCSN031483; Mon, 23 Feb 2015 16:16:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3BA02034D7; Mon, 23 Feb 2015 16:17:23 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CDF2F20337E; Mon, 23 Feb 2015 16:17:23 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NFGBBK007103; Mon, 23 Feb 2015 16:16:12 +0100 Message-ID: <54EB443B.4080802@gmail.com> Date: Mon, 23 Feb 2015 16:16:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <54EB1F2F.4000604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:16:22 -0000 Le 23/02/2015 15:11, Lorenzo Colitti a écrit : > On Mon, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu > > > wrote: > > I am asking because in private conversation I have noticed doubts > about this being done. Or, since the iPhone relies on a bsd > derivative, it would be technically feasible to implement CLAT on it; > it is nothing more than some iptables address translation plus a bit > of python scripting in case. > > > They are also free to reuse existing implementations of clat, such as > the one that Android uses, which is BSD-licensed. Maybe end users will install it and it will work off-the-shelf, just like every other app. Alex From nobody Mon Feb 23 07:40:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2D1A1B4C for ; Mon, 23 Feb 2015 07:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_20TdRW6_WW for ; Mon, 23 Feb 2015 07:40:30 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B411A1B4B for ; Mon, 23 Feb 2015 07:40:29 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id l15so18153110wiw.3 for ; Mon, 23 Feb 2015 07:40:27 -0800 (PST) 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=EFtxSHTjlGwvJ4SSNOCLqIk4nj21rBNVM/kVuoqaC7w=; b=WKqULvozhgbIrh+IQPBlc7cLR14IqDuFBoFEJCpeRQUAwh8CJY1R+tPJgap/HDO3tj kv3Xf9XG9garaEl/Glj0kq7Q5wLgT10moqakiL7cPVLp0HLVHZ7zuO+GYUTKmQsdGz6u gvdGH70OlLMUrGwkvgNyGuGTxAkqV169oE8JjCWK94bpqHXW5+hHIM+XpwvHq2pUon1J 0HVJ7v+YL7TGoR9+KGD0cg1/Ik8rO91WyayvCMg3n3d5IXcnHIUywWrzz6EnmCJVvslQ qCJY8n+9BdWtLeNZmyDoeQs841VUMg7P55whKwOga/O6NOXHCE6pylLCFwbr6YYvKDYq uTxw== MIME-Version: 1.0 X-Received: by 10.194.77.230 with SMTP id v6mr1964628wjw.25.1424706027585; Mon, 23 Feb 2015 07:40:27 -0800 (PST) Received: by 10.194.58.17 with HTTP; Mon, 23 Feb 2015 07:40:27 -0800 (PST) In-Reply-To: <54EB443B.4080802@gmail.com> References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> Date: Mon, 23 Feb 2015 07:40:27 -0800 Message-ID: From: Ca By To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7bfd028caf09b7050fc338c8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:40:31 -0000 --047d7bfd028caf09b7050fc338c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2015 at 7:16 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 23/02/2015 15:11, Lorenzo Colitti a =C3=A9crit : > >> On Mon, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu >> > >> >> wrote: >> >> I am asking because in private conversation I have noticed doubts >> about this being done. Or, since the iPhone relies on a bsd >> derivative, it would be technically feasible to implement CLAT on it; >> it is nothing more than some iptables address translation plus a bit >> of python scripting in case. >> >> >> They are also free to reuse existing implementations of clat, such as >> the one that Android uses, which is BSD-licensed. >> > > Maybe end users will install it and it will work off-the-shelf, just > like every other app. > > > Alex > > This is not a path towards success since it requires the user to care about how their connectivity is achieved. An ipv(v4|v6) decision is only ever made at scale by default, at scale That said, Android and Microsoft have already included CLAT as part of the OS. It would substantially and immediately improve my IPv6 deployment, and restoration of a proper e2e IPv6 internet, if Apple would release CLAT as part of their OS. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7bfd028caf09b7050fc338c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 23, 2015 at 7:16 AM, Alexandru Petrescu &= lt;alexan= dru.petrescu@gmail.com> wrote:
Le 23/02/2015 15:11, Lorenzo Colitti a =C3=A9crit :
On Mon, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu
 <alexa= ndru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>&g= t;

wrote:

I am asking because in private conversation I have noticed doubts
about this being done.=C2=A0 Or, since the iPhone relies on a bsd
derivative, it would be technically feasible to implement CLAT on it;
it is nothing more than some iptables address translation plus a bit
of python scripting in case.


They are also free to reuse existing implementations of clat, such as
=C2=A0the one that Android uses, which is BSD-licensed.

Maybe end users will install it and it will work off-the-shelf, just
like every other app.


Alex



This is not= a path towards success since it requires the user to care about how their = connectivity is achieved.

An ipv(v4|v6) decision i= s only ever made at scale by default, at scale

Tha= t said, Android and Microsoft have already included CLAT as part of the OS.=

It would substantially and immediately improve my= IPv6 deployment, and restoration of a proper e2e IPv6 internet, =C2=A0if A= pple would release CLAT as part of their OS.

CB
=C2=A0
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7bfd028caf09b7050fc338c8-- From nobody Mon Feb 23 07:42:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7C1A1B24 for ; Mon, 23 Feb 2015 07:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb1EalOZ_Qcu for ; Mon, 23 Feb 2015 07:41:59 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD641A1AB5 for ; Mon, 23 Feb 2015 07:41:59 -0800 (PST) Received: by iecrl12 with SMTP id rl12so24243750iec.4 for ; Mon, 23 Feb 2015 07:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xfc5wAMHNgKChrzTeYG+ZH9OX+y7UHwzxgQptjIQms0=; b=kyu7TNOImEGSnCWDkpE6ITkn59PVuMIC+jmNlg9F6LXlQIvsHVrc/r8t+xeh4aLHyA r1PfNz0nnGDBEDVonR1YSuXlNth/8KSI4QVc48ei/rnxOJSLfYJ8t+BWbCyciGYnejnl zoQ9eJmSjFk5T899wZGj1b/z7HLy64Khx36C54SM/cn+fc7HmuGpYLextI5jIvqSKeuM xW0yvcDgbN4MtfIFgH+IRXeoJ6E2A9hoaFF9uk9MW9rEY5x4hyoZnbWWPssh+4Owwpx6 hNMe3QNfOSrp0KwibaawJn5ztEBaBNzSylm2KQ+yWWZpKwaKgTk+UuAVrhYLHt1xGot1 PgLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xfc5wAMHNgKChrzTeYG+ZH9OX+y7UHwzxgQptjIQms0=; b=eI1qpHdr/aEVZm7ZfWnkP6YSassUtAtDGDsE2RYf+Sm1vh7w5LOOzB+kvuuAS2m9s6 RE+4gErSau1lWx4aZMxD31Lpi/ILtyP2Fu5hnfzAL61QIGkqGCjyIJ0YLuwGYSAtamNe iaLG4c6NFncJLBGpZkfjM90iNntDIdSDE8/YJowhurFvPTjDcaX99a1hC7NLADCYnRG1 G3AttbYK4tRCSvcZa0La0OmP8f08g3efvh7/sPj5lielFsV0ho/Xpe2ihs4STZ0lUJDN hCl/ZPbGnjA+OkC+qBu6pEfywSIQd3XE6sXNec9gHMSsCjE7jUFavrlrFO1m/eDAdzfl qsDQ== X-Gm-Message-State: ALoCoQnm2p9Vt4nm+PP9O3OFLAd7X8ujZ9DYA6vINcACiQqULsxDAkVeD+3ZQ5EoAEA35vQemG0D X-Received: by 10.50.112.98 with SMTP id ip2mr13530010igb.15.1424706118388; Mon, 23 Feb 2015 07:41:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 07:41:38 -0800 (PST) In-Reply-To: References: <54EB1F2F.4000604@gmail.com> From: Lorenzo Colitti Date: Tue, 24 Feb 2015 00:41:38 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b41416218c200050fc33ef2 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:42:00 -0000 --047d7b41416218c200050fc33ef2 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 11:11 PM, Lorenzo Colitti wrote: > > They are also free to reuse existing implementations of clat, such as the > one that Android uses, which is BSD-licensed. > (Sorry - Apache licensed.) --047d7b41416218c200050fc33ef2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 23, 2015 at 11:11 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
They are also free to reuse e= xisting implementations of clat, such as the one that Android uses, which i= s BSD-licensed.

(Sorry - Apache lic= ensed.)
--047d7b41416218c200050fc33ef2-- From nobody Mon Feb 23 07:57:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362561A1B60 for ; Mon, 23 Feb 2015 07:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.486 X-Spam-Level: * X-Spam-Status: No, score=1.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iAc2oxgGKRB for ; Mon, 23 Feb 2015 07:57:00 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107751A1B53 for ; Mon, 23 Feb 2015 07:56:59 -0800 (PST) Received: from 10.236.62.151 (EHLO OPE10HT01.tp.gk.corp.tepenet) ([10.236.62.151]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DNO10124; Mon, 23 Feb 2015 16:56:54 +0100 (CET) From: Kossut Tomasz - Hurt To: Lorenzo Colitti , Alexandru Petrescu Thread-Topic: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) Thread-Index: AQHQT3T4DWzZKDBVQkOYLK3Z4DDO7Jz+XIug Date: Mon, 23 Feb 2015 15:56:16 +0000 Message-ID: References: <54EB1F2F.4000604@gmail.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.1] Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B285129CDOPE10MB06tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.2.23.150320:17:8.317, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, __SUBJ_ALPHA_NEGATE, __HTML_FONT_BLUE, __HAS_HTML, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_6000_6999, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __RATWARE_SIGNATURE_3_N1, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0201.54EB4DC6.028E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0201.54EB4DC6.028E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 891d3c5afcc8a53ecd893979f482263d Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:57:02 -0000 --_000_A0BB7AD89EA705449C486BDB5FDCBC7B285129CDOPE10MB06tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBsaWtlIE1pY3Jvc29mdCBkaWQsIENMQVQgaXMgaW5jbHVkZWQgaW4gV2luZG93cyBQaG9u ZSA4LjEuDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjMsIDIwMTUgMzoxMiBQTQ0KVG86IEFsZXhhbmRy dSBQZXRyZXNjdQ0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBTdGF0 dXMgb2YgQ0xBVCBpbXBsZW1lbnRhdGlvbiBvbiBpUGhvbmU/IChJUHY0IGFwcHMgb24gSVB2Ni1v bmx5IFBEUCB0eXBlKQ0KDQpPbiBNb24sIEZlYiAyMywgMjAxNSBhdCA5OjM4IFBNLCBBbGV4YW5k cnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208bWFpbHRvOmFsZXhhbmRy dS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToNCkkgYW0gYXNraW5nIGJlY2F1c2UgaW4gcHJp dmF0ZSBjb252ZXJzYXRpb24gSSBoYXZlIG5vdGljZWQgZG91YnRzIGFib3V0DQp0aGlzIGJlaW5n IGRvbmUuICBPciwgc2luY2UgdGhlIGlQaG9uZSByZWxpZXMgb24gYSBic2QgZGVyaXZhdGl2ZSwN Cml0IHdvdWxkIGJlIHRlY2huaWNhbGx5IGZlYXNpYmxlIHRvIGltcGxlbWVudCBDTEFUIG9uIGl0 OyBpdCBpcyBub3RoaW5nDQptb3JlIHRoYW4gc29tZSBpcHRhYmxlcyBhZGRyZXNzIHRyYW5zbGF0 aW9uIHBsdXMgYSBiaXQgb2YgcHl0aG9uDQpzY3JpcHRpbmcgaW4gY2FzZS4NCg0KVGhleSBhcmUg YWxzbyBmcmVlIHRvIHJldXNlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiBjbGF0LCBzdWNo IGFzIHRoZSBvbmUgdGhhdCBBbmRyb2lkIHVzZXMsIHdoaWNoIGlzIEJTRC1saWNlbnNlZC4NCg== --_000_A0BB7AD89EA705449C486BDB5FDCBC7B285129CDOPE10MB06tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0 IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCBsaWtlIE1pY3Jvc29mdCBkaWQsIENMQVQgaXMgaW5j bHVkZWQgaW4gV2luZG93cyBQaG9uZSA4LjEuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iUEwiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iUEwiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVh cnkgMjMsIDIwMTUgMzoxMiBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZHJ1IFBldHJlc2N1PGJy Pg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2 b3BzXSBTdGF0dXMgb2YgQ0xBVCBpbXBsZW1lbnRhdGlvbiBvbiBpUGhvbmU/IChJUHY0IGFwcHMg b24gSVB2Ni1vbmx5IFBEUCB0eXBlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMjMsIDIwMTUgYXQgOTozOCBQTSwgQWxleGFu ZHJ1IFBldHJlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYXNraW5n IGJlY2F1c2UgaW4gcHJpdmF0ZSBjb252ZXJzYXRpb24gSSBoYXZlIG5vdGljZWQgZG91YnRzIGFi b3V0PGJyPg0KdGhpcyBiZWluZyBkb25lLiZuYnNwOyBPciwgc2luY2UgdGhlIGlQaG9uZSByZWxp ZXMgb24gYSBic2QgZGVyaXZhdGl2ZSw8YnI+DQppdCB3b3VsZCBiZSB0ZWNobmljYWxseSBmZWFz aWJsZSB0byBpbXBsZW1lbnQgQ0xBVCBvbiBpdDsgaXQgaXMgbm90aGluZzxicj4NCm1vcmUgdGhh biBzb21lIGlwdGFibGVzIGFkZHJlc3MgdHJhbnNsYXRpb24gcGx1cyBhIGJpdCBvZiBweXRob248 YnI+DQpzY3JpcHRpbmcgaW4gY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXkgYXJlIGFsc28gZnJlZSB0byByZXVzZSBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgb2YgY2xhdCwgc3VjaCBhcyB0aGUgb25lIHRoYXQgQW5kcm9pZCB1c2VzLCB3aGlj aCBpcyBCU0QtbGljZW5zZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A0BB7AD89EA705449C486BDB5FDCBC7B285129CDOPE10MB06tpgkco_-- From nobody Mon Feb 23 07:57:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1F71A1AAA for ; Mon, 23 Feb 2015 07:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfyU2d1SkQ9a for ; Mon, 23 Feb 2015 07:57:41 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5B71A1B6B for ; Mon, 23 Feb 2015 07:57:39 -0800 (PST) Received: by wesw55 with SMTP id w55so19479668wes.4 for ; Mon, 23 Feb 2015 07:57:38 -0800 (PST) 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=dvrcZP1olUoOWaUc0smvT6cXj6DWoT0M2ZUY5XRramw=; b=QXYvIrsoHBZze09zIikGsdnH3TQGxLObZnK4/g14U3wcIaB9TBrfyjPY4YRd680IFn KEAVGglQQffitgPYPwZm/vF2oqinAHMy25oTAFE6Wef0ngFuYb58fKJgsfCIJGBjc2LN 1nCJTi1fnjiK0JnIqiFdQ6vCdAD++22E0oGBXsAsxowBihNB8B/v6v9GaTOwwGwqn34x jYp/sNbHKylzECo493DsXjoDtzssayAR09u9FczV7iC7Tk0i1/MqSqpuAqgF8zJFDzzb C7BLMXXb9yezO1f4G1BE0Lm9nBtrAdwMfIJ8Cym52aVsDQVOpoEAiNWOwxjH4tXCjJlt ws8g== MIME-Version: 1.0 X-Received: by 10.181.13.42 with SMTP id ev10mr21915905wid.69.1424707057009; Mon, 23 Feb 2015 07:57:37 -0800 (PST) Received: by 10.194.58.17 with HTTP; Mon, 23 Feb 2015 07:57:36 -0800 (PST) In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Mon, 23 Feb 2015 07:57:36 -0800 Message-ID: From: Ca By To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=f46d04388df10ac8b7050fc376b8 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:57:43 -0000 --f46d04388df10ac8b7050fc376b8 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson wrote: > On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > > I stand by my earlier questions. Do we have evidence that people do this >> in production? It's not just the money - Dual-PDP is either a 100% increase >> or a 50% increase in state and signaling load over single-PDP. It also has >> worse fate-sharing properties (e.g., IPv4 can fail but IPv6 can be working, >> and vice versa). Is that something we want to recommend? >> >> I get it that if you're an operator, the ideal situation is that you have >> a >> knob to control every possible aspect of device behaviour, even if you >> never use it. But forget about that for a moment. Remember, this group is >> about providing *operational guidance*. Is this really something you would >> recommend operationally? If so, why? >> > > My opinion is the following: > > We should recommend to run IPv4v6 whereever possible to operators, for the > reasons you provide. > i don't see how we, v6ops, can recommend operators deploy ipv4 addresses that are not available. Should we include an appendix listing ipv4 brokers they can contact? Oh, and don't forget the v6ops is also publishing this https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07 Quoting: "In the network attachment stage, PDP/PDN type IPv4v6 is the major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/ PDN type IPv4v6 in the earlier releases. That PDP/PDN type is supported in new-built EPS network, but isn't supported well in the third generation network." CB > We should recommend device manufacturers to follow the 3GPP standards and > set up a second PDP context when it receives CC#52. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04388df10ac8b7050fc376b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson &= lt;swmike@swm.pp.se> wrote:
On Mon, 23 Feb 20= 15, Lorenzo Colitti wrote:

I stand by my earlier questions. Do we have evidence that people do this in= production? It's not just the money - Dual-PDP is either a 100% increa= se or a 50% increase in state and signaling load over single-PDP. It also h= as worse fate-sharing properties (e.g., IPv4 can fail but IPv6 can be worki= ng, and vice versa). Is that something we want to recommend?

I get it that if you're an operator, the ideal situation is that you ha= ve a
knob to control every possible aspect of device behaviour, even if you
never use it. But forget about that for a moment. Remember, this group is about providing *operational guidance*. Is this really something you would<= br> recommend operationally? If so, why?

 My opinion is the following:

We should recommend to run IPv4v6 whereever possible to operators, for the = reasons you provide.

i don't see ho= w we, v6ops, =C2=A0can recommend operators deploy ipv4 addresses that are n= ot available.

Should we include an appendix listing ipv4 brok= ers they can contact?

Oh, and don't forget the= v6ops is also publishing this


Quoting:

"In the network attachment stage, PDP/PDN type I= Pv4v6 is the major
   concern to the visited pre=
-Release 9 SGSN. 3GPP didn't specify PDP/
   PDN type IPv4v6 in the earlier releases.  That PDP/PDN type is
   supported in new-built EPS network, but isn't supported well in the
   third generation network."

CB
=C2=A0
We should recommend device manufacturers to follow the 3GPP standards and s= et up a second PDP context when it receives CC#52.


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d04388df10ac8b7050fc376b8-- From nobody Mon Feb 23 08:01:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DC11A00EF for ; Mon, 23 Feb 2015 08:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVLZvEA7cOey for ; Mon, 23 Feb 2015 08:01:21 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBDF1A1A1D for ; Mon, 23 Feb 2015 08:01:21 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4483A60134 for ; Mon, 23 Feb 2015 17:01:19 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E5CF16005C for ; Mon, 23 Feb 2015 17:01:18 +0100 (CET) Received: (qmail 75783 invoked by uid 1007); 23 Feb 2015 17:01:18 +0100 Date: Mon, 23 Feb 2015 17:01:18 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150223160118.GG34798@Space.Net> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB3FC5.4000904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54EB3FC5.4000904@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:01:26 -0000 Hi, On Mon, Feb 23, 2015 at 03:57:09PM +0100, Alexandru Petrescu wrote: > Le 23/02/2015 14:25, Dave Michaud a écrit : > > To further clarify the comment below, this is not a recommendation but > > it is the expected behaviour as per the 3GPP spec. > > > > Upon receiving a request for a dual-stack PDP, the network operator can > > return one of the following cause codes (there are a lot more options > > but these are the relevant ones for discussion): > > And what is the Cause code number for "PDP Type IPv4IPv6 allowed"? "Success!". If the device is capable of doing IPv4IPv6, it is supposed to try it first (if permitted by policy). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 23 08:02:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A026F1A1B07 for ; Mon, 23 Feb 2015 08:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOKwyR0dKrJu for ; Mon, 23 Feb 2015 08:02:27 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3991A00EF for ; Mon, 23 Feb 2015 08:02:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 90F85A2; Mon, 23 Feb 2015 17:02:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424707345; bh=kWNP1+McC9qXe6uQ5r2k/6mPi1+ECLAZYCpsJ5oQNWs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=q5C7t0cYmMtyK/H3gbSUnKrsnUzk6n/UWf7rHGC/yV+W+pXYSL6n311pbVT/CN7Nq lWHRs8l1TOAqs+84otYjYegjWZLKZ+pkbtZICUs0oC+aS6DjVvcYApH+xgwbqJfThs KF4APuYMkxTvGRjChB0b0KhV4xLh/lF29DttVNys= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8B140A1; Mon, 23 Feb 2015 17:02:25 +0100 (CET) Date: Mon, 23 Feb 2015 17:02:25 +0100 (CET) From: Mikael Abrahamsson To: Ca By In-Reply-To: Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:02:31 -0000 On Mon, 23 Feb 2015, Ca By wrote: >> We should recommend to run IPv4v6 whereever possible to operators, for the >> reasons you provide. > > i don't see how we, v6ops, can recommend operators deploy ipv4 addresses > that are not available. You're right, I will be more specific. If the operator wants the UEs to have simultaneous IPv4 and IPv6 access to the device, this should be done by means of a single IPv4v6 bearer and not one IPv4 and one IPv6 bearer. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 08:03:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0071A1B85 for ; Mon, 23 Feb 2015 08:03:16 -0800 (PST) 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_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1aeZAClZgHN for ; Mon, 23 Feb 2015 08:03:10 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532D51A1B87 for ; Mon, 23 Feb 2015 08:03:10 -0800 (PST) Received: from [85.158.136.3] by server-16.bemta-5.messagelabs.com id AD/99-02804-C3F4BE45; Mon, 23 Feb 2015 16:03:08 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-11.tower-123.messagelabs.com!1424707388!40816795!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29319 invoked from network); 23 Feb 2015 16:03:08 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-11.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2015 16:03:08 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Mon, 23 Feb 2015 16:02:58 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 23 Feb 2015 16:03:08 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Mon, 23 Feb 2015 16:03:07 +0000 From: "Heatley, Nick" To: Mikael Abrahamsson , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZz6AFWAgAQGuYCAAALSgIAACEIAgAAkWICAABavAP//wUeAgABcwgCAAAEYgIAAATGAgAAC74CAAAMbAIAABBOAgAADewCAAAKpgIAACLlg Date: Mon, 23 Feb 2015 16:03:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E0B009@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:03:16 -0000 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamss= on Sent: 23 February 2015 15:04 To: Lorenzo Colitti Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call My opinion is the following: We should recommend to run IPv4v6 whereever possible to operators, for th= e reasons you provide. [Heatley, Nick] If we want to recommend, then I would suggest we should r= ecommend that the operator's APN design promotes the use of a single PDP/= PDN type per subscriber, for the reasons you provide. The problem for me is that this is design in the operator network and los= ing focus on the mobile device profile. We should recommend device manufacturers to follow the 3GPP standards and= =20set up a second PDP context when it receives CC#52. [Heatley, Nick] I would not be comfortable doing anything but working wit= hin the 3GPP standards. The background is that parallel address version PDPs may exist per subscr= iber due to: 1. Legacy handsets (pre-release8 devices on dualstack networks) 2. OR Roaming situations, e.g. dualstack APN home networks on legacy visi= ted networks 3. OR Due to an individual operator's APN design. So even with a recommendation then 2. could exist and result in CC#52. IMHO the original text just acknowledges the existence of such an outcome= . NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Mon Feb 23 08:04:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA7F1A1B47 for ; Mon, 23 Feb 2015 08:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpDyRtvB_cqv for ; Mon, 23 Feb 2015 08:04:13 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0083F1A1B07 for ; Mon, 23 Feb 2015 08:04:12 -0800 (PST) Received: from [194.106.220.35] by server-8.bemta-14.messagelabs.com id C7/F1-03168-A7F4BE45; Mon, 23 Feb 2015 16:04:10 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-91.messagelabs.com!1424707449!16874409!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4320 invoked from network); 23 Feb 2015 16:04:09 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-16.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2015 16:04:09 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Mon, 23 Feb 2015 16:03:59 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 23 Feb 2015 16:04:08 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Mon, 23 Feb 2015 16:04:08 +0000 From: "Heatley, Nick" To: Ca By , Alexandru Petrescu Thread-Topic: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) Thread-Index: AQHQT2XZ58LeERvvrUufYV73r8AcUpz+RoyAgAAR+ICAAAbHgIAABnZg Date: Mon, 23 Feb 2015 16:04:08 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E0B024@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E0B024UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:04:15 -0000 --_000_6536E263028723489CCD5B6821D4B21303E0B024UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVyArMSB0byB0aGF0DQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIENhIEJ5DQpTZW50OiAyMyBGZWJydWFyeSAyMDE1IDE1OjQwDQpU bzogQWxleGFuZHJ1IFBldHJlc2N1DQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb djZvcHNdIFN0YXR1cyBvZiBDTEFUIGltcGxlbWVudGF0aW9uIG9uIGlQaG9uZT8gKElQdjQgYXBw cyBvbiBJUHY2LW9ubHkgUERQIHR5cGUpDQoNCg0KDQpPbiBNb24sIEZlYiAyMywgMjAxNSBhdCA3 OjE2IEFNLCBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208 bWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToNCkxlIDIzLzAyLzIw MTUgMTU6MTEsIExvcmVuem8gQ29saXR0aSBhIMOpY3JpdCA6DQpPbiBNb24sIEZlYiAyMywgMjAx NSBhdCA5OjM4IFBNLCBBbGV4YW5kcnUgUGV0cmVzY3UNCjxhbGV4YW5kcnUucGV0cmVzY3VAZ21h aWwuY29tPG1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPiA8bWFpbHRvOmFsZXhh bmRydS5wZXRyZXNjdUBnbWFpbC5jb208bWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5j b20+Pj4NCg0Kd3JvdGU6DQoNCkkgYW0gYXNraW5nIGJlY2F1c2UgaW4gcHJpdmF0ZSBjb252ZXJz YXRpb24gSSBoYXZlIG5vdGljZWQgZG91YnRzDQphYm91dCB0aGlzIGJlaW5nIGRvbmUuICBPciwg c2luY2UgdGhlIGlQaG9uZSByZWxpZXMgb24gYSBic2QNCmRlcml2YXRpdmUsIGl0IHdvdWxkIGJl IHRlY2huaWNhbGx5IGZlYXNpYmxlIHRvIGltcGxlbWVudCBDTEFUIG9uIGl0Ow0KaXQgaXMgbm90 aGluZyBtb3JlIHRoYW4gc29tZSBpcHRhYmxlcyBhZGRyZXNzIHRyYW5zbGF0aW9uIHBsdXMgYSBi aXQNCm9mIHB5dGhvbiBzY3JpcHRpbmcgaW4gY2FzZS4NCg0KDQpUaGV5IGFyZSBhbHNvIGZyZWUg dG8gcmV1c2UgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIGNsYXQsIHN1Y2ggYXMNCiB0aGUg b25lIHRoYXQgQW5kcm9pZCB1c2VzLCB3aGljaCBpcyBCU0QtbGljZW5zZWQuDQoNCk1heWJlIGVu ZCB1c2VycyB3aWxsIGluc3RhbGwgaXQgYW5kIGl0IHdpbGwgd29yayBvZmYtdGhlLXNoZWxmLCBq dXN0DQpsaWtlIGV2ZXJ5IG90aGVyIGFwcC4NCg0KDQpBbGV4DQoNCg0KVGhpcyBpcyBub3QgYSBw YXRoIHRvd2FyZHMgc3VjY2VzcyBzaW5jZSBpdCByZXF1aXJlcyB0aGUgdXNlciB0byBjYXJlIGFi b3V0IGhvdyB0aGVpciBjb25uZWN0aXZpdHkgaXMgYWNoaWV2ZWQuDQoNCkFuIGlwdih2NHx2Nikg ZGVjaXNpb24gaXMgb25seSBldmVyIG1hZGUgYXQgc2NhbGUgYnkgZGVmYXVsdCwgYXQgc2NhbGUN Cg0KVGhhdCBzYWlkLCBBbmRyb2lkIGFuZCBNaWNyb3NvZnQgaGF2ZSBhbHJlYWR5IGluY2x1ZGVk IENMQVQgYXMgcGFydCBvZiB0aGUgT1MuDQoNCkl0IHdvdWxkIHN1YnN0YW50aWFsbHkgYW5kIGlt bWVkaWF0ZWx5IGltcHJvdmUgbXkgSVB2NiBkZXBsb3ltZW50LCBhbmQgcmVzdG9yYXRpb24gb2Yg YSBwcm9wZXIgZTJlIElQdjYgaW50ZXJuZXQsICBpZiBBcHBsZSB3b3VsZCByZWxlYXNlIENMQVQg YXMgcGFydCBvZiB0aGVpciBPUy4NCg0KQ0INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8 bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1 ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVy c29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0g YW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiAgDQogDQpXZSBtYXkg bW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3Vy cmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlz IGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJl bWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBh ZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3Rl cmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxk LCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== --_000_6536E263028723489CCD5B6821D4B21303E0B024UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RldJVyAmIzQzOzEgdG8gdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNhIEJ5PGJy Pg0KPGI+U2VudDo8L2I+IDIzIEZlYnJ1YXJ5IDIwMTUgMTU6NDA8YnI+DQo8Yj5Ubzo8L2I+IEFs ZXhhbmRydSBQZXRyZXNjdTxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gU3RhdHVzIG9mIENMQVQgaW1wbGVtZW50YXRpb24gb24g aVBob25lPyAoSVB2NCBhcHBzIG9uIElQdjYtb25seSBQRFAgdHlwZSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEZlYiAyMywgMjAxNSBhdCA3OjE2IEFNLCBBbGV4YW5kcnUgUGV0 cmVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMjMvMDIvMjAxNSAxNTox MSwgTG9yZW56byBDb2xpdHRpIGEgw6ljcml0IDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1vbiwgRmViIDIzLCAyMDE1IGF0IDk6MzggUE0sIEFsZXhhbmRydSBQZXRy ZXNjdTxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb208L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5hbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPC9hPiZndDsmZ3Q7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCndyb3Rl Ojxicj4NCjxicj4NCkkgYW0gYXNraW5nIGJlY2F1c2UgaW4gcHJpdmF0ZSBjb252ZXJzYXRpb24g SSBoYXZlIG5vdGljZWQgZG91YnRzPGJyPg0KYWJvdXQgdGhpcyBiZWluZyBkb25lLiZuYnNwOyBP ciwgc2luY2UgdGhlIGlQaG9uZSByZWxpZXMgb24gYSBic2Q8YnI+DQpkZXJpdmF0aXZlLCBpdCB3 b3VsZCBiZSB0ZWNobmljYWxseSBmZWFzaWJsZSB0byBpbXBsZW1lbnQgQ0xBVCBvbiBpdDs8YnI+ DQppdCBpcyBub3RoaW5nIG1vcmUgdGhhbiBzb21lIGlwdGFibGVzIGFkZHJlc3MgdHJhbnNsYXRp b24gcGx1cyBhIGJpdDxicj4NCm9mIHB5dGhvbiBzY3JpcHRpbmcgaW4gY2FzZS48YnI+DQo8YnI+ DQo8YnI+DQpUaGV5IGFyZSBhbHNvIGZyZWUgdG8gcmV1c2UgZXhpc3RpbmcgaW1wbGVtZW50YXRp b25zIG9mIGNsYXQsIHN1Y2ggYXM8YnI+DQombmJzcDt0aGUgb25lIHRoYXQgQW5kcm9pZCB1c2Vz LCB3aGljaCBpcyBCU0QtbGljZW5zZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KTWF5YmUgZW5kIHVzZXJzIHdpbGwgaW5zdGFsbCBp dCBhbmQgaXQgd2lsbCB3b3JrIG9mZi10aGUtc2hlbGYsIGp1c3Q8YnI+DQpsaWtlIGV2ZXJ5IG90 aGVyIGFwcC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpBbGV4PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIGlzIG5vdCBhIHBhdGggdG93YXJkcyBzdWNjZXNzIHNpbmNlIGl0IHJlcXVpcmVzIHRoZSB1 c2VyIHRvIGNhcmUgYWJvdXQgaG93IHRoZWlyIGNvbm5lY3Rpdml0eSBpcyBhY2hpZXZlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gaXB2 KHY0fHY2KSBkZWNpc2lvbiBpcyBvbmx5IGV2ZXIgbWFkZSBhdCBzY2FsZSBieSBkZWZhdWx0LCBh dCBzY2FsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IHNhaWQsIEFuZHJvaWQgYW5kIE1pY3Jvc29mdCBoYXZlIGFscmVhZHkgaW5jbHVk ZWQgQ0xBVCBhcyBwYXJ0IG9mIHRoZSBPUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgc3Vic3RhbnRpYWxseSBhbmQgaW1tZWRp YXRlbHkgaW1wcm92ZSBteSBJUHY2IGRlcGxveW1lbnQsIGFuZCByZXN0b3JhdGlvbiBvZiBhIHBy b3BlciBlMmUgSVB2NiBpbnRlcm5ldCwgJm5ic3A7aWYgQXBwbGUgd291bGQgcmVsZWFzZSBDTEFU IGFzIHBhcnQgb2YgdGhlaXIgT1MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJU0NMQUlNRVI8 QlI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIA0K Zm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIA0Kbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0 ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Nsb3NlIG9yIHVz ZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1vbml0b3IgYWxs IGluY29taW5nIA0KYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdp c2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byANCmVuc3VyZSB0aGF0IHRoaXMgZW1haWwg YW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyAN CnlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJz ZWx5IGFmZmVjdCB5b3UuIDwvUD4NCjxQPkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJlZCBpbiBFbmds YW5kIGFuZCBXYWxlczxCUj5Db21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAyMzgyMTYxPEJS PlJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwg SGF0ZmllbGQsIA0KSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L1A+DQo8UD4mbmJzcDs8L1A+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B21303E0B024UK30S005EXS06EE_-- From nobody Mon Feb 23 08:12:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89391A1B74 for ; Mon, 23 Feb 2015 08:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VtIB-rcOgTw for ; Mon, 23 Feb 2015 08:12:50 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8431A1AAA for ; Mon, 23 Feb 2015 08:12:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NGCkAp022525; Mon, 23 Feb 2015 17:12:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85FA8203658; Mon, 23 Feb 2015 17:13:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7760C20337E; Mon, 23 Feb 2015 17:13:57 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NGCipF006418; Mon, 23 Feb 2015 17:12:46 +0100 Message-ID: <54EB517C.1030903@gmail.com> Date: Mon, 23 Feb 2015 17:12:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ca By References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:12:51 -0000 Le 23/02/2015 16:40, Ca By a écrit : > > > On Mon, Feb 23, 2015 at 7:16 AM, Alexandru Petrescu > > > wrote: > > Le 23/02/2015 15:11, Lorenzo Colitti a écrit : > > On Mon, Feb 23, 2015 at 9:38 PM, Alexandru Petrescu > > >> > > wrote: > > I am asking because in private conversation I have noticed doubts > about this being done. Or, since the iPhone relies on a bsd > derivative, it would be technically feasible to implement CLAT on > it; it is nothing more than some iptables address translation plus a > bit of python scripting in case. > > > They are also free to reuse existing implementations of clat, such > as the one that Android uses, which is BSD-licensed. > > > Maybe end users will install it and it will work off-the-shelf, just > like every other app. > > > Alex > > > > This is not a path towards success since it requires the user to care > about how their connectivity is achieved. Well right, user should be freed from this. But there is connectivity and connectivity. VPN connectivity is an app done by Enterprise, not by the device manufacturer. > An ipv(v4|v6) decision is only ever made at scale by default, at > scale > > That said, Android and Microsoft have already included CLAT as part > of the OS. WEll, I don't know how to read this. On one hand, yes, most people do it, so this company should too, to be interoperable. On another hand, being distinct and still interoperable may tempt even more. > It would substantially and immediately improve my IPv6 deployment, > and restoration of a proper e2e IPv6 internet, if Apple would > release CLAT as part of their OS. I wonder whether this is not the main goal of this draft? If yes, it would make sense to state so upfront, and involve this particular company in the discussion. Do you know somebody from this particular company here at IETF? Alex > > CB > > _________________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > From nobody Mon Feb 23 08:21:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8071A1B81 for ; Mon, 23 Feb 2015 08:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IymIa3cduONq for ; Mon, 23 Feb 2015 08:21:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4CF1A1B79 for ; Mon, 23 Feb 2015 08:21:49 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 3D24E1B8119; Mon, 23 Feb 2015 17:21:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E37FD180089; Mon, 23 Feb 2015 17:21:46 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 17:21:46 +0100 From: To: Alexandru Petrescu , Ca By Thread-Topic: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) Thread-Index: AQHQT4OcoTcIee9FyECKmQQV6TfZRpz+aPqg Date: Mon, 23 Feb 2015 16:21:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004912B7F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> <54EB517C.1030903@gmail.com> In-Reply-To: <54EB517C.1030903@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.23.133038 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:21:50 -0000 QWxleCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQWxleGFuZHJ1DQo+IFBldHJlc2N1DQo+IEVudm95w6nC oDogbHVuZGkgMjMgZsOpdnJpZXIgMjAxNSAxNzoxMw0KPiDDgMKgOiBDYSBCeQ0KPiBDY8KgOiB2 Nm9wc0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBTdGF0dXMgb2YgQ0xBVCBpbXBs ZW1lbnRhdGlvbiBvbiBpUGhvbmU/IChJUHY0IGFwcHMgb24NCj4gSVB2Ni1vbmx5IFBEUCB0eXBl KQ0KPiANCj4gDQo+ID4gSXQgd291bGQgc3Vic3RhbnRpYWxseSBhbmQgaW1tZWRpYXRlbHkgaW1w cm92ZSBteSBJUHY2IGRlcGxveW1lbnQsDQo+ID4gYW5kIHJlc3RvcmF0aW9uIG9mIGEgcHJvcGVy IGUyZSBJUHY2IGludGVybmV0LCAgaWYgQXBwbGUgd291bGQNCj4gPiByZWxlYXNlIENMQVQgYXMg cGFydCBvZiB0aGVpciBPUy4NCj4gDQo+IEkgd29uZGVyIHdoZXRoZXIgdGhpcyBpcyBub3QgdGhl IG1haW4gZ29hbCBvZiB0aGlzIGRyYWZ0PyANCg0KW01lZF0gSSBpbmZpcm0uIFRoZSBnb2FsIG9m IHRoZSBkcmFmdCBpcyBjbGVhcmx5IGNhbGxlZCBvdXQgaW4gdGhlIEludHJvZHVjdGlvbiBzZWN0 aW9uLiANCg== From nobody Mon Feb 23 08:25:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE41A1AAA for ; Mon, 23 Feb 2015 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_gjCFK2Dvht for ; Mon, 23 Feb 2015 08:25:17 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FC61A1B87 for ; Mon, 23 Feb 2015 08:25:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NGPDIb026893 for ; Mon, 23 Feb 2015 17:25:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0A189203647 for ; Mon, 23 Feb 2015 17:26:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0265D203630 for ; Mon, 23 Feb 2015 17:26:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NGPCta007462 for ; Mon, 23 Feb 2015 17:25:13 +0100 Message-ID: <54EB5468.4060401@gmail.com> Date: Mon, 23 Feb 2015 17:25:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:25:19 -0000 Le 23/02/2015 16:57, Ca By a écrit : > > > On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson > wrote: > > On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > > I stand by my earlier questions. Do we have evidence that people > do this in production? It's not just the money - Dual-PDP is > either a 100% increase or a 50% increase in state and signaling > load over single-PDP. It also has worse fate-sharing properties > (e.g., IPv4 can fail but IPv6 can be working, and vice versa). > Is that something we want to recommend? > > I get it that if you're an operator, the ideal situation is that > you have a > knob to control every possible aspect of device behaviour, even > if you > never use it. But forget about that for a moment. Remember, this > group is > about providing *operational guidance*. Is this really something > you would > recommend operationally? If so, why? > > > My opinion is the following: > > We should recommend to run IPv4v6 whereever possible to operators, > for the reasons you provide. > > > i don't see how we, v6ops, can recommend operators deploy ipv4 > addresses that are not available. Cameron - these addresses _are_ available, they're NATted anyways. I know the IPv4 exhaustion problem, but it does not apply here: that problem is a _publicly_ routable IPv4 address problem, not a private routable address problem. One can have larger than 2^32 networks entirely on IPv4 with multiple NATs and/or traffic engineering. One would appreciate an IPv4 private address with IPv4IPv6-type rather than an IPv6-only type. > Should we include an appendix listing ipv4 brokers they can contact? YEs, it is good to have such a list in one place. Do they do this automatically or does one have to fill in forms? > Oh, and don't forget the v6ops is also publishing this > > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07 > > Quoting: > > "In the network attachment stage, PDP/PDN type IPv4v6 is the major > > concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/ > PDN type IPv4v6 in the earlier releases. That PDP/PDN type is > supported in new-built EPS network, but isn't supported well in the > third generation network." So the network should be updated to support IPv4IPv6 type. Alex > > > CB > > We should recommend device manufacturers to follow the 3GPP > standards and set up a second PDP context when it receives CC#52. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _________________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Feb 23 08:33:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE8A1A1B8B for ; Mon, 23 Feb 2015 08:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG01c-yo-2MN for ; Mon, 23 Feb 2015 08:33:40 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161971A1B79 for ; Mon, 23 Feb 2015 08:33:39 -0800 (PST) Received: by wevm14 with SMTP id m14so19743326wev.8 for ; Mon, 23 Feb 2015 08:33:37 -0800 (PST) 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=kcYSnHI1edYiUxxfhqYbKgcIJ7KS1AH7xrtjYpx6BnQ=; b=FYverBUnBuWaxL8I8D8zybqB2wdAwEooI2nuyyjGxnT/oTcvM361enJd7vMfqAVGy4 cIYRFkCspJBPGGtQ5src0s7nr2/z0JQ3Kgd6431EY+K2Whx7JOvA0RFaehbCDfWIqG6W I1gT4wSNfh8mOvtv08L4ptQlEIcK2dAD+fTmYMD446mraTIrMmivvvNa2uXGmZCxAdjg gBCsBvdv8MoNN7o0JxxdipR+Bypx0SdOvJDFtivm3RhPeWFkszQXy100xmFIYp+9IY1t WNmZeB0gOiULI8Ni4HJMKoFSwGr+GgFd+Gflr7t51b+85m8H1z8jjsCreHG5LviSiJBD Wscg== MIME-Version: 1.0 X-Received: by 10.180.92.136 with SMTP id cm8mr22434976wib.41.1424709217719; Mon, 23 Feb 2015 08:33:37 -0800 (PST) Received: by 10.194.164.2 with HTTP; Mon, 23 Feb 2015 08:33:37 -0800 (PST) In-Reply-To: <54EB5468.4060401@gmail.com> References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB5468.4060401@gmail.com> Date: Mon, 23 Feb 2015 08:33:37 -0800 Message-ID: From: Ca By To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d043bdef4d49c2b050fc3f6e0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:33:42 -0000 --f46d043bdef4d49c2b050fc3f6e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 23/02/2015 16:57, Ca By a =C3=A9crit : > >> >> >> On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson > > wrote: >> >> On Mon, 23 Feb 2015, Lorenzo Colitti wrote: >> >> I stand by my earlier questions. Do we have evidence that people >> do this in production? It's not just the money - Dual-PDP is >> either a 100% increase or a 50% increase in state and signaling >> load over single-PDP. It also has worse fate-sharing properties >> (e.g., IPv4 can fail but IPv6 can be working, and vice versa). >> Is that something we want to recommend? >> >> I get it that if you're an operator, the ideal situation is that >> you have a >> knob to control every possible aspect of device behaviour, even >> if you >> never use it. But forget about that for a moment. Remember, this >> group is >> about providing *operational guidance*. Is this really something >> you would >> recommend operationally? If so, why? >> >> >> My opinion is the following: >> >> We should recommend to run IPv4v6 whereever possible to operators, >> for the reasons you provide. >> >> >> i don't see how we, v6ops, can recommend operators deploy ipv4 >> addresses that are not available. >> > > Cameron - these addresses _are_ available, they're NATted anyways. > > I know the IPv4 exhaustion problem, but it does not apply here: that > problem is a _publicly_ routable IPv4 address problem, not a private > routable address problem. One can have larger than 2^32 networks > entirely on IPv4 with multiple NATs and/or traffic engineering. > > I don't think the IETF is willing to recommend what you have described above. > One would appreciate an IPv4 private address with IPv4IPv6-type rather > than an IPv6-only type. > > Not this "one". But, you can run your network how you like. Should we include an appendix listing ipv4 brokers they can contact? >> > > YEs, it is good to have such a list in one place. Do they do this > automatically or does one have to fill in forms? > > Oh, and don't forget the v6ops is also publishing this >> >> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07 >> >> Quoting: >> >> "In the network attachment stage, PDP/PDN type IPv4v6 is the major >> >> concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/ >> PDN type IPv4v6 in the earlier releases. That PDP/PDN type is >> supported in new-built EPS network, but isn't supported well in the >> third generation network." >> > > So the network should be updated to support IPv4IPv6 type. > > This advice you provide has not been deployed in production. CB > Alex > > >> >> CB >> >> We should recommend device manufacturers to follow the 3GPP >> standards and set up a second PDP context when it receives CC#52. >> >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > swmike@swm.pp.se> >> >> _________________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/__listinfo/v6ops >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043bdef4d49c2b050fc3f6e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu &= lt;alexan= dru.petrescu@gmail.com> wrote:
Le 23/02/2015 16:57, Ca By a =C3=A9crit :


On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson <swmike@swm.pp.se
 <mailto:swmike@swm= .pp.se>> wrote:

=C2=A0 =C2=A0 On Mon, 23 Feb 2015, Lorenzo Colitti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I stand by my earlier questions. Do we have evi= dence that people
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do this in production? It's not just the mo= ney - Dual-PDP is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 either a 100% increase or a 50% increase in sta= te and signaling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 load over single-PDP. It also has worse fate-sh= aring properties
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., IPv4 can fail but IPv6 can be working, a= nd vice versa).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is that something we want to recommend?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I get it that if you're an operator, the id= eal situation is that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 knob to control every possible aspect of device= behaviour, even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 never use it. But forget about that for a momen= t. Remember, this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 about providing *operational guidance*. Is this= really something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 recommend operationally? If so, why?


=C2=A0 =C2=A0 My opinion is the following:

=C2=A0 =C2=A0 We should recommend to run IPv4v6 whereever possible to opera= tors,
=C2=A0 =C2=A0 for the reasons you provide.


i don't see how we, v6ops,=C2=A0 can recommend operators deploy ipv4 addresses that are not available.

Cameron - these addresses _are_ available, they're NATted anyways.

I know the IPv4 exhaustion problem, but it does not apply here: that
problem is a _publicly_ routable IPv4 address problem, not a private
routable address problem. One can have larger than 2^32 networks
entirely on IPv4 with multiple NATs and/or traffic engineering.


I don't think the IETF is willing = to recommend what you have described above.
=C2=A0
One would appreciate an IPv4 private address with IPv4IPv6-type rather
than an IPv6-only type.



Not this "o= ne".=C2=A0 But, you can run your network how you like.

<= br>

Should we include an appendix listing ipv4 brokers they can contact?

 YEs, it is good to have such a list in one place. Do they do this
automatically or does one have to fill in forms?

Oh, and don't forget the v6ops is also publishing this

https://tools.ietf.org/html/draft-ietf-v6op= s-ipv6-roaming-analysis-07

Quoting:

"In the network attachment stage, PDP/PDN type IPv4v6 is the major

=C2=A0 =C2=A0 concern to the visited pre-Release 9 SGSN. 3GPP didn't sp= ecify PDP/
=C2=A0 =C2=A0 PDN type IPv4v6 in the earlier releases.=C2=A0 That PDP/PDN t= ype is
=C2=A0 =C2=A0 supported in new-built EPS network, but isn't supported w= ell in the
=C2=A0 =C2=A0 third generation network."

 So the network should be updated to support IPv4IPv6 type.


This advice you provide has not been d= eployed in production.

CB=C2=A0
Alex



CB

=C2=A0 =C2=A0 We should recommend device manufacturers to follow the 3GPP =C2=A0 =C2=A0 standards and set up a second PDP context when it receives CC= #52.


=C2=A0 =C2=A0 --
 =C2=A0 =C2=A0 Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se <mailto:swmike@swm.pp.se>

=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org <mailto:v6= ops@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/v6ops
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/v6ops>=




_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d043bdef4d49c2b050fc3f6e0-- From nobody Mon Feb 23 08:45:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFC21A1B92 for ; Mon, 23 Feb 2015 08:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJI1GyDRAIWx for ; Mon, 23 Feb 2015 08:45:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DC31A1B6E for ; Mon, 23 Feb 2015 08:45:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NGjeBX009715; Mon, 23 Feb 2015 17:45:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6FECD2036D0; Mon, 23 Feb 2015 17:46:51 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 62F992036CB; Mon, 23 Feb 2015 17:46:51 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NGjcrR003928; Mon, 23 Feb 2015 17:45:40 +0100 Message-ID: <54EB5932.70807@gmail.com> Date: Mon, 23 Feb 2015 17:45:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ca By References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB5468.4060401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:45:50 -0000 Le 23/02/2015 17:33, Ca By a écrit : > > > On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu > > wrote: > > Le 23/02/2015 16:57, Ca By a écrit : > > > > On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson > > >> wrote: > > On Mon, 23 Feb 2015, Lorenzo Colitti wrote: > > I stand by my earlier questions. Do we have evidence > that people > do this in production? It's not just the money - > Dual-PDP is > either a 100% increase or a 50% increase in state and > signaling > load over single-PDP. It also has worse fate-sharing > properties > (e.g., IPv4 can fail but IPv6 can be working, and vice > versa). > Is that something we want to recommend? > > I get it that if you're an operator, the ideal > situation is that > you have a > knob to control every possible aspect of device > behaviour, even > if you > never use it. But forget about that for a moment. > Remember, this > group is > about providing *operational guidance*. Is this really > something > you would > recommend operationally? If so, why? > > > My opinion is the following: > > We should recommend to run IPv4v6 whereever possible to > operators, > for the reasons you provide. > > > i don't see how we, v6ops, can recommend operators deploy ipv4 > addresses that are not available. > > > Cameron - these addresses _are_ available, they're NATted anyways. > > I know the IPv4 exhaustion problem, but it does not apply here: that > problem is a _publicly_ routable IPv4 address problem, not a private > routable address problem. One can have larger than 2^32 networks > entirely on IPv4 with multiple NATs and/or traffic engineering. > > > I don't think the IETF is willing to recommend what you have described > above. I dont think IETF wants to recommend many things, I agree. I dont think anybody says IPv4 does not exist either. And I dont think anybody will refuse an offer of a publicly routable IPv6 address and an IPv4 address be it private. I sense the lack of IPv4 address (even a private one) as lack of connectivity. > One would appreciate an IPv4 private address with IPv4IPv6-type rather > than an IPv6-only type. > > > > Not this "one". But, you can run your network how you like. :-) ok You seem to favor IPv6-only PDP type, right? You do agree that CLAT has some problems, including with IPv4-only devices behind a tethering smartphone, no? > > Should we include an appendix listing ipv4 brokers they can contact? > > > YEs, it is good to have such a list in one place. Do they do this > automatically or does one have to fill in forms? > > Oh, and don't forget the v6ops is also publishing this > > https://tools.ietf.org/html/__draft-ietf-v6ops-ipv6-roaming-__analysis-07 > > > Quoting: > > "In the network attachment stage, PDP/PDN type IPv4v6 is the major > > concern to the visited pre-Release 9 SGSN. 3GPP didn't > specify PDP/ > PDN type IPv4v6 in the earlier releases. That PDP/PDN type is > supported in new-built EPS network, but isn't supported > well in the > third generation network." > > > So the network should be updated to support IPv4IPv6 type. > > > This advice you provide has not been deployed in production. In some places many things can be tried prior to converging. That's an enviable situation. In other places there is less chance to try many things, one should be best at the first trial. Alex > > CB > > Alex > > > > CB > > We should recommend device manufacturers to follow the 3GPP > standards and set up a second PDP context when it receives > CC#52. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > > > ___________________________________________________ > v6ops mailing list > v6ops@ietf.org > > https://www.ietf.org/mailman/____listinfo/v6ops > > > > > > > > _________________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > > > _________________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/__listinfo/v6ops > > > From nobody Mon Feb 23 08:51:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4AB1A1BEA for ; Mon, 23 Feb 2015 08:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-ELPSlkHQrq for ; Mon, 23 Feb 2015 08:51:14 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6D81A1BED for ; Mon, 23 Feb 2015 08:51:00 -0800 (PST) Received: from [2a02:fe0:c411:9e40:b6b6:76ff:fe17:2e83] (port=33319 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YPwDj-0006if-2D; Mon, 23 Feb 2015 17:50:59 +0100 Date: Mon, 23 Feb 2015 17:50:58 +0100 From: Tore Anderson To: Ca By Message-ID: <20150223175058.42be90e0@envy.fud.no> In-Reply-To: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB5468.4060401@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:51:15 -0000 * Ca By > On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > > > So the network should be updated to support IPv4IPv6 type. > > > This advice you provide has not been deployed in production. Telenor Norway and Tele2 Sweden both have APNs that support IPv4v6 in production, AFAIK. Telenor defaults to this for new handsets. Tore From nobody Mon Feb 23 10:09:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFC61A1B7F for ; Mon, 23 Feb 2015 10:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFjgdSfSuXaM for ; Mon, 23 Feb 2015 10:09:32 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C66F1A1B4B for ; Mon, 23 Feb 2015 10:09:31 -0800 (PST) Received: from [2a02:fe0:c411:9e40:b6b6:76ff:fe17:2e83] (port=33378 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YPxRh-00009k-3w; Mon, 23 Feb 2015 19:09:29 +0100 Date: Mon, 23 Feb 2015 19:09:28 +0100 From: Tore Anderson To: Ca By Message-ID: <20150223190928.23340db8@envy.fud.no> In-Reply-To: References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:09:34 -0000 * Ca By > On Mon, Feb 23, 2015 at 7:16 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: >=20 > > Le 23/02/2015 15:11, Lorenzo Colitti a =C3=A9crit : > > > >> They are also free to reuse existing implementations of clat, such as > >> the one that Android uses, which is BSD-licensed. > > > > Maybe end users will install it and it will work off-the-shelf, just > > like every other app. >=20 > This is not a path towards success since it requires the user to care > about how their connectivity is achieved. Assuming it's possible to write such an app for iOs in the first place, couldn't you pre-load it on the handsets you sell and have it start up automatically? If so, the user wouldn't be required to care. As I understand it, it's common carrier practise to pre-load the handsets with other kinds of "value add" apps anyway, right? For example: Orange Poland's 464XLAT deployment. As I understand it, they are *not* using DNS64, so I guess that necessarily means they pre-configure the handsets' CLAT with their NAT64/PLAT prefix before shipping them the customers. So if doing such custom modifications is doable, pre-loading a CLAT app doesn't seem impossible either. It wouldn't work for for retail handsets of course, but I understand that in the US the majority of people buy their handsets from their carriers rather than from retail stores anyway, so perhaps it's okay that those relatively few customers that bring retail iPhones onto your network either 1) get IPv4-only for now, or 2) will be asked to install the (presumably free) CLAT app if they want Skype to work. > It would substantially and immediately improve my IPv6 deployment, and > restoration of a proper e2e IPv6 internet, if Apple would release CLAT as > part of their OS. For the record, I'm not disagreeing that having it in iOS proper would be the optimal solution. It just seems to me there's another viable way forward that does not depend on Apple being the ones to implement the CLAT. But I'm probably missing something? Tore From nobody Mon Feb 23 10:20:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB71A1F1D for ; Mon, 23 Feb 2015 10:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp94UvPzlVy1 for ; Mon, 23 Feb 2015 10:20:29 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1544F1A1EF6 for ; Mon, 23 Feb 2015 10:20:07 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F2385602FF for ; Mon, 23 Feb 2015 19:20:05 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C6F056025D for ; Mon, 23 Feb 2015 19:20:05 +0100 (CET) Received: (qmail 97611 invoked by uid 1007); 23 Feb 2015 19:20:05 +0100 Date: Mon, 23 Feb 2015 19:20:05 +0100 From: Gert Doering To: Tore Anderson Message-ID: <20150223182005.GO34798@Space.Net> References: <54EB1F2F.4000604@gmail.com> <54EB443B.4080802@gmail.com> <20150223190928.23340db8@envy.fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150223190928.23340db8@envy.fud.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:20:39 -0000 Hi, On Mon, Feb 23, 2015 at 07:09:28PM +0100, Tore Anderson wrote: > > [CLAT as an app] > > Assuming it's possible to write such an app for iOs in the first place, > couldn't you pre-load it on the handsets you sell and have it start up > automatically? If so, the user wouldn't be required to care. As I > understand it, it's common carrier practise to pre-load the handsets > with other kinds of "value add" apps anyway, right? >From what I understand, it would be possible to write such an app, using the VPN API. The problem with that API is that you need NDA'ed documentation from Apple, and the resulting app needs to be specially signed by Apple to be permitted to access it (which makes sense, given that such an app is effectively able to steal other app's traffic) - so you need fairly deep involvement from Apple, and if they are interested enough to do that, they could write the CLAT themselves right away... Auto-starting a VPN app is also possible (VPN on demand), but I'm not sure this can be tied to "only on 3G, and only if no IPv4 is there", so that aspect could be a bit tricky. [..] > For the record, I'm not disagreeing that having it in iOS proper would > be the optimal solution. It just seems to me there's another viable way > forward that does not depend on Apple being the ones to implement the > CLAT. But I'm probably missing something? Access restrictions to the VPN API... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 23 12:39:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5B31A6F04 for ; Mon, 23 Feb 2015 12:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtWW0CJWT05D for ; Mon, 23 Feb 2015 12:38:59 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C36B1A6F17 for ; Mon, 23 Feb 2015 12:38:59 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so39146990obc.1 for ; Mon, 23 Feb 2015 12:38:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hMqZ9LOyHWm6hkDclPx1zRU3EeG8KXiR6gpgnpZZeE8=; b=BJFALgblXXI/c2uWPN/KK6ng1/0E5JL2LxjaHMFDnAeIKcSthDiZ80i+3m3eN9U+By uWleUOXz+kiucmukVccbwO+GxuNgo1m7XiaX7sM5AKdzR+SLB4e/2OVNeGsQlNlxeYcI FKd/Av+vHKelHCvZKlc5HFPl9IncU2MbxIfvel2beuRifuD1S0Ffq2AdCOL0R3rAv6dQ yzNX7fTbL01ZHrFlwMcV/eVRaJ7sa5SHlJ0qCgPkx3JbGbEEUHc4n9y/vI9LIiDjupt6 Zw6nNZgemT+kvHbfbRoviGlxxXWprIoM1PvSCr9BQ9TM02O8JBGrCJpFhiypuK6rpn8F oyww== X-Gm-Message-State: ALoCoQkq/xz64jySnEMFlEsTKgymYZtbk5/GftlnDM0RMLa1RyldDTyxW1ta7SOSOMCszXpUlyAM MIME-Version: 1.0 X-Received: by 10.202.95.2 with SMTP id t2mr8381340oib.104.1424723938851; Mon, 23 Feb 2015 12:38:58 -0800 (PST) Received: by 10.76.150.2 with HTTP; Mon, 23 Feb 2015 12:38:58 -0800 (PST) In-Reply-To: <54EB1F2F.4000604@gmail.com> References: <54EB1F2F.4000604@gmail.com> Date: Mon, 23 Feb 2015 12:38:58 -0800 Message-ID: From: James Woodyatt To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a113cdcce475b0d050fc764e3 Archived-At: Subject: Re: [v6ops] Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:39:02 -0000 --001a113cdcce475b0d050fc764e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable p1. I have no inside information from Apple's Core OS Networking group newer than seventeen months ago when I separated. I'm not at liberty to discuss confidential stuff even today. That said, I can dispel some myths. p2. The security architecture for networking on iOS will effectively prevent any third-party efforts from delivering a CLAT for iOS. Andrew Yourtchenko wrote one for OS X, but it will be necessary for Apple Core OS engineers to deliver it on iOS. Anyone who wants to review the source code for the Darwin kernel in publicsource.apple.com should be able to get a sense of the scope of this problem. p3. The Android implementation may be Apache-licensed, but=E2=80=94 like Mr= . Yourtchenko's implementation=E2=80=94 it's unsuitable for general productio= n use with Apple's networking stack, which has diverged substantially from FreeBSD in the last several years. The Darwin kernel networking stack in iOS and OS X has interface scoped routes, which the Core Networking and Core Telephony subsystems use extensively. The IPv4 addresses assigned to the host via the CLAT must be attached to the same interface as the translated IPv6 address or the interface scoped routing won't work properly. Again, see the Darwin kernel source code for details. p4. It might be comparatively easy for Apple to deliver a very limited CLAT, using one of several Darwin-specific tricks, e.g. a socket filter, that only works to enable certain 3rd-party applications, e.g. Skype, on IPv6-only LTE networks with a PLAT service available, but that will also have some interoperability issues that make it unsuitable for general reliability. I hope they don't go that way, but I don't work there anymore, and I don't think anyone there would listen to me anyway, if that's what they were to decide to do. I can kinda see why they might choose to do this= . For these reasons, I would counsel any operators expecting Apple to deliver a CLAT in a forthcoming release of iOS to test it extensively before accepting it. Especially: A) test it with Internet Sharing enabled, B) test it with VPN connect-on-demand, and C) test it with AirDrop and AirPlay in use. Whatever method they choose to implement a CLAT, it will be a tricky job, and I would be surprised if it doesn't take a lot of Radar problems to be opened and closed before it works acceptably. Shorter james: I don't think IETF should list having a CLAT as requirement for 3GPP mobile devices. It could be awkward for us while the leading vendor of IPv6-capable handsets is shipping without one. On Mon, Feb 23, 2015 at 4:38 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hello participants to v6ops WG, > > What is the status of a CLAT implementation on iPhone? Any hint in that > direction? > > I am asking because in private conversation I have noticed doubts about > this being done. Or, since the iPhone relies on a bsd derivative, > it would be technically feasible to implement CLAT on it; it is nothing > more than some iptables address translation plus a bit of python > scripting in case. > > (CLAT is needed by some IPv4 apps to continue working on a smartphone > connected solely with an IPv6-only PDP type). > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 james woodyatt Nest Labs, Communications Engineering --001a113cdcce475b0d050fc764e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
p1. I have no inside information from Apple's Core OS = Networking group newer than seventeen months ago when I separated. I'm = not at liberty to discuss confidential stuff even today. That said, I can d= ispel some myths.

p2. The security architecture for netw= orking on iOS will effectively prevent any third-party efforts from deliver= ing a CLAT for iOS. Andrew Yourtchenko wrote one for OS X, but it will be n= ecessary for Apple Core OS engineers to deliver it on iOS. Anyone who wants= to review the source code for the Darwin kernel in publicsource.apple.com should be able to get a sense= of the scope of this problem.

p3. The Android imp= lementation may be Apache-licensed, but=E2=80=94 like Mr. Yourtchenko's= implementation=E2=80=94 it's unsuitable for general production use wit= h Apple's networking stack, which has diverged substantially from FreeB= SD in the last several years. The Darwin kernel networking stack in iOS and= OS X has interface scoped routes, which the Core Networking and Core Telep= hony subsystems use extensively. The IPv4 addresses assigned to the host vi= a the CLAT must be attached to the same interface as the translated IPv6 ad= dress or the interface scoped routing won't work properly. Again, see t= he Darwin kernel source code for details.

p4. It m= ight be comparatively easy for Apple to deliver a very limited CLAT, using = one of several Darwin-specific tricks, e.g. a socket filter, that only work= s to enable certain 3rd-party applications, e.g. Skype, on IPv6-only LTE ne= tworks with a PLAT service available, but that will also have some interope= rability issues that make it unsuitable for general reliability. I hope the= y don't go that way, but I don't work there anymore, and I don'= t think anyone there would listen to me anyway, if that's what they wer= e to decide to do. I can kinda see why they might choose to do this.
<= div>
For these reasons, I would counsel any operators expecti= ng Apple to deliver a CLAT in a forthcoming release of iOS to test it exten= sively before accepting it. Especially: A) test it with Internet Sharing en= abled, B) test it with VPN connect-on-demand, and C) test it with AirDrop a= nd AirPlay in use. Whatever method they choose to implement a CLAT, it will= be a tricky job, and I would be surprised if it doesn't take a lot of = Radar problems to be opened and closed before it works acceptably.

Shorter james: I don't think IETF should list having a= CLAT as requirement for 3GPP mobile devices. It could be awkward for us wh= ile the leading vendor of IPv6-capable handsets is shipping without one.


On Mon, Feb 23, 2015 at 4:38 AM, Alexandru Petrescu <ale= xandru.petrescu@gmail.com> wrote:
Hello participants to v6ops WG,

What is the status of a CLAT implementation on iPhone?=C2=A0 Any hint in th= at
direction?

I am asking because in private conversation I have noticed doubts about
this being done.=C2=A0 Or, since the iPhone relies on a bsd derivative,
it would be technically feasible to implement CLAT on it; it is nothing
more than some iptables address translation plus a bit of python
scripting in case.

(CLAT is needed by some IPv4 apps to continue working on a smartphone
=C2=A0connected solely with an IPv6-only PDP type).

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--
james woodyatt <jhw@nestlabs.com>
Nest Labs,= Communications Engineering
--001a113cdcce475b0d050fc764e3-- From nobody Mon Feb 23 16:49:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6581A1B4A for ; Mon, 23 Feb 2015 16:49:11 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbBypt8Sl26p for ; Mon, 23 Feb 2015 16:49:08 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809621A1A79 for ; Mon, 23 Feb 2015 16:49:08 -0800 (PST) Received: by padhz1 with SMTP id hz1so31620622pad.9 for ; Mon, 23 Feb 2015 16:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gGlTsmejU9Y5ZhC9NfQdiZ/T493Rvbvg+OtKp1TwzZA=; b=HjUEdNxGYLQEq9WbpI9tF60mgVGh1Rof+fnF91AbTB2l0EQMv4NtFT78AFNtjRhNKP ntthAUzG3ETBMmw0NOaP9hFs3jWvZnpio6FRK6j43j8lrKbQUkUGbKRA2fQEanHXr73K 9LyMTV78zV1PpGnA7w9AozxOnaj+QtaiVWuMyh3uQ5CRSRZL+k8ldki1VuIRZYzgBr/i gtc5rTgVsBK7IkOy1mTyl2PTIH0vCjLaQtSK7t4exoN5QNinoM0Ftul0LOX8LjHYQWAv DLp7kkI/C4AfDCby/aXh/LoSEcge76DnYuIn9KF9J3dg3+n49iN+lP34tN7kKS2D0gEn L4Rw== X-Received: by 10.66.217.230 with SMTP id pb6mr24419113pac.2.1424738947741; Mon, 23 Feb 2015 16:49:07 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id ek12sm29842725pdb.92.2015.02.23.16.49.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 16:49:06 -0800 (PST) Message-ID: <54EBCA81.30301@gmail.com> Date: Tue, 24 Feb 2015 13:49:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <8C48B86A895913448548E6D15DA7553B0612B394@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B0612B394@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inviting discussion: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 00:49:11 -0000 On 20/02/2015 09:54, Fred Baker (fred) wrote: > https://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes > "Considerations for Running Multiple IPv6 Prefixes", Bing Liu, Sheng > Jiang, Yang Bo, 2014-10-11, > > This draft was prepared for IETF 91, but didn't get discussed in part because a number of Chinese participants didn't make it to Honolulu for a Monday meeting. Is there interest in discussing it at IETF 92? I think we should discuss whether the WG wants to publish a background document on this topic. This is one of the aspects of v6 that seems to be quite unexpected by current operators of site networks. Educating them seems desirable. The only thing is, this really is only a background document, not a "how to" guide - and it cites 7 I-Ds, which isn't ideal for an informational document. Will it help those operators, or will they throw it on the "too hard" heap? So, if we give it agenda time, I suggest we discuss the purpose of the document, not its details. Brian From nobody Mon Feb 23 23:10:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8B1A86EB for ; Mon, 23 Feb 2015 23:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV-EhFxBkCVt for ; Mon, 23 Feb 2015 23:10:37 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4AA1A86E8 for ; Mon, 23 Feb 2015 23:10:37 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3D9DAA3; Tue, 24 Feb 2015 08:10:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424761824; bh=e3POobIsSlWw/ZWy96jyRVne8NvTfkYTrozkAArK5xY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HcX/qGLpgVtg6GcKSZqcp6hIBQamJfelXr9zMYwv+Ka6/PCST/Umml2v37MpPrhBu SqxR8HgEtXKAaMZiCOk/WVTO4xteWVGkMlVbHvRvsTKDf2DdNaxWtF+fMEiU6lKmvD uDxNuuQaXigfnBW9KOORlTsoMZKSMyO0Rm+PJ9zE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 39E5FA2; Tue, 24 Feb 2015 08:10:24 +0100 (CET) Date: Tue, 24 Feb 2015 08:10:24 +0100 (CET) From: Mikael Abrahamsson To: Tore Anderson In-Reply-To: <20150223175058.42be90e0@envy.fud.no> Message-ID: References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EB5468.4060401@gmail.com> <20150223175058.42be90e0@envy.fud.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:10:39 -0000 On Mon, 23 Feb 2015, Tore Anderson wrote: > * Ca By > >> On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com> wrote: >> >>> So the network should be updated to support IPv4IPv6 type. >>> >> This advice you provide has not been deployed in production. > > Telenor Norway and Tele2 Sweden both have APNs that support IPv4v6 in > production, AFAIK. Telenor defaults to this for new handsets. I can confirm that there is to my direct knowledge at least one network in the world with millions of customers, that supports IPv4v6 PDP context and proper handover of this between 2G/3G/4G, and this is also supported by devices from at least 3 different UE manufacturers. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 23:14:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8FC1A86EE; Mon, 23 Feb 2015 23:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joGSrnjuQJA5; Mon, 23 Feb 2015 23:14:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C71A86F2; Mon, 23 Feb 2015 23:14:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224071453.10413.98575.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 23:14:53 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:14:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Dave Michaud Diego R. Lopez Filename : draft-ietf-v6ops-mobile-device-profile-19.txt Pages : 19 Date : 2015-02-23 Abstract: This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network) with a special focus on IPv4 service continuity features. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 23 23:18:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA741A86F4 for ; Mon, 23 Feb 2015 23:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjwld1fzGX2c for ; Mon, 23 Feb 2015 23:18:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B544B1A86E8 for ; Mon, 23 Feb 2015 23:18:05 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id C04B11B820B; Tue, 24 Feb 2015 08:18:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 9A0B015823B; Tue, 24 Feb 2015 08:18:03 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 08:18:03 +0100 From: To: Mikael Abrahamsson Thread-Topic: Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) Thread-Index: AdBQAgS9g1BPPzc4Sui0AP3R2MhF+g== Date: Tue, 24 Feb 2015 07:18:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004912FDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.24.43033 Archived-At: Cc: "v6ops@ietf.org" Subject: [v6ops] Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:18:08 -0000 Hi Mickael,=20 This new version integrates your comments (http://www.ietf.org/mail-archive= /web/v6ops/current/msg21487.html).=20 Please double check it and let me know if it OK with you. Thank you. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 24 f=E9vrier 2015 08:15 > =C0=A0: i-d-announce@ietf.org > Cc=A0: v6ops@ietf.org > Objet=A0: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : An Internet Protocol Version 6 (IPv6) Profile > for 3GPP Mobile Devices > Authors : David Binet > Mohamed Boucadair > Ales Vizdal > Gang Chen > Nick Heatley > Ross Chandler > Dave Michaud > Diego R. Lopez > Filename : draft-ietf-v6ops-mobile-device-profile-19.txt > Pages : 19 > Date : 2015-02-23 >=20 > Abstract: > This document defines a profile that is a superset of that of the > connection to IPv6 cellular networks defined in the IPv6 for Third > Generation Partnership Project (3GPP) Cellular Hosts document. This > document defines an IPv6 profile that a number of operators recommend > in order to connect 3GPP mobile devices to an IPv6-only or dual-stack > wireless network (including 3GPP cellular network) with a special > focus on IPv4 service continuity features. >=20 > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-19 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile= -19 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 23 23:24:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8241A86EE for ; Mon, 23 Feb 2015 23:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8uIMZrkoypr for ; Mon, 23 Feb 2015 23:24:42 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED2E1A86E8 for ; Mon, 23 Feb 2015 23:24:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 77A92A3; Tue, 24 Feb 2015 08:24:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424762680; bh=TJRhGPmNL088pIi9CI6A6hy4Tv+6uTnbG3f3lZJ1SbQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=L/wU6tcrOhIJtN3ehwAmyXYSAtb0DE/ftKMCxJCT0oo7cpRqmQQyvuHCPFBsRABK2 fIuwdsOIOZB76Wt3FSib0xuPXVAdN3i33RArSp/K/BtRs7+5FoTUwcBsXudbgqGsJN ayolRL/IyGAxej3so+xtMFQ9dYRGCmoMHG2fNCtI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 700B5A2; Tue, 24 Feb 2015 08:24:40 +0100 (CET) Date: Tue, 24 Feb 2015 08:24:40 +0100 (CET) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <787AE7BB302AE849A7480A190F8B933004912FDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> Message-ID: References: <787AE7BB302AE849A7480A190F8B933004912FDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:24:43 -0000 On Tue, 24 Feb 2015, mohamed.boucadair@orange.com wrote: > Hi Mickael, > > This new version integrates your comments (http://www.ietf.org/mail-archive/web/v6ops/current/msg21487.html). > > Please double check it and let me know if it OK with you. Hi, I am reading the diff between -18 and -19. You've changed the terminology to include 802.11. I believe it's unwise to go down this path, because I know of devices with 3GPP baseband that can connect to bluetooth, to wired ethernet, I can probably dig up 802.15.4 as well. I would recommend to make this more generalized. page 4 line 48 "Moreover, this profile covers cellular CPEs" I would add an "also" in there, for instance "... this profile also convers...." Apart from that, the new text shown in the -18 to -19 diff looks fine to me. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 23:33:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B571A8707 for ; Mon, 23 Feb 2015 23:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyfAIkp6N0z4 for ; Mon, 23 Feb 2015 23:33:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8C41A86E8 for ; Mon, 23 Feb 2015 23:33:13 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 61B631903D0; Tue, 24 Feb 2015 08:33:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 33A8C15815A; Tue, 24 Feb 2015 08:33:11 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 08:33:11 +0100 From: To: Mikael Abrahamsson Thread-Topic: Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) Thread-Index: AQHQUAL0sj6VOAtU6EC4IVPF03zA3Jz/Zm7g Date: Tue, 24 Feb 2015 07:33:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004913056@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933004912FDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.24.63919 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:33:15 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Envoy=E9=A0: mardi 24 f=E9vrier 2015 08:25 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: v6ops@ietf.org > Objet=A0: Re: Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops- > mobile-device-profile-19.txt) >=20 > On Tue, 24 Feb 2015, mohamed.boucadair@orange.com wrote: >=20 > > Hi Mickael, > > > > This new version integrates your comments (http://www.ietf.org/mail- > archive/web/v6ops/current/msg21487.html). > > > > Please double check it and let me know if it OK with you. >=20 > Hi, >=20 > I am reading the diff between -18 and -19. You've changed the terminology > to include 802.11. I believe it's unwise to go down this path, because I > know of devices with 3GPP baseband that can connect to bluetooth, to wire= d > ethernet, I can probably dig up 802.15.4 as well. I would recommend to > make this more generalized. [Med] The definition does not include 802.11. Below the text as it appears = in the new version: o "3GPP cellular host" (or cellular host for short) denotes a 3GPP device which can be connected to 3GPP mobile networks. o "3GPP cellular device" (or cellular device for short) refers to a cellular host which supports the capability to share its WAN (Wide Area Network) connectivity. >=20 > page 4 line 48 >=20 > "Moreover, this profile covers cellular CPEs" >=20 > I would add an "also" in there, for instance "... this profile also > convers...." [Med] Works for me. >=20 > Apart from that, the new text shown in the -18 to -19 diff looks fine to > me. >=20 [Med] Cool! Thank you. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 23 23:37:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45841A8709 for ; Mon, 23 Feb 2015 23:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwHuAJoGCMVB for ; Mon, 23 Feb 2015 23:37:36 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70081A8707 for ; Mon, 23 Feb 2015 23:37:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 003C4A3; Tue, 24 Feb 2015 08:37:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1424763440; bh=f62n0PkKl3CoMXcUGm6/sWUuqdzlesDbxk5dyAeN8Xw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=v4CLMCfmrluHplIbfSPlyCa/JJ4NDWJ5xbO5wErot9howL+3dssPtUeEPKmWyGuf1 21+g+HNcFB8Qornm4sTRQP6ZJXYPh/tMkU7rjYVQK4A/JdfaMsGi/Zj4mAr8O/WMKM 9LpVDYwA4COF2/zp3POkUNMl7MWuLdCMc5I72MXM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ED031A2; Tue, 24 Feb 2015 08:37:19 +0100 (CET) Date: Tue, 24 Feb 2015 08:37:19 +0100 (CET) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <787AE7BB302AE849A7480A190F8B933004913056@OPEXCLILM23.corporate.adroot.infra.ftgroup> Message-ID: References: <787AE7BB302AE849A7480A190F8B933004912FDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933004913056@OPEXCLILM23.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 07:37:36 -0000 On Tue, 24 Feb 2015, mohamed.boucadair@orange.com wrote: > [Med] The definition does not include 802.11. Below the text as it appears in the new version: > > o "3GPP cellular host" (or cellular host for short) denotes a 3GPP > device which can be connected to 3GPP mobile networks. > > o "3GPP cellular device" (or cellular device for short) refers to a > cellular host which supports the capability to share its WAN (Wide > Area Network) connectivity. Hi, my bad, I read the diff backwards, you had removed (not added as I first thought) the 802.11 reference from -19, which is what I wanted as well. So all is good! -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 27 05:21:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5241D1A0167 for ; Fri, 27 Feb 2015 05:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piqT5Awzakld for ; Fri, 27 Feb 2015 05:21:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C051A1ADC for ; Fri, 27 Feb 2015 05:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2826; q=dns/txt; s=iport; t=1425043301; x=1426252901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cZ4EKv1bKDVfDcg9LyAoP8B7cLVPxQHm9X6NiTE+tn0=; b=DPsx2eRQPmFDJhFgOrmrNjuO+X3Xg7RqNKZrIQkf8wCkWMp3kwDenEth nyaggeNLuPsSWpL02rVvbG6W+mUF7et9QgNPhu+QJyeaP7qMuvLlOlbnx Y+oF/2ACewgn1YgWJDUb0bfdvCR+PJVqQJvweahUTAP6H5Im6dPCEBONq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQBQDjbfBU/49dJa1bgwJSWgSDBr8ECoVwAhyBA00BAQEBAQF8hA8BAQEEAQEBIBE3AwsMBAIBCBEEAQEDAiYCAgIlCxUICAIEAQ0FiBsDEQ28apoQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGCRIIPGwcGgmKBQwWEMTUKiwSDYINsOYFBgRs5gmWJD4JLgz4jg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,659,1418083200"; d="scan'208";a="399712062" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2015 13:21:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1RDLeis031349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Feb 2015 13:21:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 07:21:39 -0600 From: "Eric Vyncke (evyncke)" To: Mark ZZZ Smith , "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie Thread-Index: AQHQRfjbocoNklbsR0a/YDkpY0h88pzsutuAgBhO9AA= Date: Fri, 27 Feb 2015 13:21:39 +0000 Message-ID: References: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com> <488920676.3641546.1423710481890.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <488920676.3641546.1423710481890.JavaMail.yahoo@mail.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.68] Content-Type: text/plain; charset="utf-8" Content-ID: <785A8D981BEC2D469285839C456FC9C9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 13:21:44 -0000 TWFyaywgRGFuIGFuZCBSYXkNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBCVFcs IHRoaXMgaXMga2luZCBvZiBhbiAnb2xkJyBkcmFmdA0KcHJlc2VudGVkIGluIEhvbm9sdWx1Lg0K DQpCcmFpbiBDYXJwZW50ZXIgYnJvdWdodCBteSBhdHRlbnRpb24gdG8gc2VjdGlvbiA4LjIgb2Yg UkZDIDY4ODMgIklQdjYNCkd1aWRhbmNlIGZvciBJbnRlcm5ldCBDb250ZW50IFByb3ZpZGVycyIg d2hpY2ggc3VtbWFyaXplcyB0aGUgc2FtZSBpc3N1ZQ0KaW4gb25lIHNpbmdsZSBwYXJhZ3JhcGgu IFNvLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBzcGVjaWZpYyBJLUQNCnNob3VsZCBjb250 aW51ZT8gT24gb25lIHNpZGUsIGl0IGlzIHJlcGV0aXRpb24gYnV0IG9uIHRoZSBvdGhlciBpdCBt YWtlcw0KdGhpcyBpc3N1ZSBnbGFyaW5nIGFuZCBtdWNoIG1vcmUgdmlzaWJsZS4NCg0KQW55d2F5 LCBJIGFtIHVwZGF0aW5nIGl0IHdpdGggeW91ciBjb21tZW50cyAoYW5kIG90aGVycykgdGhlbiB1 cGxvYWQgaXQuDQoNClJlZ2FyZHMgYW5kIHRoYW5rcw0KDQotw6lyaWMNCg0KT24gMTIvMDIvMTUg MDQ6MDgsICJNYXJrIFpaWiBTbWl0aCIgPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+IHdyb3Rl Og0KDQo+SSB0aGluayB0aGlzIGlzIGEgZ29vZCBkcmFmdCwgYW5kIEkgYWdyZWUgd2l0aCB3aGF0 IGl0IHNheXMsIGhvd2V2ZXIgSQ0KPnRoaW5rIHBlcmhhcHMgaXQgcmVhbGx5IGJlbG9uZ3MgaW4g dGhlIGh0dHBiaXMgd29ya2luZyBncm91cCwgYXMgdGhleSdyZQ0KPnRoZSBIVFRQIGV4cGVydHM/ DQo+DQo+VGhlIG9ubHkgb3RoZXIgdGhvdWdodCBJJ3ZlIGhhZCBpcyB0aGF0IGl0IG1pZ2h0IGJl IHdvcnRoIGRvY3VtZW50aW5nDQo+dGhhdCBNUFRDUCBzaG91bGRuJ3Qgc3VmZmVyIGZyb20gdGhp cyBwcm9ibGVtIGFzIGlmIGFuIGFwcGxpY2F0aW9uIGNhcmVzDQo+YWJvdXQgSVAgYWRkcmVzc2Vz LCB0aGVuIG9ubHkgdGhlIGZpcnN0IHN1YmZsb3cncyBJUCBhZGRyZXNzZXMgYXJlDQo+ZXhwb3Nl ZCB0byB0aGUgYXBwbGljYXRpb24sIGV2ZW4gaWYgYSBsYXRlciBzdWJmbG93IHVzZXMgYSBkaWZm ZXJlbnQNCj5hZGRyZXNzIGZhbWlseS4gVGhlcmUgbWF5IGJlIGEgbGl0dGxlIGNvbmZ1c2lvbiBp biB0aGlzIGFyZWEgYXMgTVBUQ1AgYW5kDQo+SEUgbWlnaHQgYXBwZWFyIHRvIGJlIGZhaXJseSBz aW1pbGFyIGF0IGZhY2UgdmFsdWUgKGFuZCBJIHRoaW5rIEhFDQo+dGVjaG5pcXVlcyBhcHBsaWVk IHRvIGluaXRpYWwgTVBUQ1Agc3ViZmxvdyBzZXR1cCBtaWdodCBpbXByb3ZlIHRoZSBNUFRDUA0K PmVzdGFibGlzaG1lbnQgcGVyZm9ybWFuY2UuKS4NCj4NCj5SZWdhcmRzLA0KPk1hcmsuDQo+DQo+ DQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJmcmVkQGNpc2NvLmNvbSIg PGZyZWRAY2lzY28uY29tPg0KPlRvOiB2Nm9wc0BpZXRmLm9yZw0KPkNjOiBkcmFmdC12eW5ja2Ut djZvcHMtaGFwcHktZXllYmFsbHMtY29va2llQHRvb2xzLmlldGYub3JnDQo+U2VudDogV2VkbmVz ZGF5LCAxMSBGZWJydWFyeSAyMDE1LCAyMzo0Nw0KPlN1YmplY3Q6IFt2Nm9wc10gbmV3IGRyYWZ0 OiBkcmFmdC12eW5ja2UtdjZvcHMtaGFwcHktZXllYmFsbHMtY29va2llDQo+DQo+QSBuZXcgZHJh ZnQgaGFzIGJlZW4gcG9zdGVkLCBhdA0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxscy1jb29raWUuDQo+UGxlYXNlIHRha2UgYSBsb29r IGF0IGl0IGFuZCBjb21tZW50Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0DQo+djZvcHNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxp c3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCg0K From nobody Sat Feb 28 10:44:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626DE1A7D81 for ; Sat, 28 Feb 2015 10:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7fF_40MbIPb for ; Sat, 28 Feb 2015 10:44:11 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBDA1A026F for ; Sat, 28 Feb 2015 10:44:10 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id a7c02f45.0.257173.00-2353.709459.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 28 Feb 2015 18:44:10 +0000 (UTC) X-MXL-Hash: 54f20c7a3a1300f6-02e87d213563a542c1348fa3af16870dbd236f90 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1SIi9m5023325 for ; Sat, 28 Feb 2015 13:44:09 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1SIi38S023303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 28 Feb 2015 13:44:06 -0500 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor) for ; Sat, 28 Feb 2015 18:43:48 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.149]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0224.002; Sat, 28 Feb 2015 13:43:48 -0500 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: comments on draft-ietf-v6ops-mobile-device-profile-19 Thread-Index: AdBTanJNvJBbZ0pnRLOCo1ESaXFM+A== Date: Sat, 28 Feb 2015 18:43:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.115.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EvxlW1gA c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zhobYCeBVNkA:10 a=yy6f1W50eQUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9] X-AnalysisOut: [nkA:10 a=8pif782wAAAA:8 a=-tGrwHRrAAAA:8 a=l37wT53hQxIhjg_] X-AnalysisOut: [qZiwA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 18:44:13 -0000 I've read through this draft and have some comments. I focused mostly on "m= ust" requirements, because it's always easy to justify not doing a "should"= . The authors are free to change nothing as a result of my comments. I'm no= t voicing opposition. I'm simply expressing in more detail why I would not = recommend to my employer (or any other service provider) that they use this= draft as an RFC reference without very careful thought as to the desirabil= ity of each requirement. Barbara --------- Note that the term "[3GPP] cellular host" includes a wide variety of device= s, including those which are considered "IoT" or "M2M" (such as tracking/lo= cating devices, health monitors, eReaders, automobiles, etc.). Some of thes= e devices are intended (by the service provider who procures them) to be us= ed with a service that does not support roaming to other providers' networ= ks. Some are single function devices, where the function is fully specified= at time of procurement. These devices are generally intended to be as low-= complexity and energy-efficient as possible. If a service provider is creat= ing an RFP for such a device, that service provider would be best advised t= o figure out their IPv6 architecture before sending out an RFP with any of = the requirements in this draft. For a service provider to say "I have no cl= ue what my IPv6 architecture is going to be, so I want to require even the = simplest and lowest complexity cellular hosts to have support for all possi= ble IPv6 architectures" is not an approach I would recommend.=20 But that is exactly what this draft recommends: C_REC#1: In order to allow each operator to select their own strategy regarding IPv6 introduction, the cellular host must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. There are also other requirements which appear to impose complexity on low-= end non-roaming/single-purpose cellular hosts in order to allow the service= provider maximum flexibility in ultimately deciding on an IPv6 architectur= e. I'm not enough of a cellular expert to be able to properly identify all = of these. As for cellular hosts that do roam, I think the service provider needs to p= ut some thought into how important it is for such devices to support all IP= v6 architectures. I'm not fully convinced that it won't be acceptable to us= ers of low-end cellular hosts that do roam to just do IPv4 on networks with= unsupported IPv6 architectures.=20 --------- CPE (Customer Premises Equipment): The draft does provide the acronym expan= sion of CPE, but does not define the term. Given the context in which the d= raft uses the term, I suspect that the authors are not intending a definiti= on consistent with that at, for example, [1] and [2]. The first of these re= ferences includes the sentence "CPE generally refers to devices such as tel= ephones, routers, switches, residential gateways (RG), set-top boxes, fixed= mobile convergence products, home networking adapters and Internet access = gateways that enable consumers to access communications service providers' = services and distribute them around their house via a local area network (L= AN)." The second includes the sentence "Today, almost any end-user equipmen= t can be called customer premise [sic] equipment and it can be owned by the= customer or by the provider." But the set of CPE that could also reasonabl= y be expected to include a 3GPP interface are, of course, much smaller than= this broad definition. One such piece of CPE, though, is a home automation= /security gateway that interfaces with various monitoring, automation, and = security devices. Such CPE have both an Ethernet WAN interface (that allows= them to be behind the CE router) and a 3GPP interface (for backup and perh= aps some other management purposes). Since these are "CPE" and "cellular" a= nd they provide LAN connectivity to various home automation devices, they w= ould appear to fall under the requirements of Section 3, and specifically t= hose that apply to "cellular CPE". I would not recommend applying RFC 7084 = to such CPE. If "CE router" is intended, instead of all devices that can be= classified as "CPE", then I suggest using the term "CE router".=20 [1] http://en.wikipedia.org/wiki/Customer-premises_equipment=20 [2] http://searchnetworking.techtarget.com/definition/customer-premises-equ= ipment=20 -------- Discussion as to which device requirements the authors are really trying to= drive seems to be largely focused on smartphones. Given there has been no = input from most smartphone OS providers and opposition from people associat= ed with one smartphone OS, IMO this draft will not be a useful mechanism fo= r driving these requirements into smartphone OSs.
On S= un, Feb 15, 2015 at 9:08 AM, Edward Lewis <edward.lewis@icann.org= > wrote:
Whether or not it is a= candidate for WG adoption is another matter.=C2=A0 For
now, I=E2=80=99d appreciate thoughts on whether this is a =E2=80=98good ide= a=E2=80=99 to develop
or not.

IIRC this idea has come up at l= east once before, and maybe more (not sure where - perhaps in v6ops?). I do= n't oppose it - in fact, I think it's a good idea - but since the p= revious attempt(s) never came to anything, I assume there was no consensus = that this is useful.

If you choose ::/64 as your l= oopback prefix, then you're specifiying a range that includes all IPv4-= compatible addresses (::192.0.2.1) and all IPv4-mapped addresses (::ffff:19= 2.0.2.1) in addition to ::/128 (unspecified) and ::1/128 (loopback).
<= /div>
--20cf30334b6f3db0a8050f2eb8f2-- From nobody Sun Feb 15 22:42:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566321A8744 for ; Sun, 15 Feb 2015 22:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lI6X6_k_sHj for ; Sun, 15 Feb 2015 22:42:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C261A8739 for ; Sun, 15 Feb 2015 22:42:52 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 24EB62AC22E; Mon, 16 Feb 2015 07:42:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id F3C6415809D; Mon, 16 Feb 2015 07:42:50 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Mon, 16 Feb 2015 07:42:51 +0100 From: To: Alexandru Petrescu , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQR6fmH0P8VsyAQ0msn8bBnn4Z5Zzy1a3A Date: Mon, 16 Feb 2015 06:42:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> In-Reply-To: <54DE227D.9050303@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 06:42:56 -0000 SGkgQWxleCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEFsZXhhbmRydSBQZXRyZXNjdSBbbWFpbHRvOmFs ZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb21dIA0KRW52b3nDqcKgOiB2ZW5kcmVkaSAxMyBmw6l2 cmllciAyMDE1IDE3OjEzDQrDgMKgOiBIZWF0bGV5LCBOaWNrOyBCT1VDQURBSVIgTW9oYW1lZCBJ TVQvT0xODQpDY8KgOiB2Nm9wc0BpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19S RUMjOSA0NjRYTEFUDQoNCkxlIDEzLzAyLzIwMTUgMTY6MzMsIEhlYXRsZXksIE5pY2sgYSDDqWNy aXQgOg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBBbGV4YW5kcnUg UGV0cmVzY3UNCj4gW21haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tXSBTZW50OiAx MyBGZWJydWFyeSAyMDE1IDE0OjM1DQo+IFRvOiBIZWF0bGV5LCBOaWNrOyBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOg0KPiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0x Ny50eHQgLSBDX1JFQyM5IDQ2NFhMQVQNCj4NCj4gTGUgMTMvMDIvMjAxNSAxNDoxNCwgSGVhdGxl eSwgTmljayBhIMOpY3JpdCA6DQo+PiBIaSBBbGV4LCBZZXMsIHRoYXQgaXMgd3JvbmcuIFlvdSBj YW4gcGluZyBhbnkgSVB2NCBsaXRlcmFsIGZyb20gYQ0KPj4gNDY0eGxhdCBkZXZpY2UuIE15IGhh bmRzZXQgb25seSBoYXMgYW4gSVB2NiBhZGRyZXNzICsgQ0xBVCBhbmQgSSBhbQ0KPj4gcGluZ2lu ZyA4LjguOC44IDotKSkNCj4NCj4gT2ssIEkgc2VlLiAgSSBkaWRudCBrbm93IENMQVQtb24tZGV2 aWNlIHdhcyByZXF1aXJlZCB3aGVuIHVzaW5nDQo+IHY2LW9ubHkgQVBOcy4NCj4NCj4gW0hlYXRs ZXksIE5pY2tdIEZvciBzZXJ2aWNlIGNvbnRpbnVpdHkgd2l0aCBJUHY0LCBvbiBhbiBJUHY2LW9u bHkNCj4gYmVhcmVyIHVzZSBDTEFULiBBIHNsaWdodGx5IHBlZGFudGljIG5vdGUsICBpZiB5b3Ug aGF2ZSBhICJkdWFsIHN0YWNrDQo+IEFQTiIgYnV0IHRoZSBkZXZpY2Ugb25seSByZXF1ZXN0cyBJ UHY2IHRoZW4gdGhlIGRldmljZSB3aWxsIHJlY2VpdmUNCj4gYW4gSVB2NiBiZWFyZXIgYW5kIHJl cXVpcmVzIENMQVQuIFlvdSB3aWxsIGhlYXIgZnJvbSBSb3NzIGFuZCBtZQ0KPiB0YWxraW5nIGFi b3V0IGhhdmluZyBhIHNpbmdsZSBBUE4gc3VwcG9ydGluZyBhbGwgbW9kZXMsIElQdjQsIElQdjR2 Ng0KPiBhbmQgSVB2NiBiZWFyZXJzLiBUaGVyZSBtYXkgYmUgYnVzaW5lc3MgcmVhc29ucyBmb3Ig dGhpcywgYXMgd2VsbCBhcw0KPiBhdm9pZGluZyBjb25zdW1lcnMgaGF2aW5nIHRvIGNoYW5nZSBB UE5zLg0KDQpJbiBteSB1bmRlcnN0YW5kaW5nIDQ2NHhsYXQvY2xhdCBhcmUgdHJpYWxzIHRoZXNl IGRheXMuDQoNCltNZWRdIE5vLCBpdCBpcyBpbiB1c2UgaW4gbGl2ZSBuZXR3b3JrcywgaW5jbHVk aW5nIHdpdGhpbiBvdXIgR3JvdXAuDQoNCiAgVGhleSBjb3VsZCBiZSANCmltcHJvdmVkIGJlZm9y ZSBnb2luZyBsaXZlLiAgSWYgdGhlIDQ2NHhsYXQvY2xhdCBoYXBwZW5lZCBlbHNld2hlcmUgdGhh biANCm9uIHRoZSB1c2VyIHRlcm1pbmFsIChlLmcuIEJBc2UgU3RhdGlvbikgSSB0aGluayBtb3Jl IG9mIHRoZXNlIHRlcm1pbmFscyANCmNvdWxkIGJlIGFjY29tbW9kYXRlZCwgbW9yZSBidXNpbmVz cy4NCg0KW01lZF0gSWYgYWxsIGFwcGxpY2F0aW9ucyBhcmUgQUYtaW5kZXBlbmRlbnQgKGluY2x1 ZGluZyBJUHY0IHJlZmVycmFscyBhcmUgbm90IGluIHVzZSBvciBhZGRyZXNzIHN5bnRoZXNpcyBh IGxhIFJGQzYwNTIgaXMgc3VwcG9ydGVkKSwgdGhlbiBDTEFUIGNhbiBiZSBhdm9pZGVkLiBTb21l IG9wZXJhdG9ycyB3YW50IHRvIGFkb3B0IGFuIElQdjYtb25seSBjb25uZWN0aXZpdHkgbW9kZSBi dXQgd2l0aCBhIGNvbmRpdGlvbiB0byBwcm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIHNlcnZpY2Ug YXMgSVB2NDsgRm9yIHRob3NlIENMQVQgaXMgZXZlbiBhIG11c3QuIEl0IG1pZ2h0IGhhcHBlbiB0 aGF0IG90aGVyIG9wZXJhdG9ycyBjYW4ganVkZ2UgdGhhdCB0aGUgYnJva2VuIGFwcGxpY2F0aW9u cyB1bmRlciBhbiBJUHY2LW9ubHkgbW9kZSArIE5BVDY0IGFyZSBub3QgaW1wb3J0YW50OyBmb3Ig dGhvc2UgQ0xBVCBpcyBub3QgbmVlZGVkLiBUaGVzZSByZWFzb25zLCBhbW9uZyBvdGhlcnMsIGFy ZSB3aHkgd2Ugc2V0IHRoZSBsYW5ndWFnZSB0byAnc2hvdWxkJy4gDQoNCj4gVGhhdCBtZWFucyB0 aGF0IHRoZSBkZXZpY2UgdmVuZG9ycyBNVVNUIGltcGxlbWVudCBDTEFUIGluIHRoZQ0KPiBzbWFy dHBob25lcyB3aGljaCBjb25uZWN0IHRvIGEgdjYtb25seSBBUE4uICBJdCBpcyBhIHRvbyBzdHJv bmcNCj4gcmVxdWlyZW1lbnQuDQo+DQo+IFtIZWF0bGV5LCBOaWNrXSBUb2RheSdzIHJlYWxpdHkg aXMgdGhhdCBvcGVyYXRvcnMgY2Fubm90IHRha2UgZGV2aWNlcw0KPiB0byBJUHY2LW9ubHkgbW9k ZSBvZiBvcGVyYXRpb24gd2l0aG91dCBDTEFULiBJbiB0aGUgZnV0dXJlIHdpbGwgb3RoZXINCj4g YWx0ZXJuYXRpdmVzIGFwcGVhcj8NCg0KQWx0ZXJuYXRpdmVzIHRoZXJlIGFyZSB2ZXJ5IG1hbnku DQoNCkUuZy4gNDY0bGF0L2NsYXQgdG8gcnVuIG9uIGFuIG9wZXJhdG9yLWNvbnRyb2xsZWQgbmV0 d29yayBkZXZpY2UsIG5vdCBvbiANCmVuZC11c2VyIHRlcm1pbmFsLg0KDQpFLmcuIHVzZSBhIHY0 LUFQTiBhbmQgdjYtaW4tdjQgZW5jYXBzdWxhdGlvbiBvbiB0aGUgZW5kLXVzZXIgZGV2aWNlLg0K DQozR1BQIGFsc28gZGVzaWduZWQgYSBEUy1NSVB2Niwgbm90IHN1cmUgd2hldGhlciB5b3UgYXJl IGF3YXJlIG9mIGl0LiAgSXQgDQpoYWQgdGhlIHNhbWUgZ29hbCBvZiB0ZXJtaW5hbCBvbiB2Ni1v bmx5IGxpbmsuDQoNCltNZWRdIEFsbCB0aG9zZSBhcmUgbm8gb3B0aW9ucyBpbiB0aGUgbW9iaWxl IGNvbnRleHQuIElQdjYtb25seSArIE5BVDY0IGlzIHRoZSBtb2RlIHRoYXQgaXMgY3VycmVudGx5 IGFkb3B0ZWQgYnkgc2V2ZXJhbCBvcGVyYXRvcnMuIA0KDQo= From nobody Sun Feb 15 23:09:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1781A8744 for ; Sun, 15 Feb 2015 23:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhjb6as7zauC for ; Sun, 15 Feb 2015 23:09:27 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDBF1A01CB for ; Sun, 15 Feb 2015 23:09:23 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id e89so22147413qgf.9 for ; Sun, 15 Feb 2015 23:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VBN4hv5EGyIav8LlXl+pOdE4aA7tfS0KyL2b2oFdAjM=; b=o6RSvLLC/arZkGBPkir6KEvPLJmqpQ0ldsGYEIzf70zyAunCnIibgnf+VMTZRd40pM v4YnO+IAK5T/vRn/FfKA4E+Cs0t1qt7evhuIiEIHF6UzsDNGWn/j3McrHoBBgLcems69 kzJJz6km6hI42IKqkYj+BIJLf4tH+7OQTw0lTmYHAqqadWEwLCwzrBW0DjtWhc2FFG0/ 4x//2nqGLs17YqzBw4TcX8LuYA1YgpoMdW33iEILLlvIWNjRgy4HTwQ49quwgdJ7Yi2L Xar+eDBRH7QdTaqgQW9wcqRv2qzWkU37+E15eLoxXkQz4+waryIxlEoYgN5bXuQEkHSR v3qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VBN4hv5EGyIav8LlXl+pOdE4aA7tfS0KyL2b2oFdAjM=; b=Z2eFMvuChS0H5jVNOusHecwwGxUQmrDDD6MC9cdmDBSMb4TuZCgou1mim1CYkkXWbX fRqzJWwqHbbZZG7PWD503TskGZG3AArneqPfEnv8brwzYTvfGSe6zxX0Sxr81udLxIBU FgEb/6YLBXCf2n3tTFWESWa/jJegh1ZOUdbLOQQeOYDm0q8QBTtGbxwVnqOUdWnNdIiW jGs8eesWMPSn4wdpJeijXhTks3We72M9p4t7ZBU/3dqgvL4nK2zfuayPw51ZwT0I/zN9 VlyIc9PYl67M/yTrteXHP4nLBQjrj4o4vX06V7h7CKP0IOww6e8I2jfJP1vHmaH68eIf iOyg== X-Gm-Message-State: ALoCoQmY3c491csFr7hpom6AZooOZhoYsPbiXvr66uzzQWiRyYFj72tXH5ApaNu+l16dy0OInKLL X-Received: by 10.229.4.4 with SMTP id 4mr269484qcp.8.1424070562556; Sun, 15 Feb 2015 23:09:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.2 with HTTP; Sun, 15 Feb 2015 23:09:02 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Sun, 15 Feb 2015 23:09:02 -0800 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Edward Lewis , "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 07:09:32 -0000 > IIRC this idea has come up at least once before, and maybe more (not sure > where - perhaps in v6ops?). I don't oppose it - in fact, I think it's a good > idea - but since the previous attempt(s) never came to anything, I assume > there was no consensus that this is useful. Yep. 1::/32. https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04#section-3 From nobody Sun Feb 15 23:09:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3D1A8741 for ; Sun, 15 Feb 2015 23:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrGu0KGecOpT for ; Sun, 15 Feb 2015 23:09:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C96E1A01CB for ; Sun, 15 Feb 2015 23:09:34 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2B71D3B410B; Mon, 16 Feb 2015 08:09:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0AD782380A0; Mon, 16 Feb 2015 08:09:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 16 Feb 2015 08:09:31 +0100 From: To: Lorenzo Colitti , "Heatley, Nick" Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "Lack of Justification"? Thread-Index: AdBJt38QNIL2UaOVRwWd59ZTy+xJRw== Date: Mon, 16 Feb 2015 07:09:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490B99A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490B99AOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.16.60025 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "Lack of Justification"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 07:09:40 -0000 --_000_787AE7BB302AE849A7480A190F8B93300490B99AOPEXCLILM23corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KKEkgY2hhbmdlZCB0aGUgc3ViamVjdCBiZWNhdXNlIHRoZSBwb2ludCBy YWlzZWQgYnkgTG9yZW56byBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIG9uZSBpbml0aWFsbHkgaW4g dGhpcyB0aHJlYWQpDQoNCkkgaGF2ZSB0aHJlZSBjb21tZW50cyBoZXJlIDoNCg0KKDEpDQoNClNh eWluZyB0aGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIGluIHRoZSBkb2N1bWVudCBpcyBXUk9ORy4g SSBjYW4gdW5kZXJzdGFuZCB0aGF0IHRoZSBqdXN0aWZpY2F0aW9uIGNhbiBiZSB3ZWFrIGZyb20g eW91ciBzdGFuZHBvaW50LCBidXQgc2F5aW5nIHRoZXJlIGlzIG5vIGp1c3RpZmljYXRpb24gaXMg bm90IGZhaXIgYXQgYWxsLiBTb21lIGV4YW1wbGVzIGFyZSBwcm92aWRlcyBiZWxvdzoNCg0KPT09 PQ0KICAgQ19SRUMjMzogIFRoZSBjZWxsdWxhciBob3N0IG11c3Qgc3VwcG9ydCB0aGUgUENPIChQ cm90b2NvbA0KICAgICAgICAgICAgIENvbmZpZ3VyYXRpb24gT3B0aW9ucykgW1RTLjI0MDA4PGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1w cm9maWxlLTE3I3JlZi1UUy4yNDAwOD5dIHRvIHJldHJpZXZlIHRoZSBJUHY2DQogICAgICAgICAg ICAgYWRkcmVzcyhlcykgb2YgdGhlIFJlY3Vyc2l2ZSBETlMgc2VydmVyKHMpLg0KDQogICAgICAg ICAgICAgICAgSW4tYmFuZCBzaWduYWxpbmcgaXMgYSBjb252ZW5pZW50IG1ldGhvZCB0byBpbmZv cm0gdGhlDQogICAgICAgICAgICAgICAgY2VsbHVsYXIgaG9zdCBhYm91dCB2YXJpb3VzIHNlcnZp Y2VzLCBpbmNsdWRpbmcgRE5TDQogICAgICAgICAgICAgICAgc2VydmVyIGluZm9ybWF0aW9uLiAg SXQgZG9lcyBub3QgcmVxdWlyZSBhbnkgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICBwcm90b2Nv bCB0byBiZSBzdXBwb3J0ZWQgYW5kIGl0IGlzIGFscmVhZHkgZGVwbG95ZWQgaW4NCiAgICAgICAg ICAgICAgICBJUHY0IGNlbGx1bGFyIG5ldHdvcmtzIHRvIGNvbnZleSBzdWNoIEROUyBpbmZvcm1h dGlvbi4NCg0KICAgQ19SRUMjNjogIFRoZSBjZWxsdWxhciBob3N0IG11c3QgYmUgYWJsZSB0byBi ZSBjb25maWd1cmVkIHRvIGxpbWl0DQogICAgICAgICAgICAgUERQIHR5cGUocykgZm9yIGEgZ2l2 ZW4gQVBOLiAgVGhlIGRlZmF1bHQgbW9kZSBpcyB0byBhbGxvdw0KICAgICAgICAgICAgIGFsbCBz dXBwb3J0ZWQgUERQIHR5cGVzLiAgTm90ZSwgQ19SRUMjMiBkaXNjdXNzZXMgdGhlDQogICAgICAg ICAgICAgZGVmYXVsdCBiZWhhdmlvciBmb3IgcmVxdWVzdGluZyBQRFAtQ29udGV4dCB0eXBlKHMp Lg0KDQoNCiAgICAgICAgICAgICAgICBUaGlzIGZlYXR1cmUgaXMgdXNlZnVsIHRvIGRyaXZlIHRo ZSBiZWhhdmlvciBvZiB0aGUgVUUNCiAgICAgICAgICAgICAgICB0byBiZSBhbGlnbmVkIHdpdGg6 ICgxKSBzZXJ2aWNlLXNwZWNpZmljIGNvbnN0cmFpbnRzDQogICAgICAgICAgICAgICAgc3VjaCBh cyB0aGUgdXNlIG9mIElQdjYtb25seSBmb3IgVm9MVEUgKFZvaWNlIG92ZXIgTFRFKSwNCiAgICAg ICAgICAgICAgICAoMikgbmV0d29yayBjb25kaXRpb25zIHdpdGggcmVnYXJkcyB0byB0aGUgc3Vw cG9ydCBvZg0KICAgICAgICAgICAgICAgIHNwZWNpZmljIFBEUCB0eXBlcyAoZS5nLiwgSVB2NHY2 IFBEUC1Db250ZXh0IGlzIG5vdA0KICAgICAgICAgICAgICAgIHN1cHBvcnRlZCksICgzKSBJUHY0 IHN1bnNldCBvYmplY3RpdmVzLCAoNCkgc3Vic2NyaXB0aW9uDQogICAgICAgICAgICAgICAgZGF0 YSwgZXRjLg0KDQogICAgICAgICAgICAgICAgTm90ZSwgYSBjZWxsdWxhciBob3N0IGNoYW5naW5n IGl0cyBjb25uZWN0aW9uIGJldHdlZW4gYW4NCiAgICAgICAgICAgICAgICBJUHY2LXNwZWNpZmlj IEFQTiBhbmQgYW4gSVB2NC1zcGVjaWZpYyBBUE4gcmVzdGFydHMgdGhlDQogICAgICAgICAgICAg ICAgb25nb2luZyBhcHBsaWNhdGlvbnMuICBUaGlzIGlzIGEgYnJva2VubmVzcyBzaXR1YXRpb24u DQoNCiAgIENfUkVDIzc6ICBCZWNhdXNlIG9mIHBvdGVudGlhbCBvcGVyYXRpb25hbCBkZWZpY2ll bmNpZXMgdG8gYmUNCiAgICAgICAgICAgICBleHBlcmllbmNlZCBpbiBzb21lIHJvYW1pbmcgc2l0 dWF0aW9ucywgdGhlIGNlbGx1bGFyIGhvc3QNCiAgICAgICAgICAgICBtdXN0IGJlIGFibGUgdG8g YmUgY29uZmlndXJlZCB3aXRoIGEgaG9tZSBJUCBwcm9maWxlIGFuZCBhDQogICAgICAgICAgICAg cm9hbWluZyBJUCBwcm9maWxlLiAgVGhlIGFpbSBvZiB0aGUgcm9hbWluZyBwcm9maWxlIGlzIHRv DQogICAgICAgICAgICAgbGltaXQgdGhlIFBEUCB0eXBlKHMpIHJlcXVlc3RlZCBieSB0aGUgY2Vs bHVsYXIgaG9zdCB3aGVuDQogICAgICAgICAgICAgb3V0IG9mIHRoZSBob21lIG5ldHdvcmsuICBO b3RlIHRoYXQgZGlzdGluY3QgUERQIHR5cGUocykNCiAgICAgICAgICAgICBhbmQgQVBOKHMpIGNh biBiZSBjb25maWd1cmVkIGZvciBob21lIGFuZCByb2FtaW5nIGNhc2VzLg0KDQogICBDX1JFQyM4 OiAgSW4gb3JkZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQdjYt b25seQ0KICAgICAgICAgICAgIGRlcGxveW1lbnQgY29udGV4dCwgdGhlIGNlbGx1bGFyIGhvc3Qg c2hvdWxkIHN1cHBvcnQgYQ0KICAgICAgICAgICAgIG1ldGhvZCB0byBsb2NhbGx5IGNvbnN0cnVj dCBJUHY0LWVtYmVkZGVkIElQdjYgYWRkcmVzc2VzDQogICAgICAgICAgICAgW1JGQzYwNTI8aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1Mj5dLiAgQSBtZXRob2QgdG8gbGVhcm4gUFJF RklYNjQgc2hvdWxkIGJlIHN1cHBvcnRlZA0KICAgICAgICAgICAgIGJ5IHRoZSBjZWxsdWxhciBo b3N0Lg0KDQogICAgICAgICAgICAgICAgVGhpcyBzb2x2ZXMgdGhlIGlzc3VlIHdoZW4gYXBwbGlj YXRpb25zIHVzZSBJUHY0DQogICAgICAgICAgICAgICAgcmVmZXJyYWxzIG9uIElQdjYtb25seSBh Y2Nlc3MgbmV0d29ya3MuDQoNCiAgICAgICAgICAgICAgICBJbiBQQ1AtYmFzZWQgZW52aXJvbm1l bnRzLCBjZWxsdWxhciBob3N0cyBzaG91bGQgZm9sbG93DQogICAgICAgICAgICAgICAgW1JGQzcy MjU8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyNT5dIHRvIGxlYXJuIHRoZSBJUHY2 IFByZWZpeCB1c2VkIGJ5IGFuIHVwc3RyZWFtDQogICAgICAgICAgICAgICAgUENQLWNvbnRyb2xs ZWQgTkFUNjQgZGV2aWNlLiAgSWYgUENQIGlzIG5vdCBlbmFibGVkLCB0aGUNCiAgICAgICAgICAg ICAgICBjZWxsdWxhciBob3N0IHNob3VsZCBpbXBsZW1lbnQgdGhlIG1ldGhvZCBzcGVjaWZpZWQg aW4NCiAgICAgICAgICAgICAgICBbUkZDNzA1MDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3MDUwPl0gdG8gcmV0cmlldmUgdGhlIFBSRUZJWDY0Lg0KDQogICBDX1JFQyM5OiAgSW4gb3Jk ZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQdjYtb25seQ0KICAg ICAgICAgICAgIGRlcGxveW1lbnQgY29udGV4dCwgdGhlIGNlbGx1bGFyIGhvc3Qgc2hvdWxkIGlt cGxlbWVudCB0aGUNCiAgICAgICAgICAgICBDdXN0b21lciBTaWRlIFRyYW5zbGF0b3IgKENMQVQs IFtSRkM2ODc3PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4Nzc+XSkgZnVuY3Rpb24g d2hpY2gNCiAgICAgICAgICAgICBpcyBjb21wbGlhbnQgd2l0aCBbUkZDNjA1MjxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDUyPl1bUkZDNjE0NV1bUkZDNjE0NjxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MTQ2Pl0uDQoNCiAgICAgICAgICAgICAgICBDTEFUIGZ1bmN0aW9u IGluIHRoZSBjZWxsdWxhciBob3N0IGFsbG93cyBmb3IgSVB2NC1vbmx5DQogICAgICAgICAgICAg ICAgYXBwbGljYXRpb24gYW5kIElQdjQtcmVmZXJhbHMgdG8gd29yayBvbiBhbiBJUHY2LW9ubHkN CiAgICAgICAgICAgICAgICBjb25uZWN0aXZpdHkuICBDTEFUIGZ1bmN0aW9uIHJlcXVpcmVzIGEg TkFUNjQgY2FwYWJpbGl0eQ0KICAgICAgICAgICAgICAgIFtSRkM2MTQ2PGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYxNDY+XSBpbiB0aGUgY29yZSBuZXR3b3JrLg0KDQogICAgICAgICAg ICAgICAgVGhlIElQdjQgU2VydmljZSBDb250aW51aXR5IFByZWZpeCB1c2VkIGJ5IENMQVQgaXMN CiAgICAgICAgICAgICAgICBkZWZpbmVkIGluIFtSRkM3MzM1PGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzczMzU+XS4NCj09PT09DQoNCigyKSBJIGNoZWNrZWQgUkZDNzA4NCBhbmQgUkZD NzA2NiBvdXQgb2YgY3VyaW9zaXR5LCBJIGRpZG7igJl0IGZvdW5kIHRob3NlIGRvY3VtZW50cyBw cm92aWRlIG1vcmUgZWxhYm9yYXRlZCBqdXN0aWZpY2F0aW9ucyB0aGF0IHdoYXQgd2UgYXJlIGRv aW5nIGhlcmUuDQoNCigzKSBZb3Ugc3RpbGwgY29udGludWUgYXNzdW1pbmcgYWxsIGl0ZW1zIGlu Y2x1ZGVkIGluIHRoaXMgSS1EIGFyZSBtYW5kYXRvcnksIHRoaXMgaXMgbm90IHRydWUuIEEgZGV2 aWNlIGNhbiBzdXBwb3J0IHRoaXMgcHJvZmlsZSB3aXRob3V0IHN1cHBvcnRpbmcgYWxsIHRoZSBp dGVtcyBsaXN0ZWQgaW4gdGhpcyBwcm9maWxlLg0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBMb3JlbnpvIENvbGl0dGkNCkVudm95w6kgOiBzYW1lZGkgMTQgZsOpdnJpZXIgMjAxNSAw MjozMg0Kw4AgOiBIZWF0bGV5LCBOaWNrDQpDYyA6IElQdjYgT3BzIFdHICh2Nm9wc0BpZXRmLm9y ZykNCk9iamV0IDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXBy b2ZpbGUgbGFzdCBjYWxsLSAiaGFybWZ1bGx5IGJyb2FkIj8NCg0KT24gRnJpLCBGZWIgMTMsIDIw MTUgYXQgNzoyOSBBTSwgSGVhdGxleSwgTmljayA8bmljay5oZWF0bGV5QGVlLmNvLnVrPG1haWx0 bzpuaWNrLmhlYXRsZXlAZWUuY28udWs+PiB3cm90ZToNCkxvcmVuem8sIEkgZmVlbCB5b3UgYXJl IGxpa2UgdGhlIHNwZWNpYWxpc3Qgc3VyZ2VvbiBiZXJhdGluZyB0aGUgR1BzIGZvciBub3Qga25v d2luZyBldmVyeSBSRkMgaW4gaXRzIHB1cmUgZm9ybS4NCg0KTm8sIEkgYW0gYmVyYXRpbmcgdGhl IGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBmb3Igd3JpdGluZyBhIGRvY3VtZW50IHRoYXQgbWFrZXMg R1BzICg9ZGV2aWNlIG1hbnVmYWN0dXJlcnMsIG90aGVyIG5ldHdvcmsgb3BlcmF0b3JzKSBiZWxp ZXZlIHRoYXQgdGhleSBoYXZlIHRvIHByZXBhcmUgbG9hZHMgb2YgdW5uZWNlc3NhcnkgbWVkaWNh bCBtYWNoaW5lcnkgKD10aGUgbWFueSByZWNvbW1lbmRhdGlvbnMgdGhhdCB0aGlzIGRyYWZ0IG1h a2VzKSBiZWZvcmUgdGhleSBjYW4gb3BlbiBhIHNtYWxsIEdQIHN1cmdlcnkgKD1kZXBsb3kgSVB2 NiksIHdpdGhvdXQgYm90aGVyaW5nIHRvIHRlbGwgdGhlbSB3aHkgdGhleSBuZWVkIGFsbCB0aGF0 IG1hY2hpbmVyeSBhbmQgd2hhdCB0aGV5J3JlIHN1cHBvc2VkIHRvIGRvIHdpdGggaXQuDQo= --_000_787AE7BB302AE849A7480A190F8B93300490B99AOPEXCLILM23corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsN CgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUt bmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uZ3JleQ0KCXttc28tc3R5 bGUtbmFtZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjkwMjA3OTY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk5NTc4NzAwMCA4NTg1NDg1ODAgNjc4OTUzMjEg Njc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4 OTUzMjM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5IaSBMb3JlbnpvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+KEkgY2hhbmdlZCB0aGUgc3ViamVjdCBiZWNhdXNlIHRoZSBwb2ludCByYWlzZWQgYnkg TG9yZW56byBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIG9uZSBpbml0aWFsbHkgaW4gdGhpcyB0aHJl YWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkg aGF2ZSB0aHJlZSBjb21tZW50cyBoZXJlJm5ic3A7Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPigxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TYXlpbmcgdGhlcmUgaXMgbm8ganVzdGlmaWNhdGlv biBpbiB0aGUgZG9jdW1lbnQgaXMgV1JPTkcuIEkgY2FuIHVuZGVyc3RhbmQgdGhhdCB0aGUganVz dGlmaWNhdGlvbiBjYW4gYmUgd2VhayBmcm9tIHlvdXIgc3RhbmRwb2ludCwgYnV0IHNheWluZyB0 aGVyZSBpcyBubw0KIGp1c3RpZmljYXRpb24gaXMgbm90IGZhaXIgYXQgYWxsLiBTb21lIGV4YW1w bGVzIGFyZSBwcm92aWRlcyBiZWxvdzogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPj09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBDX1JFQyMzOiZuYnNwOyBUaGUgY2Vs bHVsYXIgaG9zdCBtdXN0IHN1cHBvcnQgdGhlIFBDTyAoUHJvdG9jb2w8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDb25maWd1cmF0aW9uIE9wdGlvbnMpIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRl dmljZS1wcm9maWxlLTE3I3JlZi1UUy4yNDAwOCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRTLjI0MDA4 PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogdG8gcmV0cmlldmUg dGhlIElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzKGVzKSBvZiB0aGUgUmVj dXJzaXZlIEROUyBzZXJ2ZXIocykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbi1iYW5kIHNpZ25hbGluZyBpcyBhIGNvbnZlbmll bnQgbWV0aG9kIHRvIGluZm9ybSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjZWxsdWxhciBob3N0IGFib3V0IHZhcmlvdXMgc2VydmljZXMsIGluY2x1ZGlu ZyBETlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2ZXIg aW5mb3JtYXRpb24uJm5ic3A7IEl0IGRvZXMgbm90IHJlcXVpcmUgYW55IHNwZWNpZmljPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2wgdG8gYmUgc3Vw cG9ydGVkIGFuZCBpdCBpcyBhbHJlYWR5IGRlcGxveWVkIGluPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVB2NCBjZWxsdWxhciBuZXR3b3JrcyB0byBjb252ZXkg c3VjaCBETlMgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IENfUkVDIzY6 Jm5ic3A7IFRoZSBjZWxsdWxhciBob3N0IG11c3QgYmUgYWJsZSB0byBiZSBjb25maWd1cmVkIHRv IGxpbWl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUERQIHR5cGUocykgZm9yIGEgZ2l2ZW4g QVBOLiZuYnNwOyBUaGUgZGVmYXVsdCBtb2RlIGlzIHRvIGFsbG93PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYWxsIHN1cHBvcnRlZCBQRFAgdHlwZXMuJm5ic3A7IE5vdGUsIENfUkVDIzIgZGlz Y3Vzc2VzIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmF1bHQgYmVoYXZpb3IgZm9y IHJlcXVlc3RpbmcgUERQLUNvbnRleHQgdHlwZShzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyBmZWF0dXJlIGlzIHVzZWZ1bCB0byBkcml2ZSB0aGUgYmVoYXZpb3Igb2YgdGhlIFVFPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUgYWxpZ25lZCB3aXRo OiAoMSkgc2VydmljZS1zcGVjaWZpYyBjb25zdHJhaW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2ggYXMgdGhlIHVzZSBvZiBJUHY2LW9ubHkgZm9yIFZv TFRFIChWb2ljZSBvdmVyIExURSksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKDIpIG5ldHdvcmsgY29uZGl0aW9ucyB3aXRoIHJlZ2FyZHMgdG8gdGhlIHN1cHBv cnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZp YyBQRFAgdHlwZXMgKGUuZy4sIElQdjR2NiBQRFAtQ29udGV4dCBpcyBub3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0ZWQpLCAoMykgSVB2NCBzdW5z ZXQgb2JqZWN0aXZlcywgKDQpIHN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRhdGEsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdGUsIGEgY2VsbHVsYXIgaG9zdCBj aGFuZ2luZyBpdHMgY29ubmVjdGlvbiBiZXR3ZWVuIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSVB2Ni1zcGVjaWZpYyBBUE4gYW5kIGFuIElQdjQtc3BlY2lm aWMgQVBOIHJlc3RhcnRzIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO29uZ29pbmcgYXBwbGljYXRpb25zLiZuYnNwOyBUaGlzIGlzIGEgYnJva2VubmVzcyBz aXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBDX1JFQyM3 OiZuYnNwOyBCZWNhdXNlIG9mIHBvdGVudGlhbCBvcGVyYXRpb25hbCBkZWZpY2llbmNpZXMgdG8g YmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleHBlcmllbmNlZCBpbiBzb21lIHJvYW1pbmcg c2l0dWF0aW9ucywgdGhlIGNlbGx1bGFyIGhvc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBt dXN0IGJlIGFibGUgdG8gYmUgY29uZmlndXJlZCB3aXRoIGEgaG9tZSBJUCBwcm9maWxlIGFuZCBh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcm9hbWluZyBJUCBwcm9maWxlLiZuYnNwOyBUaGUg YWltIG9mIHRoZSByb2FtaW5nIHByb2ZpbGUgaXMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBsaW1pdCB0aGUgUERQIHR5cGUocykgcmVxdWVzdGVkIGJ5IHRoZSBjZWxsdWxhciBob3N0IHdo ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvdXQgb2YgdGhlIGhvbWUgbmV0d29yay4mbmJz cDsgTm90ZSB0aGF0IGRpc3RpbmN0IFBEUCB0eXBlKHMpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYW5kIEFQTihzKSBjYW4gYmUgY29uZmlndXJlZCBmb3IgaG9tZSBhbmQgcm9hbWluZyBjYXNl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IENfUkVDIzg6Jm5ic3A7 IEluIG9yZGVyIHRvIGVuc3VyZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSBpbiBhbiBJUHY2LW9u bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXBsb3ltZW50IGNvbnRleHQsIHRoZSBjZWxs dWxhciBob3N0IHNob3VsZCBzdXBwb3J0IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXRo b2QgdG8gbG9jYWxseSBjb25zdHJ1Y3QgSVB2NC1lbWJlZGRlZCBJUHY2IGFkZHJlc3NlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYwNTIiIHRpdGxlPSImcXVvdDtJUHY2IEFkZHJlc3Npbmcg b2YgSVB2NC9JUHY2IFRyYW5zbGF0b3JzJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjA1 Mjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XS4mbmJzcDsNCiBBIG1l dGhvZCB0byBsZWFybiBQUkVGSVg2NCBzaG91bGQgYmUgc3VwcG9ydGVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYnkgdGhlIGNlbGx1bGFyIGhvc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHNvbHZlcyB0aGUgaXNz dWUgd2hlbiBhcHBsaWNhdGlvbnMgdXNlIElQdjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyByZWZlcnJhbHMgb24gSVB2Ni1vbmx5IGFjY2VzcyBuZXR3b3Jrcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEluIFBDUC1iYXNlZCBlbnZpcm9ubWVudHMsIGNlbGx1bGFyIGhvc3RzIHNob3VsZCBmb2xs b3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjI1IiB0aXRs ZT0iJnF1b3Q7RGlzY292ZXJpbmcgTkFUNjQgSVB2NiBQcmVmaXhlcyBVc2luZyB0aGUgUG9ydCBD b250cm9sIFByb3RvY29sIChQQ1ApJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNzIyNTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XQ0KIHRvIGxlYXJuIHRoZSBJ UHY2IFByZWZpeCB1c2VkIGJ5IGFuIHVwc3RyZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUENQLWNvbnRyb2xsZWQgTkFUNjQgZGV2aWNlLiZuYnNwOyBJZiBQ Q1AgaXMgbm90IGVuYWJsZWQsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNlbGx1bGFyIGhvc3Qgc2hvdWxkIGltcGxlbWVudCB0aGUgbWV0aG9kIHNwZWNp ZmllZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwNTAi IHRpdGxlPSImcXVvdDtEaXNjb3Zlcnkgb2YgdGhlIElQdjYgUHJlZml4IFVzZWQgZm9yIElQdjYg QWRkcmVzcyBTeW50aGVzaXMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDUwPC9zcGFu PjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogdG8gcmV0cmlldmUgdGhlIFBS RUZJWDY0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ19SRUMjOTom bmJzcDsgSW4gb3JkZXIgdG8gZW5zdXJlIElQdjQgc2VydmljZSBjb250aW51aXR5IGluIGFuIElQ djYtb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlcGxveW1lbnQgY29udGV4dCwgdGhl IGNlbGx1bGFyIGhvc3Qgc2hvdWxkIGltcGxlbWVudCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDdXN0b21lciBTaWRlIFRyYW5zbGF0b3IgKENMQVQsIFs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4NzciIHRpdGxlPSImcXVvdDs0 NjRYTEFUOiBDb21iaW5hdGlvbiBvZiBTdGF0ZWZ1bCBhbmQgU3RhdGVsZXNzIFRyYW5zbGF0aW9u JnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjg3Nzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+XSkNCiBmdW5jdGlvbiB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGlzIGNvbXBsaWFudCB3aXRoIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwNTIiIHRpdGxlPSImcXVvdDtJUHY2IEFkZHJlc3Np bmcgb2YgSVB2NC9JUHY2IFRyYW5zbGF0b3JzJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZD NjA1Mjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XVtSRkM2MTQ1XVs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYx NDYiIHRpdGxlPSImcXVvdDtTdGF0ZWZ1bCBOQVQ2NDogTmV0d29yayBBZGRyZXNzIGFuZCBQcm90 b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQdjYgQ2xpZW50cyB0byBJUHY0IFNlcnZlcnMmcXVvdDsi PjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM2MTQ2PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQ0xBVCBmdW5jdGlvbiBpbiB0aGUgY2VsbHVsYXIgaG9zdCBhbGxv d3MgZm9yIElQdjQtb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFwcGxpY2F0aW9uIGFuZCBJUHY0LXJlZmVyYWxzIHRvIHdvcmsgb24gYW4gSVB2Ni1vbmx5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ubmVjdGl2aXR5 LiZuYnNwOyBDTEFUIGZ1bmN0aW9uIHJlcXVpcmVzIGEgTkFUNjQgY2FwYWJpbGl0eTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNDYiIHRpdGxlPSImcXVvdDtT dGF0ZWZ1bCBOQVQ2NDogTmV0d29yayBBZGRyZXNzIGFuZCBQcm90b2NvbCBUcmFuc2xhdGlvbiBm cm9tIElQdjYgQ2xpZW50cyB0byBJUHY0IFNlcnZlcnMmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SRkM2MTQ2PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogaW4g dGhlIGNvcmUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJUHY0IFNlcnZpY2UgQ29udGludWl0eSBQcmVmaXgg dXNlZCBieSBDTEFUIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+ZGVmaW5lZCBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzMzNSIgdGl0bGU9IiZxdW90O0lQdjQgU2VydmljZSBDb250aW51aXR5 IFByZWZpeCZxdW90OyI+UkZDNzMzNTwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PT08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+KDIpIEkg Y2hlY2tlZCBSRkM3MDg0IGFuZCBSRkM3MDY2IG91dCBvZiBjdXJpb3NpdHksIEkgZGlkbuKAmXQg Zm91bmQgdGhvc2UgZG9jdW1lbnRzIHByb3ZpZGUgbW9yZSBlbGFib3JhdGVkIGp1c3RpZmljYXRp b25zIHRoYXQgd2hhdCB3ZSBhcmUgZG9pbmcgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+KDMpIFlvdSBzdGlsbCBjb250aW51ZSBhc3N1bWlu ZyBhbGwgaXRlbXMgaW5jbHVkZWQgaW4gdGhpcyBJLUQgYXJlIG1hbmRhdG9yeSwgdGhpcyBpcyBu b3QgdHJ1ZS4gQSBkZXZpY2UgY2FuIHN1cHBvcnQgdGhpcyBwcm9maWxlIHdpdGhvdXQgc3VwcG9y dGluZyBhbGwgdGhlDQogaXRlbXMgbGlzdGVkIGluIHRoaXMgcHJvZmlsZS4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUm bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IExvcmVuem8g Q29saXR0aTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMTQgZsOpdnJpZXIgMjAx NSAwMjozMjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gSGVhdGxleSwgTmljazxicj4NCjxiPkNjJm5i c3A7OjwvYj4gSVB2NiBPcHMgV0cgKHY2b3BzQGlldGYub3JnKTxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUg bGFzdCBjYWxsLSAmcXVvdDtoYXJtZnVsbHkgYnJvYWQmcXVvdDs/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxMywgMjAxNSBh dCA3OjI5IEFNLCBIZWF0bGV5LCBOaWNrICZsdDs8YSBocmVmPSJtYWlsdG86bmljay5oZWF0bGV5 QGVlLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+bmljay5oZWF0bGV5QGVlLmNvLnVrPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3JlbnpvLCBJIGZl ZWwgeW91IGFyZSBsaWtlIHRoZSBzcGVjaWFsaXN0IHN1cmdlb24gYmVyYXRpbmcgdGhlIEdQcyBm b3Igbm90IGtub3dpbmcgZXZlcnkgUkZDIGluIGl0cyBwdXJlIGZvcm0uPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgSSBhbSBiZXJhdGluZyB0aGUgYXV0 aG9ycyBvZiB0aGlzIGRyYWZ0IGZvciB3cml0aW5nIGEgZG9jdW1lbnQgdGhhdCBtYWtlcyBHUHMg KD1kZXZpY2UgbWFudWZhY3R1cmVycywgb3RoZXIgbmV0d29yayBvcGVyYXRvcnMpIGJlbGlldmUg dGhhdCB0aGV5IGhhdmUgdG8gcHJlcGFyZSBsb2FkcyBvZiB1bm5lY2Vzc2FyeSBtZWRpY2FsIG1h Y2hpbmVyeSAoPXRoZSBtYW55IHJlY29tbWVuZGF0aW9ucyB0aGF0DQogdGhpcyBkcmFmdCBtYWtl cykgYmVmb3JlIHRoZXkgY2FuIG9wZW4gYSBzbWFsbCBHUCBzdXJnZXJ5ICg9ZGVwbG95IElQdjYp LCB3aXRob3V0IGJvdGhlcmluZyB0byB0ZWxsIHRoZW0gd2h5IHRoZXkgbmVlZCBhbGwgdGhhdCBt YWNoaW5lcnkgYW5kIHdoYXQgdGhleSdyZSBzdXBwb3NlZCB0byBkbyB3aXRoIGl0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300490B99AOPEXCLILM23corp_-- From nobody Mon Feb 16 01:23:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731821A8760 for ; Mon, 16 Feb 2015 01:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.049 X-Spam-Level: ** X-Spam-Status: No, score=2.049 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FB_GET_MEDS=2.75, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg_I8P6Xd179 for ; Mon, 16 Feb 2015 01:23:17 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F851A8771 for ; Mon, 16 Feb 2015 01:23:11 -0800 (PST) Received: from [85.158.136.35] by server-17.bemta-5.messagelabs.com id FF/DC-03132-EF6B1E45; Mon, 16 Feb 2015 09:23:10 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-125.messagelabs.com!1424078589!35987023!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5065 invoked from network); 16 Feb 2015 09:23:09 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-16.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Feb 2015 09:23:09 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Mon, 16 Feb 2015 09:23:07 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 16 Feb 2015 09:23:08 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:23:03 +0000 From: "Heatley, Nick" To: Lorenzo Colitti , Ross Chandler Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? Thread-Index: AdBF852OT93fqpMASLCB8yKRPPF6QABHu1kAAB3XhwAAAwysgAACEdnQABXk0AAAFtSIAABXhFiAAAXD/SA= Date: Mon, 16 Feb 2015 09:23:02 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E07EE2UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:23:20 -0000 --_000_6536E263028723489CCD5B6821D4B21303E07EE2UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCkZvY3VzaW5nIG9uIGEpIHdoYXQgZG8geW91IHN1Z2dlc3Q/DQpIYXZlIHlvdSBh bm90aGVyIHdheT8NCg0KVGhlIGRpc2FwcG9pbnRlZCBmb3IgbWUgaW4gdGhlIGRpc2N1c3Npb24g YWJvdXQgdGhpcyBjb21tb24gcmVxdHMgcGFwZXIgaXMgbm90IHRoYXQgdGhlcmUgYXJlIGEgZmV3 IHN0cm9uZyB2b2ljZXMgcmVqZWN0aW5nIHRoaXMgaW5pdGlhdGl2ZS4NCkl0IGlzIHRoYXQgdGhl cmUgYXJlIG5vIHZvaWNlcyBvZiBzdXBwb3J0LiBBcyBJIHRoaW5rIHlvdSBoYXZlIHBvaW50ZWQg b3V0LCB0aGVyZSBpcyBsaXR0bGUgc3VwcG9ydCBiZXlvbmQgdGhlIGF1dGhvcnMuDQooQmV5b25k IHRoYXQgdGhlIHNpbGVuY2UgaXMgZGVhZmVuaW5nLikNCk5pY2sNCg0KDQpGcm9tOiBMb3Jlbnpv IENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQpTZW50OiAxNiBGZWJydWFyeSAy MDE1IDA2OjExDQpUbzogUm9zcyBDaGFuZGxlcg0KQ2M6IEhlYXRsZXksIE5pY2s7IElQdjYgT3Bz IFdHICh2Nm9wc0BpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtbW9iaWxlLWRldmljZS1wcm9maWxlIGxhc3QgY2FsbC0gImhhcm1mdWxseSBicm9hZCI/DQoN Ck9rLCBhbmQgdG8gY29udGludWUgdGhlIGFuYWxvZ3ksIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiB0 byBjb252aW5jZSBCaWcgUGhhcm1hIHRvIGRvIHdoYXQgdGhlIEdQcyBuZWVkIGlzIHRvIGdldCBh IG1lZGljYWwgc3RhbmRhcmRzIG9yZ2FuaXphdGlvbiAobm90IGV2ZW4gYSBHUCBjb25zb3J0aXVt ISkgdG8gcHVibGlzaCBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHNheXMgInRoaXMgZG9jdW1l bnQgaXMgbm90IGEgc3RhbmRhcmQsIGFuZCBjb21wbGlhbmNlIHdpdGggdGhpcyBkb2N1bWVudCBp cyBub3QgcmVxdWlyZWQsIGJ1dCBpZiB5b3UgaGF2ZW4ndCB5ZXQgc3RvcHBlZCByZWFkaW5nLCBo ZXJlJ3MgYSBwcm9maWxlIDMwIGZlYXR1cmVzIGxvbmcgdGhhdCB5b3UgbWlnaHQgd2FudCB0byBp bXBsZW1lbnQgaWYgeW91IGZlZWwgbGlrZSBpdCIuIEkgZG9uJ3Qgc2VlIGhvdyB0aGF0IHdpbGwg aGVscCBhdCBhbGwuDQoNClRoZSB3YXkgSSBzZWUgaXQsIHRoZSBvbmx5IGltcG9ydGFudCBpc3N1 ZXMgaGVyZSBhcmUgYSkgYWJzZW50IHN0cm9uZyBvcGVyYXRvciByZXF1aXJlbWVudHMsIGRldmlj ZSBtYW51ZmFjdHVyZXJzIGRvIG5vdCBhbHdheXMgaW1wbGVtZW50IElQdjYgaW4gYWxsIHByb2R1 Y3RzIG9uIGFsbCByZWdpb25zLCBhbmQgYikgaU9TIGRvZXMgbm90IGltcGxlbWVudCA0NjR4bGF0 Lg0KDQpJZiB5b3Ugd2FudCB0byBlZmZlY3QgbWVhbmluZ2Z1bCBjaGFuZ2UsIEknZCBzdWdnZXN0 IGZvY3VzaW5nIG9uIHRob3NlIGlzc3VlcyBpbnN0ZWFkLg0KDQpPbiBTYXQsIEZlYiAxNCwgMjAx NSBhdCA0OjI1IEFNLCBSb3NzIENoYW5kbGVyIDxyb3NzQGVpcmNvbS5uZXQ8bWFpbHRvOnJvc3NA ZWlyY29tLm5ldD4+IHdyb3RlOg0KDQpPbiAxNCBGZWIgMjAxNSwgYXQgMDE6MzEsIExvcmVuem8g Q29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3 cm90ZToNCg0KT24gRnJpLCBGZWIgMTMsIDIwMTUgYXQgNzoyOSBBTSwgSGVhdGxleSwgTmljayA8 bmljay5oZWF0bGV5QGVlLmNvLnVrPG1haWx0bzpuaWNrLmhlYXRsZXlAZWUuY28udWs+PiB3cm90 ZToNCkxvcmVuem8sIEkgZmVlbCB5b3UgYXJlIGxpa2UgdGhlIHNwZWNpYWxpc3Qgc3VyZ2VvbiBi ZXJhdGluZyB0aGUgR1BzIGZvciBub3Qga25vd2luZyBldmVyeSBSRkMgaW4gaXRzIHB1cmUgZm9y bS4NCg0KTm8sIEkgYW0gYmVyYXRpbmcgdGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBmb3Igd3Jp dGluZyBhIGRvY3VtZW50IHRoYXQgbWFrZXMgR1BzICg9ZGV2aWNlIG1hbnVmYWN0dXJlcnMsIG90 aGVyIG5ldHdvcmsgb3BlcmF0b3JzKSBiZWxpZXZlIHRoYXQgdGhleSBoYXZlIHRvIHByZXBhcmUg bG9hZHMgb2YgdW5uZWNlc3NhcnkgbWVkaWNhbCBtYWNoaW5lcnkgKD10aGUgbWFueSByZWNvbW1l bmRhdGlvbnMgdGhhdCB0aGlzIGRyYWZ0IG1ha2VzKSBiZWZvcmUgdGhleSBjYW4gb3BlbiBhIHNt YWxsIEdQIHN1cmdlcnkgKD1kZXBsb3kgSVB2NiksIHdpdGhvdXQgYm90aGVyaW5nIHRvIHRlbGwg dGhlbSB3aHkgdGhleSBuZWVkIGFsbCB0aGF0IG1hY2hpbmVyeSBhbmQgd2hhdCB0aGV54oCZcmUg c3VwcG9zZWQgdG8gZG8gd2l0aCBpdC4NCg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGFuYWxvZ3kgSSBj bGFzc2lmeSB0aGUgZGV2aWNlIG1hbnVmYWN0dXJlcnMgYXMgbWVtYmVycyBvZiBCaWcgUGhhcm1h LCBub3QgYXMgR1BzLiAgVGhlIHNtYWxsIGNvdW50cnkgR1BzIGFyZSBmYWNlZCB3aXRoIGJ1eWlu ZyBlcXVpcG1lbnQvZmVhdHVyZXMgKGR1YWwtc3RhY2sgdmFjY2luYXRpb24pIHRvIGNvbXBlbnNh dGUgZm9yIGRlZmljaWVuY2llcyBiZXR3ZWVuIG5ldHdvcmsrZGV2aWNlcyB0aGV5IGdldCBmcm9t IHRoZWlyIHZlbmRvcnMuIFVudGlsIHNvbWUgcGF5aW5nIGN1c3RvbWVyIGRlbWFuZCBhcmlzZXMg dGhhdCBnZXRzIHRoZSBHUOKAmXMgQmFuayBNYW5hZ2VyIGludGVyZXN0ZWQgaW4gaGVscGluZyB0 byBwdXNoIHRocm91Z2ggdGhlIGRldmVsb3BtZW50IHRvIHByb2R1Y3Rpb24gc2VydmljZXMgdGhl IEdQIGhhcyBsaXR0bGUgaW5jZW50aXZlIHRvIHRyeSB0byBtb3ZlIGZvcndhcmQgKGdvdCBhIHdv cmtzIG9yZGVyIGZvciB0aGF0PyBubyBkaWRu4oCZdCB0aGluayBzbykgdW5sZXNzIGhlIGFsc28g aGFwcGVucyB0byBiZSBhbiAgSVB2NiDigJx1bHRyYS1nZWVr4oCdLg0KDQpBIGxvdCBvZiBzcGVj aWZpYyBpbnB1dCBoYXMgYmVlbiB0YWtlbiBvbiBib2FyZC4gVGhlIGxpc3Qgb2YgcmVjb21tZW5k YXRpb25zIGhhcyBiZWVuIHBhaXJlZCByaWdodCBiYWNrIGFuZCB0aGV5IGFyZSBpbiBvcmRlciBv ZiBwcmlvcml0eSBhbmQgdGhlcmUgYXJlIGV4cGxhbmF0aW9ucyBpbiB0aGUgZG9jdW1lbnQuDQoN Cg0KUm9zcw0KDQoNCg0KDQoNCg0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWls IChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5h bWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIg c3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0K V2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3 aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRo YXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1 dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBk byBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0K UmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBI YXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcuDQo= --_000_6536E263028723489CCD5B6821D4B21303E07EE2UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo4MDAwMDE1NjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xODI2NTU4MDggMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3 NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODIyNDI2Nzk2Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjE5NzkyNDAy IC04NjAzMjgyNjIgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgw NzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Mb3JlbnpvLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkZvY3VzaW5nIG9uIGEpIHdoYXQgZG8geW91IHN1Z2dlc3Q/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhdmUgeW91IGFub3RoZXIgd2F5PzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIGRpc2FwcG9pbnRlZCBmb3IgbWUgaW4gdGhlIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBjb21t b24gcmVxdHMgcGFwZXIgaXMgbm90IHRoYXQgdGhlcmUgYXJlIGEgZmV3IHN0cm9uZyB2b2ljZXMg cmVqZWN0aW5nIHRoaXMgaW5pdGlhdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SXQgaXMgdGhhdCB0aGVyZSBhcmUgbm8gdm9pY2VzIG9mIHN1cHBvcnQuIEFzIEkgdGhpbmsgeW91 IGhhdmUgcG9pbnRlZCBvdXQsIHRoZXJlIGlzIGxpdHRsZSBzdXBwb3J0IGJleW9uZCB0aGUgYXV0 aG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEJleW9uZCB0aGF0IHRoZSBzaWxl bmNlIGlzIGRlYWZlbmluZy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5pY2s8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29s aXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNiBG ZWJydWFyeSAyMDE1IDA2OjExPGJyPg0KPGI+VG86PC9iPiBSb3NzIENoYW5kbGVyPGJyPg0KPGI+ Q2M6PC9iPiBIZWF0bGV5LCBOaWNrOyBJUHY2IE9wcyBXRyAodjZvcHNAaWV0Zi5vcmcpPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlIGxhc3QgY2FsbC0gJnF1b3Q7aGFybWZ1bGx5IGJyb2FkJnF1b3Q7PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PaywgYW5kIHRvIGNvbnRpbnVl IHRoZSBhbmFsb2d5LCB0aGUgcHJvcG9zZWQgc29sdXRpb24gdG8gY29udmluY2UgQmlnIFBoYXJt YSB0byBkbyB3aGF0IHRoZSBHUHMgbmVlZCBpcyB0byBnZXQgYSBtZWRpY2FsIHN0YW5kYXJkcyBv cmdhbml6YXRpb24gKG5vdCBldmVuIGEgR1AgY29uc29ydGl1bSEpIHRvIHB1Ymxpc2ggYW4gaW5m b3JtYXRpb25hbCBkb2N1bWVudCBzYXlzICZxdW90O3RoaXMgZG9jdW1lbnQgaXMgbm90DQogYSBz dGFuZGFyZCwgYW5kIGNvbXBsaWFuY2Ugd2l0aCB0aGlzIGRvY3VtZW50IGlzIG5vdCByZXF1aXJl ZCwgYnV0IGlmIHlvdSBoYXZlbid0IHlldCBzdG9wcGVkIHJlYWRpbmcsIGhlcmUncyBhIHByb2Zp bGUgMzAgZmVhdHVyZXMgbG9uZyB0aGF0IHlvdSBtaWdodCB3YW50IHRvIGltcGxlbWVudCBpZiB5 b3UgZmVlbCBsaWtlIGl0JnF1b3Q7LiBJIGRvbid0IHNlZSBob3cgdGhhdCB3aWxsIGhlbHAgYXQg YWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgd2F5IEkgc2VlIGl0LCB0aGUgb25seSBpbXBvcnRhbnQgaXNzdWVzIGhlcmUgYXJlIGEp IGFic2VudCBzdHJvbmcgb3BlcmF0b3IgcmVxdWlyZW1lbnRzLCBkZXZpY2UgbWFudWZhY3R1cmVy cyBkbyBub3QgYWx3YXlzIGltcGxlbWVudCBJUHY2IGluIGFsbCBwcm9kdWN0cyBvbiBhbGwgcmVn aW9ucywgYW5kIGIpIGlPUyBkb2VzIG5vdCBpbXBsZW1lbnQgNDY0eGxhdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdhbnQgdG8g ZWZmZWN0IG1lYW5pbmdmdWwgY2hhbmdlLCBJJ2Qgc3VnZ2VzdCBmb2N1c2luZyBvbiB0aG9zZSBp c3N1ZXMgaW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gU2F0LCBGZWIgMTQsIDIwMTUgYXQgNDoyNSBBTSwgUm9zcyBDaGFuZGxl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvc3NAZWlyY29tLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJv c3NAZWlyY29tLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTQgRmViIDIwMTUsIGF0IDAxOjMx LCBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBGZWIgMTMsIDIwMTUgYXQgNzoyOSBBTSwgSGVhdGxleSwgTmljayAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPm5pY2suaGVhdGxl eUBlZS5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TG9yZW56bywgSSBmZWVsIHlvdSBhcmUgbGlrZSB0aGUgc3BlY2lhbGlzdCBzdXJnZW9u IGJlcmF0aW5nIHRoZSBHUHMgZm9yIG5vdCBrbm93aW5nIGV2ZXJ5IFJGQyBpbiBpdHMgcHVyZSBm b3JtLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIEkg YW0gYmVyYXRpbmcgdGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBmb3Igd3JpdGluZyBhIGRvY3Vt ZW50IHRoYXQgbWFrZXMgR1BzICg9ZGV2aWNlIG1hbnVmYWN0dXJlcnMsIG90aGVyIG5ldHdvcmsg b3BlcmF0b3JzKSBiZWxpZXZlIHRoYXQgdGhleSBoYXZlIHRvIHByZXBhcmUgbG9hZHMgb2YgdW5u ZWNlc3NhcnkgbWVkaWNhbCBtYWNoaW5lcnkgKD10aGUgbWFueSByZWNvbW1lbmRhdGlvbnMgdGhh dA0KIHRoaXMgZHJhZnQgbWFrZXMpIGJlZm9yZSB0aGV5IGNhbiBvcGVuIGEgc21hbGwgR1Agc3Vy Z2VyeSAoPWRlcGxveSBJUHY2KSwgd2l0aG91dCBib3RoZXJpbmcgdG8gdGVsbCB0aGVtIHdoeSB0 aGV5IG5lZWQgYWxsIHRoYXQgbWFjaGluZXJ5IGFuZCB3aGF0IHRoZXnigJlyZSBzdXBwb3NlZCB0 byBkbyB3aXRoIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIHRoaXMgcGFydGljdWxhciBhbmFsb2d5IEkgY2xhc3NpZnkgdGhlIGRldmlj ZSBtYW51ZmFjdHVyZXJzIGFzIG1lbWJlcnMgb2YgQmlnIFBoYXJtYSwgbm90IGFzIEdQcy4mbmJz cDsgVGhlIHNtYWxsIGNvdW50cnkgR1BzIGFyZSBmYWNlZCB3aXRoIGJ1eWluZyBlcXVpcG1lbnQv ZmVhdHVyZXMgKGR1YWwtc3RhY2sgdmFjY2luYXRpb24pIHRvIGNvbXBlbnNhdGUgZm9yIGRlZmlj aWVuY2llcyBiZXR3ZWVuIG5ldHdvcmsmIzQzO2RldmljZXMNCiB0aGV5IGdldCBmcm9tIHRoZWly IHZlbmRvcnMuIFVudGlsIHNvbWUgcGF5aW5nIGN1c3RvbWVyIGRlbWFuZCBhcmlzZXMgdGhhdCBn ZXRzIHRoZSBHUOKAmXMgQmFuayBNYW5hZ2VyIGludGVyZXN0ZWQgaW4gaGVscGluZyB0byBwdXNo IHRocm91Z2ggdGhlIGRldmVsb3BtZW50IHRvIHByb2R1Y3Rpb24gc2VydmljZXMgdGhlIEdQIGhh cyBsaXR0bGUgaW5jZW50aXZlIHRvIHRyeSB0byBtb3ZlIGZvcndhcmQgKGdvdCBhIHdvcmtzIG9y ZGVyIGZvciB0aGF0Pw0KIG5vIGRpZG7igJl0IHRoaW5rIHNvKSB1bmxlc3MgaGUgYWxzbyBoYXBw ZW5zIHRvIGJlIGFuICZuYnNwO0lQdjYg4oCcdWx0cmEtZ2Vla+KAnS4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbG90IG9mIHNw ZWNpZmljIGlucHV0IGhhcyBiZWVuIHRha2VuIG9uIGJvYXJkLiBUaGUgbGlzdCBvZiByZWNvbW1l bmRhdGlvbnMgaGFzIGJlZW4gcGFpcmVkIHJpZ2h0IGJhY2sgYW5kIHRoZXkgYXJlIGluIG9yZGVy IG9mIHByaW9yaXR5IGFuZCB0aGVyZSBhcmUgZXhwbGFuYXRpb25zIGluIHRoZSBkb2N1bWVudC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlJvc3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQoNCjxQPk5PVElDRSBBTkQgRElTQ0xBSU1FUjxCUj5UaGlzIGUtbWFpbCAoaW5jbHVk aW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgDQpmb3IgdGhlIGFib3ZlLW5hbWVkIHBl cnNvbihzKS4mbmJzcDsgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgDQpu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3Vy IHN5c3RlbSBhbmQgZG8gbm90IA0KZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4mbmJz cDsgPEJSPiZuYnNwOzxCUj5XZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgDQphbmQgb3V0Z29p bmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2Vu IHN0ZXBzIHRvIA0KZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZy ZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIA0KeW91ciByZXNwb25zaWJpbGl0eSB0 byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gPC9QPg0K PFA+RUUgTGltaXRlZDxCUj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzPEJSPkNvbXBh bnkgUmVnaXN0ZXJlZCBOdW1iZXI6IA0KMDIzODIxNjE8QlI+UmVnaXN0ZXJlZCBPZmZpY2UgQWRk cmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgDQpIZXJ0Zm9yZHNo aXJlLCBBTDEwIDlCVzwvUD4NCjxQPiZuYnNwOzwvUD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6536E263028723489CCD5B6821D4B21303E07EE2UK30S005EXS06EE_-- From nobody Mon Feb 16 01:29:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE41A8786 for ; Mon, 16 Feb 2015 01:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.901 X-Spam-Level: * X-Spam-Status: No, score=1.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM-w7NFzQ_9a for ; Mon, 16 Feb 2015 01:29:13 -0800 (PST) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD251A8782 for ; Mon, 16 Feb 2015 01:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424078952; bh=wbYF494IX9o79OVAQLyxWjb7lBBXgeLQAQKMlsgXg0k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=N0r4znmJ9W5EpP6fgl13p4r+byEzGXJ5wYMIyvYNkMAPbZzX421yUZrAwr3gG0hBCk/z+vxvdYoOgq0l1T2CPy3ylONPtFuESG6sUL2uyHcTP34BvGJSRxElkyPr9Otv87NrN+uI1JikeGKPAmdKVacOJRo7nO3BE0m42lecfRUa75NaKZA2BSJyKiMcCEZo60/ea4J7NbITIPU1vmpQFbGFepWYFEqG8hTI48ZEnLma0AtsZhq9JWIbfXVJIGRqhpD2pYb5kNFGNHOUj3/DS6YlzErZOcqWvQBEMUDcMaQncrrjWDcub8kYasNf4XmVErEWd432yXP3MAaIMQ41Ug== Received: from [98.139.215.143] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 09:29:12 -0000 Received: from [98.139.212.215] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 09:29:12 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 09:29:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 214121.61984.bm@omp1024.mail.bf1.yahoo.com X-YMail-OSG: GSGJkJsVM1n0XkY3fP2vBzxBmlFadZfP4FQnQp0HqSqx762aLrUwwSnMPzFLjCp WB5ICyajd5I31zZXhJ7U0jRYnj3_KngqmUq5YT_MXr6fQGX.EQng9DhfHis3SEdaIhO0I1OC74ZG _wM3M1x8CDGQc9U_o.xc37BHiURiitQOZxGpic9pPLBpnZfz2hiDzgvMFtAht6qKprwDOTHTaJBX m6noALiuYK_fEm.ShIcPDWlsE2V8QLNuLMS0iuHupLoQkKmwq29IqjBQ2RfI4eYb5.0tya4Tfr3P Fl_HIj6aEBtulI6wbkA4x.b.gk5aJJ9d9dvJwzqyCcQdvIRFMx5tLWgynmttmr1Y7M6SW1l6xDfh .7.OxL7wTypGNez2clHVf9QO9vgEv1tVI7nZZakHJH80zevCavWs.mn3zZL1KU4xd32rb7bQgzgU 4b2.X895eTY6TPhlw0NXC2InwsPtPH0OaCGmmfP1vhf81L1OGQqwfem.WzPojNWsrkcY6diRVOwn RbzoEuiYSnoyZKBBYiqjs9pib8X4F0O0mALS7w7C4MsNOcNQ- Received: by 66.196.81.106; Mon, 16 Feb 2015 09:29:11 +0000 Date: Mon, 16 Feb 2015 09:29:10 +0000 (UTC) From: Mark ZZZ Smith To: Erik Kline , Lorenzo Colitti Message-ID: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Edward Lewis , "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:29:14 -0000 So the author of the new proposal is from ICANN. They're don't provide a reference, however they seem to proposing this use case as one purpose (the "ICANN's Controlled Interruption" referred to): https://www.icann.org/resources/pages/name-collision-2013-12-06-en "127.0.53.53 127.0.53.53 is a special IPv4 address that will appear in system logs alerting system administrators that there is potential name collision issue, enabling a quick diagnosis and remediation. The "53" is used as a mnemonic to indicate a DNS-related problem owing to the use of network port 53 for the DNS service." Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 special address registry. It should be, however as they didn't consult the IETF, it seems it also didn't go to IANA (a department of ICANN!). ( https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf) I'd strongly object to them attempting to do the same thing with an larger IPv6 loopback prefix. A loopback prefix is local to the host it appears on, and is not globally unique. Consequently, all addresses within the prefix should be available for use on the local host for what ever purpose the local host or its user decides. There should be no hidden reserved values with special global meaning. If ICANN want to do the above for IPv6, they should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefix. There is plenty of IPv6 space to do so, rather than creating a single address exception out of a block of addresses that has or would have a well known expected purpose and behaviour. Regards, Mark (author of below) ----- Original Message ----- From: Erik Kline To: Lorenzo Colitti Cc: Edward Lewis ; "v6ops@ietf.org" Sent: Monday, 16 February 2015, 18:09 Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt > IIRC this idea has come up at least once before, and maybe more (not sure > where - perhaps in v6ops?). I don't oppose it - in fact, I think it's a good > idea - but since the previous attempt(s) never came to anything, I assume > there was no consensus that this is useful. Yep. 1::/32. https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04#section-3 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 16 01:39:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B431A8793 for ; Mon, 16 Feb 2015 01:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npG2xXru3-Eo for ; Mon, 16 Feb 2015 01:39:22 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EE41A1A98 for ; Mon, 16 Feb 2015 01:39:21 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so9705317qcx.13 for ; Mon, 16 Feb 2015 01:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=wOMb/e0wE538dm7CMzVmBERv7f4MDzq3hUb1DbOtLnU=; b=ERNFiXIcudtfYKB+7UaTZ+TWccvp07En8KZ5NnVr9fkjF8xCiEbUL9UgZKgr3jARW+ WWKneCXmw82jDx+YRSxmoAvm2YLVRbq+9US+stKg2PY5sUd9cgp1XHBOXqhtN+lJtfMc 6fG973dMW8oF10pNrDm9n5Y+P9EpnaMESagGYedryCZ33rvSQppwG48VMlj9wXl8X5Et 7JJ0Y22j4OhpJCnooRiDGs5LdnuD9DbElUd+vNj6mQoQY5wwpc7FizmlsU1kkwc0OrlG pz6K3j4Yj3o8xAYiEg6ZI0r9g/HOoFMuHjZ3XADsnB5XF7t5KgFqm0ziH4FyyLQr33VK Hihw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=wOMb/e0wE538dm7CMzVmBERv7f4MDzq3hUb1DbOtLnU=; b=DPk5lqdBJuJOzdxjeON3lsr0IF96UTIy0yqC1sh/FSg6YS0BmRNnTWAyaVNVYHHtCr UUhWHov22WfTFBS0Nybk9pzgmtzBnYWlWn6Gm/fqkNoOE72GYriTuWe2XbnVEOcnW/7E 0V5O4jg8rS5hwe5iI+6ySRs1It4jckHUhRp/HHheg4HuoQa84tPTYOE+O6HkBUk2gQHF W3d2wg3TJ4D1T+vKBJ6+m5y/KfM8KGyComlblLXAEFrYwbg8lfJbVTADXLlN9DVRVmVb HDZYlEiN5vve8DL3kMiOLL2/2c/9rniga6B1Ho9O+V98XnSHGuLTQic3j5Ud7885l1VM FL4A== X-Gm-Message-State: ALoCoQkhFwArNZsFCJ/jVO87peK2qLkq5aNze3fTjALNFxQ5uPVImTb1KniCiEkxXggsGlacsFU8 X-Received: by 10.229.216.71 with SMTP id hh7mr824200qcb.0.1424079560388; Mon, 16 Feb 2015 01:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.2 with HTTP; Mon, 16 Feb 2015 01:39:00 -0800 (PST) In-Reply-To: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> From: Erik Kline Date: Mon, 16 Feb 2015 18:39:00 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Edward Lewis , "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:39:23 -0000 > If ICANN want to do the above for IPv6, they should instead reserve a new= IPv6 prefix, similar to how RFC6666 defines a special purpose discard pref= ix. There is plenty of IPv6 space to do so, rather than creating a single a= ddress exception out of a block of addresses that has or would have a well = known expected purpose and behaviour. Ah, then perhaps they could even just use 0100::53:53 (or 0100::35:35). From nobody Mon Feb 16 02:23:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A061A87A1 for ; Mon, 16 Feb 2015 02:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSHgfvyRm24h for ; Mon, 16 Feb 2015 02:23:09 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC131A8793 for ; Mon, 16 Feb 2015 02:23:08 -0800 (PST) Received: from [2a02:fe0:c410:c430::2] (port=40668 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YNIpW-0003qF-56; Mon, 16 Feb 2015 11:23:06 +0100 Date: Mon, 16 Feb 2015 11:23:05 +0100 From: Tore Anderson To: Alexandru Petrescu Message-ID: <20150216112305.375cdf9b@envy.fud.no> In-Reply-To: <54E0F83F.3020403@gmail.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:23:11 -0000 * Alexandru Petrescu > YEs, the APN type can be "IPv4IPv6", or something named like that. >=20 > Except that the 464xlat networks I am aware of to only "IPv6" kind of > APN. =C2=AB464XLAT networks=C2=BB doesn't really exist. The provider's network is simply IPv6-only, in addition to offering Stateful NAT64 (RFC6146) in addition to provisioning the customer with a DNS64-enabled resolver (RFC6147). 464XLAT exists entirely inside the customer's device. In other words, the operator does not need to configure or provision anything beyond Stateful NAT64 + DNS64 for 464XLAT to function. Stateful NAT64 + DNS64 works just fine without 464XLAT as well, only that IPv4 literals do not work, nor does applications that does not use DNS or that hard-code the use of AF_INET network sockets. > In the past some of these networks were IPv4IPv6, but now they move to=20 > IPv6-only kind of type, and 464xlat/clat is given as reason why. I think you've got this the wrong way around. 464XLAT was developed to make the IPv6-only APN type work well enough for the general populace. At that point the IPV4V6 APN type didn't really work well enough because it was too new and poorly supported, while the IPV6 type is older and is well supported. With the advent of LTE networks, this situation is changing. My own provider Telenor is now moving from IPV6+v4CGN(NAT64/DNS64)+464XLAT to IPV4V6+v4CGN(NAT44), for example. I guess the biggest advantage of this latter approach is that it works with Apple devices. Tore From nobody Mon Feb 16 02:43:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D61A877F for ; Mon, 16 Feb 2015 02:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNIZoFdTK-Ss for ; Mon, 16 Feb 2015 02:42:56 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC481A8793 for ; Mon, 16 Feb 2015 02:42:56 -0800 (PST) Received: from [194.106.220.35] by server-7.bemta-14.messagelabs.com id D2/AB-03172-EA9C1E45; Mon, 16 Feb 2015 10:42:54 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-91.messagelabs.com!1424083373!16371248!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14663 invoked from network); 16 Feb 2015 10:42:54 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Feb 2015 10:42:54 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id ; Mon, 16 Feb 2015 10:42:52 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 16 Feb 2015 10:42:52 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 10:42:53 +0000 From: "Heatley, Nick" To: Tore Anderson , Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZztaWAAgAEZwwCAAIq9AIADFVeAgAD0IICAAAR0kA== Date: Mon, 16 Feb 2015 10:42:52 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303E07F6F@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> In-Reply-To: <20150216112305.375cdf9b@envy.fud.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:42:59 -0000 V2l0aCB0aGUgYWR2ZW50IG9mIExURSBuZXR3b3JrcywgdGhpcyBzaXR1YXRpb24gaXMgY2hhbmdp bmcuIE15IG93biBwcm92aWRlciBUZWxlbm9yIGlzIG5vdyBtb3ZpbmcgZnJvbSBJUFY2K3Y0Q0dO KE5BVDY0L0ROUzY0KSs0NjRYTEFUIHRvDQpJUFY0VjYrdjRDR04oTkFUNDQpLCBmb3IgZXhhbXBs ZS4gSSBndWVzcyB0aGUgYmlnZ2VzdCBhZHZhbnRhZ2Ugb2YgdGhpcw0KbGF0dGVyIGFwcHJvYWNo IGlzIHRoYXQgaXQgd29ya3Mgd2l0aCBBcHBsZSBkZXZpY2VzLg0KDQpbSGVhdGxleSwgTmlja10g QW5kIGRvbid0IGZvcmdldCB0aGUgZGlzYWR2YW50YWdlLCB5b3Ugb2ZmaWNpYWxseSBoYXZlIDIw TSB1bmlxdWUgSVB2NCBhZGRyZXNzZXMgb24gdGhlIGluc2lkZSwgYmVmb3JlIHByaXZhdGUgYWRk cmVzcyBleGhhdXN0aW9uIG1lYW5zIHlvdSBoYXZlIHRvIGxvb2sgZm9yIGFub3RoZXIgbmV0d29y ayBjbHVkZ2UuDQpObyBuZWVkIGZvciBJUHY0IHdpdGggNDY0WExBVC4NCg0KVG9yZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGlu ZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNv bihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1v bml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJl bnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBl bWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1h aW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2 ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFRSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg YW5kIFdhbGVzDQpDb21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJl ZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwg SGVydGZvcmRzaGlyZSwgQUwxMCA5QlcuDQo= From nobody Mon Feb 16 02:47:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6865F1A877F for ; Mon, 16 Feb 2015 02:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.085 X-Spam-Level: * X-Spam-Status: No, score=1.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMekxdRYYuvR for ; Mon, 16 Feb 2015 02:47:51 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48B81A1AA1 for ; Mon, 16 Feb 2015 02:47:50 -0800 (PST) Received: from 10.236.62.154 (EHLO OPE10HT06.tp.gk.corp.tepenet) ([10.236.62.154]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DBL49364; Mon, 16 Feb 2015 11:47:46 +0100 (CET) From: Kossut Tomasz - Hurt To: BOUCADAIR Mohamed IMT/OLN , "Alexandru Petrescu" , "Heatley, Nick" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQSbedet4Jjc/nekOWukSYZ6hl8JzzD5+A Date: Mon, 16 Feb 2015 10:47:45 +0000 Message-ID: References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.2.16.100622:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, REFERENCES X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0205.54E1CAD2.03A2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0205.54E1CAD2.03A2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 404d7d34ee41fabaf27bc96f6142f182 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:47:53 -0000 SGksDQpJUHY2LW9ubHkgKyBDTEFUK05BVDY0KG5vIGRuczY0KSBpcyB1c2VkIGluIE9yYW5nZSBQ b2xhbmQgLSBzb21ld2hlcmV+IDMwJSBtb2JpbGUgdXNlcnMuIFlvdSB3b24ndCBzZWUgdGhpcyBp biB3b3JsZHdpZGUgSVB2NiBzdGF0cyB7Ik5vLiIgb2YgSVB2NiB1c2VycyBhcmUgbWVhc3VyZWQg Zm9ybSB0cmFmZmljIC1pcHY0L2lwdjYgLSB0eXBpY2FsIG1vYmlsZSB1c2VyIChzbWFydHBob25l KSBnZW5lcmF0ZXMgdXAgdG8gNiB0aW1lcyBsb3dlciB0cmFmZmljIGNvbXBhcmluZyB0byBsaW5l cyB1c2Vycy4ufSANCg0KQXNzdW1pbmcgb3VyIGV4cGVyaWVuY2U6DQoxLiBUaGUgYmVzdCBmb3Ig bW9iaWxlIG5vd2FkYXlzIGlzIENMQVQrUExBVCtETlMgDQoqT25lIHBhdGggZm9yIElQdjQgdHJh ZmZpYyAoYWx3YXlzIHZpYSBDTEFUKQ0KKkFMR+KAmXMgdHJlYXRlZCBhcyBOQVQ0NA0KKklQdjQg bGl0ZXJhbCAmIGRvbWFpbiB1c2Ugc2FtZSBwYXRoDQoqT25lIHBhdGggZm9yIElQdjYgdHJhZmZp YyAobmF0aXZlIElQdjYpDQoqTW90aXZhdGlvbiBmb3IgbmF0aXZlIElQdjYgY29udGVudA0KKkFw cGxpY2F0aW9uIGFkZHJlc3MgZmFtaWx5IGluZGVwZW5kZW50DQoqNjUlIC0gdHJhZmZpYyBmcm9t IHN1YnNjcmliZXJzIGlzIG5hdGl2ZSBJUHY2DQoqR29vZ2xlIE5leHVzLCBTb255LEhUQywgU2Ft dW5nLExHLCBXaW5kb3dzUGhvbmUsIHN1cHBvcnRzIENMQVQuDQoNCkNoZWVycywNCnRrDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXSANClNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMTYsIDIwMTUgNzo0MyBBTQ0KVG86IEFsZXhhbmRydSBQZXRyZXNjdTsgSGVh dGxleSwgTmljaw0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xNy50eHQgLSBD X1JFQyM5IDQ2NFhMQVQNCg0KSGkgQWxleCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVy cywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEFsZXhhbmRydSBQ ZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb21dDQpFbnZvecOpwqA6 IHZlbmRyZWRpIDEzIGbDqXZyaWVyIDIwMTUgMTc6MTMNCsOAwqA6IEhlYXRsZXksIE5pY2s7IEJP VUNBREFJUiBNb2hhbWVkIElNVC9PTE4gQ2PCoDogdjZvcHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6 IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2Zp bGUtMTcudHh0IC0gQ19SRUMjOSA0NjRYTEFUDQoNCkxlIDEzLzAyLzIwMTUgMTY6MzMsIEhlYXRs ZXksIE5pY2sgYSDDqWNyaXQgOg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBG cm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgDQo+IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdt YWlsLmNvbV0gU2VudDogMTMgRmVicnVhcnkgMjAxNSAxNDozNQ0KPiBUbzogSGVhdGxleSwgTmlj azsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjoNCj4gZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUt ZGV2aWNlLXByb2ZpbGUtMTcudHh0IC0gQ19SRUMjOSA0NjRYTEFUDQo+DQo+IExlIDEzLzAyLzIw MTUgMTQ6MTQsIEhlYXRsZXksIE5pY2sgYSDDqWNyaXQgOg0KPj4gSGkgQWxleCwgWWVzLCB0aGF0 IGlzIHdyb25nLiBZb3UgY2FuIHBpbmcgYW55IElQdjQgbGl0ZXJhbCBmcm9tIGEgDQo+PiA0NjR4 bGF0IGRldmljZS4gTXkgaGFuZHNldCBvbmx5IGhhcyBhbiBJUHY2IGFkZHJlc3MgKyBDTEFUIGFu ZCBJIGFtIA0KPj4gcGluZ2luZyA4LjguOC44IDotKSkNCj4NCj4gT2ssIEkgc2VlLiAgSSBkaWRu dCBrbm93IENMQVQtb24tZGV2aWNlIHdhcyByZXF1aXJlZCB3aGVuIHVzaW5nIA0KPiB2Ni1vbmx5 IEFQTnMuDQo+DQo+IFtIZWF0bGV5LCBOaWNrXSBGb3Igc2VydmljZSBjb250aW51aXR5IHdpdGgg SVB2NCwgb24gYW4gSVB2Ni1vbmx5IA0KPiBiZWFyZXIgdXNlIENMQVQuIEEgc2xpZ2h0bHkgcGVk YW50aWMgbm90ZSwgIGlmIHlvdSBoYXZlIGEgImR1YWwgc3RhY2sgDQo+IEFQTiIgYnV0IHRoZSBk ZXZpY2Ugb25seSByZXF1ZXN0cyBJUHY2IHRoZW4gdGhlIGRldmljZSB3aWxsIHJlY2VpdmUgYW4g DQo+IElQdjYgYmVhcmVyIGFuZCByZXF1aXJlcyBDTEFULiBZb3Ugd2lsbCBoZWFyIGZyb20gUm9z cyBhbmQgbWUgdGFsa2luZyANCj4gYWJvdXQgaGF2aW5nIGEgc2luZ2xlIEFQTiBzdXBwb3J0aW5n IGFsbCBtb2RlcywgSVB2NCwgSVB2NHY2IGFuZCBJUHY2IA0KPiBiZWFyZXJzLiBUaGVyZSBtYXkg YmUgYnVzaW5lc3MgcmVhc29ucyBmb3IgdGhpcywgYXMgd2VsbCBhcyBhdm9pZGluZyANCj4gY29u c3VtZXJzIGhhdmluZyB0byBjaGFuZ2UgQVBOcy4NCg0KSW4gbXkgdW5kZXJzdGFuZGluZyA0NjR4 bGF0L2NsYXQgYXJlIHRyaWFscyB0aGVzZSBkYXlzLg0KDQpbTWVkXSBObywgaXQgaXMgaW4gdXNl IGluIGxpdmUgbmV0d29ya3MsIGluY2x1ZGluZyB3aXRoaW4gb3VyIEdyb3VwLg0KDQogIFRoZXkg Y291bGQgYmUNCmltcHJvdmVkIGJlZm9yZSBnb2luZyBsaXZlLiAgSWYgdGhlIDQ2NHhsYXQvY2xh dCBoYXBwZW5lZCBlbHNld2hlcmUgdGhhbiBvbiB0aGUgdXNlciB0ZXJtaW5hbCAoZS5nLiBCQXNl IFN0YXRpb24pIEkgdGhpbmsgbW9yZSBvZiB0aGVzZSB0ZXJtaW5hbHMgY291bGQgYmUgYWNjb21t b2RhdGVkLCBtb3JlIGJ1c2luZXNzLg0KDQpbTWVkXSBJZiBhbGwgYXBwbGljYXRpb25zIGFyZSBB Ri1pbmRlcGVuZGVudCAoaW5jbHVkaW5nIElQdjQgcmVmZXJyYWxzIGFyZSBub3QgaW4gdXNlIG9y IGFkZHJlc3Mgc3ludGhlc2lzIGEgbGEgUkZDNjA1MiBpcyBzdXBwb3J0ZWQpLCB0aGVuIENMQVQg Y2FuIGJlIGF2b2lkZWQuIFNvbWUgb3BlcmF0b3JzIHdhbnQgdG8gYWRvcHQgYW4gSVB2Ni1vbmx5 IGNvbm5lY3Rpdml0eSBtb2RlIGJ1dCB3aXRoIGEgY29uZGl0aW9uIHRvIHByb3ZpZGUgdGhlIHNh bWUgbGV2ZWwgb2Ygc2VydmljZSBhcyBJUHY0OyBGb3IgdGhvc2UgQ0xBVCBpcyBldmVuIGEgbXVz dC4gSXQgbWlnaHQgaGFwcGVuIHRoYXQgb3RoZXIgb3BlcmF0b3JzIGNhbiBqdWRnZSB0aGF0IHRo ZSBicm9rZW4gYXBwbGljYXRpb25zIHVuZGVyIGFuIElQdjYtb25seSBtb2RlICsgTkFUNjQgYXJl IG5vdCBpbXBvcnRhbnQ7IGZvciB0aG9zZSBDTEFUIGlzIG5vdCBuZWVkZWQuIFRoZXNlIHJlYXNv bnMsIGFtb25nIG90aGVycywgYXJlIHdoeSB3ZSBzZXQgdGhlIGxhbmd1YWdlIHRvICdzaG91bGQn LiANCg0KPiBUaGF0IG1lYW5zIHRoYXQgdGhlIGRldmljZSB2ZW5kb3JzIE1VU1QgaW1wbGVtZW50 IENMQVQgaW4gdGhlIA0KPiBzbWFydHBob25lcyB3aGljaCBjb25uZWN0IHRvIGEgdjYtb25seSBB UE4uICBJdCBpcyBhIHRvbyBzdHJvbmcgDQo+IHJlcXVpcmVtZW50Lg0KPg0KPiBbSGVhdGxleSwg Tmlja10gVG9kYXkncyByZWFsaXR5IGlzIHRoYXQgb3BlcmF0b3JzIGNhbm5vdCB0YWtlIGRldmlj ZXMgDQo+IHRvIElQdjYtb25seSBtb2RlIG9mIG9wZXJhdGlvbiB3aXRob3V0IENMQVQuIEluIHRo ZSBmdXR1cmUgd2lsbCBvdGhlciANCj4gYWx0ZXJuYXRpdmVzIGFwcGVhcj8NCg0KQWx0ZXJuYXRp dmVzIHRoZXJlIGFyZSB2ZXJ5IG1hbnkuDQoNCkUuZy4gNDY0bGF0L2NsYXQgdG8gcnVuIG9uIGFu IG9wZXJhdG9yLWNvbnRyb2xsZWQgbmV0d29yayBkZXZpY2UsIG5vdCBvbiBlbmQtdXNlciB0ZXJt aW5hbC4NCg0KRS5nLiB1c2UgYSB2NC1BUE4gYW5kIHY2LWluLXY0IGVuY2Fwc3VsYXRpb24gb24g dGhlIGVuZC11c2VyIGRldmljZS4NCg0KM0dQUCBhbHNvIGRlc2lnbmVkIGEgRFMtTUlQdjYsIG5v dCBzdXJlIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBpdC4gIEl0IGhhZCB0aGUgc2FtZSBnb2Fs IG9mIHRlcm1pbmFsIG9uIHY2LW9ubHkgbGluay4NCg0KW01lZF0gQWxsIHRob3NlIGFyZSBubyBv cHRpb25zIGluIHRoZSBtb2JpbGUgY29udGV4dC4gSVB2Ni1vbmx5ICsgTkFUNjQgaXMgdGhlIG1v ZGUgdGhhdCBpcyBjdXJyZW50bHkgYWRvcHRlZCBieSBzZXZlcmFsIG9wZXJhdG9ycy4gDQoNCg== From nobody Mon Feb 16 02:49:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B411A87A8 for ; Mon, 16 Feb 2015 02:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoIvqxpN1-PJ for ; Mon, 16 Feb 2015 02:49:38 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F08A1A877F for ; Mon, 16 Feb 2015 02:49:38 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C1E5160134 for ; Mon, 16 Feb 2015 11:49:36 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7B06560102 for ; Mon, 16 Feb 2015 11:49:36 +0100 (CET) Received: (qmail 35279 invoked by uid 1007); 16 Feb 2015 11:49:36 +0100 Date: Mon, 16 Feb 2015 11:49:36 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150216104936.GX34798@Space.Net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E0F83F.3020403@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:49:40 -0000 Hi, On Sun, Feb 15, 2015 at 08:49:19PM +0100, Alexandru Petrescu wrote: > In the past some of these networks were IPv4IPv6, but now they move to > IPv6-only kind of type, and 464xlat/clat is given as reason why. Care to elaborate? I do not know of a single case of a 3G/4G network moving from IPv4IPv6 to IPv6-only. Some deploy dual-stack, some deploy single-stack, and all for good reasons - but this is something different than "move to IPv6-only" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 16 02:56:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566071A87CD for ; Mon, 16 Feb 2015 02:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTxW5Km8pAA for ; Mon, 16 Feb 2015 02:56:50 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83D51A87BC for ; Mon, 16 Feb 2015 02:56:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GAuft7002264; Mon, 16 Feb 2015 11:56:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C509E208365; Mon, 16 Feb 2015 11:57:41 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B761720832A; Mon, 16 Feb 2015 11:57:41 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GAsfmu006769; Mon, 16 Feb 2015 11:56:41 +0100 Message-ID: <54E1CC71.2010108@gmail.com> Date: Mon, 16 Feb 2015 11:54:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tore Anderson References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> In-Reply-To: <20150216112305.375cdf9b@envy.fud.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:56:52 -0000 Le 16/02/2015 11:23, Tore Anderson a écrit : [...] > 464XLAT exists entirely inside the customer's device. What is the name of the software that must exist inside the customer's device? > In other words, the operator does not need to configure or provision > anything beyond Stateful NAT64 + DNS64 for 464XLAT to function. But it seems to mandate "464XLAT" to exist inside the customer's device, for IPv4-literals, and for non-DNS-based apps. > Stateful NAT64 + DNS64 works just fine without 464XLAT as well, only > that IPv4 literals do not work, nor does applications that does not > use DNS or that hard-code the use of AF_INET network sockets. Ok! I think that an IPv4 access for which IPv4 literals dont work and where apps MUST use DNS, is not really an IPv4 access. > I think you've got this the wrong way around. 464XLAT was developed > to make the IPv6-only APN type work well enough for the general > populace. Ok. I also heard that 464XLAT was imported into the cellular world from DSL IPv6 deployments. > At that point the IPV4V6 APN type didn't really work well enough > because it was too new and poorly supported, while the IPV6 type is > older and is well supported. I can understand that. The IPv4IPv6 access I used worked just fine for my applications. It was 3G+ only, not LTE, but it worked excellent. > With the advent of LTE networks, this situation is changing. I can understand that. LTE networks bring in high bandwidth; but from the networking point of view there is reason to fear regression (no more publicly routable IPv4 addresses, no more ping 8.8.8.8, apps must use DNS, etc). > My own provider Telenor is now moving from > IPV6+v4CGN(NAT64/DNS64)+464XLAT to IPV4V6+v4CGN(NAT44), for example. > I guess the biggest advantage of this latter approach is that it > works with Apple devices. I guess this move is promissing, thanks for mentioning it. Using IPV4V6 may allow not only Apple devices but may enable more devices beyond smartphones: machine-class devices and in general all computers small or large which connect through a dedicated LTE USB key, or smarter 4G modules. Alex > > Tore > > From nobody Mon Feb 16 03:29:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A65C1A87E0 for ; Mon, 16 Feb 2015 03:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_62=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqwXlcIp1zW6 for ; Mon, 16 Feb 2015 03:29:54 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389CC1A885C for ; Mon, 16 Feb 2015 03:29:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GBTg58014913; Mon, 16 Feb 2015 12:29:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE4C520851D; Mon, 16 Feb 2015 12:30:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AB640208509; Mon, 16 Feb 2015 12:30:42 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GBRfnH017378; Mon, 16 Feb 2015 12:29:42 +0100 Message-ID: <54E1D42C.5040605@gmail.com> Date: Mon, 16 Feb 2015 12:27:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kossut Tomasz - Hurt , BOUCADAIR Mohamed IMT/OLN , "Heatley, Nick" References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:29:56 -0000 Le 16/02/2015 11:47, Kossut Tomasz - Hurt a écrit : > Hi, IPv6-only + CLAT+NAT64(no dns64) is used in Orange Poland - > somewhere~ 30% mobile users. You won't see this in worldwide IPv6 > stats {"No." of IPv6 users are measured form traffic -ipv4/ipv6 - > typical mobile user (smartphone) generates up to 6 times lower > traffic comparing to lines users..} > > Assuming our experience: > 1. The best for mobile nowadays is CLAT+PLAT+DNS > *One path for IPv4 traffic (always via CLAT) > *ALG’s treated as NAT44 > *IPv4 literal & domain use same path > *One path for IPv6 traffic (native IPv6) > *Motivation for native IPv6 content > *Application address family independent > *65% - traffic from subscribers is native IPv6 > *Google Nexus, Sony,HTC, Samung,LG, WindowsPhone, supports CLAT. Hi, Thank you for the report. It is good to see how good consideration is given to IPv6, and the two separated paths IPv4/IPv6. It is encouraging to see numerous smartphone manufacturers having embraced the CLAT technology. Is the network considering Machine-class devices (M2M)? For example Sierra Wireless Airprime? More than the typical smartphone users (yes, it represents already a large market) is the LTE network considering connections from more dedicated settings like: connected public transportation, home electricity counters, electric vehicle charging stations, harbour installations, connected roads? These dedicated settings look up to wireless LTE access networks as good hope to get on the Internet, especially in areas where land lines are too expensive to deploy. Alex > > Cheers, > tk > > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, February 16, 2015 7:43 AM > To: Alexandru Petrescu; Heatley, Nick > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Hi Alex, > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Envoyé : vendredi 13 février 2015 17:13 > À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc : v6ops@ietf.org Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 13/02/2015 16:33, Heatley, Nick a écrit : >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT >> >> Le 13/02/2015 14:14, Heatley, Nick a écrit : >>> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a >>> 464xlat device. My handset only has an IPv6 address + CLAT and I am >>> pinging 8.8.8.8 :-)) >> >> Ok, I see. I didnt know CLAT-on-device was required when using >> v6-only APNs. >> >> [Heatley, Nick] For service continuity with IPv4, on an IPv6-only >> bearer use CLAT. A slightly pedantic note, if you have a "dual stack >> APN" but the device only requests IPv6 then the device will receive an >> IPv6 bearer and requires CLAT. You will hear from Ross and me talking >> about having a single APN supporting all modes, IPv4, IPv4v6 and IPv6 >> bearers. There may be business reasons for this, as well as avoiding >> consumers having to change APNs. > > In my understanding 464xlat/clat are trials these days. > > [Med] No, it is in use in live networks, including within our Group. > > They could be > improved before going live. If the 464xlat/clat happened elsewhere than on the user terminal (e.g. BAse Station) I think more of these terminals could be accommodated, more business. > > [Med] If all applications are AF-independent (including IPv4 referrals are not in use or address synthesis a la RFC6052 is supported), then CLAT can be avoided. Some operators want to adopt an IPv6-only connectivity mode but with a condition to provide the same level of service as IPv4; For those CLAT is even a must. It might happen that other operators can judge that the broken applications under an IPv6-only mode + NAT64 are not important; for those CLAT is not needed. These reasons, among others, are why we set the language to 'should'. > >> That means that the device vendors MUST implement CLAT in the >> smartphones which connect to a v6-only APN. It is a too strong >> requirement. >> >> [Heatley, Nick] Today's reality is that operators cannot take devices >> to IPv6-only mode of operation without CLAT. In the future will other >> alternatives appear? > > Alternatives there are very many. > > E.g. 464lat/clat to run on an operator-controlled network device, not on end-user terminal. > > E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device. > > 3GPP also designed a DS-MIPv6, not sure whether you are aware of it. It had the same goal of terminal on v6-only link. > > [Med] All those are no options in the mobile context. IPv6-only + NAT64 is the mode that is currently adopted by several operators. > From nobody Mon Feb 16 03:46:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772B91A87F1 for ; Mon, 16 Feb 2015 03:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fa99GVN9ljl for ; Mon, 16 Feb 2015 03:46:01 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8E71A1AC8 for ; Mon, 16 Feb 2015 03:45:50 -0800 (PST) Received: from [2a02:fe0:c410:c430::2] (port=41064 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YNK7X-0005z5-E3; Mon, 16 Feb 2015 12:45:47 +0100 Date: Mon, 16 Feb 2015 12:45:46 +0100 From: Tore Anderson To: Alexandru Petrescu Message-ID: <20150216124546.7c59ba12@envy.fud.no> In-Reply-To: <54E1CC71.2010108@gmail.com> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:46:18 -0000 * Alexandru Petrescu > What is the name of the software that must exist inside the customer's > device? "CLAT". The device located in the provider's network, the "PLAT", is really nothing but a completely standard Stateful NAT64. > > In other words, the operator does not need to configure or provision > > anything beyond Stateful NAT64 + DNS64 for 464XLAT to function. > > But it seems to mandate "464XLAT" to exist inside the customer's > device, for IPv4-literals, and for non-DNS-based apps. If you want IPv4 literals to work, you'll need the CLAT, yes. However, the operator cannot really control this - if you have a device that supports the IPV6 APN type, but no CLAT/464XLAT support, then you can connect to the network just fine. You'll have access to IPv4-only websites etc. through the provider's DNS64/NAT64, but you won't have access to IPv4 literals. The only control the network operator has here, is that it can ensure that all the operator-branded devices it sells in its own store do support 464XLAT (i.e., by containing a CLAT). If you bring your own device bought from somewhere else, however, the operator has no way of knowing if your device contains a CLAT or not. > I also heard that 464XLAT was imported into the cellular world from > DSL IPv6 deployments. No, 464XLAT was designed specifically for mobile networks. I've never heard of any DSL/wireline deployment that uses it (although it is certainly technically possible). > I can understand that. LTE networks bring in high bandwidth; but from > the networking point of view there is reason to fear regression (no > more publicly routable IPv4 addresses, no more ping 8.8.8.8, apps must > use DNS, etc). I think the need to support IPv4 literals and apps not using DNS remains with LTE; the actual change is that LTE networks and devices conform to newer 3GPP releases which include the IPV4V6 APN type. Thus, devices and networks generally support it. Using IPV4V6, an operator can provision the handset with both IPv4 and IPv6 addresses, ensuring that IPv4 literals work - without requiring a CLAT. (As Nick pointed out, RFC1918/RFC6598 exhaustion might still be an issue for very large operators though.) Tore From nobody Mon Feb 16 03:49:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F021A87F1 for ; Mon, 16 Feb 2015 03:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSbifY9GDoE3 for ; Mon, 16 Feb 2015 03:48:55 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FDF1A1AC8 for ; Mon, 16 Feb 2015 03:48:54 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id t1GBkSCk037756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2015 11:46:28 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54E1D891.10805@inex.ie> Date: Mon, 16 Feb 2015 11:46:25 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Erik Kline , Mark ZZZ Smith References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Edward Lewis , "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:48:58 -0000 On 16/02/2015 09:39, Erik Kline wrote: >> If ICANN want to do the above for IPv6, they should instead reserve a >> new IPv6 prefix, similar to how RFC6666 defines a special purpose >> discard prefix. There is plenty of IPv6 space to do so, rather than >> creating a single address exception out of a block of addresses that >> has or would have a well known expected purpose and behaviour. > > Ah, then perhaps they could even just use 0100::53:53 (or 0100::35:35). Or not. There isn't a shortage of candidate ipv6 prefixes, so why squat on the discard prefix? Nick From nobody Mon Feb 16 04:19:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3D1A1AC8 for ; Mon, 16 Feb 2015 04:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tujKm-jVPLd for ; Mon, 16 Feb 2015 04:19:21 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082D51A8878 for ; Mon, 16 Feb 2015 04:19:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GCJ9oo015430; Mon, 16 Feb 2015 13:19:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE1762084ED; Mon, 16 Feb 2015 13:20:09 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B0C4720848E; Mon, 16 Feb 2015 13:20:09 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GCH6Xm012790; Mon, 16 Feb 2015 13:19:09 +0100 Message-ID: <54E1DFC1.8070900@gmail.com> Date: Mon, 16 Feb 2015 13:17:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tore Anderson References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> In-Reply-To: <20150216124546.7c59ba12@envy.fud.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:19:24 -0000 Le 16/02/2015 12:45, Tore Anderson a écrit : > * Alexandru Petrescu > >> What is the name of the software that must exist inside the >> customer's device? > > "CLAT". The device located in the provider's network, the "PLAT", is > really nothing but a completely standard Stateful NAT64. > >>> In other words, the operator does not need to configure or >>> provision anything beyond Stateful NAT64 + DNS64 for 464XLAT to >>> function. >> >> But it seems to mandate "464XLAT" to exist inside the customer's >> device, for IPv4-literals, and for non-DNS-based apps. > > If you want IPv4 literals to work, you'll need the CLAT, yes. > However, the operator cannot really control this - if you have a > device that supports the IPV6 APN type, but no CLAT/464XLAT support, > then you can connect to the network just fine. You'll have access to > IPv4-only websites etc. through the provider's DNS64/NAT64, but you > won't have access to IPv4 literals. Ok. But one would agree that access to websites is not access to the Internet. > The only control the network operator has here, is that it can > ensure that all the operator-branded devices it sells in its own > store do support 464XLAT (i.e., by containing a CLAT). Ok, the operator may control these devices. But some operators sell also SIM cards to put in other devices than smartphones (to put in cars, for example), or in other devices than the operator-controlled devices. There would be little possibility for these operators to hope imposing CLAT on each and every device connecting to 4G. > If you bring your own device bought from somewhere else, however, the > operator has no way of knowing if your device contains a CLAT or > not. Yes. And at that point that particular operator no longer offers IPv4 literal access and some IPv4 applications will not work. >> I also heard that 464XLAT was imported into the cellular world >> from DSL IPv6 deployments. > > No, 464XLAT was designed specifically for mobile networks. I've > never heard of any DSL/wireline deployment that uses it (although it > is certainly technically possible). > >> I can understand that. LTE networks bring in high bandwidth; but >> from the networking point of view there is reason to fear >> regression (no more publicly routable IPv4 addresses, no more ping >> 8.8.8.8, apps must use DNS, etc). > > I think the need to support IPv4 literals and apps not using DNS > remains with LTE; the actual change is that LTE networks and devices > conform to newer 3GPP releases which include the IPV4V6 APN type. > Thus, devices and networks generally support it. Using IPV4V6, an > operator can provision the handset with both IPv4 and IPv6 > addresses, ensuring that IPv4 literals work - without requiring a > CLAT. (As Nick pointed out, RFC1918/RFC6598 exhaustion might still be > an issue for very large operators though.) I think IPV4V6 is something good. Many end devices support IPV4V6 out of the box - it's a below-IP feature. But CLAT is an IP feature, not in the kernel, and is something that has to be added, potentially in conflict with other IP features like openvpn and mobile ip. Yes I read point saying 20million addresses may be too small (a 10.x class A supposedly); it is possible. But several private class As are afforded with multiple NATs or VPNs. Address architecture problems similar to this are common outside the cellular world: e.g. multi-site international corporations on landlines; yet none uses 464XLAT, and none enforces the end user terminal to implement NAT, CLAT, VPN. IPv6 is independent of IPv4 and vice-versa. Alex > > Tore > > From nobody Mon Feb 16 04:24:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA81A1AE5 for ; Mon, 16 Feb 2015 04:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrdXSyQ5ugRx for ; Mon, 16 Feb 2015 04:24:43 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AC31A1AE1 for ; Mon, 16 Feb 2015 04:24:42 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 333076031D for ; Mon, 16 Feb 2015 13:24:41 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id EEB0360054 for ; Mon, 16 Feb 2015 13:24:40 +0100 (CET) Received: (qmail 54526 invoked by uid 1007); 16 Feb 2015 13:24:40 +0100 Date: Mon, 16 Feb 2015 13:24:40 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150216122440.GC34798@Space.Net> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E1DFC1.8070900@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org, Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:24:48 -0000 Hi, On Mon, Feb 16, 2015 at 01:17:05PM +0100, Alexandru Petrescu wrote: > Yes. And at that point that particular operator no longer offers IPv4 > literal access and some IPv4 applications will not work. You *might* have heard about upcoming IPv4 exhaustion, and IPv4 going away in the long run. Brain cycles are spent way better on ensuring IPv6 works on new products and service offerings than on complaining that specific application niches of IPv4 usage (read: applications that do not want to use DNS and IP agnostic socket APIs) will break. Yes, they will. We all know that, but they will still break one day. Get over it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 16 04:37:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167051A88A4 for ; Mon, 16 Feb 2015 04:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8URKy18QVXf for ; Mon, 16 Feb 2015 04:37:35 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849F81A1A6F for ; Mon, 16 Feb 2015 04:37:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GCb44V023058; Mon, 16 Feb 2015 13:37:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 208C720858D; Mon, 16 Feb 2015 13:38:05 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 120FE208580; Mon, 16 Feb 2015 13:38:05 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GCZ4u9014089; Mon, 16 Feb 2015 13:37:04 +0100 Message-ID: <54E1E3F7.4010109@gmail.com> Date: Mon, 16 Feb 2015 13:35:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gert Doering References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> <20150216122440.GC34798@Space.Net> In-Reply-To: <20150216122440.GC34798@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org, Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:37:46 -0000 Le 16/02/2015 13:24, Gert Doering a écrit : > Hi, > > On Mon, Feb 16, 2015 at 01:17:05PM +0100, Alexandru Petrescu wrote: >> Yes. And at that point that particular operator no longer offers IPv4 >> literal access and some IPv4 applications will not work. > > You *might* have heard about upcoming IPv4 exhaustion, and IPv4 going > away in the long run. Gert - let me clarify. YEs, I know IPv4 exhaustion. YEs, in the long run IPv4 disappears. > Brain cycles are spent way better on ensuring IPv6 works on new products > and service offerings than on complaining that specific application > niches of IPv4 usage (read: applications that do not want to use DNS > and IP agnostic socket APIs) will break. No. What is niche for some is billion-making for others. End-user products have independent roadmaps than the network. This is a transition phase. We need to bring in IPv4 deployments. It should happen smoothly - IPv4 should be there as before and also is this IPv6. It's up to the end user to switch to IPv6 when s/he feels like; it's not up to the network to impose this change. Any transition scheme which requires effort from the end user (either upward transition, or retro-compatibility transition) is non inspiring. Alex > > Yes, they will. We all know that, but they will still break one day. > > Get over it. > > Gert Doering > -- NetMaster > From nobody Mon Feb 16 04:52:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21A61A887A for ; Mon, 16 Feb 2015 04:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gll3HcXlPiTU for ; Mon, 16 Feb 2015 04:52:30 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722E71A8877 for ; Mon, 16 Feb 2015 04:52:30 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EC3C560760 for ; Mon, 16 Feb 2015 13:52:28 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BD4C46016D for ; Mon, 16 Feb 2015 13:52:28 +0100 (CET) Received: (qmail 59846 invoked by uid 1007); 16 Feb 2015 13:52:28 +0100 Date: Mon, 16 Feb 2015 13:52:28 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150216125228.GD34798@Space.Net> References: <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> <20150216122440.GC34798@Space.Net> <54E1E3F7.4010109@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EQGG8PHzqGTb0RcC" Content-Disposition: inline In-Reply-To: <54E1E3F7.4010109@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org, Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:52:31 -0000 --EQGG8PHzqGTb0RcC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 16, 2015 at 01:35:03PM +0100, Alexandru Petrescu wrote: > What is niche for some is billion-making for others. >=20 > End-user products have independent roadmaps than the network. >=20 > This is a transition phase. We need to bring in IPv4 deployments. =20 I don't think you understand the role of the IETF, or of the *v6*ops WG. *We* are not here to make billions, or to help legacy technology survive the attempt to resist the future. There is v4sunset and other working groups where your contributions are certainly welcome, but here, you're just barking up the wrong tree. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --EQGG8PHzqGTb0RcC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVOHoDN9WwGXkzn/FAQIllxAAr3gBopDryoFsXWgkis8x3xIPmxcCP5kY 4BuVhtuS/ezKe4qB70N1i/R5GNtBR6AT8q9cH9GzwSUtn9nIWrvsI/JLrfMOnqg2 gD1jqRm/jh6FYHJFkxv6M/DA0ztzsT6BW3gDV2bfO+Kl0hqaDcWXcWVb/b7l+4KP 4P/qkbQhw5E0T5/Vg0DxbijESI6YtkIVS+aE1mavC+AcXud4x92rXkQHI8ugxgqJ ZgpwVDdD6Zz/dkiIfshjpK8tp5vyeN3rCW6K/NuFcUjmsDYxT9nLgjw+V8Wn/f1d BhqVlZo7N7NMgwtKAufYh9t09c/eOsnfZYiusn1NJ4FWNjkR/SVV6LKhgnc+jvmU Ljl6iB4A/xFszbRlzETzJGJQv1KUx7qTOVUz4Gh6pz+Q9TIH1yvxW5aTcw8RYav4 fy0nFyh5oWMnQm6WFxdW56aNF65B1BGa/3ZRebkVttFybJVpoRwK9yZnfgJ6AS1V FWUkWNKg4Y451Byzu4XbKz38yX+doxfkAwmejiPbBN+ufpA0E3xtPwHqD1dFsJHt FGZl88D2/rkCP4uSSmt0VEiwzj7b9dUZkt30TIwg7KgG+ioroZHSpMFtvprxoKxj HnOm70+vyPIw0M+sdXZJ432m/a9vWptoTSX9WyItUfaaz/SMxxYwWIyIXOWeyxoG Vm7ASrqP2dg= =pb3R -----END PGP SIGNATURE----- --EQGG8PHzqGTb0RcC-- From nobody Mon Feb 16 05:03:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A021A1ADC for ; Mon, 16 Feb 2015 05:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEZs8zHZDQJK for ; Mon, 16 Feb 2015 05:03:21 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D416A1A1ACE for ; Mon, 16 Feb 2015 05:03:21 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 16 Feb 2015 05:03:20 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 16 Feb 2015 05:03:19 -0800 From: Edward Lewis To: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSUIEjnmiENkrAUKRqDIUqGF8vpzzV4+AgAAK6wCAACcnAP//6AGA Date: Mon, 16 Feb 2015 13:03:19 +0000 Message-ID: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3506918597_1332030" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 13:03:26 -0000 --B_3506918597_1332030 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/16/15, 4:29, "Mark ZZZ Smith" wrote: >...They're don't provide a reference, however they seem to proposing this >use case as one purpose (the "ICANN's Controlled Interruption" referred >to): > >https://www.icann.org/resources/pages/name-collision-2013-12-06-en My apologies. I uploaded the wrong edition of the -00 I have on disk, the one I meant to upload had a reference to that and a few other (insignificant) edits. But no matter - the draft covered the point and feedback so far has been useful. Ed Lewis Yes, I now work for ICANN ;) PS - The reference to the previous attempt to do this is useful to have. And I was aware of the IPv4 mapped addresses, but misread where they were in the address space. --B_3506918597_1332030 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQT5k4KqbQmWq8C8VFY abMmZAd2RzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAy MTYxMzAzMTdaMA0GCSqGSIb3DQEBAQUABIIBAFssISpMeTmqLsnUW7nBLTv8u6ooedMPjYGa 4/1zK0XMJnHeuV/a4KAFF+j0EJz56lRTIsJASXf47N5nCU5oXNcI1d5PJJXDDVvjJG9zAOEM h5CjYLDUIv8IrNgrLjvO1B7lbTYthr4J31PtpCvDszVVdYX/0nR02qgvNX0Edb2lwyQMUCxn 5h1tUmdNaBnOm1YqZodrGeEnlR84IIBeOC1n9PFjHBXK46IwBoUR6QY3jlMa7uQMCBussr5W rMs8Os+jZhnNztpy44QL/aiDDp5RTHOlC/KfCHi8YiO6cGHhKzHrnr7UYeWzVruC0aKH9ghO dW4n7hiAKAO11A20ffI= --B_3506918597_1332030-- From nobody Mon Feb 16 05:04:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76BA1A8866 for ; Mon, 16 Feb 2015 05:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdNP9K1e_t6m for ; Mon, 16 Feb 2015 05:04:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A191A1B25 for ; Mon, 16 Feb 2015 05:03:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GD3qhX007176; Mon, 16 Feb 2015 14:03:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D045E20855F; Mon, 16 Feb 2015 14:04:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B934F208543; Mon, 16 Feb 2015 14:04:52 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GD1qA6009015; Mon, 16 Feb 2015 14:03:52 +0100 Message-ID: <54E1EA40.70705@gmail.com> Date: Mon, 16 Feb 2015 14:01:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gert Doering References: <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> <20150216122440.GC34798@Space.Net> <54E1E3F7.4010109@gmail.com> <20150216125228.GD34798@Space.Net> In-Reply-To: <20150216125228.GD34798@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org, Tore Anderson Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 13:04:05 -0000 Le 16/02/2015 13:52, Gert Doering a écrit : > Hi, > > On Mon, Feb 16, 2015 at 01:35:03PM +0100, Alexandru Petrescu wrote: >> What is niche for some is billion-making for others. >> >> End-user products have independent roadmaps than the network. >> >> This is a transition phase. We need to bring in IPv4 deployments. > > I don't think you understand the role of the IETF, or of the *v6*ops WG. > > *We* are not here to make billions, or to help legacy technology survive > the attempt to resist the future. Ok. > There is v4sunset and other working groups where your contributions are > certainly welcome, but here, you're just barking up the wrong tree. Ok, it's rather an argumented complain than a contribution proper. What do you think of draft-ietf-v6ops-mobile-device-profile-17.txt? Alex > > Gert Doering > -- NetMaster > From nobody Mon Feb 16 05:47:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828051A1B49 for ; Mon, 16 Feb 2015 05:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVFmYwkCxFaf for ; Mon, 16 Feb 2015 05:47:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4845F1A1B0D for ; Mon, 16 Feb 2015 05:47:35 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 04452C0140; Mon, 16 Feb 2015 14:47:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D5AB1C808F; Mon, 16 Feb 2015 14:47:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 16 Feb 2015 14:47:32 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AQHQSeT8H0P8VsyAQ0msn8bBnn4Z5ZzzRcVw Date: Mon, 16 Feb 2015 13:47:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490C062@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> <20150216122440.GC34798@Space.Net> <54E1E3F7.4010109@gmail.com> In-Reply-To: <54E1E3F7.4010109@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.16.130919 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 13:47:38 -0000 Hi Alex,=20 Based on the discussion in this thread, I don't think there is a justificat= ion to change the wording for this recommendation... but I understood you h= ave some issues with CLAT being a hurdle to have AF-applications. What abou= t the following change? OLD: C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular host should implement the Customer Side Translator (CLAT, [RFC6877]) function which is compliant with [RFC6052][RFC6145][RFC6146]. CLAT function in the cellular host allows for IPv4-only application and IPv4-referals to work on an IPv6-only connectivity. CLAT function requires a NAT64 capability [RFC6146] in the core network. The IPv4 Service Continuity Prefix used by CLAT is defined in [RFC7335]. NEW: C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular host should implement the Customer Side Translator (CLAT, [RFC6877]) function which is compliant with [RFC6052][RFC6145][RFC6146]. CLAT function in the cellular host allows for IPv4-only application and IPv4-referals to work on an IPv6-only connectivity. The more applications are address family independent, the less CLAT function is solicited. CLAT function requires a NAT64 capability [RFC6146] in the network. The IPv4 Service Continuity Prefix used by CLAT is defined in [RFC7335]. The activation of the CLAT function does not interfere with native IPv6 communications. BTW, do you think a modification is needed for L_REC#4: L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular device should support the Customer Side Translator (CLAT) [RFC6877]. Various IP devices are likely to be connected to cellular device, acting as a CPE. Some of these devices can be dual-stack, others are IPv6-only or IPv4-only. IPv6-only connectivity for cellular device does not allow IPv4-only sessions to be established for hosts connected on the LAN segment of cellular devices. In order to allow IPv4 sessions establishment initiated from devices located on LAN segment side and target IPv4 nodes, a solution consists in integrating the CLAT function in the cellular device. As elaborated in Section 2, the CLAT function allows also IPv4 applications to continue running over an IPv6-only host. The IPv4 Service Continuity Prefix used by CLAT is defined in [RFC7335].=20 Thank you. Cheers, Med -----Message d'origine----- De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petres= cu Envoy=E9=A0: lundi 16 f=E9vrier 2015 13:35 =C0=A0: Gert Doering Cc=A0: v6ops@ietf.org; Tore Anderson Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17= .txt - C_REC#9 464XLAT Le 16/02/2015 13:24, Gert Doering a =E9crit : > Hi, > > On Mon, Feb 16, 2015 at 01:17:05PM +0100, Alexandru Petrescu wrote: >> Yes. And at that point that particular operator no longer offers IPv4 >> literal access and some IPv4 applications will not work. > > You *might* have heard about upcoming IPv4 exhaustion, and IPv4 going > away in the long run. Gert - let me clarify. YEs, I know IPv4 exhaustion. YEs, in the long=20 run IPv4 disappears. > Brain cycles are spent way better on ensuring IPv6 works on new products > and service offerings than on complaining that specific application > niches of IPv4 usage (read: applications that do not want to use DNS > and IP agnostic socket APIs) will break. No. What is niche for some is billion-making for others. End-user products have independent roadmaps than the network. This is a transition phase. We need to bring in IPv4 deployments. It=20 should happen smoothly - IPv4 should be there as before and also is this=20 IPv6. It's up to the end user to switch to IPv6 when s/he feels like;=20 it's not up to the network to impose this change. Any transition scheme which requires effort from the end user (either=20 upward transition, or retro-compatibility transition) is non inspiring. Alex > > Yes, they will. We all know that, but they will still break one day. > > Get over it. > > Gert Doering > -- NetMaster > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 16 06:51:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53AC1A1B0D for ; Mon, 16 Feb 2015 06:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S84thoxbd_ai for ; Mon, 16 Feb 2015 06:51:33 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DC51A1B9B for ; Mon, 16 Feb 2015 06:51:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GEpUw3030070; Mon, 16 Feb 2015 15:51:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D5DA92081C3; Mon, 16 Feb 2015 15:52:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C9355200E0F; Mon, 16 Feb 2015 15:52:30 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GEpUGA001077; Mon, 16 Feb 2015 15:51:30 +0100 Message-ID: <54E203F2.8040104@gmail.com> Date: Mon, 16 Feb 2015 15:51:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no> <54E1CC71.2010108@gmail.com> <20150216124546.7c59ba12@envy.fud.no> <54E1DFC1.8070900@gmail.com> <20150216122440.GC34798@Space.Net> <54E1E3F7.4010109@gmail.com> <787AE7BB302AE849A7480A190F8B93300490C062@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490C062@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 14:51:37 -0000 Le 16/02/2015 14:47, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > Based on the discussion in this thread, I don't think there is a > justification to change the wording for this recommendation... but I > understood you have some issues with CLAT being a hurdle to have > AF-applications. What about the following change? Hello Med, Thank you for the suggestion of better text. > OLD: > > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the Customer > Side Translator (CLAT, [RFC6877]) function which is compliant with > [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows for IPv4-only application > and IPv4-referals to work on an IPv6-only connectivity. CLAT > function requires a NAT64 capability [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by CLAT is defined in > [RFC7335]. > > NEW: > > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the Customer > Side Translator (CLAT, [RFC6877]) function which is compliant with > [RFC6052][RFC6145][RFC6146]. I disagree with that SHOULD. It should be a MAY. It should be accompanied by all other mechanisms achieving the same, like tunnelling. > CLAT function in the cellular host allows for IPv4-only application > and IPv4-referals to work on an IPv6-only connectivity. The more > applications are address family independent, the less CLAT function > is solicited. YEs, I agree with the more AF-independence, the less CLAT-requirement. In addition, now reading it, I am afraid it may be circular. I think CLAT itself is not AF-independent and makes use of IPv4 and IPv6 literals. As such, it can't pretend to be a panacea solution to IPv4-referral use. I think this could be re-written: >> Functions like CLAT and tunnelling in the Computer MAY allow for >> IPv4-only applications using IPv4-referals (literals), and >> applications not relying on DNS resolution, to still work when the >> computer has only an IPv6 connection. Note that setting up the >> CLAT function itself does not rely on DNS and makes use of IPv4 >> and IPv6 literals. The more the applications are AF-independent, >> and more reliance on DNS, the less the functions like CLAT (or >> tunnelling) are solicited. > CLAT function requires a NAT64 capability [RFC6146] in the network. > > The IPv4 Service Continuity Prefix used by CLAT is defined in > [RFC7335]. > > The activation of the CLAT function does not interfere with native > IPv6 communications. One should also consider: - activation with CLAT interferes with native IPv4 communications. - CLAT software itself involves manual configuration by way of literals IPv4 and IPv6. For these reasons, I do not understand why making CLAT a SHOULD on the end-user device. One could write that CLAT may be used by some users in need of _some_ kind of IPv4 Internet connectivity, and that IPv4 connectivity is limited in nature (interferes with some IPv4 applications, etc.) > BTW, do you think a modification is needed for L_REC#4: > > L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular device should support the Customer > Side Translator (CLAT) [RFC6877]. On one hand, this makes think that if the end user device implements CLAT then IPv4 access is fine. It is not: one still has to use literals to configure CLAT itself. On another hand, there are several other ways in which better IPv4 access can be obtained when connecting to a v6-only access, and which do not use CLAT nor address translation: for example tunnelling, Mobile IP, VPN. For these reasons, L_REC#4 could be a "MAY" only. Also, the notion of "service continuity" could be understood as "session continuity" - using Mobile IP. Maybe one should clarify what is meant by this continuity. > Various IP devices are likely to be connected to cellular device, > acting as a CPE. I agree. The cellular device is rather a 'cellular interface'. 'CPE' - Customer PRemisses Equipment - makes sense in fixed home/office context, but when deployed out in the field, where there is no customer, one would call it just a Router. Or anything else but a CPE. > Some of these devices can be dual-stack, others are IPv6-only or > IPv4-only. IPv6-only connectivity for cellular device does not allow > IPv4-only sessions to be established for hosts connected on the LAN > segment of cellular devices. Right. Except that 'cellular devices' are actually cellular interfaces. I may have several cellular interfaces on a same unique Router, for bandwidth augmentation. > In order to allow IPv4 sessions establishment initiated from devices > located on LAN segment side and target IPv4 nodes, a solution > consists in integrating the CLAT function in the cellular device. As HEre instead of cellular device I would rather think "the Router on which that cellular interface connects" > elaborated in Section 2, the CLAT function allows also IPv4 > applications to continue running over an IPv6-only host. ^through ^Router YEs, I agree, that is one solution. But it is just one. It is not a SHOULD because there are other solutions equally well qualified as CLAT. If I were to use a SHOULD I would say that "an operator/equipmentvendor should not enforce CLAT on the end user device." Alex > > The IPv4 Service Continuity Prefix used by CLAT is defined in > [RFC7335]. > > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : lundi 16 février 2015 13:35 À : Gert Doering Cc : > v6ops@ietf.org; Tore Anderson Objet : Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT > > Le 16/02/2015 13:24, Gert Doering a écrit : >> Hi, >> >> On Mon, Feb 16, 2015 at 01:17:05PM +0100, Alexandru Petrescu >> wrote: >>> Yes. And at that point that particular operator no longer offers >>> IPv4 literal access and some IPv4 applications will not work. >> >> You *might* have heard about upcoming IPv4 exhaustion, and IPv4 >> going away in the long run. > > Gert - let me clarify. YEs, I know IPv4 exhaustion. YEs, in the > long run IPv4 disappears. > >> Brain cycles are spent way better on ensuring IPv6 works on new >> products and service offerings than on complaining that specific >> application niches of IPv4 usage (read: applications that do not >> want to use DNS and IP agnostic socket APIs) will break. > > No. > > What is niche for some is billion-making for others. > > End-user products have independent roadmaps than the network. > > This is a transition phase. We need to bring in IPv4 deployments. > It should happen smoothly - IPv4 should be there as before and also > is this IPv6. It's up to the end user to switch to IPv6 when s/he > feels like; it's not up to the network to impose this change. > > Any transition scheme which requires effort from the end user > (either upward transition, or retro-compatibility transition) is non > inspiring. > > Alex > > >> >> Yes, they will. We all know that, but they will still break one >> day. >> >> Get over it. >> >> Gert Doering -- NetMaster >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Mon Feb 16 08:00:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE291A1B0D for ; Mon, 16 Feb 2015 08:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDzsSBMUwimq for ; Mon, 16 Feb 2015 08:00:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393701A8896 for ; Mon, 16 Feb 2015 08:00:12 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id A58583B452A; Mon, 16 Feb 2015 17:00:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 87BE2C80B0; Mon, 16 Feb 2015 17:00:09 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Mon, 16 Feb 2015 17:00:09 +0100 From: To: Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT Thread-Index: AdBKAZlORYhLG8ElSsuBFQaeczGL1Q== Date: Mon, 16 Feb 2015 16:00:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490C2B8@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 16:00:28 -0000 Re-, Please see inline. Cheers, Med -----Message d'origine----- De=A0: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Envoy=E9=A0: lundi 16 f=E9vrier 2015 15:52 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: v6ops@ietf.org Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17= .txt - C_REC#9 464XLAT Le 16/02/2015 14:47, mohamed.boucadair@orange.com a =E9crit : > Hi Alex, > > Based on the discussion in this thread, I don't think there is a > justification to change the wording for this recommendation... but I > understood you have some issues with CLAT being a hurdle to have > AF-applications. What about the following change? Hello Med, Thank you for the suggestion of better text. > OLD: > > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the Customer > Side Translator (CLAT, [RFC6877]) function which is compliant with > [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows for IPv4-only application > and IPv4-referals to work on an IPv6-only connectivity. CLAT > function requires a NAT64 capability [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by CLAT is defined in > [RFC7335]. > > NEW: > > C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular host should implement the Customer > Side Translator (CLAT, [RFC6877]) function which is compliant with > [RFC6052][RFC6145][RFC6146]. I disagree with that SHOULD. It should be a MAY. It should be accompanied by all other mechanisms achieving the same, like tunnelling. [Med] I thought we clarified this point ;-) Tunneling is not an option for = current IPv6 deployment in mobile networks: native IPv6 connectivity + NAT6= 4 is currently the favorite option of mobile providers. (Note, I recall the= re was a proposal to adapt DS-Lite to the mobile context (Gi-DS-Lite, RFC66= 74) but that proposal is not adopted in operational networks.) We set this = recommendation to "should" because we have to find a balanced position betw= een:=20 * the operators that want to provide the same service level as in IPv4 when= adopting an IPv6-only mode. For those operators, CLAT is a "MUST"=20 * Those who do not care about these broken application can ignore CLAT. =20 > CLAT function in the cellular host allows for IPv4-only application > and IPv4-referals to work on an IPv6-only connectivity. The more > applications are address family independent, the less CLAT function > is solicited. YEs, I agree with the more AF-independence, the less CLAT-requirement. [Med] Great! In addition, now reading it, I am afraid it may be circular. I think CLAT itself is not AF-independent and makes use of IPv4 and IPv6 literals. As such, it can't pretend to be a panacea solution to IPv4-referral use. [Med] Not sure to get your point here. CLAT fixes an issue with application= s that make use of IPv4 referrals. We all are for AF-independent applicatio= ns. I think this could be re-written: >> Functions like CLAT and tunnelling in the Computer MAY allow for >> IPv4-only applications using IPv4-referals (literals), and >> applications not relying on DNS resolution, to still work when the >> computer has only an IPv6 connection. Note that setting up the >> CLAT function itself does not rely on DNS and makes use of IPv4 >> and IPv6 literals. The more the applications are AF-independent, >> and more reliance on DNS, the less the functions like CLAT (or >> tunnelling) are solicited. [Med] Which "tunneling"? The text you are proposing is at most vague. Pleas= e don't forget this is a profile document that ambitions to include explici= t features not generic assumption. CLAT has proven its efficiency + it is R= FCed.=20 > CLAT function requires a NAT64 capability [RFC6146] in the network. > > The IPv4 Service Continuity Prefix used by CLAT is defined in > [RFC7335]. > > The activation of the CLAT function does not interfere with native > IPv6 communications. One should also consider: - activation with CLAT interferes with native IPv4 communications. [Med] CLAT assumes NAT64 is deployed in the network. Translation leads to a= loss of semantic but other issues can be solved, please refer to https://t= ools.ietf.org/html/rfc6889=20 - CLAT software itself involves manual configuration by way of literals IPv4 and IPv6. [Med] This profile document advocates for means to discover the PREFIX64 + = indicate which IPv4 prefix is to be used by the CLAT function. What manual = configuration are you referring to? For these reasons, I do not understand why making CLAT a SHOULD on the end-user device. One could write that CLAT may be used by some users in need of _some_ kind of IPv4 Internet connectivity, and that IPv4 connectivity is limited in nature (interferes with some IPv4 applications, etc.) > BTW, do you think a modification is needed for L_REC#4: > > L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only > deployment context, the cellular device should support the Customer > Side Translator (CLAT) [RFC6877]. On one hand, this makes think that if the end user device implements CLAT then IPv4 access is fine. It is not: one still has to use literals to configure CLAT itself. On another hand, there are several other ways in which better IPv4 access can be obtained when connecting to a v6-only access, and which do not use CLAT nor address translation: for example tunnelling, Mobile IP, VPN. For these reasons, L_REC#4 could be a "MAY" only. Also, the notion of "service continuity" could be understood as "session continuity" - using Mobile IP. Maybe one should clarify what is meant by this continuity. > Various IP devices are likely to be connected to cellular device, > acting as a CPE. I agree. The cellular device is rather a 'cellular interface'. 'CPE' - Customer PRemisses Equipment - makes sense in fixed home/office context, but when deployed out in the field, where there is no customer, one would call it just a Router. Or anything else but a CPE. [Med] There is always a "customer" that can delegate the right to use the s= ervice to a user. I suspect you are the user for the case you are referring= to. Someone has to pay the bill ;-) > Some of these devices can be dual-stack, others are IPv6-only or > IPv4-only. IPv6-only connectivity for cellular device does not allow > IPv4-only sessions to be established for hosts connected on the LAN > segment of cellular devices. Right. Except that 'cellular devices' are actually cellular interfaces. I may have several cellular interfaces on a same unique Router, for bandwidth augmentation. > In order to allow IPv4 sessions establishment initiated from devices > located on LAN segment side and target IPv4 nodes, a solution > consists in integrating the CLAT function in the cellular device. As HEre instead of cellular device I would rather think "the Router on which that cellular interface connects" [Med] Please note this definition the I-D: o "3GPP cellular device" (or cellular device for short) refers to a cellular host which supports the capability to share its WAN (Wide Area Network) connectivity. > elaborated in Section 2, the CLAT function allows also IPv4 > applications to continue running over an IPv6-only host. ^through ^Router [Med] The initial wording is correct. This is just a reminder to the other = usage of CLAT as indicated in Section 2. From nobody Mon Feb 16 08:08:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340721A1BCC for ; Mon, 16 Feb 2015 08:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60x6IuNPIwIx for ; Mon, 16 Feb 2015 08:08:27 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40901A1B0D for ; Mon, 16 Feb 2015 08:08:27 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 16 Feb 2015 08:08:25 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 16 Feb 2015 08:08:25 -0800 From: Edward Lewis To: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt Thread-Index: AQHQSUIEjnmiENkrAUKRqDIUqGF8vpzzV4+AgAAK6wCAACcnAIAAG7gA Date: Mon, 16 Feb 2015 16:08:24 +0000 Message-ID: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3506929702_1735019" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 16:08:30 -0000 --B_3506929702_1735019 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable After checking the mail archives, I see where that ratholed. On 2/16/15, 4:29, "Mark ZZZ Smith" wrote: >If ICANN want to do the above for IPv6, they should instead reserve a new >IPv6 prefix, similar to how RFC6666 defines a special purpose discard >prefix. There is plenty of IPv6 space to do so, rather than creating a >single address exception out of a block of addresses that has or would >have a well known expected purpose and behaviour. It=E2=80=99s not just ICANN (which I noted in the version of the draft that was *supposed* to be posted). The use case is evident in applications that want to signal some meaning/semantic in the address (kind of a overt covert channel) and then want the other end to not make use of the address. Another example (beyond name collision) is DNS black lists: 127.0.0.1 - whitelist -> trusted 127.0.0.2 - blacklist -> block 127.0.0.3 - yellowlist -> mix What these cases need is not a loopback per se, the misconception had been from IPv4 co-mingling loopback and the ability to create the "overt covert channel." Back to the drawing board... --B_3506929702_1735019 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSn544zOef8J0cuvjb4 qxDCMPP+EDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAy MTYxNjA4MjJaMA0GCSqGSIb3DQEBAQUABIIBABVsBPKoFCps/sWazXpgSTLIrhywfSt0EQOr JNxGri9qfK96UVyweLVuZRpAC7UKk4YsSKvFj4y0bMuv6i03lsulx3M+31rOKZxG46091VNa 7/ikW72uYx1C4lhJFG80Q09oqrARrGOwbXEQNkiHvfeaYGmhaCpVbqPfRCj7d2itSRnhEn/5 0F/yK2OCuCn2Vp38ZnI2fLQA2wqHFb8nYcpVA4sglcBrvNPy5gFY3WUjZOmni6Z4jxMAbnaC lffFaDXYgookY4yarn4Id1fxfTdHKZ6w3Kv7eoXth7Bop0r/cyowcaLXhcoOwozXK9fnHjpD sI4+u8bQqNX2/ZGjSnY= --B_3506929702_1735019-- From nobody Mon Feb 16 09:20:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1C1A1B4E for ; Mon, 16 Feb 2015 09:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT2ldFf6RFKD for ; Mon, 16 Feb 2015 09:19:50 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303A91A1B6A for ; Mon, 16 Feb 2015 09:19:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GHJmee025187; Mon, 16 Feb 2015 18:19:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A32F7208763; Mon, 16 Feb 2015 18:20:48 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9579F20871D; Mon, 16 Feb 2015 18:20:48 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GHJlMw026435; Mon, 16 Feb 2015 18:19:47 +0100 Message-ID: <54E226B3.6070103@gmail.com> Date: Mon, 16 Feb 2015 18:19:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <787AE7BB302AE849A7480A190F8B93300490C2B8@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490C2B8@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:20:01 -0000 Med - Le 16/02/2015 17:00, mohamed.boucadair@orange.com a écrit : > Re-, > > Please see inline. > > Cheers, Med > > -----Message d'origine----- De : Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Envoyé : lundi 16 février 2015 > 15:52 À : BOUCADAIR Mohamed IMT/OLN Cc : v6ops@ietf.org Objet : Re: > [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - > C_REC#9 464XLAT > > Le 16/02/2015 14:47, mohamed.boucadair@orange.com a écrit : >> Hi Alex, >> >> Based on the discussion in this thread, I don't think there is a >> justification to change the wording for this recommendation... but >> I understood you have some issues with CLAT being a hurdle to have >> AF-applications. What about the following change? > > Hello Med, > > Thank you for the suggestion of better text. > >> OLD: >> >> C_REC#9: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular host should implement >> the Customer Side Translator (CLAT, [RFC6877]) function which is >> compliant with [RFC6052][RFC6145][RFC6146]. >> >> CLAT function in the cellular host allows for IPv4-only >> application and IPv4-referals to work on an IPv6-only connectivity. >> CLAT function requires a NAT64 capability [RFC6146] in the core >> network. >> >> The IPv4 Service Continuity Prefix used by CLAT is defined in >> [RFC7335]. >> >> NEW: >> >> C_REC#9: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular host should implement >> the Customer Side Translator (CLAT, [RFC6877]) function which is >> compliant with [RFC6052][RFC6145][RFC6146]. > > I disagree with that SHOULD. It should be a MAY. It should be > accompanied by all other mechanisms achieving the same, like > tunnelling. > > [Med] I thought we clarified this point ;-) Tunneling is not an > option for current IPv6 deployment in mobile networks: Tunneling should always be an option in mobile networks and elsewhere. If the first-hop operator does not provide a tunnel endpoint (for various reasons), other entities in the network do. These tunnels must co-exist with any other option, like CLAT. There are many viable tunnels out there. Is CLAT compatible with them? > native IPv6 connectivity + NAT64 is currently the favorite option of > mobile providers. Well, stated so I can only agree. But there should always be an option to tunnel through, this should not be blocked. > (Note, I recall there was a proposal to adapt DS-Lite to the mobile > context (Gi-DS-Lite, RFC6674) but that proposal is not adopted in > operational networks.) YEs, I recall as well. There may have been several proposals, like DS-MIPv6 RFC5555 as well. Probably this is not adopted in the operational networks either. > We set this recommendation to "should" because we have to find a > balanced position between: * the operators that want to provide the > same service level as in IPv4 when adopting an IPv6-only mode. For > those operators, CLAT is a "MUST" * Those who do not care about > these broken application can ignore CLAT. And there should be an operator offering full IPv6 and full IPv4 at the same time. And I doubt that what an operator does all the others should too. >> CLAT function in the cellular host allows for IPv4-only >> application and IPv4-referals to work on an IPv6-only connectivity. >> The more applications are address family independent, the less CLAT >> function is solicited. > > YEs, I agree with the more AF-independence, the less > CLAT-requirement. > > [Med] Great! > > In addition, now reading it, I am afraid it may be circular. I > think CLAT itself is not AF-independent and makes use of IPv4 and > IPv6 literals. As such, it can't pretend to be a panacea solution to > IPv4-referral use. > > [Med] Not sure to get your point here. CLAT fixes an issue with > applications that make use of IPv4 referrals. We all are for > AF-independent applications. YEs, we are all for AF-independent apps. But that's hard to do. Is CLAT itself not AF-independent and not making use of literals? > I think this could be re-written: > >>> Functions like CLAT and tunnelling in the Computer MAY allow for >>> IPv4-only applications using IPv4-referals (literals), and >>> applications not relying on DNS resolution, to still work when >>> the computer has only an IPv6 connection. Note that setting up >>> the CLAT function itself does not rely on DNS and makes use of >>> IPv4 and IPv6 literals. The more the applications are >>> AF-independent, and more reliance on DNS, the less the functions >>> like CLAT (or tunnelling) are solicited. > > [Med] Which "tunneling"? The text you are proposing is at most vague. > Please don't forget this is a profile document that ambitions to > include explicit features not generic assumption. CLAT has proven its > efficiency + it is RFCed. "Tunnelling" - IPv6 packet with an UDP payload carrying an IPv4 packet in turn; not sure which RFC should I cite? OpenVPN can do this, I think. CLAT is efficient - ok, but should not prohibit OpenVPN from doing it. >> CLAT function requires a NAT64 capability [RFC6146] in the >> network. >> >> The IPv4 Service Continuity Prefix used by CLAT is defined in >> [RFC7335]. >> >> The activation of the CLAT function does not interfere with native >> IPv6 communications. > > One should also consider: - activation with CLAT interferes with > native IPv4 communications. > > [Med] CLAT assumes NAT64 is deployed in the network. Translation > leads to a loss of semantic but other issues can be solved, please > refer to https://tools.ietf.org/html/rfc6889 Thanks for the pointer. I dont complain about translation in general. But compared to tunnelling it should not be mandatory. In the same vein, there is also Specific Routing (Routing Header) which is an intermediary form between Tunnelling and Translation. One wouldn't take sides either. > - CLAT software itself involves manual configuration by way of > literals IPv4 and IPv6. > > [Med] This profile document advocates for means to discover the > PREFIX64 + indicate which IPv4 prefix is to be used by the CLAT > function. What manual configuration are you referring to? The IPv4 address for self. > For these reasons, I do not understand why making CLAT a SHOULD on > the end-user device. > > One could write that CLAT may be used by some users in need of > _some_ kind of IPv4 Internet connectivity, and that IPv4 connectivity > is limited in nature (interferes with some IPv4 applications, etc.) > >> BTW, do you think a modification is needed for L_REC#4: >> >> L_REC#4: In order to ensure IPv4 service continuity in an >> IPv6-only deployment context, the cellular device should support >> the Customer Side Translator (CLAT) [RFC6877]. > > On one hand, this makes think that if the end user device implements > CLAT then IPv4 access is fine. It is not: one still has to use > literals to configure CLAT itself. > > On another hand, there are several other ways in which better IPv4 > access can be obtained when connecting to a v6-only access, and which > do not use CLAT nor address translation: for example tunnelling, > Mobile IP, VPN. > > For these reasons, L_REC#4 could be a "MAY" only. > > Also, the notion of "service continuity" could be understood as > "session continuity" - using Mobile IP. Maybe one should clarify > what is meant by this continuity. > >> Various IP devices are likely to be connected to cellular device, >> acting as a CPE. > > I agree. > > The cellular device is rather a 'cellular interface'. > > 'CPE' - Customer PRemisses Equipment - makes sense in fixed > home/office context, but when deployed out in the field, where there > is no customer, one would call it just a Router. Or anything else > but a CPE. > > [Med] There is always a "customer" that can delegate the right to use > the service to a user. I suspect you are the user for the case you > are referring to. Someone has to pay the bill ;-) Ok. >> Some of these devices can be dual-stack, others are IPv6-only or >> IPv4-only. IPv6-only connectivity for cellular device does not >> allow IPv4-only sessions to be established for hosts connected on >> the LAN segment of cellular devices. > > Right. Except that 'cellular devices' are actually cellular > interfaces. I may have several cellular interfaces on a same unique > Router, for bandwidth augmentation. > >> In order to allow IPv4 sessions establishment initiated from >> devices located on LAN segment side and target IPv4 nodes, a >> solution consists in integrating the CLAT function in the cellular >> device. As > > HEre instead of cellular device I would rather think "the Router on > which that cellular interface connects" > > [Med] Please note this definition the I-D: > > o "3GPP cellular device" (or cellular device for short) refers to a > cellular host which supports the capability to share its WAN (Wide > Area Network) connectivity. WEll, noted. This reads like a Router, not like a Host. It 'shares' its connectivity. Besides, we want it to be able to run DHCPv6 Prefix Delegation. Its name would also be a "Requesting Router". >> elaborated in Section 2, the CLAT function allows also IPv4 >> applications to continue running over an IPv6-only host. > ^through ^Router > > [Med] The initial wording is correct. This is just a reminder to the > other usage of CLAT as indicated in Section 2. Noted. I wanted to ask this: assuming IPv4 access dies out and IPv6 is the only possible access, all an IPv4-inclined can do is run CLAT? Alex > > > From nobody Mon Feb 16 15:04:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111891A88B2 for ; Mon, 16 Feb 2015 15:04:07 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckudUXsWSTEE for ; Mon, 16 Feb 2015 15:04:04 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DBF1A6ED9 for ; Mon, 16 Feb 2015 15:04:04 -0800 (PST) Received: by padhz1 with SMTP id hz1so1579535pad.9 for ; Mon, 16 Feb 2015 15:04:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ARZXbtl1XrOtYVIsctJfS+vEUmdTns7733AdpexnxHs=; b=W64Nlky0ZKmKxLSC7YHUKIkasBYTeKHk6FjsK4NisW2/3ZPmqTZVPVhiXqAzFghZws BT59YVfrs3h3rmamwVh97Vxt8PydxEWLIHOZHzmbY/JdLQ2pqXIJ3VbXlBipiu5hL8FA ZDzv9ZrW7SuBwkuAnfyOrLfEkve+t7tMf/Do/+qLR2uHaTgGoGaUBHqo5uufFmuDKLlc YvqWkkuEBOGaKZvHkLt8ZePyrXqUUQkAYTe4+xV5zu+wTrFKahoWo3sJ2e0zNEE4aX1O RGwbgcqkR/4jOIjFD1/8YAp1SOxucsjbI21+7lEQGahFPaDb8KuHdu7CXNoybGNath7k 4tKQ== X-Gm-Message-State: ALoCoQlCJYvrvS6nr+pVyVD4nip8yETcboRtVtgT0duzvOMZaNGJRsmBduqck+0m+zKfyM8o7z7O X-Received: by 10.70.20.164 with SMTP id o4mr43840950pde.106.1424127844310; Mon, 16 Feb 2015 15:04:04 -0800 (PST) Received: from [10.0.1.10] ([73.162.11.223]) by mx.google.com with ESMTPSA id dr5sm11596887pdb.48.2015.02.16.15.04.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Feb 2015 15:04:03 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1CCDD4B0-E931-4B11-AA34-6F368EC7CDC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: David Conrad In-Reply-To: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 16 Feb 2015 15:04:00 -0800 Message-Id: References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:04:07 -0000 --Apple-Mail=_1CCDD4B0-E931-4B11-AA34-6F368EC7CDC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 = special address registry. It should be, Could you explain why? A number of RBLs use localhost addresses as flags to designate different = forms of block lists (e.g., https://www.spamhaus.org/zen/). Do you = believe those should be registered in the IANA IPv4 special address = registry? > If ICANN want to do the above for IPv6, they should instead reserve a = new IPv6 prefix, similar to how RFC6666 defines a special purpose = discard prefix. OK. However, for clarity, this isn't specifically about "Controlled = Interruption" or what ICANN "wants". It is about trying to have the same = sort of facility that is available in IPv4 for IPv6. Is there some reason I'm unaware of why IPv6 does not have a loopback = prefix that allows a network of more than one host like IPv4? Thanks, -drc (ICANN CTO, but speaking only for myself) --Apple-Mail=_1CCDD4B0-E931-4B11-AA34-6F368EC7CDC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4ndhAAoJENV6ebf0/4rX5qEIAIhkk6eve+M5wqwCUNv7irpy NV52rgC/irGMVGQ23uzLlThs3ci8+5ZxBP0ocVn+Ry9Snzq6yN2frcvZKa6H+bPP BEQ7PGeOwnxL8beVRjCFxQTkDEJ7U3MSgbks8NA+qcaXw+Q4P+oD274OsmLUj+vc dKULtZt85UErSWbWy6Pu6XPyiANW345h2FgAstaUXWsFeGHRk/MqQ9CP8GhfhoqU sD6DNwHfMnTZ8OJaafykiO0j7pwKjTxsYueZiavg7doF3wjzIZL9hKyGN9C6wKwU UQIdHT8bmrKjrbeVAS7oPx7moTSmriBG+dQFN8FWqfAL6Ss/8XNWohX/BFr8O8o= =srVR -----END PGP SIGNATURE----- --Apple-Mail=_1CCDD4B0-E931-4B11-AA34-6F368EC7CDC9-- From nobody Mon Feb 16 15:17:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4A41A88EB for ; Mon, 16 Feb 2015 15:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJan9JsWcsXv for ; Mon, 16 Feb 2015 15:17:13 -0800 (PST) Received: from nm36.bullet.mail.bf1.yahoo.com (nm36.bullet.mail.bf1.yahoo.com [72.30.239.5]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907FD1A88E8 for ; Mon, 16 Feb 2015 15:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424128632; bh=QE/4zAHat+8zSbMjs0cKQ4QxvLOExCCguWkDZUOSQjQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=pJDezOOSS/AnHMt9k0IpQ2bXAEBZY6sz29kWJE8uBk4pCXAKRVgd4qcGP4cglzuPMZVCXNkw5uNTMaAOmaVBuVz7cS5kxWN9aa6CnUpqkzFncmNVJiAcjYzWeWgoLnyE7bLVdEix2afS7lwemfa6tR30oMJZqH09wOtzzlTeWHLoEDqqe1Z1Zb9lCC0P4N2qMtxqWYejyIre7pikexsXURXye3WpCHFPukJVoEuSfFtshiaeKc+LoKEPYnGZ7SGNyXVpY4yXaQr/hgGUyl/x4hZR2aeUWHwcuCyHKcWPQyUAp6OvfGcIz8DBQ1wm+tiRsfMAzyOngTSoOdfmUQwRtA== Received: from [98.139.215.140] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 23:17:12 -0000 Received: from [98.139.212.238] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 23:17:12 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 16 Feb 2015 23:17:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 746621.11819.bm@omp1047.mail.bf1.yahoo.com X-YMail-OSG: IB3dVrsVM1k7yIcjRSLIGjMpVWuTDaUPnYo3lIq_KekVc.WzLnsJROy_BxI5q6l fTpmj0sxMIsrAUzSc0ENHI40IimBAKNSfi.IaoIYG1yvW.jL._9KaP3TwXSR3qxYM8sjzcR.UB3L g.CYZay7Jtkx4IPyOAJLQx2g3OoLgoK1W3xfZ6rrb8ntvVh6.qq5wC4aMhwoEN4wQYWIEEoAXrG_ YBw0.W2n_xPUkdKRzy2GvsTtAI4hhA48BNYQbftRBgcazkAd.bIVE8xmiClaDPtfTi4AURIyBv_L ott2ja1FAdUqMY6u38fxcYq0ydFM1y6ogsvb8fFzS6nBMkvSk3wm6QbDymXN2IESspsnTeQICBrP J9lmm7MjXEeCyxqlFuNrD7KYmkecZtTmV4rWgL.ZIqbni4vjQZAcFCsLlq3xwR2cMTyXX_ARN.Rw 5JDRqBoNgiYJQ9GOYuO1Of46ZcgiGgphSPIT8LH59t6dYEwHQU7IcBkIFQ_wXco8i6bX5FYd98O0 l1zUdRnnbOPgPS_NBHdyqspkh.gmQ7qMPRgK9_ujMO8Duiu0n5A-- Received: by 76.13.26.65; Mon, 16 Feb 2015 23:17:12 +0000 Date: Mon, 16 Feb 2015 23:16:53 +0000 (UTC) From: Mark ZZZ Smith To: Edward Lewis , "v6ops@ietf.org" Message-ID: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:17:15 -0000 ----- Original Message ----- From: Edward Lewis To: "v6ops@ietf.org" Cc:=20 Sent: Tuesday, 17 February 2015, 3:08 Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loop= back-prefix-00.txt After checking the mail archives, I see where that ratholed. On 2/16/15, 4:29, "Mark ZZZ Smith" wrote: >If ICANN want to do the above for IPv6, they should instead reserve a new >IPv6 prefix, similar to how RFC6666 defines a special purpose discard >prefix. There is plenty of IPv6 space to do so, rather than creating a >single address exception out of a block of addresses that has or would >have a well known expected purpose and behaviour. It=E2=80=99s not just ICANN (which I noted in the version of the draft that= was *supposed* to be posted). / ICANN should know better than pretty much anybody else about how to do so= mething properly and most certainly be leading by example. ICANN has no abi= lity to claim ignorance on how Internet specifications are developed and re= viewed, and how IANA reserves special purpose values. The use case is evident in applications that want to signal some meaning/semantic in the address (kind of a overt covert channel) and then want the other end to not make use of the address. Another example (beyond name collision) is DNS black lists: 127.0.0.1 - whitelist -> trusted 127.0.0.2 - blacklist -> block 127.0.0.3 - yellowlist -> mix / These addresses do not have this semantic meaning to me, because I do not= deal with DNS black lists (and don't think they're a great way to solve th= e spam problem anyway). / This problem is all about signalling colliding names or other semantics i= n DNS, so DNS is where the problem is best solved, rather than at the IP ad= dress layer. The best people to talk to then are the IETF DNS working group= (dnsop wg), as they're the experts on DNS. RCODE YXDOMAIN, "Some name that= ought not to exist, does exist." at face value sounds like the right one t= o use, if not, they can assign a new RCODE with corresponding specification= s. Back to the drawing board... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 16 15:22:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5E81A88EC for ; Mon, 16 Feb 2015 15:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmeUMS6o5bwQ for ; Mon, 16 Feb 2015 15:22:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2DC1A88F3 for ; Mon, 16 Feb 2015 15:22:17 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 160B4349315; Mon, 16 Feb 2015 23:22:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 28383160067; Mon, 16 Feb 2015 23:29:06 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id E8C2A160060; Mon, 16 Feb 2015 23:29:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3123C29A61F1; Tue, 17 Feb 2015 10:22:13 +1100 (EST) To: David Conrad From: Mark Andrews References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> In-reply-to: Your message of "Mon, 16 Feb 2015 15:04:00 -0800." Date: Tue, 17 Feb 2015 10:22:12 +1100 Message-Id: <20150216232213.3123C29A61F1@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:22:19 -0000 We don't need *more* reserved address for this. This is from my laptop and it has been configured like this for years. Yes, I have a ULA site on my loopback interface. If your loopback interface does not support this it is broken. Mark lo0: flags=8049 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet 10.53.0.1 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::1 prefixlen 64 inet 10.53.0.2 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::2 prefixlen 64 inet 10.53.0.3 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::3 prefixlen 64 inet 10.53.0.4 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::4 prefixlen 64 inet 10.53.0.5 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::5 prefixlen 64 inet 10.53.0.6 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::6 prefixlen 64 inet 10.53.0.7 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::7 prefixlen 64 inet 10.53.0.8 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::8 prefixlen 64 inet 10.53.0.9 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::9 prefixlen 64 inet 10.53.0.10 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::10 prefixlen 64 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 16 16:23:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8281A890E for ; Mon, 16 Feb 2015 16:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQdsnICwR35S for ; Mon, 16 Feb 2015 16:23:44 -0800 (PST) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25991A890A for ; Mon, 16 Feb 2015 16:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424132623; bh=jBrr07ZhMrT7/mk6+h2SzEKbycj4LHVuDIC04jiSexA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=I1VZOm/5oJ5fnaDKdGbNAZct2xXUI/U+4LBwLRMrSoEoMtBwKh1f3sWYFTegK9FXcS4lISlCyd/16+OLBq/wVaGyzjRhc2J6nbtjQou20Y9cHLHb9mJNmjzgxrKxIoq6/X6H1S+sldfrKTnNINZpsRRJ4LZ2O604oftMyNeEzZHovK1Ev7tq63JS9Ml7PgeTmSSfZnRALHzFic3PJZxW6uS+eYmbYqGszHJ/0gbGxeHOub3yxWVDNRfeHTzvq4RaEwEtpQHPwYuLzsTRn0eL1zhbImqF5vhLtlof1YhwAMQf9/HQcDJuWx9MUaFKp8bL2B3vimXA/25ZJBl9uqZhsw== Received: from [98.139.212.151] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:23:43 -0000 Received: from [98.139.215.229] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:23:43 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:23:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 826053.40371.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: m9NYrq4VM1mSn_bYeetX4RqVMz2ybrPJCHQf7BVSW34UWW4h338axwyTf2Xb9Nw rIFF6yTR3JPnCHX_wBxtOHImOZEXWYJ80xSlLm9dFBFuXFNGjxbsSEJEx1IP4a1qned.Orq.g1Mq i3zs5GQ4iRx7G6Di5KNMBWTDrC3GJs98yXTWy13LOrinfzlNg.lY1JNFNWPk8kP0KIbBEJVodR9h sFWm4hQ3XY8Yumz7x.nF0GTtRMZz8nDC5v9BFAcvtvVPbHqzhsc.jvzw.HggNAZvVEiBefHTV_Ct BcypeuIFmee4JwHj.kb8hk7xH7I7VVGYl_JRW6LBjH2oP_dhc7_mrCN0bPMydu_Ud8agGrQ3BsSE ghK_wVUmtfFVd1Q0Kk4Fpo_IETjz_7Xott61WP6pq1h4IaNYUkKGFxYUEAsQyAXUbzVQLTZhrQOP ZBxYj8qUOSoLrZoIBBzkeni8_uGoSlRe1cbgkMlIpj33li3FWwqakpjEg6JgdKsgt1vu2zZT1_g8 9rSH9n7IJXtOgwJj9vKHBuTbA9hLg1mWh.tfloIrXkYnEF3HfnTlT23vRsZahnWhTNf2SG6Ycxf_ FbGf_zhY5MCSqOnQWIWtziAeALhCZ8uoOQaQqcjlzpUED4vz0ZkUWdWgB0SlGZVFhIjD_KvkyEbF G8Fb90FvMd5UopW7UqPckLnVP8ZIDF6hrpr79ogiLsJ2fsDlDtUogT1sf3StLaTtGz98eHfo5NZr LTLg3Gtc8K4eGAOUtKr141iBzFBdmws4jerugAi3lkjmhazPeLVatpCJGzEjHyMpzcCb8YQmkqbP lfgDxMufRJnDfPUahOumB9kKRrjMzltJtJTjF6zI- Received: by 66.196.80.146; Tue, 17 Feb 2015 00:23:43 +0000 Date: Tue, 17 Feb 2015 00:23:16 +0000 (UTC) From: Mark ZZZ Smith To: David Conrad Message-ID: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 00:23:46 -0000 ________________________________ From: David Conrad To: Mark ZZZ Smith Cc: "v6ops@ietf.org" Sent: Tuesday, 17 February 2015, 10:04 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt Mark, > Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 special address registry. It should be, Could you explain why? A number of RBLs use localhost addresses as flags to designate different forms of block lists (e.g., https://www.spamhaus.org/zen/). Do you believe those should be registered in the IANA IPv4 special address registry? / Yes. If they're supposed to have global and universal meaning, they should be an global registry of some form. Are, for example, spamhaus the global authority on the semantic meaning of 127/8 addresses? Are they the global authority on the semantic meaning of 127/8 addresses when performing DNS blacklisting? > If ICANN want to do the above for IPv6, they should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefix. OK. However, for clarity, this isn't specifically about "Controlled Interruption" or what ICANN "wants". It is about trying to have the same sort of facility that is available in IPv4 for IPv6. / What specific facility? I agree with having a larger IPv6 loopback prefix because of the reasons I outlined in the larger loopback ID I wrote a few years ago. I don't agree with then punching "global" holes in that host-local address space for specific meaning for specific application protocols. By themselves, IP addresses do not have any application semantics - they're either an end-point identifier or locator. Is there some reason I'm unaware of why IPv6 does not have a loopback prefix that allows a network of more than one host like IPv4? / Other people here would know far better than I would however it is likely just that 127/8 seemed excessive in the context of IPv4 addresses running out. As for why 127/8 was a /8, I went looking for some explanation while writing that ID. Here's a summary of what I found: - RFC790, "Assigned Numbers", September 1981, first listed (Class A) 127 as reserved. Previously it had been listed as Unassigned in RFC776, "Assigned Numbers", January 1981. - RFC990, "Assigned Numbers", November 1986, first described the loopback operation: "The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere." - Going by the early TCP-IP mailing list archives (http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/), it seems that Class A 127 being used as a loopback network first occurred on 4.x releases of BSD unix. - The first email to that list was a complaint about them leaking from Dave Mills (I think Dave is also the original NTP person): 4-Apr-86 11:36:40-PST,697;000000000001 Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 11:31:03-PST Date: 4 Apr 1986 14:29:47 EST From: MILLS@USC-ISID.ARPA Subject: Martians go home To: tcp-ip@SRI-NIC.ARPA Folks, I just caught a beta-4.3bsd coughing up ICMP Source Quench and claiming its address to be 127.0.0.1, but truly was on a net-128.5 subnet. This is yet again evidence supporting the well-travelled axiom that says to resist the urge to encroach on the net-address space as a substitute for intra-host routing mechaniss. I would like to suggest that a new net be conceived called DEAD-LETTER with net number 127.0. Volunteers are invited to submit gateways to that net. Dave - The earliest dated BSD source code code file that I found for a loopback interface with a 127 address was in 2.9BSD, although according to the website 2.9BSD was released later than 4.2BSD. http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop.c - What looks to be a datestamp that file seems to be "82/06/20" or June 1982. - Classes within IPv4 addresses were defined somewhere between RFC760 (January 1980) and RFC791 (September 1981). - As mentioned before, in RFC776, January 1981, 127 was unassigned, where as in RFC790, September 1981, it became reserved. So the above source code is all around the time that Classes within IPv4 addresses were being defined, and I suspect that the BSD people chose to use unassigned 127 for their loopback prefix before Classes B and C existed (i.e., all IPv4 addresses had 'Class A' structure'), which is why it is (now) so large. Regards, Mark. Thanks, -drc (ICANN CTO, but speaking only for myself) From nobody Mon Feb 16 16:31:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7BB1A8934 for ; Mon, 16 Feb 2015 16:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b17XtqDFEcqM for ; Mon, 16 Feb 2015 16:31:43 -0800 (PST) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC941A892A for ; Mon, 16 Feb 2015 16:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424133100; bh=ao+NhAoKeDG08vv6eM/oAMU94Szu63QTQYmR1sukRa0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=EvlSxspP/QgoQUGSGtTkD1gVRtSUfJrD0uFViWFtki0RQ+wwvhyy8eCFAqADxJKtLYQddnAXk+ModOUKqedzm0ZrisSlnRXUF3AIASCfOmjqCVE8gl5eu3+nzqHD6sCsE4UpgazQos5MzEAnVJGD8fY6iT6jzNsX5B/lIvsNE/i5xa6BR/cmKk8HXqQkx3XiAPYvtr+lR6JWEyRjFA8UGiLe9k6cUySJB5B63LZynhqWYYUJsbNRsYiR4TZ+fm9LUieIpUFPJKcjmLtZOmsbhLoLJhpKt77/5rjaZH3Wd/7F7aNo89AlDkDb3FJUGzS1t+0WUdkXqNQY/aM2FKOnDA== Received: from [98.139.215.143] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:31:40 -0000 Received: from [98.139.212.244] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:31:40 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 00:31:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 20785.41132.bm@omp1053.mail.bf1.yahoo.com X-YMail-OSG: 4AgiTLYVM1mPmbkUEvfgQD7cTttOUpWkF57hTPIfwHQi.02St1_KfC3kTXAXK.P njH6JgLnQ2I51V4I4dQeQ4PLYblf8sxJiLoJTQJ2gYHI8gHu7yOdZ5ItxVtVG24iCTpIU2rU9_u4 1I.3XHwzATqKAJJTOQSOQ76c1gBpwtq5ELHicIHd6XX1rNCg92nqT_c7uyjN9gKgPdYXJs9JmLuF B88MZ2gwLnfHnJvIyhdn5IwX2T_zgNlZvrJDEyt9Sij1Ye7T5_7IA9f3U4rCUyQLGRoqEHTOfjSf 5_SeTKAlAz1A7YCARGCZ5Yjs3hTpZW7gTmILa0.FtHydDZsoi6MT5DhndjFkrVRDO0Mm7htmU0D5 6yBZLloWjjVQfeqKNJ0qu.sskmWdhNIHcxy7qDg2aN8T7jyCFZnOIMbRaMuz9f4pRovPovW.lb_X 4R8S2HXtSCfF73dasMd6aagosqMWluDhxnDtqXnBSL190YCRgBLVgLH2ZhpLgH8p2hDak9y29Nnl 4y4TdfOLslhXrRqL.0qugRuVhDSwZDsGWlJmdo89q_umoyVA_e5eOEoyConKUBR8ezIpjD5KSKmx qnwJ_qsh5RZbpFNmcAuGzLr8KWdL0eL1EgWzcN7noORtSjydERdGrIzbnvT_oaFxhzSMboo7MXzu isud.kDfNY5cWpuqVFNwL0e4rhvNOVVT1yxe9CeMSoo095K62 Received: by 66.196.80.151; Tue, 17 Feb 2015 00:31:39 +0000 Date: Tue, 17 Feb 2015 00:31:31 +0000 (UTC) From: Mark ZZZ Smith To: Mark Andrews , David Conrad Message-ID: <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150216232213.3123C29A61F1@rock.dv.isc.org> References: <20150216232213.3123C29A61F1@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 00:31:45 -0000 So the fundamental problem is 'configured like this'. It's a manual operation to generate and apply a ULA. ULAs on loopbacks aren't going to well known or ubiquitous. If you want something to be used you need to make it easy, and the best way to make something easy is to make it automatic. The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or would be automatically configured by the OS, with operator intervention. It's always there, and always available to use. The 4.1c/2.9BSD people though there was value in automatic configuration of the loopback address on a loopback interface, way back in 1982/1983: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.c ----- Original Message ----- From: Mark Andrews To: David Conrad Cc: Mark ZZZ Smith ; "v6ops@ietf.org" Sent: Tuesday, 17 February 2015, 10:22 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt We don't need *more* reserved address for this. This is from my laptop and it has been configured like this for years. Yes, I have a ULA site on my loopback interface. If your loopback interface does not support this it is broken. Mark lo0: flags=8049 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet 10.53.0.1 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::1 prefixlen 64 inet 10.53.0.2 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::2 prefixlen 64 inet 10.53.0.3 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::3 prefixlen 64 inet 10.53.0.4 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::4 prefixlen 64 inet 10.53.0.5 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::5 prefixlen 64 inet 10.53.0.6 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::6 prefixlen 64 inet 10.53.0.7 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::7 prefixlen 64 inet 10.53.0.8 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::8 prefixlen 64 inet 10.53.0.9 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::9 prefixlen 64 inet 10.53.0.10 netmask 0xffffffff inet6 fd92:7065:b8e:ffff::10 prefixlen 64 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 16 16:50:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AD1A892B for ; Mon, 16 Feb 2015 16:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNtisikUlr2x for ; Mon, 16 Feb 2015 16:50:02 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECDA1A892A for ; Mon, 16 Feb 2015 16:50:02 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id l6so26740225qcy.2 for ; Mon, 16 Feb 2015 16:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o/iKhNlsUB27Yy3t0m5MxCQq9PNdbfBZXPR3BK+jkT8=; b=Gj3C/8c0ocwhIs8FaoboNGHRkWMHsrUbyTRwPiH33p/aLDHQk1MXQEoMbDzAO2R1mY hprT7SWtpkgKI46EWrsRjiGOvnQrDQRGdZNxHCvIE1wfDM6Bgl5HA/dIMsO8UkB0MMwz sDK2fntgw15KfbibeVX5l63nhT3p6eD7LNrcdLEOeibX7GC0TumY5camke4mwX8DZq1l pCwsG8dKqZvVGGoBVIdlO7c5EuukLeiPVl9jpjrvlRofs1vBhhlltMfPF+CV8Vyg9v9c OYQqJNvCqNLe8VaKKB4dsRPH1vBuLwnltXdSDYnN/nbdJobN3cjKTfJb+kKevaKySWF9 qRPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=o/iKhNlsUB27Yy3t0m5MxCQq9PNdbfBZXPR3BK+jkT8=; b=j1V/LiV7dD+0jz59clAwBBQkvx0CnPRUs0NXKNHs/LVJNBxR+NfrhspDJqMlS1TaWx UYakMvJfWsgsFQH2zO+wYC6j2myLLRINmpLo+N26uHg3QjUz4xNr9zSoKt1b0JhZ7bpM f+20MvMwCkQP68k+dnATA5MVsqbnsqsXRXfrnQYyF3DA0R3eJEYZBJbUMnn7fP5k0u8b DrhFV49SKFQdSQZJJOsqh0/gYjElObOogJ6aK/YcM8FYBpvQSNzLvZjGcdnJbfpsckgR XVXK8N2X3gG8n33WAOkcuqK/RayfycJeLXso8FeLk9IVrLjj4Zn4Sndutap+V1mpWsNW +QNA== X-Gm-Message-State: ALoCoQlcIcybuBcCwCoeoDlXX3kpopSyCILl24449Q131al+uhgGlskkDgFlWpfxMNKiqz4VOA3N X-Received: by 10.140.164.8 with SMTP id k8mr251666qhk.23.1424134201228; Mon, 16 Feb 2015 16:50:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.2 with HTTP; Mon, 16 Feb 2015 16:49:40 -0800 (PST) In-Reply-To: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> References: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> From: Erik Kline Date: Tue, 17 Feb 2015 09:49:40 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 00:50:03 -0000 I was wondering about maybe an update/doc that merged this use case? I was in favor of your loopback prefix, as I recall (it would be especially handy if any application should implicitly bind to 1::${RAND96} /without/ any special permissions), but I can't recall the opposition at the time. /me re-reads/ Ah, yeah it turns out the use cases I wanted it for are exactly the ones that were opposed by others at the time (the implicit delivery of all packets to destinations in this prefix is /technically/ new behaviour). Sad panda. From nobody Mon Feb 16 17:09:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282B11A8951 for ; Mon, 16 Feb 2015 17:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BW1Hy8n_fJJ for ; Mon, 16 Feb 2015 17:09:25 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19121A894C for ; Mon, 16 Feb 2015 17:09:24 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so26922086igk.1 for ; Mon, 16 Feb 2015 17:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+VGZsSYQNl/nHg8TFzbANUMOhLz2O7JLqztrcHLz6f8=; b=GAilF9gdopHrdkWCM/kXsSRCoX9Dl1q1WVGisvlQGI36wot3Y+I85tm3dDYLYV9pWa zmrw1f7lgu2xtcGksltt1E4/DiP00IGDcKAx8tWDrbY/UJUkgVXPl1sBr7dPgkj2YewY qr+1AvZ5pM8qiFA9+vlY3G+TAZS9PODvbjAQvIUOsK64omjb8B9qMRiA9FvJZyVPO+er 7k8t9fueq+ifI8zBpHUqJydMG1cmvd2p6O1pLF1RFcT+uboXWkZt0OKNi7B2PWKdWL5C ITxegAAhYPWvDIXJmnTJr0pxqPu4rlzjPIT2hYyIsM5AOPpZqxdRDqogkWGWmznpuYwT v+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+VGZsSYQNl/nHg8TFzbANUMOhLz2O7JLqztrcHLz6f8=; b=Bnx+FdvWdRiGChYHLHuxehzIgZ6CLvE7ur0ek6Ol3/oK09KDcJ8ddX/PPJCNV2vE2m pBun4tKdyvcRYKFY8+5Uq9MVd9yvw4e94HFtAyxAAmHzEDcPZQnfAhllJkYJ+zpShS6H V0Btmiq6hpOFHbF5dorKSUikRfgjMuxjHAuQbETpt4DgdNAqX6sNIkFADdoix6CJ6XxU s5fTse98v0S5f/vTIWWm4DOBUjoJ+3nV2lyaJZNy6qHGk6soHy3A3KgJgoGzR7HfAtZ7 3Or14q2gF7Pw/sWPS7KS8k8DE3Lj5HX9RMAIZ8/IDkCFmJ9lfkQJSCPQHXPJ0bzyFh6V zPHg== X-Gm-Message-State: ALoCoQnGxCG/PlxH1IDy2qJo6PXiJEY39CZMBjsoNKqUIVf/PycQJMmSfTZodCZRCNasLnGfDroA X-Received: by 10.50.222.70 with SMTP id qk6mr24667378igc.47.1424135363883; Mon, 16 Feb 2015 17:09:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 17:09:03 -0800 (PST) In-Reply-To: <20150216232213.3123C29A61F1@rock.dv.isc.org> References: <602226231.6806482.1424078950598.JavaMail.yahoo@mail.yahoo.com> <20150216232213.3123C29A61F1@rock.dv.isc.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 10:09:03 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11344d8a7a13f1050f3e5afa Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:09:26 -0000 --001a11344d8a7a13f1050f3e5afa Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 8:22 AM, Mark Andrews wrote: > We don't need *more* reserved address for this. This is from my > laptop and it has been configured like this for years. > > Yes, I have a ULA site on my loopback interface. If your loopback > interface does not support this it is broken. > Forgive me, but that seems a bit silly. If you're going to assign an IPv6 address range to your loopback interface, why not make that address predictable? The value of the loopback prefix is not that it's routed to loopback. It's that *everybody knows* it's always routed to loopback. --001a11344d8a7a13f1050f3e5afa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 8:22 AM, Mark Andrews <marka@isc.org> wrote:=
We don't need *more* reserved addres= s for this.=C2=A0 This is from my
laptop and it has been configured like this for years.

Yes, I have a ULA site on my loopback interface.=C2=A0 If your loopback
interface does not support this it is broken.

Forgive me, but that seems a bit silly. If you're going to assig= n an IPv6 address range to your loopback interface, why not make that addre= ss predictable?

The value of the loopback prefix i= s not that it's routed to loopback. It's that *everybody knows* it&= #39;s always routed to loopback.
--001a11344d8a7a13f1050f3e5afa-- From nobody Mon Feb 16 17:23:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A451A036C for ; Mon, 16 Feb 2015 17:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-wrPDk4s0jJ for ; Mon, 16 Feb 2015 17:23:36 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE131A01E7 for ; Mon, 16 Feb 2015 17:23:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id C6C651FCAE9; Tue, 17 Feb 2015 01:23:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55CBD160067; Tue, 17 Feb 2015 01:30:23 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id DFDC0160060; Tue, 17 Feb 2015 01:30:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 698E829A71C4; Tue, 17 Feb 2015 12:23:26 +1100 (EST) To: Mark ZZZ Smith From: Mark Andrews References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> In-reply-to: Your message of "Tue, 17 Feb 2015 00:31:31 -0000." <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Feb 2015 12:23:25 +1100 Message-Id: <20150217012326.698E829A71C4@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:23:38 -0000 The fundemental reason for 127.0.0.0/8 was to give each node a addresses block they could use. 127.0.0.1 evolved as the "standard" loopback address over time. For the most part no one uses the rest of 127.0.0.0/8 but it is useful to have available. That said any use of the rest of 127.0.0.0/8 has to be negotiated between the users. You can't just grab 127.0.0.2 and hope that no one else is using it for IP traffic. In IPv6 we had both link local and site local addresses from the get go. These gave the operator addresses they could use. They were also slightly more complicated than a GUA as you needed to specify scope. We now have ULA addresses which gets rid of the need to specify scope. Just like with 127.0.0.2 you need to negotiate the use of a address. Reserving a new block of addressing in IPv6 will not stop the need to negotiate address use. If you need truly automatic assignment you need to go to IANA or a RIR (e.g. ARIN and 100.64/10) and request a block for a specific purpose. There is no other way to do truly automatic. Mark In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, Mar k ZZZ Smith writes: > So the fundamental problem is 'configured like this'. It's a manual operation > to generate and apply a ULA. ULAs on loopbacks aren't going to well known or > ubiquitous. > > If you want something to be used you need to make it easy, and the best way t > o make something easy is to make it automatic. > > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or wo > uld be automatically configured by the OS, with operator intervention. It's a > lways there, and always available to use. The 4.1c/2.9BSD people though there > was value in automatic configuration of the loopback address on a loopback i > nterface, way back in 1982/1983: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop.c > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.c > > > > ----- Original Message ----- > From: Mark Andrews > To: David Conrad > Cc: Mark ZZZ Smith ; "v6ops@ietf.org" org> > Sent: Tuesday, 17 February 2015, 10:22 > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p > refix-00.txt > > > We don't need *more* reserved address for this. This is from my > laptop and it has been configured like this for years. > > Yes, I have a ULA site on my loopback interface. If your loopback > interface does not support this it is broken. > > > Mark > > lo0: flags=8049 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet 10.53.0.1 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::1 prefixlen 64 > inet 10.53.0.2 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::2 prefixlen 64 > inet 10.53.0.3 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::3 prefixlen 64 > inet 10.53.0.4 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::4 prefixlen 64 > inet 10.53.0.5 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::5 prefixlen 64 > inet 10.53.0.6 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::6 prefixlen 64 > inet 10.53.0.7 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > inet 10.53.0.8 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::8 prefixlen 64 > inet 10.53.0.9 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::9 prefixlen 64 > inet 10.53.0.10 netmask 0xffffffff > inet6 fd92:7065:b8e:ffff::10 prefixlen 64 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 16 17:27:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E80C1A037C for ; Mon, 16 Feb 2015 17:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBvdcYlIUEFX for ; Mon, 16 Feb 2015 17:27:11 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077591A01E7 for ; Mon, 16 Feb 2015 17:27:10 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so26868472igd.4 for ; Mon, 16 Feb 2015 17:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MqDfLCUz7CJJr2GHLaTPc2f9Hz8lFo+OXR/WCNtGhpY=; b=MV9BpiK/U4Zzkx8Ne7wQR1a1tFFvhBPO7sCSfnTV/s+hDr41aJ3BZeG2/xWfWdBj7G 4bMLTM5rNwpOGFklvdcyaMSTRH7WYr+aViH7ElHd92o7KeQS11YVXXyRMmPY7Wy5ULKJ aQnqPPeilwS8JAnOw4JAghT1tjmhr2ttygv9xPcKf9POy03sg9Q7qrzug7LIyqmZC97t Eh9ymEefxTsTvpVb0JazzILqB3ktlTaq01V0CVxSNJxSWjhucLB5Pk4tRSZd/ibtL2m1 yGMw/iB3AyKeVjMauRM7q8u+GpDiv5kSl9Pw97sXka1CGj1eCm7eAa87Kv5/HRzOavFh mDeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MqDfLCUz7CJJr2GHLaTPc2f9Hz8lFo+OXR/WCNtGhpY=; b=fhtYK3pnosUQnDSZZTfVrIL4YKhZ4Eyvh7ftxmBexVRit335gqFpXZBHzRqSmDPlkP CELXJB3JnUJtCyUvav8qPoXJPtOjQJg/5ypKmYpnb/8X/Qf6W4syLRjc4jLDs9q5+Q4T xYCoaAeKE8bolkLWRetZgHyW1CP+nIEYfwKo8496c6O3Hrf2B7oT1EusEnEaECngWkSi pJuUhkm+nDwUyyg5E43FIdUeDVweacLlPs9uWO4bxYw5qp76ekZcg/wLzfwYVMRKr/E7 GHK44tdW5rJ/MuAxFlaZUFqnJKB4QgzxXpcF+zrCkTdEhDKil7nJyVl2TQIF9/2wK/2E 4Y9g== X-Gm-Message-State: ALoCoQlRvogG20AeIHUBDbqETvzCEmBGISDdqP4cVi8eY59Y7jLBPz4t+GuRDLNJPpyddVYDAtmX X-Received: by 10.107.151.80 with SMTP id z77mr20148732iod.51.1424136430214; Mon, 16 Feb 2015 17:27:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 17:26:49 -0800 (PST) In-Reply-To: <20150217012326.698E829A71C4@rock.dv.isc.org> References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 10:26:49 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1140f5ee090f24050f3e9ab4 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:27:12 -0000 --001a1140f5ee090f24050f3e9ab4 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 10:23 AM, Mark Andrews wrote: > If you need truly automatic assignment you need to go to IANA or a > RIR (e.g. ARIN and 100.64/10) and request a block for a specific > purpose. There is no other way to do truly automatic. > There is. Just make the block big enough and pick addresses out of it at random. --001a1140f5ee090f24050f3e9ab4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 10:23 AM, Mark Andrews <marka@isc.org> wrote= :
If you need truly automatic assignment = you need to go to IANA or a
RIR (e.g. ARIN and 100.64/10) and request a block for a specific
purpose.=C2=A0 There is no other way to do truly automatic.

There is. Just make the block big enough and pick addr= esses out of it at random.
--001a1140f5ee090f24050f3e9ab4-- From nobody Mon Feb 16 17:58:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBD61A036C for ; Mon, 16 Feb 2015 17:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMr53zN_k1DL for ; Mon, 16 Feb 2015 17:57:57 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686A31A6FF3 for ; Mon, 16 Feb 2015 17:57:57 -0800 (PST) Received: by iecvy18 with SMTP id vy18so37812805iec.6 for ; Mon, 16 Feb 2015 17:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p/BZgXU854uARh5789v3k994q/cQ78f0ND8xD59fg4Q=; b=WMr6povVha9GXfS7Cl4XiZnYrNkaXVWqRvK1u2Zo1juCc36vV9+p0dD7lJyecFNv3e 74PDOiEk7NpqEYPSj/WEgn8CUDjveWxsQZbPL2OWBMaYiS5qoxxuCGqPYRsIxHXR1Fpa B1tgVU5wDvjyb6bSbbqzhdR6Warfa4Apl5pjV57D4x5q5GNrQjdM3QjZkE+lRIk9QvBs DQgQIonGchfw3gl2ch1FXrRjUcPNhnXb1c+3nYTedTQftHIsXCjlC8FK29frIxCbnPcB /Ps+jBS+rdR8pcx/ZbU7SirZOkt2duuIH3b+APixMsq3aX/lvzgQhYrH5+3VmowU90dr i3fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p/BZgXU854uARh5789v3k994q/cQ78f0ND8xD59fg4Q=; b=kz3yM84FsLLPOxjE7sGzLytxo8h7DfiFosdyX/vlL7asAw3XRiLtsBkAMtzr/B8prF U8wxxrKhZ5c7MoVKWbVmedEiX4gcv6sYik1UdgdOInZVlSgNi8QBwPYqtwrSCXusN0JN M73x++7+T79l7JKY7zEirY+Txpcr0fsVuZzpkfQpW56cOFbuqq0+oWmIEP8vprJRyYc7 VX1Tgi/XwEiSyoAFRFdsbqVSFqLXlQl17QaTEJsMWu5uu3Cg1ax5+GaANwS43EbsEps1 24bhrh+jMWiDDZcV1AU2xAb0rYhk83fcCqk3mqoQGAoCa3DB5wSFsm26uKmuFu2hrHy1 QIVw== X-Gm-Message-State: ALoCoQnyi5EoYkV+mHJoj+lMT4XcYrbk9FMJlxy3G7EnhOYSoWA8LhbxK6RSqN6f+4/uGyyuwivL X-Received: by 10.43.79.129 with SMTP id zq1mr13120844icb.28.1424138276763; Mon, 16 Feb 2015 17:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 17:57:36 -0800 (PST) In-Reply-To: <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 10:57:36 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=001a11332018191c4b050f3f082b Archived-At: Cc: "IPv6 Ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 01:57:59 -0000 --001a11332018191c4b050f3f082b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 16, 2015 at 6:23 PM, Heatley, Nick wrote: > Lorenzo, > > Focusing on a) what do you suggest? > > Have you another way? > Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and give the OEMs a credible signal that from date X onwards, you *will* fail TA on every device that doesn't implement IPv6, and you *will not* waive the requirement. That's what Verizon and T-Mobile did, and it worked for them. It's true that T-Mobile and Verizon have more market power than some of the carriers that are behind this draft. However, they definitely do not have more market power than all the carriers behind this draft taken together. Also, when they put those requirements down, IPv6 support in mobile devices was in a much worse state; some devices didn't implement it at all, and some had pretty severe bugs. Today, any OEM that sells to T-Mobile or Verizon must have an IPv6 stack that's high-enough quality that tens of millions of users can use it. So the problem you need to solve is easier than the one they needed to solve; all you need to do is ask them not to disable IPv6 in the European firmware, just like it's not disabled in the US firmware. If your problem is that you want to go directly from IPv4-only to IPv6-only, but you feel that you can't do that because iOS doesn't support 464xlat, then you're in the same boat as T-Mobile. And in fact, I believe that their requirement is something along the lines of "if your device runs an operating system that supports 464xlat, you MUST configure your device as IPv6-only with 464xlat" (which is roughly equivalent to saying, "you must do 464xlat unless you're Apple"). That has a lot of value, because whatever percentage of your users are on Android or Windows Phone won't consume IPv4 addresses. The public statistics say T-Mobile is close to 50% devices running IPv6-only. That's a lot IPv4 addresses saved. Over time, the more operators take this position, the more will be using 464xlat, and eventually even Apple will read the writing on the wall and implement it. They're free to use the Android implementation; it's Apache-licensed. The disappointed for me in the discussion about this common reqts paper is > not that there are a few strong voices rejecting this initiative. > > It is that there are no voices of support. As I think you have pointed > out, there is little support beyond the authors. > Personally, I think the resistance/lack of support is mostly due to the fact that it is not the IETF's job to dictate/influence which technologies are used in the Internet. The IETF's job is to specify those technologies, but that's already been done. --001a11332018191c4b050f3f082b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 16, 2015 at 6:23 PM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:

Lorenzo,

Focusing on a) what do you suggest?

Have you another way?

=

Yes. Make IPv6* (see below) a requirement = for carrier-branded devices, and give the OEMs a credible signal that from = date X onwards, you *will* fail TA on every device that doesn't impleme= nt IPv6, and you *will not* waive the requirement. That's what Verizon = and T-Mobile did, and it worked for them.

It's= true that T-Mobile and Verizon have more market power than some of the car= riers that are behind this draft. However, they definitely do not have more= market power than all the carriers behind this draft taken together. Also,= when they put those requirements down, IPv6 support in mobile devices was = in a much worse state; some devices didn't implement it at all, and som= e had pretty severe bugs. Today, any OEM that sells to T-Mobile or Verizon = must have an IPv6 stack that's high-enough quality that tens of million= s of users can use it. So the problem you need to solve is easier than the = one they needed to solve; all you need to do is ask them not to disable IPv= 6 in the European firmware, just like it's not disabled in the US firmw= are.

If your problem is that you want to go direct= ly from IPv4-only to IPv6-only, but you feel that you can't do that bec= ause iOS doesn't support 464xlat, then you're in the same boat as T= -Mobile. And in fact, I believe that their requirement is something along t= he lines of "if your device runs an operating system that supports 464= xlat, you MUST configure your device as IPv6-only with 464xlat" (which= is roughly equivalent to saying, "you must do 464xlat unless you'= re Apple"). That has a lot of value, because whatever percentage of yo= ur users are on Android or Windows Phone won't consume IPv4 addresses. = The public statistics say T-Mobile is close to 50% devices running IPv6-onl= y. That's a lot IPv4 addresses saved.

Over tim= e, the more operators take this position, the more will be using 464xlat, a= nd eventually even Apple will read the writing on the wall and implement it= . They're free to use the Android implementation; it's Apache-licen= sed.

=

The disappointed for me in the discussion ab= out this common reqts paper is not that there are a few strong voices rejec= ting this initiative.

It is that there are no voices of support. A= s I think you have pointed out, there is little support beyond the authors.=


Personally, I think= the resistance/lack of support is mostly due to the fact that it is not th= e IETF's job to dictate/influence which technologies are used in the In= ternet. The IETF's job is to specify those technologies, but that's= already been done.
--001a11332018191c4b050f3f082b-- From nobody Mon Feb 16 18:12:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA611A86E2 for ; Mon, 16 Feb 2015 18:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.202 X-Spam-Level: *** X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S4hw2ISnyvt for ; Mon, 16 Feb 2015 18:12:40 -0800 (PST) Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743C41A86DE for ; Mon, 16 Feb 2015 18:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424139159; bh=nVsZHsRxbzlB5ZRZPh10QkUBYc9wTPhcRT52kjSkDqs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=pG16wgvUQovtzq7C9azQ4a7GoQ9HADVeOnc9iPPyCEyDbUFQYl28hK003/srQemn1bHObMGCfb5ybd9qNWKgQ0KmPVAkRcP105bWUJo2dkTRuytQDTURv1alj5v8w76d763jyFANw8L7GhcBp/w4FQzVkb/NBEjFzDerjnBaRVUhqRFWmhQLtXrgbu9qFQwoHwt6h34aqQY3MtMyTFwNexI4DiUGlkeiek3A8yyEJ379w7EkQft6AojzaxXZAqMqekq7YFZ7OQOFqGkBb6IgbsgxT/wAC9+pG5Yov61f3ktLlCpqnGttR6P6NENkj3tHafT+rfwUpKAge0SjTGi32w== Received: from [66.196.81.172] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:12:39 -0000 Received: from [98.139.215.249] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:12:39 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 17 Feb 2015 02:12:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 545919.50058.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: xhHoVVEVM1kStlTvM9KccMGMJ1W8KS0MbVxjzMfmUTPzJJbwjod0LVOl8aiC_Eo 2wSBPQXgh13cw.Nu6RBaeKm0ePyIeX_urROEz453JX48B0UQ1rZw8SliTcqomL5YCRGuz.vBg8gZ 5DGm5vMMR8u97KsaadqlD_5gr8jSEOC3hVtSchUqZc12sonOu2uoSkt1jYvwkLWljVgmvplYHYUg eUlyl3rvYnPAagQFGnE7BhzbdeFCI40RqsFtzOvyM7GuVyewLpYO0lqt8Zv16jY3FHq9S8tjH5qW vBn4wP7OmLMDYmk9tDwouFkfrcQfj5_zbTEmbdguiwB4uq1W7VDIkKLxG5mSEpygA__eoYGSkHme Xj4Bc.tiZqJLLJW3QvnSer_P3oGrGzSuCuGEM4XDYH3QrV8XgO9yLx0WsuczocUzzvFGix_pbvyD kx8rcvQPuwVeHeypQZJ4zsScEDMPt6zetR.5gaSpoM5TJTAtphbIMnh0lW5_0N5sQTr.STciY04j 6ZE4nmn181owwqX2Vbb9iw_jOJOCUpn2C_Ev4qRYRTCZkDMOHW28aiV_ph3rn33zpPrY.6J7Yss2 YTX_ESCPV_ogmEfIn9Fh6MpRpDpMg.BkKEM4augM1jbHjQSHhR8D. Received: by 66.196.80.144; Tue, 17 Feb 2015 02:12:39 +0000 Date: Tue, 17 Feb 2015 02:12:38 +0000 (UTC) From: Mark ZZZ Smith To: Erik Kline Message-ID: <1644303459.8177267.1424139158558.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8177266_1925493831.1424139158551" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:12:42 -0000 ------=_Part_8177266_1925493831.1424139158551 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, it was actually a completely new prefix (but similar to ::1/128 to ma= ke easy to remember ('1' at the front verses '1' at the end), so I think ne= w behaviour is fine. I did propose slightly different loopback/forwarding p= rocessing for this new 1::/32 prefix to match how 127/8 is processed, diffe= rent to the current ::1/128 rules: 5.2. =C2=A0Router Rules =C2=A0 =C2=A0IPv4 loopback packet processing rules for routers, specified i= n=C2=A0 =C2=A0[RFC1812], by default prohibited forwarding of packets with 1= 27/8=C2=A0 =C2=A0destinations, other than those originated locally and retu= rned back=C2=A0 =C2=A0to the router itself. =C2=A0A software switch could b= e provided to disable=C2=A0 =C2=A0this prohibition. =C2=A0This special case= of allowing forwarding of=C2=A0 =C2=A0packets towards 127/8 destinations h= as been taken advantage of by=C2=A0 =C2=A0[RFC4379], for MPLS troubleshooti= ng purposes. =C2=A0An equivalent function=C2=A0 =C2=A0for IPv6 is provided = by using the IPv4-Mapped IPv6 prefix of ::ffff: Smith =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires August 24, 2013 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 7]=C2=A0Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0A Larger IPv6= Loopback Prefix =C2=A0 =C2=A0 =C2=A0 =C2=A0February 2013 =C2=A0 =C2=A0127.0.0.0/104. =C2=A0 =C2=A0The existing ::1/128 packet processing rules for routers are t= he same=C2=A0 =C2=A0as those for IPv6 hosts [RFC4291]. =C2=A0 =C2=A0For the new larger loopback prefix, the IPv6 router processing= rules=C2=A0 =C2=A0are changed to match those of IPv4, to suit future uses = similar to=C2=A0 =C2=A0the MPLS troubleshooting case. From: Erik Kline To: Mark ZZZ Smith =20 Cc: David Conrad ; "v6ops@ietf.org" = =20 Sent: Tuesday, 17 February 2015, 11:49 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopbac= k-prefix-00.txt =20 I was wondering about maybe an update/doc that merged this use case? I was in favor of your loopback prefix, as I recall (it would be especially handy if any application should implicitly bind to 1::${RAND96} /without/ any special permissions), but I can't recall the opposition at the time. /me re-reads/ Ah, yeah it turns out the use cases I wanted it for are exactly the ones that were opposed by others at the time (the implicit delivery of all packets to destinations in this prefix is /technically/ new behaviour).=C2=A0 Sad panda. ------=_Part_8177266_1925493831.1424139158551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, = it was actually a completely new prefix (but similar to ::1/128 to make eas= y to remember ('1' at the front verses '1' at the end), so I think new beha= viour is fine. I did propose slightly different loopback/forwarding process= ing for this new 1::/32 prefix to match how 127/8 is processed, different t= o the current ::1/128 rules:


5.2.  Router Rules=

   IPv4 loopback pack= et processing rules for routers, specified in
   [RFC1812= ], by default prohibited forwarding of packets with 127/8
  &n= bsp;destinations, other than those originated locally and returned back
   to the router itself.  A software switch could be p= rovided to disable
   this prohibition.  This specia= l case of allowing forwarding of
   packets towards 127/8= destinations has been taken advantage of by
   [RFC4379]= , for MPLS troubleshooting purposes.  An equivalent function
&= nbsp;  for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::= ffff:


=

Smith       &nbs= p;            Expires August 24, 2013   =              [Page 7]
 
Internet-Draft        A Larger IPv6 Loopback Pref= ix        February 2013


   127.0.0.0/104.<= /div>

   The existing ::1/12= 8 packet processing rules for routers are the same
   as = those for IPv6 hosts [RFC4291].

=    For the new larger loopback prefix, the IPv6 router processing= rules
   are changed to match those of IPv4, to suit f= uture uses similar to
   the MPLS troubleshooting case.

From: Erik Kline <ek@google.com>
To: Mark ZZZ Smith <markzzzsmith@yaho= o.com.au>
Cc: David= Conrad <drc@virtualized.org>; "v6ops@ietf.org" <v6ops@ietf.org>= ;
Sent: Tuesday, 17 F= ebruary 2015, 11:49
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p= refix-00.txt

I was wondering about maybe an update/doc th= at merged this use case?

I was in favo= r of your loopback prefix, as I recall (it would be
espec= ially handy if any application should implicitly bind to
= 1::${RAND96} /without/ any special permissions), but I can't recall
the opposition at the time.

/me re-reads/

Ah, yeah it turns out t= he use cases I wanted it for are exactly the
ones that we= re opposed by others at the time (the implicit delivery of
all packets to destinations in this prefix is /technically/ new
behaviour).  Sad panda.


=



------=_Part_8177266_1925493831.1424139158551-- From nobody Mon Feb 16 18:16:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A31A86E8 for ; Mon, 16 Feb 2015 18:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYHrJIsUVR6x for ; Mon, 16 Feb 2015 18:16:20 -0800 (PST) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id F08A21A802F for ; Mon, 16 Feb 2015 18:16:19 -0800 (PST) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 571C014FA0CF; Mon, 16 Feb 2015 19:15:49 -0700 (MST) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 57BCA14FA039 for ; Mon, 16 Feb 2015 19:15:48 -0700 (MST) Message-ID: <54E2A454.3080908@iridiumlinux.org> Date: Mon, 16 Feb 2015 19:15:48 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050901060502050208020602" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:16:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050901060502050208020602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/02/2015 16:16, Mark ZZZ Smith wrote: > / These addresses do not have this semantic meaning to me, because I do= not deal with DNS black lists (and don't think they're a great way to so= lve the spam problem anyway). > > / This problem is all about signalling colliding names or other semanti= cs in DNS, so DNS is where the problem is best solved, rather than at the= IP address layer. The best people to talk to then are the IETF DNS worki= ng group (dnsop wg), as they're the experts on DNS. RCODE YXDOMAIN, "Some= name that ought not to exist, does exist." at face value sounds like the= right one to use, if not, they can assign a new RCODE with corresponding= specifications. I suggest that perhaps the best way to handle this is not to use A or AAAA records at all, but rather TXT records with specific text in the tag (or request an entirely new RRtype, called something like MXTRUST).=20 Allocating a large swath of IPv6 address space, even though we have a lot of it, seems like exactly the wrong thing to do here -- addresses are addresses, not tags. -- --Falcon Darkstar Momot --Shadytel --------------ms050901060502050208020602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTcwMjE1 NDhaMCMGCSqGSIb3DQEJBDEWBBTG3sq3RInU3V7/A0w0o9gSjlH2zjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBAAGX8HrvZYh4OPbfTP0bgfVtwSZW4P8PAiWYNPQslBhAYTrw Zt2PgvSydRtzyfC62ebxCH9+c3Pz7Qa5vxeWQtomRHGGy8YnxVfsXazOlSmg61Xv0no4j7HR eBEeZ+/zFTTw86gOcBlcYe1DvPYJnJWs44HBfhd588j/s9Jcf9qXUomAPOwd0rDSasBMLesj czM7jaHNzgZigTFBCBRH793sdCls16Ykcy2lQTygZqjQvdRbE/g00AzPr1jYHpdqQd7psvOa s2dn3Xa8HkTLRiZNx5rL3BjG6FUN0oIBSnMlCbODHn+Z3IEJCGGX4PQ3x7gw/onrETr9CFPE ZrPNS7cAAAAAAAA= --------------ms050901060502050208020602-- From nobody Mon Feb 16 18:19:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BCD1A701F for ; Mon, 16 Feb 2015 18:19:27 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_dB--lAEIQX for ; Mon, 16 Feb 2015 18:19:25 -0800 (PST) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E86F1A6FCF for ; Mon, 16 Feb 2015 18:19:25 -0800 (PST) Received: by pdbfp1 with SMTP id fp1so40231873pdb.9 for ; Mon, 16 Feb 2015 18:19:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=oz7PUnuL6gkLlX8VdCO823TOyJ7Uli2hmglACs2ttXA=; b=Byrg3LlfNwnqwBAAkHyqLJb9s7j+Jd98y+Gma3pB/EJuhhF+Zk936UvCzDk6d6NMt3 KXczarzPbWo+YUAUOp1CvLe4+HtACdIAaQI0gz8bHqtAXusFpSQNCNTt/TeS+4V8dEnU rT42fg958/JrAePQ2Ohe8WiHVmqQQNYshmeddgIY3LgA4cQdaz9I9meSKLSNr+QbYjX6 JifruqFISx0ftePbPdGPF6b1Sibd3tkuq5f/2pe2ryYQgx+ezfR7ZDotnVPp03rh9fl7 I2XzFWCgOD6DYCphnSazWkyOCyPyZDYFSosLv0r1+FvD5bVHwW+tJQooIjp0rflp8lt4 KBAQ== X-Gm-Message-State: ALoCoQn9k8HvrxyVMEX9uKpkAJjebUf2Llr9GGiJz+0DjN+OdIjHEHFcfrMqWJbuFVhFcrfZZBvF X-Received: by 10.68.221.165 with SMTP id qf5mr44225096pbc.101.1424139564712; Mon, 16 Feb 2015 18:19:24 -0800 (PST) Received: from [10.0.1.10] ([73.162.11.223]) by mx.google.com with ESMTPSA id ki10sm10780811pbd.47.2015.02.16.18.19.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Feb 2015 18:19:23 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6FB31593-79D5-415D-A215-DEE5356663B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: David Conrad In-Reply-To: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 16 Feb 2015 18:19:21 -0800 Message-Id: References: <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:19:27 -0000 --Apple-Mail=_6FB31593-79D5-415D-A215-DEE5356663B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, >> A number of RBLs use localhost addresses as flags to designate = different forms of block lists (e.g., https://www.spamhaus.org/zen/). Do = you believe those should be registered in the IANA IPv4 special address = registry? > Yes. If they're supposed to have global and universal meaning, they = should be an global registry of some form. Are, for example, spamhaus = the global authority on the semantic meaning of 127/8 addresses? Are = they the global authority on the semantic meaning of 127/8 addresses = when performing DNS blacklisting? Sorry, your "yes" confuses me. I don't believe Spamhaus' use of 127/8 is = intended to have global or universal meaning: they are understood by the = folks who make use of Spamhaus RBLs. Nor do I think Spamhaus assuming = global authority for the semantic meaning of 127/8 or even when = performing DNS blacklisting. Now, if Spamhaus wrote an RFC that says "if you want to use DNS to = identify specific RBL sub-types, the address 127.0.0.2 means type X, .3 = means type Y, etc." and other blacklist providers thought that was = useful, I could see a point for listing those addresses in an IANA = registry, however I don't think there's sufficient interest and it = wouldn't be Spamhaus being the global authority, that would still rest = with the IANA. >> OK. However, for clarity, this isn't specifically about "Controlled = Interruption" or what ICANN "wants". It is about trying to have the same = sort of facility that is available in IPv4 for IPv6. > / What specific facility? Sorry, I was speaking of the general loopback network functionality. > I agree with having a larger IPv6 loopback prefix because of the = reasons I outlined in the larger loopback ID I wrote a few years ago. I wasn't aware of that earlier effort. Thanks for the reference. = Interesting reading. > I don't agree with then punching "global" holes in that host-local = address space for specific meaning for specific application protocols. I gather then that you disagree with Spamhaus' use of 127/8 as flags for = particular RBLs? > By themselves, IP addresses do not have any application semantics - = they're either an end-point identifier or locator. A philosophical point, but I'd go further and say that by themselves, IP = addresses are just integers -- the semantics, including end point = identification and/or routing location, are imposed by the applications = (including host and router software) that make use of them. Regards, -drc (ICANN CTO, but speaking only for myself) --Apple-Mail=_6FB31593-79D5-415D-A215-DEE5356663B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4qUqAAoJENV6ebf0/4rXOLQH/0EjPjO9OTkKxEdEFKGCTVE/ J5abMS76bUF9HIDXv06d8n0fLZIk38lJ4mCxStjzWtrj6Q+agjTS2NGC3cwAybKk FuoDcz8LAXx309M5A604/1lvJIGNgoxtlwouSQImgBTGpm4Jq+X5Jlw/7J4mXNAV cdGRalZ+62JCu3+xOOwK3/J5kvJ/wNhM95Qs9vjirGbQY3giBM9pk2bZ3U7rsz5I /kxYfigjQaGTcDAmbjeZIq4/IDAmS652PafWjZq/F2dvzN7UhbdxhLRfSTD4oVEo 4AsxKcwjFNKviv6wXEtLAcp41Zob4ses4l5y2DDDNTA/942Tnj8TRahR0YkpYIo= =G9wx -----END PGP SIGNATURE----- --Apple-Mail=_6FB31593-79D5-415D-A215-DEE5356663B1-- From nobody Mon Feb 16 18:24:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5617C1A702D for ; Mon, 16 Feb 2015 18:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yA_ThLSDU34 for ; Mon, 16 Feb 2015 18:24:17 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FF01A6FCF for ; Mon, 16 Feb 2015 18:24:17 -0800 (PST) Received: by iecat20 with SMTP id at20so37949090iec.12 for ; Mon, 16 Feb 2015 18:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aThrm/BHgmsXbqkcihASBkhdj0gjjvAVrF38J6XtUD8=; b=VS1czrg1Av1LzB/pw+/tMz1mn7BwvkS8SgnjenYpob1Mvckug0ihI5Wa0DwyFlz6/g 18oYuhlDtRNMqlBGIY/D0HYyM0j83iFV11ycXvnAhNvTdAQ8H8eGL/rxjJKSqJXBnBB6 tEXGZUHqO3GxECW4CCsKPkN2sI7WrRD5tYjARmaY0Q1UkbGbp8dtteLf5E0P4muq550X LzJ5uHOn5cJAIN8E4maRfS4/Uh7j3sz1pjuCTPEkoYgTbSEjVloU1DlvuYzKtp4jYuCM 221FDOeCvWllgxhH/K+ZgDa4BgtkSsp4DZ3tuQLpPzfb4QIcqeXsFJfnTgoiCohzhqCy zd8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aThrm/BHgmsXbqkcihASBkhdj0gjjvAVrF38J6XtUD8=; b=ODs6RkzwUHFavyteXQFRNCMNK07meZacUGj559MAkSYBw2IUHoqjOTg/ce+/DmYItd JF/u4OCp9s1oJ25jtXrg4nbwdjjr2eLDu7kVxElDC9WWLVpYZCZVxxPdeOU3e/HE+v61 MUjHa1lOEGdgz9yAEmJxUkF3JYbzzlkog3Ymk9GkBhfzAVZcOfuoIV29JFpQ2/vjtlgr f7ljUJFnNVzO3XDEmyFzHBOGqFDd3IjHDkabIoNXTra/TIkfm3J7faewc+XsZ2zN/CrA EeaH7cxLs42EpQJj2LgCFaQsh74jA3icB/so8YFKB8LZi6HzCfrmHYADywDpa+DpgA2c 4KHA== X-Gm-Message-State: ALoCoQkv1kUHz9AqFUirNDG0h6BWiAcOL/Pb3HGSU1u5IeSpDKdvMndarU2AI0hTj2XKuto/UXFj X-Received: by 10.50.137.99 with SMTP id qh3mr25496762igb.7.1424139857154; Mon, 16 Feb 2015 18:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 18:23:57 -0800 (PST) In-Reply-To: <54E2A454.3080908@iridiumlinux.org> References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 11:23:57 +0900 Message-ID: To: Falcon Darkstar Momot Content-Type: multipart/alternative; boundary=001a11c3bcbc4c0353050f3f664b Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:24:19 -0000 --001a11c3bcbc4c0353050f3f664b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 11:15 AM, Falcon Darkstar Momot < falcon@iridiumlinux.org> wrote: > Allocating a large swath of IPv6 address space, even though we have a > lot of it, seems like exactly the wrong thing to do here -- addresses > are addresses, not tags. > That doesn't make sense. A /64 *is* a large swath of IPv6 address space. And there are lots of them. --001a11c3bcbc4c0353050f3f664b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 11:15 AM, Falcon Darkstar Momot <<= a href=3D"mailto:falcon@iridiumlinux.org" target=3D"_blank">falcon@iridiuml= inux.org> wrote:
Allocati= ng a large swath of IPv6 address space, even though we have a
lot of it, seems like exactly the wrong thing to do here -- addresses
are addresses, not tags.

That doesn'= ;t make sense. A /64 *is* a large swath of IPv6 address space. And there ar= e lots of them.
--001a11c3bcbc4c0353050f3f664b-- From nobody Mon Feb 16 18:27:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39D01A7D80 for ; Mon, 16 Feb 2015 18:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb6fJPDuJYid for ; Mon, 16 Feb 2015 18:27:46 -0800 (PST) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 130641A702D for ; Mon, 16 Feb 2015 18:27:46 -0800 (PST) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id B217414FA0CF; Mon, 16 Feb 2015 19:27:45 -0700 (MST) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 992C314FA039 for ; Mon, 16 Feb 2015 19:27:44 -0700 (MST) Message-ID: <54E2A721.7010106@iridiumlinux.org> Date: Mon, 16 Feb 2015 19:27:45 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400090901090300000307" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:27:47 -0000 This is a cryptographically signed message in MIME format. --------------ms030400090901090300000307 Content-Type: multipart/alternative; boundary="------------090901040700090302010908" This is a multi-part message in MIME format. --------------090901040700090302010908 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/02/2015 19:23, Lorenzo Colitti wrote: > On Tue, Feb 17, 2015 at 11:15 AM, Falcon Darkstar Momot > > wrote: > > Allocating a large swath of IPv6 address space, even though we have= a > lot of it, seems like exactly the wrong thing to do here -- address= es > are addresses, not tags. > > > That doesn't make sense. A /64 *is* a large swath of IPv6 address > space. And there are lots of them. The point is that they're addresses, not tags. Why would you allocate addresses that have absolutely no purpose in relation to routing? If a use case (involving routing) for multiple loopback addresses is evident, I'd say this makes sense, but I just don't see it. DNS RBL tagging is not such a use case. -- --Falcon Darkstar Momot --Shadytel --------------090901040700090302010908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 16/02/2015 19:23, Lorenzo Colitti wrote:
On Tue, Feb 17, 2015 at 11:15 AM, Falcon Darkstar Momot <falcon@iridiumlinux.org> wrote:
Allocatin= g a large swath of IPv6 address space, even though we have a<= br> lot of it, seems like exactly the wrong thing to do here -- addresses
are addresses, not tags.

That doesn't make sense. A /64 *is* a large swath of IPv6 address space. And there are lots of them.

The point is that they're addresses, not tags.=C2=A0 Why would you allocate addresses that have absolutely no purpose in relation to routing?

If a use case (involving routing) for multiple loopback addresses is evident, I'd say this makes sense, but I just don't see it.=C2=A0 DNS= RBL tagging is not such a use case.

--
--Falcon Darkstar Momot
--Shadytel
--------------090901040700090302010908-- --------------ms030400090901090300000307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTcwMjI3 NDVaMCMGCSqGSIb3DQEJBDEWBBTfBlCeth8Z1ZXsPHjeY0TIGGnv3jBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBAIxKp6OEKly6ekYVcm51yu8fWyx0FsT7irmKghNAm0L/f7oq oVZ6r4uzK2yOQ3c9n0TrDX8Q0FnfHxNynmIZBEh2ainqKZz7B8jInGMTH69d0X06GK3pxZe+ Nc+VnHWIpKgGCSUIl8Sg6rEy3+u/JQ8ZQz48HxzpYf0eXahYuFT1M6f7OZgH/cIOgDEcdzcr HqlwI+PQlnESOAOtl+R5ufGpxegYMGufrk2FVsepdNIagwtj0CnIRJjopV2euyn36+Hk5QCc 4GzD7E6DvwHHJszJxcgGEnP6sN1QZY8QYj/pNqEBPDcJA4NhVzj4AkdCwPAQmFlKd2nqNMsl EEBAV0EAAAAAAAA= --------------ms030400090901090300000307-- From nobody Mon Feb 16 18:30:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5231A8029 for ; Mon, 16 Feb 2015 18:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmH0CafAi1Ty for ; Mon, 16 Feb 2015 18:30:48 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A53F1A702D for ; Mon, 16 Feb 2015 18:30:48 -0800 (PST) Received: by ierx19 with SMTP id x19so38059628ier.3 for ; Mon, 16 Feb 2015 18:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ei4n+n5/657rlNtIM6BAGwEQPY2FtdoN1qcw6PQQ3YI=; b=I6EvGXlcieOUpsRIc5pQ8O7ZZ+Gta5RMkN/TlyA7QbcajUBkKYJB0XurQnKgLWbX39 slmhYzXCCCL18NYCevOftqo8dbrgiRczztqxGbnG9byxWMJ0dy1wPAKIIPhpaeDzsNDl u21DwCbxqOExHUwrSps6ZDH3yqEmWTtc8vDfRKGGfdOyqAos1mZR8dQ+qHTnrhGxqFKZ /rspiQiLxlN6E7vCOH4xpEyMkrSjrO6pZz0nkkT+hJXwyTj7g4RCLApzYdQ7tFsw3DSu paG6nFpj34buUoRpk+AwFk3oh2m7q7INUbAmxTXLEItjraX0kh8EVlk0XrFuRBMzn26R VYHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ei4n+n5/657rlNtIM6BAGwEQPY2FtdoN1qcw6PQQ3YI=; b=MG67lPGSHvkUf6PibDiUobUrLLuBi8EY92XNir7DHTJiPO6cDFIT2jlQ/u7MrPQ4Tg A5dbKMNHffHn3G408RuIgSmWM/FOD9i4hrXjTRedfag0GoPKfXjOFLgCXXmy/A9q5A5H O8/N5Y9IhCD8ARyexc/pPfiVLHVDz7Nu+C6fYF+cYEF4gkFUVqwoBXzozOvOi8Emc0e+ ufFZMfTBhXGCIF2S4lXsQlQTY+i7EwQiUdXtnu3Ar68MHEgoFd6Umtjush73/OFgHBJS slgIi8xVtQem0F6vTbrFV400Pkk7McwbBnDfuOHDEsZIR5cM1GQyEFitmGmGPa9teFDn wn0A== X-Gm-Message-State: ALoCoQky4yMWLHH3ScModF+iuTPLvv3z0e1rdaUYaEC3O8LVdb92tKm6Nz06DZcDQ+sxu4Glx9vP X-Received: by 10.107.134.103 with SMTP id i100mr1286030iod.90.1424140247904; Mon, 16 Feb 2015 18:30:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.104 with HTTP; Mon, 16 Feb 2015 18:30:27 -0800 (PST) In-Reply-To: <54E2A721.7010106@iridiumlinux.org> References: <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <54E2A721.7010106@iridiumlinux.org> From: Lorenzo Colitti Date: Tue, 17 Feb 2015 11:30:27 +0900 Message-ID: To: Falcon Darkstar Momot Content-Type: multipart/alternative; boundary=001a113ece62965f1c050f3f7d8f Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 02:30:50 -0000 --001a113ece62965f1c050f3f7d8f Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot < falcon@iridiumlinux.org> wrote: > That doesn't make sense. A /64 *is* a large swath of IPv6 address space. > And there are lots of them. > > > The point is that they're addresses, not tags. Why would you allocate > addresses that have absolutely no purpose in relation to routing? > That's what we did in IPv4 with 127.0.0.0/8. As a proportion to the size of the IPv4 address pool, that's way more space than we're talking about here. > If a use case (involving routing) for multiple loopback addresses is > evident, I'd say this makes sense, but I just don't see it. DNS RBL > tagging is not such a use case. > Pointing network at addresses inside 127.0.0.0/8 is a very reliable way to cause said applications to fail fast without emitting any packets. We don't have a way to do that in IPv6 except pointing them at ::1. --001a113ece62965f1c050f3f7d8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot <<= a href=3D"mailto:falcon@iridiumlinux.org" target=3D"_blank">falcon@iridiuml= inux.org> wrote:
=20 =20 =20
<= div class=3D"gmail_quote">
That doesn't make sense. A /64 *is* a la= rge swath of IPv6 address space. And there are lots of them.

The point is that they're addresses, not tags.=C2=A0 Why would you allocate addresses that have absolutely no purpose in relation to routing?

That's what we d= id in IPv4 with 127.0.0.0/8. As a propor= tion to the size of the IPv4 address pool, that's way more space than w= e're talking about here.
=C2=A0
If a use case (involving r= outing) for multiple loopback addresses is evident, I'd say this makes sense, but I just don't see it.=C2= =A0 DNS RBL tagging is not such a use case.

P= ointing network =C2=A0at addresses inside 12= 7.0.0.0/8 is a very reliable way to cause said applications to fail fas= t without emitting any packets. We don't have a way to do that in IPv6 = except pointing them at ::1.