From nobody Fri Jun 2 04:44:41 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1488D1293E0 for ; Fri, 2 Jun 2017 04:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igW8YeCTndC6 for ; Fri, 2 Jun 2017 04:44:36 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0113.outbound.protection.outlook.com [104.47.2.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B793B129477 for ; Fri, 2 Jun 2017 04:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PT7xlJEX5ZaXUeJm6DuMEbfdIYW8gSzWVSgkfVizMjA=; b=ihkEhZEy8ZzCi3GwOB0/+OjyPKE5TMHXs5f/tr2UXUYK33Z5EwrhXtYgHpImvQZ6ju5Ftvytw1fOQev/bvbI3iGBe2b/5oF/S2G5WncxQ0Usd2wcdtZr5r+/BohHR9gXxEbZdAKolfH85jlblCypBn+IrlHy1SM72Y00+xGJL80= Received: from VI1PR08MB2688.eurprd08.prod.outlook.com (10.175.245.26) by VI1PR08MB2686.eurprd08.prod.outlook.com (10.175.245.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Fri, 2 Jun 2017 11:44:33 +0000 Received: from VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::ad6f:79cb:db32:9318]) by VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::ad6f:79cb:db32:9318%13]) with mapi id 15.01.1124.013; Fri, 2 Jun 2017 11:44:33 +0000 From: Juan Carlos Zuniga To: "Black, David" , Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt Thread-Index: AQHSz1SH0iphSNDc20iq1juOTUC1M6H5EJqAgAdvfICAAAkTAIARAoNw Date: Fri, 2 Jun 2017 11:44:33 +0000 Message-ID: References: <149505650017.6670.1022872968633952096@ietfa.amsl.com> <2fbd3252-c8eb-8a71-4a01-43c0044fe877@isi.edu> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dell.com; dkim=none (message not signed) header.d=none;dell.com; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.152.104] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR08MB2686; 7:1STNCGZBYWhtYpxU7zh/HbIyG9IhMYY8t31pPfB4EAHUU6DSk9tE9Mn2LwQNaPpAr1fUlSs9kwa/X0jaaHT5OKsJW03kVan22uoVkt0AdDOGv38/EL1ycz0gnAv5eECU7ZB+MHD75VwJd7nhqS6pspryDgMdUDqk891N9Ur6qosClSfqXa8ox16Tx0Z3Y+6NkoJxfGb3kRHWMyTiyr6+1XMRKU7YWbSWAtiOi9jc0KGXeqqvG1+GpSycNB5g3Q9VCn/Pp+qKbSRvwnIAQEWjfwwjmiLHha/Idw7hjp/LNmCUVuRSiBOwXkiKb+rLLEmZaFSGdJSFB0IOsQEYuhbFew== x-ms-traffictypediagnostic: VI1PR08MB2686: x-ms-office365-filtering-correlation-id: add7e089-156b-4c4b-ef8f-08d4a9acbd10 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR08MB2686; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(39337521807258)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR08MB2686; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR08MB2686; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39450400003)(39830400002)(377424004)(377454003)(51914003)(24454002)(8676002)(6116002)(76176999)(86362001)(5660300001)(74316002)(478600001)(7906003)(66066001)(2950100002)(33656002)(53546009)(230783001)(50986999)(93886004)(7696004)(2906002)(7736002)(25786009)(2501003)(6306002)(38730400002)(229853002)(54356999)(966005)(54896002)(53936002)(14454004)(2171002)(6246003)(606005)(2900100001)(3846002)(8936002)(3280700002)(3660700001)(790700001)(189998001)(55016002)(8666007)(81166006)(102836003)(9686003)(99286003)(6436002)(5250100002)(236005)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR08MB2686; H:VI1PR08MB2688.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR08MB2688E026EA5AFE0AB9C8677289F70VI1PR08MB2688eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2017 11:44:33.7086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2686 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 11:44:40 -0000 --_000_VI1PR08MB2688E026EA5AFE0AB9C8677289F70VI1PR08MB2688eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQoNCkpvZSwgTWFyazogUGxlYXNlIHByb2NlZWQgd2l0 aCB0aGUgcmVxdWlyZWQgY2hhbmdlcyBpbiB0aGUgZG9jdW1lbnQgKFNlY3Rpb24gNSwgZXRjLikg dG8gbW92ZSBpdCB0byBCQ1AuDQoNCkJlc3QsDQoNCkp1YW4gQ2FybG9zICYgV2Fzc2ltDQoNCkZy b206IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJsYWNrLCBEYXZpZA0KU2VudDogTWF5IDIyLCAyMDE3IDExOjU2IEFNDQpUbzogSm9lIFRv dWNoIDx0b3VjaEBpc2kuZWR1PjsgaW50LWFyZWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW50 LWFyZWFdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2LnR4dA0KDQor MSDigJMgSSBjb25jdXIgd2l0aCBGcmVkIHRoYXQgdGhpcyBkcmFmdCBzaG91bGQgYmVjb21lIGEg QkNQLiAgVGhlIGNvbmNlcHQgb2YgYSB0dW5uZWwgYXMgYSBsaW5rIGlzIGZ1bmRhbWVudGFsIGFu ZCBzaG91bGQgYmUgYSBmb3VuZGF0aW9uYWwgcHJpbmNpcGxlIGZvciBob3cgdHVubmVscyBhcmUg ZGVzaWduZWQvc3BlY2lmaWVkLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KRnJvbTogSW50LWFyZWEg W21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwg RnJlZCBMDQpTZW50OiBNb25kYXksIE1heSAyMiwgMjAxNyAxMToyNCBBTQ0KVG86IEpvZSBUb3Vj aCA8dG91Y2hAaXNpLmVkdTxtYWlsdG86dG91Y2hAaXNpLmVkdT4+OyBpbnQtYXJlYUBpZXRmLm9y ZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNi50eHQNCg0KSGkgSm9lLA0KDQpJ IHJlYWQgdGhlIHdob2xlIGRvY3VtZW50LCBhbmQgSSB0aGluayBpcyByZWFkeSBmb3IgYWR2YW5j ZW1lbnQgaW4gaXRzIGN1cnJlbnQgZm9ybQ0KbW9kdWxvIHRoZSBJbmZvcm1hdGlvbmFsIC0+IEJD UCBkZWNpc2lvbi4gSSBzdXBwb3J0IGNoYW5naW5nIHRoZSBkb2N1bWVudCB0cmFjaw0KZnJvbSBJ bmZvcm1hdGlvbmFsIHRvIEJDUCwgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IG1vcmUgd29y ayB3aWxsIGJlIG5lZWRlZA0KaW4gU2VjdGlvbiA1IGlmIHRoYXQgd291bGQgYmUgdGhlIGNhc2Uu IFRoYW5rcyBmb3IgdGhpcyB3b3JrLg0KDQpGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29t PG1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPg0KDQpGcm9tOiBJbnQtYXJlYSBbbWFp bHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2UgVG91Y2gNClNl bnQ6IFdlZG5lc2RheSwgTWF5IDE3LCAyMDE3IDI6NTEgUE0NClRvOiBpbnQtYXJlYUBpZXRmLm9y ZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNi50eHQNCg0KDQpIaSwgYWxsLA0K DQpBIG5ldyB2ZXJzaW9uIG9mIGludGFyZWEtdHVubmVscyBoYXMgYmVlbiBwb3N0ZWQsIGFzIG5v dGVkIGJlbG93Lg0KDQpBdCB0aGlzIHBvaW50LCBJIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBjaGFp cnMgdG8gc3RhcnQgYSBXRyBjYWxsIHRvIGNvbnNpZGVyIHJldmlzaW5nIHRoZSBkb2N1bWVudCB0 cmFjaywgYXMgcGVyIGJlbG93Lg0KDQpTb21lIGhpc3Rvcnk6DQoNClRoaXMgZG9jdW1lbnQgYmVn YW4gYXMgYSBzZXQgb2YgZGlzY3Vzc2lvbnMgYXQgSUVURiA3MiBpbiBQaGlsYWRlbHBoaWEgKDIw MDgpLCB3aGVyZSBhIGZldyBBRHMgYXBwcm9hY2hlZCB1cyB0byB0cnkgdG8gaW50ZWdyYXRlIGEg bnVtYmVyIG9mIGVtZXJnaW5nIHR1bm5lbCBlZmZvcnRzLCB3aXRoIHRoZSBhc3N1bXB0aW9uIG9m IHNpbXBseSBpbnRlZ3JhdGluZyB0aGVtLiBUaGUgcmVzdWx0IHdhcyBhbiBhdHRlbXB0IHRvIHNp bXBseSBvcmdhbml6ZSB0aGUgbGFuZHNjYXBlIGF0IHRoZSB0aW1lLg0KDQpXZSBzdGFydGVkIHRo YXQgbGFuZHNjYXBlIGFzIGFuIElOVEFSRUEgV0cgaW5mb3JtYXRpb25hbCBkb2MgaW4gTWFyY2gg MjAxMC4gSXQgdG9vayBmaXZlIHllYXJzIG9mIGRpc2N1c3Npb25zLCBib3RoIG9uIHRoaXMgbGlz dCBhbmQgaW4gb3RoZXIgV0dzLCB0byByZWFsaXplIHdlIG5lZWRlZCB0byBzdGFydCBieSBleHBs YWluaW5nIG91ciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb25jZXB0IG9mIGEgdHVubmVsIGFzIGEg bGluayAoaXNzdWVzIGluIDIwMTUpLiBBdCB0aGF0IHBvaW50IHdlIHJlYWxpemVkIHRoYXQgbWFu eSBleGlzdGluZyBhbmQgZW1lcmdpbmcgdHVubmVscyB3ZXJlIGluY29uc2lzdGVudCB3aXRoIGVh Y2ggb3RoZXIgYW5kIHdpdGggZXhpc3RpbmcgcmVxdWlyZW1lbnRzLg0KDQpXZSBjYW1lIHVwIHdp dGggYW4gYXBwcm9hY2ggd2hpY2ggd2UgYmVsaWV2ZSBpcyBib3RoIGNvcnJlY3QgYW5kIGNvbnNp c3RlbnQgd2l0aCBleGlzdGluZyBjb3JlIEludGVybmV0IHJlcXVpcmVtZW50cywgYW5kIGhpZ2hs aWdodGVkIHdoZXJlIGl0IGRpZmZlcnMgZnJvbSBjdXJyZW50IHR1bm5lbHMgKHN0YW5kYXJkcyB0 cmFjaywgaW5mb3JtYXRpb25hbCwgb3Igb3RoZXJ3aXNlKSBpbiBTZWN0aW9uIDUuIEF0IHRoaXMg cG9pbnQsIHdlIGJlbGlldmUgdGhlIGNvcmUgb2YgdGhpcyBkb2N1bWVudCBpcyBib3RoIHN0YWJs ZSBhbmQgcmVwcmVzZW50cyBub3Qgb25seSBhIGNsZWFyIHZpZXcgb2YgdHVubmVscyBhcyBhbiBh cmNoaXRlY3R1cmFsIGNvbXBvbmVudCBvZiB0aGUgSW50ZXJuZXQsIGJ1dCBhbHNvIHJlcHJlc2Vu dHMgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZXMgcmVnYXJkaW5nIHRoZSBkZXNpZ24gYW5kIHVz ZSBvZiB0dW5uZWxzLg0KDQpPdXIgcmVxdWVzdDoNCg0KQXMgYSByZXN1bHQsIHdlJ2QgbGlrZSB0 byBhc2sgdGhlIGNoYWlycyB0byBpbml0aWF0ZSBhIGNhbGwgdG8gY2hhbmdlIHRoZSB0cmFjayBv ZiB0aGlzIGRvY3VtZW50IGZyb20gSW5mb3JtYXRpb25hbCB0byBCQ1AuDQoNClRoZSByZXN1bHQg b2YgdGhpcyBkZWNpc2lvbiB3aWxsIGltcGFjdCBob3cgU2VjdGlvbiA1IGlzIHJlc29sdmVkLiBJ ZiB0aGlzIGRvY3VtZW50IGJlY29tZXMgYSBCQ1AsIHRoYXQgc2VjdGlvbiB3aWxsIGJlIGZsZXNo ZWQgb3V0IGZvciBXRyBjb25zZW5zdXMuIElmIHRoaXMgZG9jdW1lbnQgcmVtYWlucyBJbmZvcm1h dGlvbmFsLCB0aGVuIHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiA1IG1pZ2h0IG5vdCBi ZSBhcHByb3ByaWF0ZSwgYW5kIHdpbGwgbGlrZWx5IG5lZWQgdG8gYmUgb21pdHRlZCBpbiB3aG9s ZSBvciBwYXJ0Lg0KSm9lDQoNCi0tLS0tLS0NCg0KU3VtbWFyeSBvZiAwNiBjaGFuZ2VzOg0KDQog ICAgLSB1cGRhdGVkIEVDTVAgZGlzY3Vzc2lvbg0KDQogICAgLSB1cGRhdGVkIG11bHRpcG9pbnQg ZGlzY3Vzc2lvbg0KDQogICAgLSB1cGRhdGVkIHRlcm1pbm9sb2d5IChhdG9tIC0+IGF0b21pYyBw YWNrZXQpDQoNCiAgICAtIHJldmlzZWQgRmlnIDEyIGFuZCBGaWcgMTMgYWxnb3JpdGhtcyAoaXQg d2Fzbid0IGNsZWFyIHRoYXQgdGhpcyB3YXMgb3V0ZXIgZnJhZ21lbnRhdGlvbikNCg0KLS0tLS0t DQoNCk9uIDUvMTcvMjAxNyAyOjI4IFBNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVybmV0IEFyZWEg V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAg IDogSVAgVHVubmVscyBpbiB0aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlDQoNCiAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogSm9lIFRvdWNoDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFy ayBUb3duc2xleQ0KDQogRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5l bHMtMDYudHh0DQoNCiBQYWdlcyAgICAgICAgICAgOiA1Mg0KDQogRGF0ZSAgICAgICAgICAgIDog MjAxNy0wNS0xNw0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2Vz IHRoZSByb2xlIG9mIElQIHR1bm5lbHMgaW4gdGhlIEludGVybmV0DQoNCiAgIGFyY2hpdGVjdHVy ZS4gQW4gSVAgdHVubmVsIHRyYW5zaXRzIElQIGRhdGFncmFtcyBhcyBwYXlsb2FkcyBpbiBub24t DQoNCiAgIGxpbmsgbGF5ZXIgcHJvdG9jb2xzLiBUaGlzIGRvY3VtZW50IGV4cGxhaW5zIHRoZSBy ZWxhdGlvbnNoaXAgb2YgSVANCg0KICAgdHVubmVscyB0byBleGlzdGluZyBwcm90b2NvbCBsYXll cnMgYW5kIHRoZSBjaGFsbGVuZ2VzIGluIHN1cHBvcnRpbmcNCg0KICAgSVAgdHVubmVsaW5nLCBi YXNlZCBvbiB0aGUgZXF1aXZhbGVuY2Ugb2YgdHVubmVscyB0byBsaW5rcy4gVGhlDQoNCiAgIGlt cGxpY2F0aW9ucyBvZiB0aGlzIGRvY3VtZW50IGFyZSB1c2VkIHRvIGRlcml2ZSByZWNvbW1lbmRh dGlvbnMgdGhhdA0KDQogICB1cGRhdGUgTVRVIGFuZCBmcmFnbWVudCBpc3N1ZXMgaW4gUkZDIDQ0 NTkuDQoNCg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aW50YXJlYS10dW5uZWxzLw0KDQoNCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMg YXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p bnRhcmVhLXR1bm5lbHMtMDYNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNg0KDQoNCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYNCg0KDQoNCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoNCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCg0KSW50LWFyZWFAaWV0 Zi5vcmc8bWFpbHRvOkludC1hcmVhQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQoNCg== --_000_VI1PR08MB2688E026EA5AFE0AB9C8677289F70VI1PR08MB2688eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojOTkzMzY2O30NCnNwYW4uRW1haWxTdHlsZTI1 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1DQSIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sm9lLCBNYXJrOiBQbGVhc2UgcHJvY2VlZCB3 aXRoIHRoZSByZXF1aXJlZCBjaGFuZ2VzIGluIHRoZSBkb2N1bWVudCAoU2VjdGlvbiA1LCBldGMu KSB0byBtb3ZlIGl0IHRvIEJDUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5KdWFuIENhcmxvcyAmYW1wOyBXYXNzaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJsYWNrLCBEYXZpZDxicj4NCjxiPlNlbnQ6PC9iPiBN YXkgMjIsIDIwMTcgMTE6NTYgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvZSBUb3VjaCAmbHQ7dG91Y2hA aXNpLmVkdSZndDs7IGludC1hcmVhQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb SW50LWFyZWFdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2LnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzY2 Ij4mIzQzOzEg4oCTIEkgY29uY3VyIHdpdGggRnJlZCB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJl Y29tZSBhIEJDUC4mbmJzcDsgVGhlIGNvbmNlcHQgb2YgYSB0dW5uZWwgYXMgYSBsaW5rIGlzIGZ1 bmRhbWVudGFsIGFuZCBzaG91bGQNCiBiZSBhIGZvdW5kYXRpb25hbCBwcmluY2lwbGUgZm9yIGhv dyB0dW5uZWxzIGFyZSBkZXNpZ25lZC9zcGVjaWZpZWQuPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+VGhhbmtz LCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSW50LWFyZWEgWzxh IGhyZWY9Im1haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aW50LWFyZWEt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlbXBsaW4sIEZyZWQg TDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMiwgMjAxNyAxMToyNCBBTTxicj4NCjxi PlRvOjwvYj4gSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+dG91 Y2hAaXNpLmVkdTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmciPg0K aW50LWFyZWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSW50LWFyZWFd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2LnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBKb2Us PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgcmVhZCB0aGUgd2hvbGUgZG9jdW1lbnQsIGFuZCBJIHRoaW5rIGlzIHJl YWR5IGZvciBhZHZhbmNlbWVudCBpbiBpdHMgY3VycmVudCBmb3JtPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5tb2R1bG8gdGhlIEluZm9ybWF0aW9uYWwgLSZndDsgQkNQIGRlY2lzaW9u LiBJIHN1cHBvcnQgY2hhbmdpbmcgdGhlIGRvY3VtZW50IHRyYWNrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5mcm9tIEluZm9ybWF0aW9uYWwgdG8gQkNQLCB3aXRoIHRoZSB1bmRlcnN0 YW5kaW5nIHRoYXQgbW9yZSB3b3JrIHdpbGwgYmUgbmVlZGVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5pbiBTZWN0aW9uIDUgaWYgdGhhdCB3b3VsZCBiZSB0aGUgY2FzZS4gVGhhbmtz IGZvciB0aGlzIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Im1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tIj5mcmVkLmwu dGVtcGxpbkBib2VpbmcuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBJbnQtYXJl YSBbPGEgaHJlZj0ibWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppbnQt YXJlYS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9lIFRvdWNo PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE3LCAyMDE3IDI6NTEgUE08YnI+DQo8 Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzppbnQtYXJlYUBpZXRmLm9yZyI+aW50LWFyZWFAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSW50LWFyZWFdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCBh bGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZl cnNpb24gb2YgaW50YXJlYS10dW5uZWxzIGhhcyBiZWVuIHBvc3RlZCwgYXMgbm90ZWQgYmVsb3cu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkF0IHRoaXMgcG9p bnQsIEkgd291bGQgbGlrZSB0byBhc2sgdGhlIGNoYWlycyB0byBzdGFydCBhIFdHIGNhbGwgdG8g Y29uc2lkZXIgcmV2aXNpbmcgdGhlIGRvY3VtZW50IHRyYWNrLCBhcyBwZXIgYmVsb3cuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PGI+PHU+PHNwYW4gbGFuZz0iRU4tVVMiPlNvbWUgaGlzdG9y eTo8L3NwYW4+PC91PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgZG9jdW1lbnQgYmVnYW4gYXMgYSBzZXQgb2Yg ZGlzY3Vzc2lvbnMgYXQgSUVURiA3MiBpbiBQaGlsYWRlbHBoaWEgKDIwMDgpLCB3aGVyZSBhIGZl dyBBRHMgYXBwcm9hY2hlZCB1cyB0byB0cnkgdG8gaW50ZWdyYXRlIGEgbnVtYmVyIG9mIGVtZXJn aW5nIHR1bm5lbCBlZmZvcnRzLCB3aXRoIHRoZSBhc3N1bXB0aW9uIG9mIHNpbXBseSBpbnRlZ3Jh dGluZyB0aGVtLiBUaGUgcmVzdWx0IHdhcyBhbiBhdHRlbXB0DQogdG8gc2ltcGx5IG9yZ2FuaXpl IHRoZSBsYW5kc2NhcGUgYXQgdGhlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPldlIHN0YXJ0ZWQgdGhhdCBsYW5kc2NhcGUgYXMgYW4gSU5UQVJFQSBX RyBpbmZvcm1hdGlvbmFsIGRvYyBpbiBNYXJjaCAyMDEwLiBJdCB0b29rIGZpdmUgeWVhcnMgb2Yg ZGlzY3Vzc2lvbnMsIGJvdGggb24gdGhpcyBsaXN0IGFuZCBpbiBvdGhlciBXR3MsIHRvIHJlYWxp emUgd2UgbmVlZGVkIHRvIHN0YXJ0IGJ5IGV4cGxhaW5pbmcgb3VyIHVuZGVyc3RhbmRpbmcgb2Yg dGhlIGNvbmNlcHQgb2YgYSB0dW5uZWwNCiBhcyBhIGxpbmsgKGlzc3VlcyBpbiAyMDE1KS4gQXQg dGhhdCBwb2ludCB3ZSByZWFsaXplZCB0aGF0IG1hbnkgZXhpc3RpbmcgYW5kIGVtZXJnaW5nIHR1 bm5lbHMgd2VyZSBpbmNvbnNpc3RlbnQgd2l0aCBlYWNoIG90aGVyIGFuZCB3aXRoIGV4aXN0aW5n IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyI+V2UgY2FtZSB1cCB3aXRoIGFuIGFwcHJvYWNoIHdoaWNoIHdlIGJlbGlldmUgaXMgYm90aCBj b3JyZWN0IGFuZCBjb25zaXN0ZW50IHdpdGggZXhpc3RpbmcgY29yZSBJbnRlcm5ldCByZXF1aXJl bWVudHMsIGFuZCBoaWdobGlnaHRlZCB3aGVyZSBpdCBkaWZmZXJzIGZyb20gY3VycmVudCB0dW5u ZWxzIChzdGFuZGFyZHMgdHJhY2ssIGluZm9ybWF0aW9uYWwsIG9yIG90aGVyd2lzZSkgaW4gU2Vj dGlvbiA1LiBBdA0KIHRoaXMgcG9pbnQsIHdlIGJlbGlldmUgdGhlIGNvcmUgb2YgdGhpcyBkb2N1 bWVudCBpcyBib3RoIHN0YWJsZSBhbmQgcmVwcmVzZW50cyBub3Qgb25seSBhIGNsZWFyIHZpZXcg b2YgdHVubmVscyBhcyBhbiBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudCBvZiB0aGUgSW50ZXJuZXQs IGJ1dCBhbHNvIHJlcHJlc2VudHMgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZXMgcmVnYXJkaW5n IHRoZSBkZXNpZ24gYW5kIHVzZSBvZiB0dW5uZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxiPjx1PjxzcGFuIGxhbmc9IkVOLVVTIj5PdXIgcmVxdWVzdDo8L3NwYW4+PC91PjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiPkFzIGEgcmVzdWx0LCB3ZSdkIGxpa2UgdG8gYXNrIHRoZSBjaGFpcnMgdG8gaW5pdGlhdGUg YSBjYWxsIHRvIGNoYW5nZSB0aGUgdHJhY2sgb2YgdGhpcyBkb2N1bWVudCBmcm9tIEluZm9ybWF0 aW9uYWwgdG8gQkNQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgcmVzdWx0IG9mIHRoaXMgZGVjaXNpb24gd2lsbCBpbXBhY3QgaG93IFNlY3Rpb24gNSBp cyByZXNvbHZlZC4gSWYgdGhpcyBkb2N1bWVudCBiZWNvbWVzIGEgQkNQLCB0aGF0IHNlY3Rpb24g d2lsbCBiZSBmbGVzaGVkIG91dCBmb3IgV0cgY29uc2Vuc3VzLiBJZiB0aGlzIGRvY3VtZW50IHJl bWFpbnMgSW5mb3JtYXRpb25hbCwgdGhlbiB0aGUgcmVjb21tZW5kYXRpb25zIGluIFNlY3Rpb24g NSBtaWdodCBub3QNCiBiZSBhcHByb3ByaWF0ZSwgYW5kIHdpbGwgbGlrZWx5IG5lZWQgdG8gYmUg b21pdHRlZCBpbiB3aG9sZSBvciBwYXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Kb2U8YnI+DQo8YnI+DQotLS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlN1bW1hcnkgb2YgMDYg Y2hhbmdlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gdXBkYXRlZCBFQ01QIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gdXBkYXRl ZCBtdWx0aXBvaW50IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gdXBkYXRlZCB0ZXJtaW5vbG9neSAoYXRv bSAtJmd0OyBhdG9taWMgcGFja2V0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgLSByZXZpc2VkIEZpZyAxMiBhbmQgRmlnIDEz IGFsZ29yaXRobXMgKGl0IHdhc24ndCBjbGVhciB0aGF0IHRoaXMgd2FzIG91dGVyIGZyYWdtZW50 YXRpb24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDUvMTcvMjAxNyAyOjI4IFBNLCA8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj4NCmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvYT4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgSW50ZXJuZXQgQXJlYSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBJUCBUdW5uZWxzIGluIHRoZSBJbnRl cm5ldCBBcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRo b3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSm9l IFRvdWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWFyayBUb3duc2xleTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+IEZpbGVuYW1lJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1pbnRhcmVh LXR1bm5lbHMtMDYudHh0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4gUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgOiA1MjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE3LTA1LTE3PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9j dW1lbnQgZGlzY3Vzc2VzIHRoZSByb2xlIG9mIElQIHR1bm5lbHMgaW4gdGhlIEludGVybmV0PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgYXJjaGl0ZWN0dXJlLiBBbiBJUCB0dW5uZWwgdHJhbnNpdHMgSVAgZGF0YWdyYW1zIGFzIHBh eWxvYWRzIGluIG5vbi08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyBsaW5rIGxheWVyIHByb3RvY29scy4gVGhpcyBkb2N1bWVudCBl eHBsYWlucyB0aGUgcmVsYXRpb25zaGlwIG9mIElQPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdHVubmVscyB0byBleGlzdGluZyBw cm90b2NvbCBsYXllcnMgYW5kIHRoZSBjaGFsbGVuZ2VzIGluIHN1cHBvcnRpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBJUCB0 dW5uZWxpbmcsIGJhc2VkIG9uIHRoZSBlcXVpdmFsZW5jZSBvZiB0dW5uZWxzIHRvIGxpbmtzLiBU aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyBpbXBsaWNhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBhcmUgdXNlZCB0byBkZXJpdmUg cmVjb21tZW5kYXRpb25zIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB1cGRhdGUgTVRVIGFuZCBmcmFnbWVudCBpc3N1ZXMg aW4gUkZDIDQ0NTkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWludGFyZWEtdHVubmVs cy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaW50YXJlYS10 dW5uZWxzLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDY8L2E+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaW50YXJl YS10dW5uZWxzLTA2Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtaW50YXJlYS10dW5uZWxzLTA2PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1pbnRhcmVhLXR1bm5lbHMtMDYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5JbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5JbnQtYXJlYSBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1h aWx0bzpJbnQtYXJlYUBpZXRmLm9yZyI+SW50LWFyZWFAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR08MB2688E026EA5AFE0AB9C8677289F70VI1PR08MB2688eurp_-- From nobody Mon Jun 5 08:10:40 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A8128B91; Mon, 5 Jun 2017 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvgRG5NdPSkQ; Mon, 5 Jun 2017 08:10:36 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-oln040092072040.outbound.protection.outlook.com [40.92.72.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494E2128B4E; Mon, 5 Jun 2017 08:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ID3teUm/FeGZ7XN72ZneUKkjNPITf2R2PdWAJ4dCU6A=; b=lfkjF71bgF9Mk1x9GTI8IEP2yBA1sqXOrj7cwXz5TKnS+kD1Y3AMf6tbwRYK/n3UfoW4ycpJY6uMuZpLIXaN24tBLI/cicPzGbFTQz4gaXh3pn3SNA24Mt+emuYVmCu0rlsTMYvnnHvjTkQkx5ie093T/1pUaiJ3ixPQXrj+x8aZMdXjM0y/WfLbvsnMhH+fNnM92Vqje8BFzLYlOQt9kKWry/+fOyGX7tN2siVABq1yqtAPjYyLxviPpp9szJ2dv4OEZ8HCRs++jT0X332/Qx+w8cLtJepNokkihQarktHZDA26Rsol/j/ZZ5nb5eByoeFhBu7SrDrXLo6v46edXQ== Received: from AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com (10.152.16.60) by AM5EUR03HT246.eop-EUR03.prod.protection.outlook.com (10.152.17.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Mon, 5 Jun 2017 15:10:34 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.16.57) by AM5EUR03FT031.mail.protection.outlook.com (10.152.16.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Mon, 5 Jun 2017 15:10:34 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377%18]) with mapi id 15.01.1143.016; Mon, 5 Jun 2017 15:10:34 +0000 From: Khaled Omar To: int-area , intarea-ads , intarea-chairs , chair Thread-Topic: IPv10, KRP (RRP) IDs. Thread-Index: AQHS3g3hXZ1j/a6PxE+a/2tbNdv+Zg== Date: Mon, 5 Jun 2017 15:10:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:43294C41BF6C9DD791B07E5373B47D4C727920B8DACEA759DA25B3DB871D7459; UpperCasedChecksum:6AAFCDBADCA5BC48476BAD8DEA58C73A2797811A28CA1BF584F0677F648C06F4; SizeAsReceived:8165; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [vSGUCRajcb1DYnlp3r3f4g1Hbca6UjhL] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR03HT246; 24:+Z19g66I1eDhKnupO4r3b9ko9BHrNSy+iXkQvS9O2JSlAS22XxZHLVjAeSGuvO/9NgpeWhkDtvIojAA7kboI2YDNV0jusBBLwN7Mxiop8DM=; 7:qgMu0W/3JOQvszwnRr1d6jQP0uWHhCH2K80B3SEimGdzUPXrccbhdMpyGE8SftVPJqw9aH0ZkchGbLYap4SnlkUN2Dz+LQtekh7bCo7HNDf9Nk/NyvrUkcNhzGnKxThrsjzn9XD1N3b1ibq0YXEsJDRaTsC51hexbRMBqMcrE0JifGGBw1HjPoNLtFv7xG/Pb4v3Bbpik9qzI1vnJ0wTEwH6fFrQvnIXn4Xf5SE7sXyV2vILntgGumGu1yq6NgAic0ePnlIJ9YXQbJGkZQ9lQDDugyYkiy9doycF97l8/IyfDvMIEV4l69SD/Uw8PPEc x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR03HT246; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-traffictypediagnostic: AM5EUR03HT246: x-ms-office365-filtering-correlation-id: f377a426-7710-41fc-a7f2-08d4ac250327 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR03HT246; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:AM5EUR03HT246; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5EUR03HT246; x-forefront-prvs: 0329B15C8A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB22414B7D5CB01BA8BAA30AC0BDCA0AM4PR0401MB2241_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 15:10:34.1658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT246 Archived-At: Subject: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:10:38 -0000 --_000_AM4PR0401MB22414B7D5CB01BA8BAA30AC0BDCA0AM4PR0401MB2241_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IElQdjEwLCBL UlAgKFJSUCkgSURzLg0KRnJvbTogS2hhbGVkIE9tYXINClRvOiBpZXRmDQpDQzoNCg0KDQpIaSBl dmVyeW9uZSwNCg0KSSBzdGlsbCBkaWRuJ3QgZ2V0IGFueSByZXNwb25zZSBmcm9tIGFueSBpZXRm IG1lbWJlciByZWdhcmRpbmcgdGhlIElEcyBsaXN0ZWQgb24gdGhlIHN1YmplY3QgbGluZSBvZiB0 aGlzIGUtbWFpbC4NCg0KUmVjZW50bHksIHRoZXkgYXJlIHN0aWxsIHVwbG9hZGVkIGFuZCBub3Qg cmVtb3ZlZCwgcmVnYXJkaW5nIHRoZWlyIGRpc2N1c3Npb25zLCBubyB0ZWNobmljYWwgZGlzY3Vz c2lvbiBzdGFydGVkIHNpbmNlIHRoZSB0ZWNobmljYWwgcHJvYmxlbSBvY2N1cmVkIGR1cmluZyB0 aGUgSVB2MTAgcmVtb3RlIHByZXNlbnRhdGlvbiwgZXZlbiB3aXRoIHRoZSByZWNlbnQgc3RhdGlz dGljcyBzaG93cyBhIGNsZWFyIGRpdmlzaW9uIGhhcHBlbmluZyBvbiB0aGUgaW50ZXJuZWwuDQoN CkkgY2Fubm90IGRvIG1vcmUgdGhhbmsgYXNraW5nIGZvciByZW1vdmFsIGlmIG5vIGNsZWFyIGlu dGVyZXN0IGlzIHNob3duIGZvciB0YWtpbmcgdGhlc2UgZHJhZnRzIGZ1cnRoZXIsIGJ1dCBJIHN0 aWxsIHNlZSBubyByZXNwb25zZSwgd2hpY2ggaXMgcmlkaWN1bG91cywgYXMgSSBzaG91bGRuJ3Qg cmVwZWF0IG15IHJlcXVlc3QgZm9yIGEgMm5kIHRpbWUuDQoNClJlZ2FyZHNzLA0KDQpLaGFsZWQg T21hcg0K --_000_AM4PR0401MB22414B7D5CB01BA8BAA30AC0BDCA0AM4PR0401MB2241_ Content-Type: text/html; charset="utf-8" Content-ID: <88A882E6B08A8D4F8140FCAF72254942@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBjbGFzcz0i cXVvdGUiIHN0eWxlPSJsaW5lLWhlaWdodDogMS41Ij48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPg0KU3ViamVjdDogSVB2MTAsIEtSUCAoUlJQKSBJRHMu PGJyPg0KRnJvbTogS2hhbGVkIE9tYXIgPGVuZy5raGFsZWQub21hckBob3RtYWlsLmNvbT48YnI+ DQpUbzogaWV0ZiA8aWV0ZkBpZXRmLm9yZz48YnI+DQpDQzogPGJyPg0KPGJyPg0KPGJyIHR5cGU9 ImF0dHJpYnV0aW9uIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K SGkgZXZlcnlvbmUsPGJyPg0KPGJyPg0KSSBzdGlsbCBkaWRuJ3QgZ2V0IGFueSByZXNwb25zZSBm cm9tIGFueSBpZXRmIG1lbWJlciByZWdhcmRpbmcgdGhlIElEcyBsaXN0ZWQgb24gdGhlIHN1Ympl Y3QgbGluZSBvZiB0aGlzIGUtbWFpbC48YnI+DQo8YnI+DQpSZWNlbnRseSwgdGhleSBhcmUgc3Rp bGwgdXBsb2FkZWQgYW5kIG5vdCByZW1vdmVkLCByZWdhcmRpbmcgdGhlaXIgZGlzY3Vzc2lvbnMs IG5vIHRlY2huaWNhbCBkaXNjdXNzaW9uIHN0YXJ0ZWQgc2luY2UgdGhlIHRlY2huaWNhbCBwcm9i bGVtIG9jY3VyZWQgZHVyaW5nIHRoZSBJUHYxMCByZW1vdGUgcHJlc2VudGF0aW9uLCBldmVuIHdp dGggdGhlIHJlY2VudCBzdGF0aXN0aWNzIHNob3dzIGEgY2xlYXIgZGl2aXNpb24gaGFwcGVuaW5n IG9uIHRoZQ0KIGludGVybmVsLjxicj4NCjxicj4NCkkgY2Fubm90IGRvIG1vcmUgdGhhbmsgYXNr aW5nIGZvciByZW1vdmFsIGlmIG5vIGNsZWFyIGludGVyZXN0IGlzIHNob3duIGZvciB0YWtpbmcg dGhlc2UgZHJhZnRzIGZ1cnRoZXIsIGJ1dCBJIHN0aWxsIHNlZSBubyByZXNwb25zZSwgd2hpY2gg aXMgcmlkaWN1bG91cywgYXMgSSBzaG91bGRuJ3QgcmVwZWF0IG15IHJlcXVlc3QgZm9yIGEgMm5k IHRpbWUuPGJyPg0KPGJyPg0KUmVnYXJkc3MsPGJyPg0KPGJyPg0KS2hhbGVkIE9tYXI8L2Jsb2Nr cXVvdGU+DQo8L2lldGZAaWV0Zi5vcmc+PC9lbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb20+PC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR0401MB22414B7D5CB01BA8BAA30AC0BDCA0AM4PR0401MB2241_-- From nobody Mon Jun 5 08:46:13 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBE5128ACA for ; Mon, 5 Jun 2017 08:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgmlIplJ5bgN for ; Mon, 5 Jun 2017 08:46:10 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 D85161294B2 for ; Mon, 5 Jun 2017 08:46:08 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 4so7950294ybl.1 for ; Mon, 05 Jun 2017 08:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n0MseXISR5w9J++7dcCb1d5/5Uj7RPOKLBdVisbJYuc=; b=USYHyvmvuix6lS0NQAgCjbgWrmVXwPeXwU5aw1D93gEUWFnjEwmD7ZwhHsB0UIKprj 1Q40TfQFtb0K0L47Jp3k0pXHY5BGSxtBy9T2WqY6GetSYQgNJM8IJu7hMOefhMQ/yvUu TDlOPEGHU3uOKscWFWWoC2I/tQNKZ+y5ZntxvW5zXaj1MloT8/Y136ackc/zfbKEnzwx dwHIz0gsNYBsKWAeNNEhBebLCFei/VXVD+eZe66KCtRgEwdPQ/nS4drfBJuXw11ncriC ruKD7HRUooT/eTjOVdrMb5HkYY3oq1PqTukGkjb0FNbTzbicxKfy7s7dODLu2/xxCHDQ nQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n0MseXISR5w9J++7dcCb1d5/5Uj7RPOKLBdVisbJYuc=; b=pygn5vGN733U/QGi5m6/QaATf9O6ARACecgC7zAmOs0vhIQNPSG5MTHFiwJORKoJ2M WLbxXDaozMSMHXqW/zdpgda4ES5XteEDdW10ECT8LMaHF0X/jGteYpyicF3ECMOw4onk K9HyV0yy34MIEuZjQXwz6SPGCYmXRuMAJpqFnNdFpx22T8RPT1AjQ8fPSHQJhIdaGhBR y7+VP9ve5vxciKVt68KbiWa3QiyrI8/Nk50vezZW8zpGW55p6A81ApeoxWa32gBws/EA RVpQgGNoQCgLL7hQNun26LJMAuAxdvEfQf2onjx+DCEyi2lrho+8flfJDeiE/qsrvrC8 m7qQ== X-Gm-Message-State: AODbwcAVeSAc5/+ZSvjnac/gALcKbrg665IpwTxKCaPNC6Ha3OFpvUTX hiRMwPofbL5pckZlPH2FFsPn0Y5r+k7D X-Received: by 10.37.224.147 with SMTP id x141mr10002465ybg.193.1496677567877; Mon, 05 Jun 2017 08:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Mon, 5 Jun 2017 08:45:47 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 6 Jun 2017 00:45:47 +0900 Message-ID: To: Khaled Omar Cc: int-area , intarea-ads , intarea-chairs , chair Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c089c96cd6db90551386691" Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:46:13 -0000 --94eb2c089c96cd6db90551386691 Content-Type: multipart/alternative; boundary="94eb2c089c96c7a69a0551386660" --94eb2c089c96c7a69a0551386660 Content-Type: text/plain; charset="UTF-8" You probably want to read the RFCs and NOTE WELL about contributions to the IETF. On 6 June 2017 at 00:10, Khaled Omar wrote: > > > -------- Original Message -------- > Subject: IPv10, KRP (RRP) IDs. > From: Khaled Omar > To: ietf > CC: > > > Hi everyone, > > I still didn't get any response from any ietf member regarding the IDs > listed on the subject line of this e-mail. > > Recently, they are still uploaded and not removed, regarding their > discussions, no technical discussion started since the technical problem > occured during the IPv10 remote presentation, even with the recent > statistics shows a clear division happening on the internel. > > I cannot do more thank asking for removal if no clear interest is shown > for taking these drafts further, but I still see no response, which is > ridiculous, as I shouldn't repeat my request for a 2nd time. > > Regardss, > > Khaled Omar > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > --94eb2c089c96c7a69a0551386660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You probably want to read the RFCs and NOTE WELL about con= tributions to the IETF.

On 6 June 2017 at 00:10, Khaled Omar <eng.khaled.oma= r@hotmail.com> wrote:


-------- Original Message --------
Subject: IPv10, KRP (RRP) IDs.
From: Khaled Omar
To: ietf
CC:


Hi everyone,

I still didn't get any response from any ietf member regarding the IDs = listed on the subject line of this e-mail.

Recently, they are still uploaded and not removed, regarding their discussi= ons, no technical discussion started since the technical problem occured du= ring the IPv10 remote presentation, even with the recent statistics shows a= clear division happening on the internel.

I cannot do more thank asking for removal if no clear interest is shown for= taking these drafts further, but I still see no response, which is ridicul= ous, as I shouldn't repeat my request for a 2nd time.

Regardss,

Khaled Omar

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


--94eb2c089c96c7a69a0551386660-- --94eb2c089c96cd6db90551386691 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgs4gzzLH0OyPDfUbF4NGMjEmu7F5KM89V YZvGc3KvJagwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA1 MTU0NjA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAK5jcLpcHe+Qiv3+j+X3XErfqN/r5DeQLPAVuI2cwD80Qv4SZJuQ vuQ/TPgVdNftbR+py1lIlZqKc9Yzwf1UP5QUOBE5HWl4rLSWl+qSqBFB1dsYOFQe+yuBjRDIiLHE XUTXKrIwlcS9ROd1TYR5hH5rbnXX8WyPXvakanZ8MEcUIt1upG5WX5FQljiGvwK7aVcJuV/5GUE5 3IxfgGuaHYyKH0TjLGLAWwezi9IRVjxPQFzFu67O8SXQybzeIhbMSGOZgQMaJuUIs/IZLZNx269P Q2u39C0VChv686kSUlS5SE5hh/1QxAzcwhaC8gdeyUgWu0zfqABLDtvLykhwPgI= --94eb2c089c96cd6db90551386691-- From nobody Mon Jun 5 09:42:39 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717E129B62 for ; Mon, 5 Jun 2017 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSoRH7nX_Sn5 for ; Mon, 5 Jun 2017 09:42:35 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 5DB23128D3E for ; Mon, 5 Jun 2017 09:42:35 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id h39so24453163uaa.3 for ; Mon, 05 Jun 2017 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CDca+JS0KYneBZl+30l3++LbT4gykLOZeJgABaTL1YE=; b=mN1BKgbyICqR/2wvBkM8aOub9Q6LygSBFJmLMWmICr80GX48F3AkE2lsSVrcH9f5bj U8LQi9KNJVYVHk9788QGHVuDoKWxOJhoFwnEZ/Tx8OQh39ztLOTY+J+dMJk0tcjsJ/Le kYjex4i5FU27pQBeopzHrrN0pQ5EQ5iFJ8gmCCtjSVsxKR0Kg5IJPWAVLsorV+aCFtN0 0GG4HaKt3IUtf29n7bObiy4Nv7lPylwHiviSTl4WzkLFK+oFwgMIT7TF6QoC7ztn9Oo1 z+FCjYWUwE+F8k5ZHAzLJM9y0RrdvBPvTK/USzrRR94lwFJjuIJf3okeHpwq4f7Crj5v VOgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CDca+JS0KYneBZl+30l3++LbT4gykLOZeJgABaTL1YE=; b=IkqPqq3Tpet4kNHSzn0R44t8ocmSNZ3HZBmE+z75Xxw6cl2lz6HV1mEvsiPXxgC8D4 DPgloZRFbOhkrLAEX1UPibDS7FUrAjIa+FsEYMyhjDs3AaYhYrYID4f48vIeoPJUDALe rbMdUyAUwvKwnlg2XjAKCswwAKakMU7/7qRpyhJtKZv+ExX70xZQiYtyKdAfdO4nO0Gd 0S3KS9FThf29fsH7u/8cUScuemuy8KVZ/OjxSIum9oNdgZ/z5CV+sytCfVOC3ZVnyaLA pILUxly6+NDMbFzq5oy4/uCjZcvW2Uts4MTxKVK4J4w2vKdftgxvQWGxkjkXVa+LWMMV 8IHg== X-Gm-Message-State: AODbwcC7BxX1qC0o6c98xQXYxGOxm9cM0bdPzG50rBQm5BmkpZ6iVVM/ Qhl+mMAUkTVlGXW244DWhedAaO8F5f0B X-Received: by 10.176.0.248 with SMTP id 111mr8210578uaj.133.1496680954436; Mon, 05 Jun 2017 09:42:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Mon, 05 Jun 2017 16:42:23 +0000 Message-ID: To: Erik Kline , Khaled Omar Cc: chair , int-area , intarea-ads , intarea-chairs Content-Type: multipart/alternative; boundary="001a113ac2d4a20c91055139303e" Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:42:38 -0000 --001a113ac2d4a20c91055139303e Content-Type: text/plain; charset="UTF-8" ... and the email which was sent to you. https://mailarchive.ietf.org/arch/msg/ietf/tllVkC8PXR9pv1OsuM53Pg4bLnA W On Mon, Jun 5, 2017 at 11:46 AM Erik Kline wrote: > You probably want to read the RFCs and NOTE WELL about contributions to > the IETF. > > On 6 June 2017 at 00:10, Khaled Omar wrote: > >> >> >> -------- Original Message -------- >> Subject: IPv10, KRP (RRP) IDs. >> From: Khaled Omar >> To: ietf >> CC: >> >> >> Hi everyone, >> >> I still didn't get any response from any ietf member regarding the IDs >> listed on the subject line of this e-mail. >> >> Recently, they are still uploaded and not removed, regarding their >> discussions, no technical discussion started since the technical problem >> occured during the IPv10 remote presentation, even with the recent >> statistics shows a clear division happening on the internel. >> >> I cannot do more thank asking for removal if no clear interest is shown >> for taking these drafts further, but I still see no response, which is >> ridiculous, as I shouldn't repeat my request for a 2nd time. >> >> Regardss, >> >> Khaled Omar >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> >> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --001a113ac2d4a20c91055139303e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
... and the email which was sent to you.

=
W


On Mon, Jun 5, 2017 at 11:46 AM Erik Kline <ek@google.com> wrote:
You probably want to read the RFCs and NOTE WEL= L about contributions to the IETF.

On 6 June 2017 at 00:10, Khaled Omar <eng.khaled.omar= @hotmail.com> wrote:


-------- Original Message --------
Subject: IPv10, KRP (RRP) IDs.
From: Khaled Omar
To: ietf
CC:


Hi everyone,

I still didn't get any response from any ietf member regarding the IDs = listed on the subject line of this e-mail.

Recently, they are still uploaded and not removed, regarding their discussi= ons, no technical discussion started since the technical problem occured du= ring the IPv10 remote presentation, even with the recent statistics shows a= clear division happening on the internel.

I cannot do more thank asking for removal if no clear interest is shown for= taking these drafts further, but I still see no response, which is ridicul= ous, as I shouldn't repeat my request for a 2nd time.

Regardss,

Khaled Omar

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
--001a113ac2d4a20c91055139303e-- From nobody Mon Jun 5 09:51:55 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9D129B56; Mon, 5 Jun 2017 09:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTs8Xek_BeQY; Mon, 5 Jun 2017 09:51:51 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-oln040092072073.outbound.protection.outlook.com [40.92.72.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DEF127275; Mon, 5 Jun 2017 09:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3W8AeaqBX515YSI3+tK6jcNvsZbw+lam7guIZIsc/ts=; b=T7v20actdERgt6yQjJtiktFHQ1r6W3cGQxpRr4vY3izvdzPBp/hlsyIFDOskdPwKYUwQOa0g0x09mYzdASbqEqcPeO0gvA9gSKeIE4pR7rJuEUgx1wrFYDIUJfDgFlkQjnOwuCMbAjT61YSjcyp00RURjMO6OBJ8p0IjHmM4e3bU+TdG1lZyEmbylMQCGIAfoS5qE//qbyVMg41Li2q/ryuW16i07hdVa069Efzi9+t7zTVQomWaRJezJTsO9fVyUCuz1cYeYfWrjcLy0r6AxvOcB5tjwbqYhWm8cXJCIbV6xPf68mlWN6ZWx2LChQVVQDdPseaqVSh2wG397nX5UA== Received: from AM5EUR03FT037.eop-EUR03.prod.protection.outlook.com (10.152.16.53) by AM5EUR03HT011.eop-EUR03.prod.protection.outlook.com (10.152.16.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Mon, 5 Jun 2017 16:51:48 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.16.56) by AM5EUR03FT037.mail.protection.outlook.com (10.152.17.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Mon, 5 Jun 2017 16:51:48 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377%18]) with mapi id 15.01.1143.016; Mon, 5 Jun 2017 16:51:48 +0000 From: Khaled Omar To: Warren Kumari , Erik Kline CC: chair , int-area , intarea-ads , intarea-chairs Thread-Topic: [Int-area] Fw: IPv10, KRP (RRP) IDs. Thread-Index: AQHS3g3hXZ1j/a6PxE+a/2tbNdv+Zg== Date: Mon, 5 Jun 2017 16:51:48 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:CF9B6092C4E433918D99648D2E2B4E77890D990BA71B7C7288027B71E67FDC96; UpperCasedChecksum:702A48A3F6239FDB8DC92B658C941178984B9C3049BD8AF532154A6C2230288E; SizeAsReceived:8353; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [W3n5w/zPSHidYa6xgXrKU6eEi0sD6kT9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR03HT011; 24:cipyYxDkV7imj2WbFdxGLJKnVUGW7jntBuVFegij1DioGMM2yeQuE7cYljl45KBfW21JySpDrp5cdQkZ5za7KlXzCQgySr4kyvTQUsaYCis=; 7:CirFvjDPol72eyXwARRWMLZ9/EpoHdVaM+fh66fSgfZ7BJIY43+bqtiTLO25oUOZDQmjxox3hbbXVMIjpyuZN53S+GMtQoHeQer5MIp+tOANaVaH5oG0lfo5IJWQKEMlLM4ESPedwfeQjoX7ExFh601T8uAzhzPeg4KaxaqCTIHoptjBQzxCpyrzxQwJ5lskKqkwuXq2Qh3TlPMJnSWQEYvTNOvQZOlvdXTKw3fbkdPMCp5KJrgJFyyuEv/vxHTEKh2LASWQi6b6SdwuSC8faDxD23hSCIduRkwz3xtziK6uveCUiwvCor7/hpYc+w0L x-incomingheadercount: 45 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR03HT011; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-traffictypediagnostic: AM5EUR03HT011: x-ms-office365-filtering-correlation-id: 177d6141-15ab-4719-43bf-08d4ac332776 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR03HT011; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:AM5EUR03HT011; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5EUR03HT011; x-forefront-prvs: 0329B15C8A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB2241EE7B633DB9DA034E8011BDCA0AM4PR0401MB2241_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 16:51:48.2883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT011 Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:51:53 -0000 --_000_AM4PR0401MB2241EE7B633DB9DA034E8011BDCA0AM4PR0401MB2241_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZXBsaWVkIHRvIHRoaXMgZS1tYWlsIGxvbmcgdGltZSBhZ28uDQoNClRoZXNlIGFyZSBteSBk cmFmdHMgYXMgaSdtIHRoZSBvbmx5IGF1dGhvciwgSSBoYXZlIHRoZSByaWdodCB0byBhc2sgZm9y IHVwbG9hZGluZyBhbmQgcmVtb3ZhbCwgd2hhdCBpcyBkaWZmaWN1bHQgaW4gdGhpcyB0b28hISEN Cg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiBSZTogW0lu dC1hcmVhXSBGdzogSVB2MTAsIEtSUCAoUlJQKSBJRHMuDQpGcm9tOiBXYXJyZW4gS3VtYXJpDQpU bzogRXJpayBLbGluZSAsS2hhbGVkIE9tYXINCkNDOiBjaGFpciAsaW50LWFyZWEgLGludGFyZWEt YWRzICxpbnRhcmVhLWNoYWlycw0KDQoNCi4uLiBhbmQgdGhlIGVtYWlsIHdoaWNoIHdhcyBzZW50 IHRvIHlvdS4NCg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZXRmL3Rs bFZrQzhQWFI5cHYxT3N1TTUzUGc0YkxuQQ0KDQpXDQoNCg0KT24gTW9uLCBKdW4gNSwgMjAxNyBh dCAxMTo0NiBBTSBFcmlrIEtsaW5lIDxla0Bnb29nbGUuY29tPG1haWx0bzpla0Bnb29nbGUuY29t Pj4gd3JvdGU6DQpZb3UgcHJvYmFibHkgd2FudCB0byByZWFkIHRoZSBSRkNzIGFuZCBOT1RFIFdF TEwgYWJvdXQgY29udHJpYnV0aW9ucyB0byB0aGUgSUVURi4NCg0KT24gNiBKdW5lIDIwMTcgYXQg MDA6MTAsIEtoYWxlZCBPbWFyIDxlbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb208bWFpbHRvOmVu Zy5raGFsZWQub21hckBob3RtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IElQdjEwLCBLUlAgKFJSUCkgSURzLg0KRnJvbTog S2hhbGVkIE9tYXINClRvOiBpZXRmDQpDQzoNCg0KDQpIaSBldmVyeW9uZSwNCg0KSSBzdGlsbCBk aWRuJ3QgZ2V0IGFueSByZXNwb25zZSBmcm9tIGFueSBpZXRmIG1lbWJlciByZWdhcmRpbmcgdGhl IElEcyBsaXN0ZWQgb24gdGhlIHN1YmplY3QgbGluZSBvZiB0aGlzIGUtbWFpbC4NCg0KUmVjZW50 bHksIHRoZXkgYXJlIHN0aWxsIHVwbG9hZGVkIGFuZCBub3QgcmVtb3ZlZCwgcmVnYXJkaW5nIHRo ZWlyIGRpc2N1c3Npb25zLCBubyB0ZWNobmljYWwgZGlzY3Vzc2lvbiBzdGFydGVkIHNpbmNlIHRo ZSB0ZWNobmljYWwgcHJvYmxlbSBvY2N1cmVkIGR1cmluZyB0aGUgSVB2MTAgcmVtb3RlIHByZXNl bnRhdGlvbiwgZXZlbiB3aXRoIHRoZSByZWNlbnQgc3RhdGlzdGljcyBzaG93cyBhIGNsZWFyIGRp dmlzaW9uIGhhcHBlbmluZyBvbiB0aGUgaW50ZXJuZWwuDQoNCkkgY2Fubm90IGRvIG1vcmUgdGhh bmsgYXNraW5nIGZvciByZW1vdmFsIGlmIG5vIGNsZWFyIGludGVyZXN0IGlzIHNob3duIGZvciB0 YWtpbmcgdGhlc2UgZHJhZnRzIGZ1cnRoZXIsIGJ1dCBJIHN0aWxsIHNlZSBubyByZXNwb25zZSwg d2hpY2ggaXMgcmlkaWN1bG91cywgYXMgSSBzaG91bGRuJ3QgcmVwZWF0IG15IHJlcXVlc3QgZm9y IGEgMm5kIHRpbWUuDQoNClJlZ2FyZHNzLA0KDQpLaGFsZWQgT21hcg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSW50LWFyZWEgbWFpbGluZyBsaXN0 DQpJbnQtYXJlYUBpZXRmLm9yZzxtYWlsdG86SW50LWFyZWFAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkludC1hcmVhIG1haWxpbmcgbGlzdA0K SW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOkludC1hcmVhQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0K --_000_AM4PR0401MB2241EE7B633DB9DA034E8011BDCA0AM4PR0401MB2241_ Content-Type: text/html; charset="utf-8" Content-ID: <265F5EDC9258B145A9CDC5B54A79EEED@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KSSByZXBsaWVkIHRv IHRoaXMgZS1tYWlsIGxvbmcgdGltZSBhZ28uPGJyPg0KPGJyPg0KVGhlc2UgYXJlIG15IGRyYWZ0 cyBhcyBpJ20gdGhlIG9ubHkgYXV0aG9yLCBJIGhhdmUgdGhlIHJpZ2h0IHRvIGFzayBmb3IgdXBs b2FkaW5nIGFuZCByZW1vdmFsLCB3aGF0IGlzIGRpZmZpY3VsdCBpbiB0aGlzIHRvbyEhIQ0KPGRp diBjbGFzcz0icXVvdGUiIHN0eWxlPSJsaW5lLWhlaWdodDogMS41Ij48YnI+DQo8YnI+DQotLS0t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPg0KU3ViamVjdDogUmU6IFtJbnQtYXJl YV0gRnc6IElQdjEwLCBLUlAgKFJSUCkgSURzLjxicj4NCkZyb206IFdhcnJlbiBLdW1hcmkgPHdh cnJlbkBrdW1hcmkubmV0Pjxicj4NClRvOiBFcmlrIEtsaW5lIDxla0Bnb29nbGUuY29tPixLaGFs ZWQgT21hciA8ZW5nLmtoYWxlZC5vbWFyQGhvdG1haWwuY29tPjxicj4NCkNDOiBjaGFpciA8Y2hh aXJAaWV0Zi5vcmc+LGludC1hcmVhIDxpbnQtYXJlYUBpZXRmLm9yZz4saW50YXJlYS1hZHMgPGlu dGFyZWEtYWRzQGlldGYub3JnPg0KLGludGFyZWEtY2hhaXJzIDxpbnRhcmVhLWNoYWlyc0BpZXRm Lm9yZz48YnI+DQo8YnI+DQo8YnIgdHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xh c3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPi4uLiBhbmQg dGhlIGVtYWlsIHdoaWNoIHdhcyBzZW50IHRvIHlvdS48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48 YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL2lldGYvdGxsVmtDOFBYUjlwdjFPc3VNNTNQZzRiTG5BIj5odHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lldGYvdGxsVmtDOFBYUjlwdjFPc3VN NTNQZzRiTG5BPC9hPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPlc8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxi cj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+T24gTW9uLCBKdW4gNSwgMjAxNyBh dCAxMTo0NiBBTSBFcmlrIEtsaW5lICZsdDs8YSBocmVmPSJtYWlsdG86ZWtAZ29vZ2xlLmNvbSI+ ZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2PllvdSBwcm9iYWJseSB3YW50IHRv IHJlYWQgdGhlIFJGQ3MgYW5kIE5PVEUgV0VMTCBhYm91dCBjb250cmlidXRpb25zIHRvIHRoZSBJ RVRGLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiA2IEp1bmUgMjAxNyBhdCAwMDoxMCwgS2hhbGVkIE9tYXIgPHNwYW4+Jmx0 OzxhIGhyZWY9Im1haWx0bzplbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5lbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0K PGRpdiBjbGFzcz0ibV81NjcyMDMyMjU1NDg3NTgxMjk3bV83NTkzNDg5NTg2NjMwMzUxMnF1b3Rl IiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41Ij4NCjxicj4NCjxicj4NCi0tLS0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0tLS08YnI+DQpTdWJqZWN0OiBJUHYxMCwgS1JQIChSUlApIElEcy48YnI+ DQpGcm9tOiBLaGFsZWQgT21hciA8dT48L3U+PGJyPg0KVG86IGlldGYgPHU+PC91Pjxicj4NCkND OiA8YnI+DQo8YnI+DQo8YnIgdHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9 Im1fNTY3MjAzMjI1NTQ4NzU4MTI5N21fNzU5MzQ4OTU4NjYzMDM1MTJxdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KSGkgZXZlcnlvbmUsPGJyPg0KPGJyPg0KSSBzdGlsbCBkaWRuJ3QgZ2V0IGFueSByZXNw b25zZSBmcm9tIGFueSBpZXRmIG1lbWJlciByZWdhcmRpbmcgdGhlIElEcyBsaXN0ZWQgb24gdGhl IHN1YmplY3QgbGluZSBvZiB0aGlzIGUtbWFpbC48YnI+DQo8YnI+DQpSZWNlbnRseSwgdGhleSBh cmUgc3RpbGwgdXBsb2FkZWQgYW5kIG5vdCByZW1vdmVkLCByZWdhcmRpbmcgdGhlaXIgZGlzY3Vz c2lvbnMsIG5vIHRlY2huaWNhbCBkaXNjdXNzaW9uIHN0YXJ0ZWQgc2luY2UgdGhlIHRlY2huaWNh bCBwcm9ibGVtIG9jY3VyZWQgZHVyaW5nIHRoZSBJUHYxMCByZW1vdGUgcHJlc2VudGF0aW9uLCBl dmVuIHdpdGggdGhlIHJlY2VudCBzdGF0aXN0aWNzIHNob3dzIGEgY2xlYXIgZGl2aXNpb24gaGFw cGVuaW5nIG9uIHRoZQ0KIGludGVybmVsLjxicj4NCjxicj4NCkkgY2Fubm90IGRvIG1vcmUgdGhh bmsgYXNraW5nIGZvciByZW1vdmFsIGlmIG5vIGNsZWFyIGludGVyZXN0IGlzIHNob3duIGZvciB0 YWtpbmcgdGhlc2UgZHJhZnRzIGZ1cnRoZXIsIGJ1dCBJIHN0aWxsIHNlZSBubyByZXNwb25zZSwg d2hpY2ggaXMgcmlkaWN1bG91cywgYXMgSSBzaG91bGRuJ3QgcmVwZWF0IG15IHJlcXVlc3QgZm9y IGEgMm5kIHRpbWUuPGJyPg0KPGJyPg0KUmVnYXJkc3MsPGJyPg0KPGJyPg0KS2hhbGVkIE9tYXI8 L2Jsb2NrcXVvdGU+DQo8dT48L3U+PHU+PC91PjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkludC1hcmVhIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJbnQtYXJlYUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPkludC1hcmVhQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWEiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFy ZWE8L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSW50LWFy ZWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkludC1hcmVhQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+SW50LWFyZWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYSIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p bnQtYXJlYTwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR0401MB2241EE7B633DB9DA034E8011BDCA0AM4PR0401MB2241_-- From nobody Mon Jun 5 10:28:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A52129AE8; Mon, 5 Jun 2017 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkvenvQQJrWb; Mon, 5 Jun 2017 10:28:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065014.outbound.protection.outlook.com [40.92.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A0B129534; Mon, 5 Jun 2017 10:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i9QSl5ZxETBZ8ELBe5AFmD5cQPzFnUbEAZnujb+wrII=; b=ubYoqfFBeXIan8wUmiLa2Hd6jbTD99vTbYppOepzanKsbtcA9rOo5nup/JUT9MfWUeYT1ObY7qMlKqiThnDl/sBR2PsWF326EOduNbfKW78S8uafwwUr5eMZn4e8k+vqNsm28dAcpQeN4U6DgwafLFdHNdpxyfbBRiQofHkhhAzBIZP4bAPRxcfRX8lFoWmZxnLFmKPNJ6GqBwenJ5/JYk11AWwt2nqNQ2AqCZciod1Y47dfnjNccz6hO/vUxH0EajzFgZN8fRwF9WF1hn9wNfQPwRmot8Q5AKO7FARHWTqWje2p8mrQse38u40KiPqp9n5sAIVrSAji2wdi07QCtQ== Received: from DB5EUR01FT062.eop-EUR01.prod.protection.outlook.com (10.152.4.51) by DB5EUR01HT192.eop-EUR01.prod.protection.outlook.com (10.152.5.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Mon, 5 Jun 2017 17:28:18 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.4.55) by DB5EUR01FT062.mail.protection.outlook.com (10.152.5.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Mon, 5 Jun 2017 17:28:18 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377%18]) with mapi id 15.01.1143.016; Mon, 5 Jun 2017 17:28:18 +0000 From: Khaled Omar To: int-area , intarea-ads , intarea-chairs Thread-Topic: [Int-area] Fw: IPv10, KRP (RRP) IDs. Thread-Index: AQHS3g3hXZ1j/a6PxE+a/2tbNdv+Zg== Date: Mon, 5 Jun 2017 17:28:17 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:2B039B76B2F1862D2314A3EE954D392B45811A971FD5AC7FC8C6B4A8CC537B5C; UpperCasedChecksum:D15E24AD9A881FADA5F2E30B2E0EF0156BFD53F3012CD3162439FB443FA25F7C; SizeAsReceived:8241; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [4IfTow6Aauq6Sk/7MeKj00u6YI7YoKZf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5EUR01HT192; 24:6JEnLkNi0tFWQK8A4evnXuATEjQZZoqwKzeeLhV46xE6ZwFPpmyMiaffI+1OqtkWXFuarBZTPpgOiolkeLNm5j0X42QsIDhdmZ3YWH9ud1g=; 7:4OnG4hhhOvIieA8Y4TWuuwCOT8e1gfkjljrfd5AHVoYdFnTGADSbake5mUmFbnhrZcccqw9C/3PvMDKGgM6yLMiRH64HYK88r7Lv6PSoBiBpSz5YsqM63jhPqDNCY1O/SjY9MXLL/zv5FhAFCWdqqjhV2pbF8SPbQOixikpLN3vfOfHoHtTMuyidu+pB+4gPrRiqGG3EU+Yn/MLY6Y01GbBrJ3j4fLJhaAwxEDOMM55he1sUm3m4kA1Rk94XPgPZZvCC+ySdiC+Ek4QK+bI7GUGed8Innz4GJUNeHOfCWqt35kgyQbenvKnQsZXwC84I x-incomingheadercount: 44 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR01HT192; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-traffictypediagnostic: DB5EUR01HT192: x-ms-office365-filtering-correlation-id: 15aeeb72-2d9e-4ade-7118-08d4ac3840c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:DB5EUR01HT192; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:DB5EUR01HT192; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5EUR01HT192; x-forefront-prvs: 0329B15C8A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB2241EAA00D863A8494037113BDCA0AM4PR0401MB2241_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 17:28:17.9761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT192 Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:28:23 -0000 --_000_AM4PR0401MB2241EAA00D863A8494037113BDCA0AM4PR0401MB2241_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gb25lIGNhbiBmb3JjZSBhbiBpbnRlcm5ldCBkcmFmdCB0byBub3QgYmUgcmVtb3ZlZCBpZiB0 aGUgb25seSBhdXRob3IgYXNrZWQgZm9yIHRoYXQsIHNheWluZyBrZWVwaW5nIHRoZW0gZm9yZXZl ciBtZWFucyB5b3UgaGF2ZSBjb25mbGljdHMgaW5zaWRlIHVyc2VsZiwgYW5kIGRvbid0IGtub3cg d2hhdCB0byBkbywgc28gSSdtIHRlbGxpbmcgdSBub3cgd2hhdCB0byBkbywgUkVNT1ZFIHRoZXNl IElEcyBhbmQgbm8gbW9yZSByZXByZXNlbnRhdGlvbiBieSB0aGlzIGlldGYuDQoNCg0KLS0tLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gRnc6 IElQdjEwLCBLUlAgKFJSUCkgSURzLg0KRnJvbTogTWlrYWVsIEFicmFoYW1zc29uDQpUbzogS2hh bGVkIE9tYXINCkNDOg0KDQoNCk9uIE1vbiwgNSBKdW4gMjAxNywgS2hhbGVkIE9tYXIgd3JvdGU6 DQoNCj4gVGhlc2UgYXJlIG15IGRyYWZ0cyBhcyBpJ20gdGhlIG9ubHkgYXV0aG9yLCBJIGhhdmUg dGhlIHJpZ2h0IHRvIGFzayBmb3INCj4gdXBsb2FkaW5nIGFuZCByZW1vdmFsLCB3aGF0IGlzIGRp ZmZpY3VsdCBpbiB0aGlzIHRvbyEhIQ0KDQpZb3UgbmVlZCB0byByZS1yZWFkIHRoZSBub3RlIHdl bGwsIGJlY2F1c2Ugd2hhdCB5b3UncmUgc2F5aW5nIGlzIG5vdA0KYWNjdXJhdGUuDQoNCkRyYWZ0 cyBhcmUgbm90IHJlbW92ZWQuIEFzIHNvb24gYXMgeW91IHVwbG9hZGVkIHRoZW0geW91IGhhdmUg Y29udHJpYnV0ZWQNCnRoZW0uDQoNClJlYWQgdGhlIG5vdGUgd2VsbC4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYWJvdXQvbm90ZS13ZWxsLmh0bWwNCg0KIkFueSBzdWJtaXNzaW9uIHRvIHRoZSBJ RVRGIGludGVuZGVkIGJ5IHRoZSBDb250cmlidXRvciBmb3IgcHVibGljYXRpb24gYXMNCmFsbCBv ciBwYXJ0IG9mIGFuIElFVEYgSW50ZXJuZXQtRHJhZnQgb3IgUkZDIGFuZCBhbnkgc3RhdGVtZW50 IG1hZGUgd2l0aGluDQp0aGUgY29udGV4dCBvZiBhbiBJRVRGIGFjdGl2aXR5IGlzIGNvbnNpZGVy ZWQgYW4gIklFVEYgQ29udHJpYnV0aW9uIi4iDQoNCiJBbGwgSUVURiBDb250cmlidXRpb25zIGFy ZSBzdWJqZWN0IHRvIHRoZSBydWxlcyBvZiBSRkMgNTM3OCBhbmQgUkZDIDM5NzkNCih1cGRhdGVk IGJ5IFJGQyA0ODc5KS4iDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Mzc4DQoN CiIzLjEuIFJpZ2h0cyBHcmFudGVkIGluIENvbnRyaWJ1dGlvbnMNCg0KVGhlIElFVEYgVHJ1c3Qg YW5kIHRoZSBJRVRGIG11c3Qgb2J0YWluIHRoZSByaWdodCB0byBwdWJsaXNoIGFuIElFVEYNCkNv bnRyaWJ1dGlvbiBhcyBhbiBSRkMgb3IgYW4gSW50ZXJuZXQtRHJhZnQgZnJvbSB0aGUgQ29udHJp YnV0b3JzLg0KDQpBIHByaW1hcnkgb2JqZWN0aXZlIG9mIHRoaXMgcG9saWN5IGlzIHRvIG9idGFp biBmcm9tIHRoZSBkb2N1bWVudA0KYXV0aG9ycyBvbmx5IHRoZSBub24tZXhjbHVzaXZlIHJpZ2h0 cyB0aGF0IGFyZSBuZWVkZWQgdG8gZGV2ZWxvcCBhbmQNCnB1Ymxpc2ggSUVURiBEb2N1bWVudHMg YW5kIHRvIHVzZSBJRVRGIENvbnRyaWJ1dGlvbnMgaW4gdGhlIElFVEYNClN0YW5kYXJkcyBQcm9j ZXNzIGFuZCBwb3RlbnRpYWxseSBlbHNld2hlcmUuDQoNClRoZSBhdXRob3JzIHJldGFpbiBhbGwg b3RoZXIgcmlnaHRzLCBidXQgY2Fubm90IHdpdGhkcmF3IHRoZSBhYm92ZQ0KcmlnaHRzIGZyb20g dGhlIElFVEYgVHJ1c3QgYW5kIHRoZSBJRVRGLg0KIg0KDQpCeSB1cGxvYWRpbmcgdGhlIGRyYWZ0 cywgeW91IGdhdmUgdGhlIElFVEYgcmlnaHQgdG8ga2VlcCB0aGVzZSBkcmFmdHMNCmZvcmV2ZXIu DQoNCi0tDQpNaWthZWwgQWJyYWhhbXNzb24gZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCg== --_000_AM4PR0401MB2241EAA00D863A8494037113BDCA0AM4PR0401MB2241_ Content-Type: text/html; charset="utf-8" Content-ID: <551A2D1AE58BE643B9CDF75B7D02E5A5@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KTm8gb25lIGNhbiBm b3JjZSBhbiBpbnRlcm5ldCBkcmFmdCB0byBub3QgYmUgcmVtb3ZlZCBpZiB0aGUgb25seSBhdXRo b3IgYXNrZWQgZm9yIHRoYXQsIHNheWluZyBrZWVwaW5nIHRoZW0gZm9yZXZlciBtZWFucyB5b3Ug aGF2ZSBjb25mbGljdHMgaW5zaWRlIHVyc2VsZiwgYW5kIGRvbid0IGtub3cgd2hhdCB0byBkbywg c28gSSdtIHRlbGxpbmcgdSBub3cgd2hhdCB0byBkbywgUkVNT1ZFIHRoZXNlIElEcyBhbmQgbm8g bW9yZSByZXByZXNlbnRhdGlvbg0KIGJ5IHRoaXMgaWV0Zi4NCjxkaXYgY2xhc3M9InF1b3RlIiBz dHlsZT0ibGluZS1oZWlnaHQ6IDEuNSI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tLTxicj4NClN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIEZ3OiBJUHYxMCwgS1JQ IChSUlApIElEcy48YnI+DQpGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAu c2U+PGJyPg0KVG86IEtoYWxlZCBPbWFyIDxlbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb20+PGJy Pg0KQ0M6IDxicj4NCjxicj4NCjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBj bGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCk9uIE1vbiwgNSBKdW4gMjAxNywgS2hhbGVkIE9t YXIgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBUaGVzZSBhcmUgbXkgZHJhZnRzIGFzIGknbSB0aGUg b25seSBhdXRob3IsIEkgaGF2ZSB0aGUgcmlnaHQgdG8gYXNrIGZvciA8YnI+DQomZ3Q7IHVwbG9h ZGluZyBhbmQgcmVtb3ZhbCwgd2hhdCBpcyBkaWZmaWN1bHQgaW4gdGhpcyB0b28hISE8YnI+DQo8 YnI+DQpZb3UgbmVlZCB0byByZS1yZWFkIHRoZSBub3RlIHdlbGwsIGJlY2F1c2Ugd2hhdCB5b3Un cmUgc2F5aW5nIGlzIG5vdCA8YnI+DQphY2N1cmF0ZS48YnI+DQo8YnI+DQpEcmFmdHMgYXJlIG5v dCByZW1vdmVkLiBBcyBzb29uIGFzIHlvdSB1cGxvYWRlZCB0aGVtIHlvdSBoYXZlIGNvbnRyaWJ1 dGVkIDxicj4NCnRoZW0uPGJyPg0KPGJyPg0KUmVhZCB0aGUgbm90ZSB3ZWxsLjxicj4NCjxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2Fib3V0L25vdGUtd2VsbC5odG1sPGJyPg0KPGJyPg0KJnF1 b3Q7QW55IHN1Ym1pc3Npb24gdG8gdGhlIElFVEYgaW50ZW5kZWQgYnkgdGhlIENvbnRyaWJ1dG9y IGZvciBwdWJsaWNhdGlvbiBhcyA8YnI+DQphbGwgb3IgcGFydCBvZiBhbiBJRVRGIEludGVybmV0 LURyYWZ0IG9yIFJGQyBhbmQgYW55IHN0YXRlbWVudCBtYWRlIHdpdGhpbiA8YnI+DQp0aGUgY29u dGV4dCBvZiBhbiBJRVRGIGFjdGl2aXR5IGlzIGNvbnNpZGVyZWQgYW4gJnF1b3Q7SUVURiBDb250 cmlidXRpb24mcXVvdDsuJnF1b3Q7PGJyPg0KPGJyPg0KJnF1b3Q7QWxsIElFVEYgQ29udHJpYnV0 aW9ucyBhcmUgc3ViamVjdCB0byB0aGUgcnVsZXMgb2YgUkZDIDUzNzggYW5kIFJGQyAzOTc5IDxi cj4NCih1cGRhdGVkIGJ5IFJGQyA0ODc5KS4mcXVvdDs8YnI+DQo8YnI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTM3ODxicj4NCjxicj4NCiZxdW90OzMuMS4gUmlnaHRzIEdyYW50 ZWQgaW4gQ29udHJpYnV0aW9uczxicj4NCjxicj4NClRoZSBJRVRGIFRydXN0IGFuZCB0aGUgSUVU RiBtdXN0IG9idGFpbiB0aGUgcmlnaHQgdG8gcHVibGlzaCBhbiBJRVRGPGJyPg0KQ29udHJpYnV0 aW9uIGFzIGFuIFJGQyBvciBhbiBJbnRlcm5ldC1EcmFmdCBmcm9tIHRoZSBDb250cmlidXRvcnMu PGJyPg0KPGJyPg0KQSBwcmltYXJ5IG9iamVjdGl2ZSBvZiB0aGlzIHBvbGljeSBpcyB0byBvYnRh aW4gZnJvbSB0aGUgZG9jdW1lbnQ8YnI+DQphdXRob3JzIG9ubHkgdGhlIG5vbi1leGNsdXNpdmUg cmlnaHRzIHRoYXQgYXJlIG5lZWRlZCB0byBkZXZlbG9wIGFuZDxicj4NCnB1Ymxpc2ggSUVURiBE b2N1bWVudHMgYW5kIHRvIHVzZSBJRVRGIENvbnRyaWJ1dGlvbnMgaW4gdGhlIElFVEY8YnI+DQpT dGFuZGFyZHMgUHJvY2VzcyBhbmQgcG90ZW50aWFsbHkgZWxzZXdoZXJlLjxicj4NCjxicj4NClRo ZSBhdXRob3JzIHJldGFpbiBhbGwgb3RoZXIgcmlnaHRzLCBidXQgY2Fubm90IHdpdGhkcmF3IHRo ZSBhYm92ZTxicj4NCnJpZ2h0cyBmcm9tIHRoZSBJRVRGIFRydXN0IGFuZCB0aGUgSUVURi48YnI+ DQomcXVvdDs8YnI+DQo8YnI+DQpCeSB1cGxvYWRpbmcgdGhlIGRyYWZ0cywgeW91IGdhdmUgdGhl IElFVEYgcmlnaHQgdG8ga2VlcCB0aGVzZSBkcmFmdHMgPGJyPg0KZm9yZXZlci48YnI+DQo8YnI+ DQotLSA8YnI+DQpNaWthZWwgQWJyYWhhbXNzb24gZW1haWw6IHN3bWlrZUBzd20ucHAuc2U8YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM4PR0401MB2241EAA00D863A8494037113BDCA0AM4PR0401MB2241_-- From nobody Mon Jun 5 11:30:23 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC47129BAE; Mon, 5 Jun 2017 11:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v_eCNAe6hAk; Mon, 5 Jun 2017 11:30:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 B7117129BAC; Mon, 5 Jun 2017 11:30:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 08796A3; Mon, 5 Jun 2017 20:30:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1496687414; bh=RdV7yRV1d7ACNEBMESntiBCbiJ356Gt21vRw12k/99A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=T4PQa0BiXaLbN4enHQ0aHKH9wYeMZfMMLVTBBZNmsGEpBODyKVAtzrsJBAsOgToli 9O3T22rR9TVcnbmE+tUT5Gn4z5NSa7FOQ2d4Rk7gV2uc9EuuJLoZdjJc0NUfjwSJ3l 6uEdVQ1hYgUvc0V9/FsSgwbS5zGWgamxBkPoqNpk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA09FA1; Mon, 5 Jun 2017 20:30:13 +0200 (CEST) Date: Mon, 5 Jun 2017 20:30:13 +0200 (CEST) From: Mikael Abrahamsson To: Khaled Omar cc: int-area , intarea-ads , intarea-chairs In-Reply-To: Message-ID: References: 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: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:30:22 -0000 On Mon, 5 Jun 2017, Khaled Omar wrote: > No one can force an internet draft to not be removed if the only author > asked for that, saying keeping them forever means you have conflicts > inside urself, and don't know what to do, so I'm telling u now what to > do, REMOVE these IDs and no more representation by this ietf. So you took my private email I sent directly to you, and sent it to the IETF without my permission, and you're now claiming rights to have things removed? What about my rights to not have my text sent to the IETF without my permission? You're a very confused person. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Jun 5 11:40:53 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7554129BBE; Mon, 5 Jun 2017 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYL14JZlazJJ; Mon, 5 Jun 2017 11:40:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064057.outbound.protection.outlook.com [40.92.64.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6672126DEE; Mon, 5 Jun 2017 11:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RNsKe0omQzz82wvGMvrIqI3xi7pN8L3Hx8wUJ5PD4W8=; b=UPSB1DOAOTZaC7FaVIrFnK1EqcU3bU6ejUXOIUXaKjoeYRTJwrP2LrQbSJstNlIDzmoV3DA6odORXsm5GfCapHmMeOkB42czVuJqT+V11jxPj1Oeb4j0Os+vG2sTxWJvUQfGsnwRyZE+UIsMS0uq04GSRnLSyP6DhYX+lxHw5L8flSRB7MKXsmHBJ0LZvHUjh0nJYhh4CzIoy65UpsG5bGItxV19uQdLpMxLfk1hBStQow5iILt+D3SGUGAFAh9zMj0cvw4BpOMFfnvZHUhSxAm6bchE5AK8uHWq2EMEtI79R2NVX5/hF8suZ/Ps6WQbWMZcAqpkLgT3cPFe2/ybwA== Received: from DB5EUR01FT041.eop-EUR01.prod.protection.outlook.com (10.152.4.54) by DB5EUR01HT109.eop-EUR01.prod.protection.outlook.com (10.152.5.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Mon, 5 Jun 2017 18:40:48 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.4.53) by DB5EUR01FT041.mail.protection.outlook.com (10.152.5.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Mon, 5 Jun 2017 18:40:47 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377%18]) with mapi id 15.01.1143.016; Mon, 5 Jun 2017 18:40:47 +0000 From: Khaled Omar To: Mikael Abrahamsson CC: int-area , intarea-ads , intarea-chairs , "iesg@ietf.org" Thread-Topic: [Int-area] Fw: IPv10, KRP (RRP) IDs. Thread-Index: AQHS3g3hXZ1j/a6PxE+a/2tbNdv+ZqIWl26AgAACKuA= Date: Mon, 5 Jun 2017 18:40:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: swm.pp.se; dkim=none (message not signed) header.d=none;swm.pp.se; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:A2379967A7BADE8D535AF39BAFE9F6F0AE874F7114F29265E863797E5AB305EF; UpperCasedChecksum:838BFD01AA5C6BAECE1526FEED097F73CDBCB585A1FAC3FD078EFDB1E66E3013; SizeAsReceived:8494; Count:45 x-tmn: [KLX0hkYZNcCpZ2MOYIKxNSy28spIvO9z] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5EUR01HT109; 24:thhOnGs05ACkfJLeHfZu9ilEoJbfrT6a5s+xyq0XFcIuQn++wBitD4ePHRWQA6d5yWJl2f0S/QozH9YWJVvP9UgGB69nKjnGLCy6CJIMNYU=; 7:PZBoMHoGJ7s3Bn9mPrY6VfI6Rn9cZ+XbfDsnw3gjwwHWyJtOlZJZ2xnYGZcRTz83LzpJJ7fgjyZ7HEpiFPtvbRHgc2yzL0iK6p5wUT686yXg7QLJvDMcs/rQG6yZGJ1d58ATK4aU5fvXoyGNE1sEpCHLMcqkHrQJGZ17fXqIzzgkQ26352QqIJbpRn0e9ekv9Jr42n3qCGXW86D3+zsJBhRTLoMKRu3dlhBPFW3Jfn6ZFtID7SdySK9pli9HicxAINy+QlJMAwWtQW13SJsoQj4o2BxuRh0Qm/jNLfy+uoO473NB7BJPzRZwZhlpAMdR x-incomingheadercount: 45 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR01HT109; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-traffictypediagnostic: DB5EUR01HT109: x-ms-office365-filtering-correlation-id: 39ffbd0c-8f2a-4d2b-1633-08d4ac426200 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:DB5EUR01HT109; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:DB5EUR01HT109; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5EUR01HT109; x-forefront-prvs: 0329B15C8A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 18:40:47.7163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT109 Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:40:52 -0000 Don't reply using your own rules with the tongue of the ietf again. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Monday, June 5, 2017 8:30 PM To: Khaled Omar Cc: int-area; intarea-ads; intarea-chairs Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. On Mon, 5 Jun 2017, Khaled Omar wrote: > No one can force an internet draft to not be removed if the only=20 > author asked for that, saying keeping them forever means you have=20 > conflicts inside urself, and don't know what to do, so I'm telling u=20 > now what to do, REMOVE these IDs and no more representation by this ietf. So you took my private email I sent directly to you, and sent it to the IET= F without my permission, and you're now claiming rights to have things remo= ved? What about my rights to not have my text sent to the IETF without my p= ermission? You're a very confused person. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Jun 5 13:15:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259C1270A7; Mon, 5 Jun 2017 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM6nk18rKIHq; Mon, 5 Jun 2017 13:15:28 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 A9DFC126CE8; Mon, 5 Jun 2017 13:15:28 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id w69so21837343pfk.1; Mon, 05 Jun 2017 13:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pxD6wj1kILUOh2I3zxKnq20p+jjM8ELpRO3S0AmCAZ8=; b=j7qdU7VyKPoszAvccowh54PMNA9GHZPhWWT4OSblWTGriJmuPTaU5qrHgo9BXC0f/1 iWM/lGLO9ciJJgEU5QA+MLeUu8kWvD96EmAmSshcsbWYsU0Wy3RNP184rM3kAaFsvBEY ssC+aeGN4nN3Gja4Kv/9YyTg7HqsK0EKT8Vhg2/k078V+OJ1URWWAe3WRsc3TVmtw/Rc N2Sl6nqIntaAVda7RryEXqqjnpxkaKGPlLDOACUiPk5AK8zR5W+zakEkYwtOxDH96aRM 7ipdH/0/QhoIG9fqep4kRnKT/8XG+EHceqfb+QhZaeeBbhruZR0XTvBx63D9QQKx1IVI bHQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=pxD6wj1kILUOh2I3zxKnq20p+jjM8ELpRO3S0AmCAZ8=; b=UxA2phmG/19k9pl+9oZ37JkW7lXTJ+26ZzslFFIE+6DNhQKTK1JwX6BwjKaefgQTNA e6qsL1v4Mq5LAfVgLWGIPGuvJfJlpqfrdj4rJ51HHlzAMFubEQmyF4nYaJU4U5UUQf7X dIDIQrW2QF2l21cFTvgfe1q2O5x2EY+P9K7rlc8PP1b6sziNt7CbsuaEZGYtxEvGHmH9 F1uazlZ3IhT+xGevTjk4Dgroii9pvrHrC0VnKvCyJ2UF/CaGUyJh+KdrYDHvVLSyUwJv OMnYnmI633xlyDd7OsCTqgSsEYcWM75zS0r4j0oeOdiFPA17zTEyy5Dhk8BmAfFuDalG GZEA== X-Gm-Message-State: AODbwcCCOELsAjbeACL5tq8UnQnXtXodWAIfgBuS1w7wVEQN5Kmfi/hb bDwApGnZXnjYMH4N78k= X-Received: by 10.99.100.65 with SMTP id y62mr22538898pgb.217.1496693727994; Mon, 05 Jun 2017 13:15:27 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v9sm22090592pgb.25.2017.06.05.13.15.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 13:15:27 -0700 (PDT) To: Khaled Omar Cc: chair , int-area References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <0bf5b439-603a-2a7e-a927-7adca113923e@gmail.com> Date: Tue, 6 Jun 2017 08:15:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:15:30 -0000 Khaled, On 06/06/2017 04:51, Khaled Omar wrote: > I replied to this e-mail long time ago. > > These are my drafts as i'm the only author, I have the right to ask for uploading and removal, what is difficult in this too!!! You have the right to ask for anything you want, but you gave the IETF permission to publish the drafts and use the material as it wishes, by submitting the drafts under the IETF conditions, as indicated in the drafts themselves ("This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79" etc.). So the IETF is fully entitled to say no to your request. I pointed out to you at a very early stage that your proposal suffers from exactly the same problem as my own proposal in 1994, namely that an untouched IPv4-only host can never communicate directly with an extended address host. I'm not ashamed of that work, but it was useless. Unfortunately the IETF archive doesn't go back that far, but I'm quite happy that it's still visible at https://www.cs.auckland.ac.nz/~brian/draft-carpenter-aeiou-00.txt We all live and learn. Please do follow the IETF discussions and participate in future. Regards Brian From nobody Mon Jun 5 13:59:46 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34B212EB0C; Mon, 5 Jun 2017 13:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGmEr-x4rNTf; Mon, 5 Jun 2017 13:59:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064073.outbound.protection.outlook.com [40.92.64.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1F312EB17; Mon, 5 Jun 2017 13:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ILALraCDfE+oWMqYyIkd3cuoRbfG3i7cXHqf3icEJg8=; b=fPefD8Kr4ckr54vvxFoZEbj7iI58KUHmxQ7T52N2Y5aRuUKH3FKQzyg6sFfTMG7r/V9zhn3jD43e1qy0JzsCrQVDJOS/l1tJHlNAo5qCw/qzIM3m38P3TuNOIjDM298TpVyf/M3GYmOozlA5TA0hjkJNmrRXT4JpeBcNf/I8Rlu7ES2m6VAAxt5A1zmW1QC/bK2FlK/Jribnse+naqMQBAmlegdMM9PCsfe+FUI0QPGHhd6554TeSBtwt7QAPUeoIBDXH7L/V9xPBz2FLikWQx++nRLOhAdh5P7VG4eW0+FSvugetbrqo6k9IrLJcD4j2Grlkt3exKLFQQ3G3X680A== Received: from HE1EUR01FT039.eop-EUR01.prod.protection.outlook.com (10.152.0.60) by HE1EUR01HT215.eop-EUR01.prod.protection.outlook.com (10.152.1.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Mon, 5 Jun 2017 20:59:36 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.0.58) by HE1EUR01FT039.mail.protection.outlook.com (10.152.0.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Mon, 5 Jun 2017 20:59:36 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::65e0:8c3c:d7ed:2377%18]) with mapi id 15.01.1143.016; Mon, 5 Jun 2017 20:59:36 +0000 From: Khaled Omar To: Brian E Carpenter CC: chair , int-area , "iesg@ietf.org" Thread-Topic: [Int-area] Fw: IPv10, KRP (RRP) IDs. Thread-Index: AQHS3g3hXZ1j/a6PxE+a/2tbNdv+ZqIWtNEAgAALhhA= Date: Mon, 5 Jun 2017 20:59:36 +0000 Message-ID: References: <0bf5b439-603a-2a7e-a927-7adca113923e@gmail.com> In-Reply-To: <0bf5b439-603a-2a7e-a927-7adca113923e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:89ACC2B63554403E2E399D0A44D0E3CE86EF5E0572BD003BDDB7266907D71D99; UpperCasedChecksum:D1649942F94B15673AF00AFE131953FEB2D9EB34B87DB56999923684DD2C8FFD; SizeAsReceived:8451; Count:45 x-tmn: [cbPfR0Q67fwgEmCARGiRcaMUHSUEy+L/] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT215; 24:+e9hMZLYMZfpj27bK6MuUitN7GPc9phou1UiujGjDxn1JnGtbViY7Mb/+qFmJqnfMm0m0xdis4SsSZYCJQsmB1N1h3+f2Gfj3yculmFxiDA=; 7:LzJXb8sLwVg3awMnidjjQdOmr47kd36h1dUyio9yP1614Vji6B2XaOz3SqZEYhimNNIGCXGE1fm4gwOb8GEKRzW+oJKZWlfSxv8UomM+sKYyjfbyAuYKhCn39kA37giym3f8e0VXnS6nDVFXSQBYPta0eATKMn6dCYjSlKtrIwJlHs5wSVGkX6w6Eebhgv9tSV9FFgpPv9ne6HqHqUPe+NexT2oFoS7wpzQXAnq+ttsLmTKHOp4CgNu7PKlGgpxNOwH1Wx+Fa4MqyDmFMGVxjl7bnN2uih7XL6oxS0qWL/iY0PzW6ZBL6ddgmGKRJgUc x-incomingheadercount: 45 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT215; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-traffictypediagnostic: HE1EUR01HT215: x-ms-office365-filtering-correlation-id: 860ab132-4076-4621-b449-08d4ac55c623 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR01HT215; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HE1EUR01HT215; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1EUR01HT215; x-forefront-prvs: 0329B15C8A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 20:59:36.1347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT215 Archived-At: Subject: Re: [Int-area] Fw: IPv10, KRP (RRP) IDs. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:59:45 -0000 R3JlYXQsIG5vdyB0aGUgaWV0ZiBkb24ndCBuZWVkIHRoZSBJUHYxMCBJLUQgYmVjYXVzZSBvZiB3 aGF0IHlvdSBoYXZlIHNhaWQsIHRoZXJlIGlzIG5vIG5lZWQgdG8ga2VlcCB1cGxvYWRpbmcgYSBk cmFmdCB0aGF0IHdpbGwgbm90IGJlIHVzZWQgYW5kIGlzIHVzZWxlc3MgZXRjLg0KDQpMZXQgbWUg YXNrIGFnYWluIGZvciByZW1vdmluZyBJUHYxMCBJLUQgYW5kIEkgd2lsbCB0cnkgdG8gcGFydGlj aXBhdGUgaW4gb3RoZXIgc29sdXRpb25zIGZvciB0aGlzIHByb2JsZW0gaWYgeW91IHRoaW5rIHRo ZXJlIGlzIGV2ZW4gYSBwcm9ibGVtLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bV0gDQpTZW50OiBNb25kYXksIEp1bmUgNSwgMjAxNyAxMDoxNSBQTQ0KVG86IEtoYWxlZCBPbWFy DQpDYzogY2hhaXI7IGludC1hcmVhDQpTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBGdzogSVB2MTAs IEtSUCAoUlJQKSBJRHMuDQoNCktoYWxlZCwNCg0KT24gMDYvMDYvMjAxNyAwNDo1MSwgS2hhbGVk IE9tYXIgd3JvdGU6DQo+IEkgcmVwbGllZCB0byB0aGlzIGUtbWFpbCBsb25nIHRpbWUgYWdvLg0K PiANCj4gVGhlc2UgYXJlIG15IGRyYWZ0cyBhcyBpJ20gdGhlIG9ubHkgYXV0aG9yLCBJIGhhdmUg dGhlIHJpZ2h0IHRvIGFzayBmb3IgdXBsb2FkaW5nIGFuZCByZW1vdmFsLCB3aGF0IGlzIGRpZmZp Y3VsdCBpbiB0aGlzIHRvbyEhIQ0KDQpZb3UgaGF2ZSB0aGUgcmlnaHQgdG8gYXNrIGZvciBhbnl0 aGluZyB5b3Ugd2FudCwgYnV0IHlvdSBnYXZlIHRoZSBJRVRGIHBlcm1pc3Npb24gdG8gcHVibGlz aCB0aGUgZHJhZnRzIGFuZCB1c2UgdGhlIG1hdGVyaWFsIGFzIGl0IHdpc2hlcywgYnkgc3VibWl0 dGluZyB0aGUgZHJhZnRzIHVuZGVyIHRoZSBJRVRGIGNvbmRpdGlvbnMsIGFzIGluZGljYXRlZCBp biB0aGUgZHJhZnRzIHRoZW1zZWx2ZXMgKCJUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBC Q1AgNzkiIGV0Yy4pLiBTbyB0aGUgSUVURiBpcyBmdWxseSBlbnRpdGxlZCB0byBzYXkgbm8gdG8g eW91ciByZXF1ZXN0Lg0KDQpJIHBvaW50ZWQgb3V0IHRvIHlvdSBhdCBhIHZlcnkgZWFybHkgc3Rh Z2UgdGhhdCB5b3VyIHByb3Bvc2FsIHN1ZmZlcnMgZnJvbSBleGFjdGx5IHRoZSBzYW1lIHByb2Js ZW0gYXMgbXkgb3duIHByb3Bvc2FsIGluIDE5OTQsIG5hbWVseSB0aGF0IGFuIHVudG91Y2hlZCBJ UHY0LW9ubHkgaG9zdCBjYW4gbmV2ZXIgY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBhbiBleHRl bmRlZCBhZGRyZXNzIGhvc3QuIEknbSBub3QgYXNoYW1lZCBvZiB0aGF0IHdvcmssIGJ1dCBpdCB3 YXMgdXNlbGVzcy4NClVuZm9ydHVuYXRlbHkgdGhlIElFVEYgYXJjaGl2ZSBkb2Vzbid0IGdvIGJh Y2sgdGhhdCBmYXIsIGJ1dCBJJ20gcXVpdGUgaGFwcHkgdGhhdCBpdCdzIHN0aWxsIHZpc2libGUg YXQgaHR0cHM6Ly93d3cuY3MuYXVja2xhbmQuYWMubnovfmJyaWFuL2RyYWZ0LWNhcnBlbnRlci1h ZWlvdS0wMC50eHQNCg0KV2UgYWxsIGxpdmUgYW5kIGxlYXJuLiBQbGVhc2UgZG8gZm9sbG93IHRo ZSBJRVRGIGRpc2N1c3Npb25zIGFuZCBwYXJ0aWNpcGF0ZSBpbiBmdXR1cmUuDQoNClJlZ2FyZHMN CiAgIEJyaWFuDQo= From nobody Thu Jun 8 18:04:35 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D85C12EB0D; Thu, 8 Jun 2017 18:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149697027314.2998.4542540666333234346@ietfa.amsl.com> Date: Thu, 08 Jun 2017 18:04:33 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-tunnels-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:04:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : IP Tunnels in the Internet Architecture Authors : Joe Touch Mark Townsley Filename : draft-ietf-intarea-tunnels-07.txt Pages : 52 Date : 2017-06-08 Abstract: This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-tunnels-07 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-07 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 Jun 8 18:12:44 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A8B126557; Thu, 8 Jun 2017 18:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G1f5pFoT9xCb; Thu, 8 Jun 2017 18:12:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 8CEF112EB19; Thu, 8 Jun 2017 18:12:40 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v591C6sE003042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Jun 2017 18:12:16 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: int-area@ietf.org References: <149697027314.2998.4542540666333234346@ietfa.amsl.com> From: Joe Touch Message-ID: <541d33fc-0ad5-fc1b-eb45-0cfa005b8f6d@isi.edu> Date: Thu, 8 Jun 2017 18:12:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149697027314.2998.4542540666333234346@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:12:43 -0000 Hi, all, This is a quick update to reflect the change in intended document status. Section 5 is now under active development, and will be posted when ready for feedback. Joe On 6/8/2017 6:04 PM, 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 Internet Area Working Group of the IETF. > > Title : IP Tunnels in the Internet Architecture > Authors : Joe Touch > Mark Townsley > Filename : draft-ietf-intarea-tunnels-07.txt > Pages : 52 > Date : 2017-06-08 > > Abstract: > This document discusses the role of IP tunnels in the Internet > architecture. An IP tunnel transits IP datagrams as payloads in non- > link layer protocols. This document explains the relationship of IP > tunnels to existing protocol layers and the challenges in supporting > IP tunneling, based on the equivalence of tunnels to links. The > implications of this document are used to derive recommendations that > update MTU and fragment issues in RFC 4459. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-07 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-07 > > > 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/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 16 08:28:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD827126E01 for ; Fri, 16 Jun 2017 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpvpUwdietqY for ; Fri, 16 Jun 2017 08:28:28 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C4A611201F8 for ; Fri, 16 Jun 2017 08:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:To:References:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wSq1ANu8zTVTC5gANe/NkJsrAbx8NRQU/cnId1SCo9s=; b=n5Ou9AW7/D/vpjAut4bNB7TOF OjdM79BujOVDPY1T7KFgZ3y0ON94c3DSqF2+7GtvDAtA9tLYdoHrFWPK6KJNrZA1exziAL0SasR5G eydO93MzcAFAmSczM4uKvn9EHQd5qnKS1Kri0YTe1NLrXjYfJL5LKSdVGP3bIGYOrIOrkw6HqfwZx t3QlCJLL2DSZMGaEG2wI2tGSyfgzhvZ9XiC5PITP/+eMbWYAjfCWtzQg4bKlIOlMQ3/VDGbzYzpD8 TPpMYlPu+9zwBK78WXlNYOohSEi9jJWLHfLnRu8ZwlBvWINlYNSAuziV09T8YRo2hVdf9eY3bQpXv Fd8bqUMng==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:57832 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dLtAf-0005Lf-EK; Fri, 16 Jun 2017 16:28:25 +0100 References: To: intarea IETF list , intarea-chairs@tools.ietf.org From: Bob Briscoe X-Forwarded-Message-Id: Message-ID: <849a54e4-894d-2709-31a1-03521187724a@bobbriscoe.net> Date: Fri, 16 Jun 2017 16:28:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6A8598B895095012921B5D2C" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [Int-area] Propagating ECN Across IP-shim-(L2)-IP: draft-ietf-tsvwg-rfc6040update-shim-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 15:28:31 -0000 This is a multi-part message in MIME format. --------------6A8598B895095012921B5D2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wasim, Juan-Carlos, int-area list, I have posted a major rev of draft-ietf-tsvwg-rfc6040update-shim-02 It now gives specific text updating those tunnel protocols that didn't mention ECN processing. Pls review/comment. I am not on the int-area list, so pls include my email explicitly. It includes an update to GRE specifying a safe config for legacy GRE tunnel endpoints, and also specifies how GRE can be updated to support ECN. It also updates L2TP v2 & v3, and it is planned to update Teredo, once I hear from Christian Huitema It includes a list of other tunnel protocols in scope, which I believe is now complete (famous last words!) It is planned to WGLC in tsvwg by Sep 2017. Pls tell the doc Shepherd (David Black, in cc) if you want it WGLC'd in int-area too. If you want me to present a heads-up in int-area in Prague, also pls just say. I have sent similar notifications to relevant authors and: * NVO3 regarding implications for VXLAN-GPE * opsawg regarding implications for CAPWAP * l2tpext regarding implications for L2TP * tsvwg, which is the home for ECN activity Cheers Bob -------- Forwarded Message -------- Subject: New Version draft-ietf-tsvwg-rfc6040update-shim-02 Date: Fri, 16 Jun 2017 15:47:58 +0100 From: Bob Briscoe To: Black, David CC: tsvwg IETF list David, as doc shepherd. I have just posted a major revision to draft-ietf-tsvwg-rfc6040update-shim Please also take this as a request to give a 10min presentation in tsvwg. As requested, I included specific text necessary to update certain shim tunnel protocols that didn't mention ECN at all (L2TPv2, L2TPv3, GRE). There are two others to do: * Teredo: I'll do this once I hear from the original author, Christian Huitema * VXLAN-GPE: This is a draft currently going through NVO3 on the standards track. AFAIK the Linux implementation already supports ECN via RFC6040, but the authors will need to add ECN text to the spec, so there is something for other implementations to follow. I have contacted them - they should do this, not me. I have also added more protocols to the list (e.g. CAPWAP, LISP), but these already supported ECN. As you have seen, I have been in conversation with people on the l2tpext list, and on opsawg (for CAPWAP). I haven't found anyone specific to talk to regarding GRE yet, but I have notified int-area and I gave a heads-up at a recent IETF. BTW, your plan was to last call draft-ietf-tsvwg-rfc6040update-shim along with ecn-encap-guidelines, deadline Sep 2017. I should point out that draft-ietf-trill-ecn-support is in WGLC in trill, and it depends normatively on ecn-encap-guidelines opsawg would like to last call draft-ietf-tsvwg-rfc6040update-shim as well (altho I have now realized that no update to CAPWAP is needed, but opsawg is now working on alternative tunnelling protocols to CAPWAP: draft-ietf-opsawg-capwap-alt-tunnel ). I guess int-area might want to last call draft-ietf-tsvwg-rfc6040update-shim too. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-02.txt Date: Fri, 16 Jun 2017 07:14:46 -0700 From: internet-drafts@ietf.org To: Bob Briscoe A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-02.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-ietf-tsvwg-rfc6040update-shim Revision: 02 Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Document date: 2017-06-16 Group: tsvwg Pages: 15 URL:https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-02.txt Status:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Htmlized:https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-02 Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-02 Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-02 Abstract: RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification extends the scope of RFC 6040 to include tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for packet forwarding. It surveys widely deployed IP tunnelling protocols separated by a shim and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). The specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. 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 --------------6A8598B895095012921B5D2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Wasim, Juan-Carlos, int-area list,

I have posted a major rev of draft-ietf-tsvwg-rfc6040update-shim-02
It now gives specific text updating those tunnel protocols that didn't mention ECN processing.
Pls review/comment.
I am not on the int-area list, so pls include my email explicitly.

It includes an update to GRE specifying a safe config for legacy GRE tunnel endpoints, and also specifies how GRE can be updated to support ECN.
It also updates L2TP v2 & v3, and it is planned to update Teredo, once I hear from Christian Huitema

It includes a list of other tunnel protocols in scope, which I believe is now complete (famous last words!)


It is planned to WGLC in tsvwg by Sep 2017.
Pls tell the doc Shepherd (David Black, in cc) if you want it WGLC'd in int-area too.
If you want me to present a heads-up in int-area in Prague, also pls just say.

I have sent similar notifications to relevant authors and:
* NVO3 regarding implications for VXLAN-GPE
* opsawg regarding implications for CAPWAP
* l2tpext regarding implications for L2TP
* tsvwg, which is the home for ECN activity

Cheers


Bob


-------- Forwarded Message --------
Subject: New Version draft-ietf-tsvwg-rfc6040update-shim-02
Date: Fri, 16 Jun 2017 15:47:58 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Black, David <david.black@emc.com>
CC: tsvwg IETF list <tsvwg@ietf.org>


David, as doc shepherd.

I have just posted a major revision to draft-ietf-tsvwg-rfc6040update-shim

Please also take this as a request to give a 10min presentation in tsvwg.

As requested, I included specific text necessary to update certain shim tunnel protocols that didn't mention ECN at all (L2TPv2, L2TPv3, GRE).
There are two others to do:
* Teredo: I'll do this once I hear from the original author, Christian Huitema
* VXLAN-GPE: This is a draft currently going through NVO3 on the standards track. AFAIK the Linux implementation already supports ECN via RFC6040, but the authors will need to add ECN text to the spec, so there is something for other implementations to follow. I have contacted them - they should do this, not me.

I have also added more protocols to the list (e.g. CAPWAP, LISP), but these already supported ECN.

As you have seen, I have been in conversation with people on the l2tpext list, and on opsawg (for CAPWAP). I haven't found anyone specific to talk to regarding GRE yet, but I have notified int-area and I gave a heads-up at a recent IETF.


BTW, your plan was to last call draft-ietf-tsvwg-rfc6040update-shim along with ecn-encap-guidelines, deadline Sep 2017.
I should point out that draft-ietf-trill-ecn-support is in WGLC in trill, and it depends normatively on ecn-encap-guidelines

opsawg would like to last call draft-ietf-tsvwg-rfc6040update-shim as well (altho I have now realized that no update to CAPWAP is needed, but opsawg is now working on alternative tunnelling protocols to CAPWAP: draft-ietf-opsawg-capwap-alt-tunnel ). I guess int-area might want to last call draft-ietf-tsvwg-rfc6040update-shim too.



Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-02.txt
Date: Fri, 16 Jun 2017 07:14:46 -0700
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net> 


A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-02.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-ietf-tsvwg-rfc6040update-shim
Revision:	02
Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
Document date:	2017-06-16
Group:		tsvwg
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-02

Abstract:
   RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
   rules for propagation of ECN consistent for all forms of IP in IP
   tunnel.  This specification extends the scope of RFC 6040 to include
   tunnels where two IP headers are separated by at least one shim
   header that is not sufficient on its own for packet forwarding.  It
   surveys widely deployed IP tunnelling protocols separated by a shim
   and updates the specifications of those that do not mention ECN
   propagation (L2TPv2, L2TPv3, GRE and Teredo).  The specification also
   updates RFC 6040 with configuration requirements needed to make any
   legacy tunnel ingress safe.

                                                                                  


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
--------------6A8598B895095012921B5D2C-- From nobody Thu Jun 22 10:45:00 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F796129B18 for ; Thu, 22 Jun 2017 10:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1Ymzz8hOKHE3 for ; Thu, 22 Jun 2017 10:44:56 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2D6128CFF for ; Thu, 22 Jun 2017 10:44:56 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3A2LAe1BJ1H1FI3vtHidmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgRKf3xwZ3uMQTl6Ol3ixeRBMOAuq0C07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9ZDeZwdFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhi?= =?us-ascii?q?kHOTAn82/Zl8N/g75Urhymuxxy2JLUYJiJO/ZiZK7RYdEXSGxcVchRTSxBBYa8?= =?us-ascii?q?YpMBAeobJ+lYoI79pVsTphWmBAmjGP7vyjtWiX/twaI6zvkqHAbb0ww6Bd0Ov3?= =?us-ascii?q?PUrM7vOKcUUOC60LTIzTHdYPNNxTj99ZPFfQw6of2WRbJwbNHexVM1FwPCl1id?= =?us-ascii?q?r5HuMTCN1ukVrmSW4PdsWfishmMnsQ19vCajy8U2hoTHgI8e10rK+j9jwIkvIN?= =?us-ascii?q?21UEt7Ydm5H5ROryyaLI52Qt86Q2FvpSY61qUKuZ6lcygOz5Qq3wDfa/mdfIiJ?= =?us-ascii?q?5hLvTvqeISxiiHJ9ZbKwnAy+8VKnyuHkV8m01khFrjZdn9XRuX0Bygbf58uHR/?= =?us-ascii?q?dn4EutxzSC2xrd5+1cJEA7j6vbK5ovwr4qkZoTtFzOETLsmErsg6+WcV4k9vKu?= =?us-ascii?q?6+Tmfrrmu5ucOJFvig7iL6QjgdCwAf8iPggWQmiU4v6w1Kfk/UHhWrVFkuU2kr?= =?us-ascii?q?XFsJDdPckbp6i5AxNM3ok58RawES2p3c8ZnXYZMFJFdgiLj4/zO1HBc7jECqK+?= =?us-ascii?q?hUjpmS1mztjHM6HvRJLXISvtirDkKJpn4kFbKkIVzNtC459PAaxJdP7pU0D2r5?= =?us-ascii?q?reDxQkNwGvyPvPA847zp4UH3iIVPzKeJjOuEOFs7p8a9KHY5UY7W7w?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BpHADnAExZ/wPjVY1dHgYMGQYMgwCGC?= =?us-ascii?q?IsMkEuYK4Ykg1sBAQEBAQEBAQIBaihCAQEDCQKBYSKCbWgBIgINGQJbikesH4I?= =?us-ascii?q?mjB2BC4IchWKHQmKCR4JhBZFGAY0cpXGVFAJXgQpRhT4BAQgBAQEBAYJGgm2DY?= =?us-ascii?q?4QAAQEB?= X-IPAS-Result: =?us-ascii?q?A2BpHADnAExZ/wPjVY1dHgYMGQYMgwCGCIsMkEuYK4Ykg1s?= =?us-ascii?q?BAQEBAQEBAQIBaihCAQEDCQKBYSKCbWgBIgINGQJbikesH4ImjB2BC4IchWKHQ?= =?us-ascii?q?mKCR4JhBZFGAY0cpXGVFAJXgQpRhT4BAQgBAQEBAYJGgm2DY4QAAQEB?= X-IronPort-AV: E=Sophos;i="5.39,373,1493672400"; d="scan'208";a="847488" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 22 Jun 2017 20:44:54 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 6FE901A60198 for ; Thu, 22 Jun 2017 20:44:54 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZZ6w99H3y1t2 for ; Thu, 22 Jun 2017 20:44:54 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 520031A60199 for ; Thu, 22 Jun 2017 20:44:54 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id 4A3BE1A60198 for ; Thu, 22 Jun 2017 20:44:54 +0300 (EEST) Date: Thu, 22 Jun 2017 20:44:54 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: int-area@ietf.org Message-ID: <2089397462.3653731.1498153494229.JavaMail.zimbra@cs.pub.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC55 (Linux)/8.6.0_GA_1194) Thread-Topic: SOCKSv6 Thread-Index: T3/FxpxdlJKQ+9RkzKYjjy5G8RNaqg== Archived-At: Subject: [Int-area] SOCKSv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:44:59 -0000 Hello,=20 At University Politehnica of Bucharest we have a project building a TCP pro= xy protocol that is meant as an upgrade to SOCKS to leverage some benefits = at the transport layer that came after SOCKSv5 such as TCP fastopen, and mu= ltipath TCP. The current design targets the following advantages:=20 1. Reduced RTTs compared to SOCKSv5;=20 2. Can leverage TFO on the client-proxy and/or proxy-server leg; 3. Enhances MPTCP proxy assisted deployment, can achieve 0-RTT authenticati= on; =20 Our prototype is coming along nicely and will hopefully be deployed at Oran= ge Romania next year, but we are interested in standardizing it too. The last SOCKSv5 protocol(RFC1928) was standardized 20 years ago in the "Ne= twork Working Group", is INTAREA WG the right venue to discuss this?=20 Any suggestion is appreciated.=20 --=20 Drago=C8=99 From nobody Fri Jun 23 12:55:40 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5971128D44; Fri, 23 Jun 2017 12:55:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149824773063.17383.492358539882882073@ietfa.amsl.com> Date: Fri, 23 Jun 2017 12:55:30 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 19:55:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : PROBE: A Utility For Probing Interfaces Authors : Ron Bonica Reji Thomas Jen Linkova Chris Lenart Mohamed Boucadair Filename : draft-ietf-intarea-probe-00.txt Pages : 17 Date : 2017-06-23 Abstract: This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-probe-00 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-00 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 Jun 23 17:10:21 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFE0129B7F; Fri, 23 Jun 2017 17:07:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh.krishnan@gmail.com, int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282344.7840.5580709479759368871.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:03 -0700 Archived-At: Subject: [Int-area] intarea - Requested session has been scheduled for IETF 99 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:04 -0000 Dear Wassim Haddad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. intarea Session 1 (1:30:00) Thursday, Morning Session I 0930-1200 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Internet Area Working Group Area Name: Internet Area Session Requester: Wassim Haddad Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: lpwan 6tisch 6man homenet v6ops irtfopen 6lo dhc saag lisp nvo3 t2trg Second Priority: softwire sunset4 tsvwg dnsop netconf nfvrg People who must be present: Wassim Haddad Suresh Krishnan Juan Carlos Zuniga Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jun 25 09:59:03 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7A124D37; Sun, 25 Jun 2017 09:59:02 -0700 (PDT) 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_PASS=-0.001] autolearn=ham autolearn_force=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 AAx_x8rxU2ky; Sun, 25 Jun 2017 09:59:01 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 211291201F2; Sun, 25 Jun 2017 09:59:00 -0700 (PDT) X-AuditID: c6180641-bd7ff70000001788-e1-594fa573519b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 52.4E.06024.375AF495; Sun, 25 Jun 2017 13:58:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0352.000; Sun, 25 Jun 2017 12:58:59 -0400 From: Wassim Haddad To: "int-area@ietf.org" CC: "intarea-chairs@ietf.org" , Juan Carlos Zuniga , "Suresh.Krishnan@gmail.com" , Wassim Haddad Thread-Topic: [Int-area] Call for Agenda Items @ IETF99 Thread-Index: AQHS7dROlSWqKuyb9kmRC6I3x6f1pw== Date: Sun, 25 Jun 2017 16:58:44 +0000 Message-ID: <2A087E9E-2FE7-4A1D-B551-33CE5B8D765E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_2A087E9E2FE74A1DB55133CE5B8D765Eericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXSPn27xUv9Ig0krTC1uzLrJYjH7gZdF 7+1ZjBZHNpxldWDx2DnrLrvHkiU/mTyefsgMYI7isklJzcksSy3St0vgyniwdxFTwXqFit1H n7A3MK6T72Lk5JAQMJFYf66XrYuRi0NI4CijROvBV8wQznJGiYaby1hAqtgEDCS+Lj/LCmKL CGhL7H9ygAWkiFngMlDHk8NgCWEBI4nVK9czQhSZS6xv+swEYetJnLw7hb2LkYODRUBV4vQ6 fhCTV8Beou1pFkgFo4CYxPdTa8CqmQXEJW49mc8EcZyAxJI955khbFGJl4//gW0SBZrYt2AP C0RcSeLj7/nsEL3JEtMW3wKzeQUEJU7OfMIygVF4FpKxs5CUzUJSNgvoImYBTYn1u/QhShQl pnQ/ZIewNSRa58xlhyixlni31BFZyQJGjlWMHKXFBTm56UaGmxiBMXVMgs1xB+PeXs9DjAIc jEo8vHJT/SOFWBPLiitzDzFKcDArifC2PwcK8aYkVlalFuXHF5XmpBYfYpTmYFES531XfiFC SCA9sSQ1OzW1ILUIJsvEwSnVwFi3U8+2xW+aOPP+D6GLpsYazM8+ETInt/v17L+qmU+v/LHw XcJ2rsAwTXVzYMrVAh+JrZuNttwo2OZnr+MzbfI6llDeTUk310RstjkyJT9N4Uqy1qYr1yeb /tvc53p29vQ1EW4y6mXbL/9cKfD2tv6Pfl3rm19n5auE8l42EZectcm2/AhPWbgSS3FGoqEW c1FxIgD5eUgepQIAAA== Archived-At: Subject: [Int-area] Call for Agenda Items @ IETF99 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 16:59:03 -0000 --_000_2A087E9E2FE74A1DB55133CE5B8D765Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkluIHByZXBhcmF0aW9uIGZvciB0aGUgSW50YXJlYSBXRyBtZWV0aW5nIHNj aGVkdWxlZCBvbiBUaHVyc2RheSBtb3JuaW5nICgwNy8yMCksIHBsZWFzZSBzZW5kIGFnZW5kYSBy ZXF1ZXN0cyB0byB0aGUgY2hhaXJzLiBQbGVhc2UgaW5kaWNhdGUgc2hvcnQgYWJzdHJhY3QsIGRy YWZ0IG5hbWUsIGFuZCB0aW1lIHJlcXVlc3RlZC4NCg0KDQpUaGFua3MsDQoNCkp1YW4gQ2FybG9z LCBTdXJlc2ggYW5kIFdhc3NpbQ0KDQo= --_000_2A087E9E2FE74A1DB55133CE5B8D765Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHByZXBhcmF0aW9uIGZvciB0aGUgSW50YXJl YSBXRyBtZWV0aW5nIHNjaGVkdWxlZCBvbiBUaHVyc2RheSBtb3JuaW5nICgwNy8yMCksIHBsZWFz ZSBzZW5kIGFnZW5kYSByZXF1ZXN0cyB0byB0aGUgY2hhaXJzLiBQbGVhc2UgaW5kaWNhdGUgc2hv cnQgYWJzdHJhY3QsIGRyYWZ0IG5hbWUsIGFuZCB0aW1lIHJlcXVlc3RlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5KdWFuIENh cmxvcywgU3VyZXNoIGFuZCBXYXNzaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2A087E9E2FE74A1DB55133CE5B8D765Eericssoncom_-- From nobody Tue Jun 27 01:44:37 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE5127333 for ; Tue, 27 Jun 2017 01:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8xRT5FtzgD5 for ; Tue, 27 Jun 2017 01:44:33 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 323F4126C23 for ; Tue, 27 Jun 2017 01:44:33 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id w126so17960991wme.0 for ; Tue, 27 Jun 2017 01:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=uE9eYvwIx92Wz8xZNGOOTumMDJXPjD1RJY8kLTSHQ50=; b=JsWjCLg9EVmNsZHekBs34x/NpR87XtxbUraoJOkotAaibMuJVAuC6e7Hs5t/rJG+hC GKRtHwNqHtWdVjGTWU6DgHrU4vkrLF7Qg/PDaotF40vf5WCqK419+W+2Y0MKwfniEcs0 sQ41UOp7R+w4yWA996059ORqFg1wPiDdKcY7+IO0EeFiQkTGJuaDPIpaS3mG3OlOPYV6 M942S8C1IFZ5aEeXsJnHca3z5EiGvR/Oe+pfJFYJT96SUe6QC540dVtV5ADBbXyJTpoU VfSJ+xuaTAOpUdVVU4tfnk5tAKG+M+LXAc6R+2Q+UvF6mWfcTX/gzAFtPBPt80snYKC1 efJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=uE9eYvwIx92Wz8xZNGOOTumMDJXPjD1RJY8kLTSHQ50=; b=ZTm+ltSPV1vuWZFU1/81xeVWwKQshYgPBsNeKWa4jcY9DnU58RjDhFkAJUR/Wd0524 RMt8S64yxS8b9wAr5zk0jzbeKCZZXZnoubT47FUCtQlTEr4fms4FfImZK7A7I+41NaNN ldVd2zFNEcUZZrJXgOkcmT1xyOPKTGUO/J9mp2RFPOch8PikTp1vHUz7Xa91uL0oyZZa IYDuRe9KnAVPq+cWe9/ruzJwkAp1z1pZZ+n/JyDDHuQDGrjzqtscm26ewHzHC3WBW8NV odmTdxhcJ/gbFPNrri1Am3qDj0GqpETFNih74e1biX7+HeDl2RfphTa+/5TTb5U8yRw2 Nl8Q== X-Gm-Message-State: AKS2vOzMUeJWHlMkADi6jFpFLeFHsAoXqNd5VkrFUmHj54KM//yEsxuC uIo+8+Me5XIFDkFvaq1s2J2HuoT+qJde X-Received: by 10.80.159.165 with SMTP id c34mr3197573edf.11.1498553071668; Tue, 27 Jun 2017 01:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.170.19 with HTTP; Tue, 27 Jun 2017 01:44:31 -0700 (PDT) From: Tal Mizrahi Date: Tue, 27 Jun 2017 11:44:31 +0300 Message-ID: To: int-area@ietf.org Cc: acmorton@att.com, joachim.fabini@tuwien.ac.at, talmi@marvell.com Content-Type: multipart/alternative; boundary="94eb2c19c90e83954b0552ed130e" Archived-At: Subject: [Int-area] Fwd: New Version Notification for draft-mizrahi-intarea-packet-timestamps-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 08:44:36 -0000 --94eb2c19c90e83954b0552ed130e Content-Type: text/plain; charset="UTF-8" Hi, I would like to point your attention to a new draft that presents guidelines for defining packet timestamp formats. Please see the abstract and links below. Any comments will be welcome. Cheers, Tal, Joachim, and Al. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, June 27, 2017 11:35 AM To: Joachim Fabini; Tal Mizrahi; Al Morton Subject: New Version Notification for draft-mizrahi-intarea-packet-timestamps-00.txt A new version of I-D, draft-mizrahi-intarea-packet-timestamps-00.txt has been successfully submitted by Tal Mizrahi and posted to the IETF repository. Name: draft-mizrahi-intarea-packet-timestamps Revision: 00 Title: Guidelines for Defining Packet Timestamps Document date: 2017-06-27 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-mizrahi-intarea- packet-timestamps-00.txt Status: https://datatracker.ietf.org/doc/draft-mizrahi-intarea- packet-timestamps/ Htmlized: https://tools.ietf.org/html/draft-mizrahi-intarea-packet- timestamps-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mizrahi- intarea-packet-timestamps-00 Abstract: This document specifies guidelines for defining binary packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this memo includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. 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 --94eb2c19c90e83954b0552ed130e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I would like to point yo= ur attention to a new draft that presents guidelines for defining packet ti= mestamp formats. Please see the abstract and links below.

Any comments will be welcome.

Cheers,
Tal, Joachim, and Al.



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=C2=A0
Sent: Tuesday, June 27, 2017 11:35 AM
T= o: Joachim Fabini; Tal Mizrahi; Al Morton
S= ubject: New Version Notification for draft-mizrahi-intarea-packet-timestamp= s-00.txt


A new version of I-D, draft-mizrahi-intarea-packet-timestamps-00.txt has been successfully submitted by Tal Mizrahi and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mizrahi-intarea-packet-= timestamps
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Guidelines for Defining Packet Tim= estamps
Document date:=C2=A0 2017-06-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-mizrahi-intarea-packet-timestamps-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mizrahi-intarea-<= wbr>packet-timestamps/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mizrahi-intarea-packet-ti= mestamps-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mizrahi-intarea-packet-timestamps-00


Abstract:
=C2=A0 =C2=A0This document specifies guidelines for defining binary packet<= br> =C2=A0 =C2=A0timestamp formats in networking protocols at various layers.= =C2=A0 It also
=C2=A0 =C2=A0presents three recommended timestamp formats.=C2=A0 The target= audience of
=C2=A0 =C2=A0this memo includes network protocol designers.=C2=A0 It is exp= ected that a
=C2=A0 =C2=A0new network protocol that requires a packet timestamp will, in= most
=C2=A0 =C2=A0cases, use one of the recommended timestamp formats.=C2=A0 If = none of the
=C2=A0 =C2=A0recommended formats fits the protocol requirements, the new pr= otocol
=C2=A0 =C2=A0specification should specify the format of the packet timestam= p
=C2=A0 =C2=A0according to the guidelines in this document.




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.

The IETF Secretariat


--94eb2c19c90e83954b0552ed130e-- From nobody Tue Jun 27 08:04:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6555129AD1; Tue, 27 Jun 2017 05:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3sn1z_sjLH9; Tue, 27 Jun 2017 05:00:06 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6DE5E129ABE; Tue, 27 Jun 2017 05:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:To:References:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xEA3WGcZJ4DY7w+iccN9PQ7hDQNw6Tv/8nOsJeeDve4=; b=v1f995+2Nj3yxEa2m9Fo1TQ5z WsC1m3+Fe9t/oJg5KsIR9BSDLI8+qabOsUK7oNtKtBAYVcE0FtKnBzGMU0xkCPQY5a3WsXWuwUPcX KZaMCKe1A2xZOlVBQSNv3c08GpaGd9cUwCnmLS9X1Cw8Mg3iwWZl5+H/QiE3JXE/OdNQXctgvkYg/ cTrp8+ThxTURhE7wyJrPL0acfcn2hB7oqkr4Yqmn16GejOimWXErwAtr5sl+LQIg2EhcItU1JOO5m 67JNpYx16SEt9CCbLxF88+OJNfrbjLe3j7yXN4SsqXlyF3BdB6A7fUtwpwyKBBcTlxVbrPduDAlGb GcW694M5w==; Received: from [31.185.128.124] (port=52714 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dPpA3-0002YR-Bm; Tue, 27 Jun 2017 13:00:03 +0100 References: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> To: "Black, David" , "Carlos Pignataro (cpignata)" , Ignacio Goyret , Alia ATLAS , Praveen Balasubramanian , Joe Touch , "nvo3@ietf.org" , Christian Huitema Cc: tsvwg IETF list , intarea IETF list , l2tp IETF list , "opsawg-chairs@ietf.org" , Service Function Chaining IETF list From: Bob Briscoe X-Forwarded-Message-Id: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> Message-ID: <291369ad-5f3a-e529-c2ef-24dfe2406b2f@bobbriscoe.net> Date: Tue, 27 Jun 2017 13:00:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------6A1261D435D710497D63773F" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Tue, 27 Jun 2017 08:04:30 -0700 Subject: [Int-area] ECN over IP-shim-(L2)-IP Tunnels: New draft-ietf-tsvwg-rfc6040update-shim-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:00:09 -0000 This is a multi-part message in MIME format. --------------6A1261D435D710497D63773F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David (as doc shepherd), This is the 3rd revision in the last 2 months. This revision attempts to capture all the comments collected thanks to Carlos, Ignacio, Praveen, Joe and Alia. It would be useful to have a confirmation from each of you that I have addressed your concerns (or not). I have cross-posted all the lists potentially affected by this draft (intended proposed standard). If you reply concerning a specific point, pls trim the distribution only to those interested/relevant. * tsvwg: owns updates to ECN * int-area: owns mtce of many tunnelling protocols, particularly GRE?, Teredo? GUE * l2tpext: owns mtce of L2TP * opsawg: owns mtce of CAPWAP * nvo3: currently defining Geneve, VXLAN-GPE * sfc: currently defining NSH From my point of view, this draft is now 'finished'. I.e. I am happy with it, and it is the first draft where all the ToDo's are done. I believe it is on track for the milestone of WGLC before the Nov'17 IETF. As I understand it, WGLC will run in tsvwg and in parallel in int-area, l2tpext and perhaps opsawg. Main changes since -02: * Completely restructured, with definitions of scope before even mentioning "tightly coupled shim headers", and new subsections where existing text on feasibility and desirability has been re-homed. * Explanation of the safety problem, and the procedural problem this caused when previous ECN RFCs were written (an RFC cannot retrospectively set requirements on implementations, so we can only set operational requirements - configuration). * Added NSH, but it doesn't seem to cover encapsulation. * No longer categorized VXLAN-GPE as intended for standards track * Added Teredo update text (for safety). Cheers Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-03.txt Date: Tue, 27 Jun 2017 04:13:58 -0700 From: internet-drafts@ietf.org To: Bob Briscoe A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-03.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-ietf-tsvwg-rfc6040update-shim Revision: 03 Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Document date: 2017-06-27 Group: tsvwg Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-03 Abstract: RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols separated by such shim header(s) and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. 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 --------------6A1261D435D710497D63773F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit David (as doc shepherd),

This is the 3rd revision in the last 2 months. This revision attempts to capture all the comments collected thanks to Carlos, Ignacio, Praveen, Joe and Alia. It would be useful to have a confirmation from each of you that I have addressed your concerns (or not).

I have cross-posted all the lists potentially affected by this draft (intended proposed standard).
If you reply concerning a specific point, pls trim the distribution only to those interested/relevant.

* tsvwg: owns updates to ECN
* int-area: owns mtce of many tunnelling protocols, particularly GRE?, Teredo? GUE
* l2tpext: owns mtce of L2TP
* opsawg: owns mtce of CAPWAP
* nvo3: currently defining Geneve, VXLAN-GPE
* sfc: currently defining NSH

From my point of view, this draft is now 'finished'. I.e. I am happy with it, and it is the first draft where all the ToDo's are done. I believe it is on track for the milestone of WGLC before the Nov'17 IETF. As I understand it, WGLC will run in tsvwg and in parallel in int-area, l2tpext and perhaps opsawg.

Main changes since -02:
* Completely restructured, with definitions of scope before even mentioning "tightly coupled shim headers", and new subsections where existing text on feasibility and desirability has been re-homed.
* Explanation of the safety problem, and the procedural problem this caused when previous ECN RFCs were written (an RFC cannot retrospectively set requirements on implementations, so we can only set operational requirements - configuration).
* Added NSH, but it doesn't seem to cover encapsulation.
* No longer categorized VXLAN-GPE as intended for standards track
* Added Teredo update text (for safety).

Cheers


Bob

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-03.txt
Date: Tue, 27 Jun 2017 04:13:58 -0700
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net> 


A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-03.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-ietf-tsvwg-rfc6040update-shim
Revision:	03
Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
Document date:	2017-06-27
Group:		tsvwg
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-03

Abstract:
   RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
   rules for propagation of ECN consistent for all forms of IP in IP
   tunnel.  This specification updates RFC 6040 to clarify that its
   scope includes tunnels where two IP headers are separated by at least
   one shim header that is not sufficient on its own for wide area
   packet forwarding.  It surveys widely deployed IP tunnelling
   protocols separated by such shim header(s) and updates the
   specifications of those that do not mention ECN propagation (L2TPv2,
   L2TPv3, GRE and Teredo).  This specification also updates RFC 6040
   with configuration requirements needed to make any legacy tunnel
   ingress safe.

                                                                                  


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
--------------6A1261D435D710497D63773F-- From nobody Wed Jun 28 22:08:52 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D291201F2 for ; Wed, 28 Jun 2017 22:08:51 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XMYE9fjEjzCG for ; Wed, 28 Jun 2017 22:08:48 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0397112704A for ; Wed, 28 Jun 2017 22:08:47 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3A4SvF9R1TZwhcXK2csmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIVLvad9pjvdHbS+e9qxAeQG96KtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXXdPXshPWSJBAY2y?= =?us-ascii?q?YYUAAOUDMulEtITyvUcCoAGkCAWwCu7iyDlFjWL2060g1OQhFBnL0wMkH90UrX?= =?us-ascii?q?vUrdD1NKYIUeuo1afIySnDYO1M1jf79YjDbxcsoe+IXb1qbMXRyEwvFwLfjlmK?= =?us-ascii?q?rozlOy+V2foXvGid8uptTv6gi3U9pwFpvzig3d0gipPOho8MzF3P6Ct3wIEwJd?= =?us-ascii?q?KiSU57Z8apEJpOuCGGOYt6WMQiQ3tnuCs817YIuoa7cTAXxJko2hLTcf+KfoiS?= =?us-ascii?q?7h79SuqcIy10iXx9dL+7hxu+60qtx+zmWsWpzlpHrTBJnsfQunwQ0RHY99KJRe?= =?us-ascii?q?Fn/ki73DaCzwXT6uZZLk8qjafbMJshwqIolpoUrETDAjf6mEXog6+ScUUp4vao?= =?us-ascii?q?6+H9bbXnop+QLZN7ihrkPqQ2h8ywGv40MhIJX2SD+OS80qPs/VHhTblXgfA6j7?= =?us-ascii?q?PVvZPaKMgBuKK1HQ1Y3pwt5hqnCjepytUYnX0JLFJffxKHipDkO0/KIP/iEPi/?= =?us-ascii?q?glGskDZxx/zcOb3hBonNIWbZn7fnYLZw8FJTyBEpwdBH+pJbEasNIOj0WkPprt?= =?us-ascii?q?zXEgc5MxCow+bgENh914UeWX6WDqCDKqPdr0WH6/kuI+aSeI8VtizxK/8/5/7h?= =?us-ascii?q?3jcFngoce7Xs1IEaYVi5E+hoZUKDbinCmNAERFkOtwY/Se3wwHqGTTNaYWv6C7?= =?us-ascii?q?w47z06DYO8S4DHWo2khqGp1zz9BoBcIHpBXAPfWUz0fpmJDq9fIBmZJdVsx3ld?= =?us-ascii?q?DeCs?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BfCgDnilRZ/wPjVY1dHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhBEDgQuOeJBTIpgMLoVpAwICg2IBAQEBAQEBAQIBaiiCMyQBgkA?= =?us-ascii?q?BAwMjVhAcAwECKwICTwgTBgIBAYovDLIagiYpiyEBAQEHAgElgyeDTIIMC4dCg?= =?us-ascii?q?ymCYQWJW4ZqgQWNKoIchSCMOYIIVoEPg2WDS4Z4lScCV4EKMCFXh0BzAYlAAQE?= =?us-ascii?q?B?= X-IPAS-Result: =?us-ascii?q?A2BfCgDnilRZ/wPjVY1dHAEBBAEBCgEBFwEBBAEBCgEBhBE?= =?us-ascii?q?DgQuOeJBTIpgMLoVpAwICg2IBAQEBAQEBAQIBaiiCMyQBgkABAwMjVhAcAwECK?= =?us-ascii?q?wICTwgTBgIBAYovDLIagiYpiyEBAQEHAgElgyeDTIIMC4dCgymCYQWJW4ZqgQW?= =?us-ascii?q?NKoIchSCMOYIIVoEPg2WDS4Z4lScCV4EKMCFXh0BzAYlAAQEB?= X-IronPort-AV: E=Sophos;i="5.40,278,1496091600"; d="scan'208,217";a="860739" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 29 Jun 2017 08:08:43 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 2C4761A600CA; Thu, 29 Jun 2017 08:08:43 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Nr_jruxb4TRj; Thu, 29 Jun 2017 08:08:43 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 0985E1A6010F; Thu, 29 Jun 2017 08:08:43 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id ED9881A600CA; Thu, 29 Jun 2017 08:08:42 +0300 (EEST) References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> To: int-area@ietf.org From: Vladimir Olteanu X-Forwarded-Message-Id: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> Message-ID: <86644203-198b-c7b9-a029-2dc375398d39@cs.pub.ro> Date: Thu, 29 Jun 2017 08:08:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BA277A70D408CF2792FAB21E" Content-Language: en-US Archived-At: Subject: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:08:51 -0000 This is a multi-part message in MIME format. --------------BA277A70D408CF2792FAB21E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, We have submitted a draft describing a new version of the SOCKS=20 protocol. You can find the abstract and a link to the draft below. Best, Vlad and Drago=C8=99 -------- Forwarded Message -------- Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.t= xt Date: Wed, 28 Jun 2017 22:01:16 -0700 From: internet-drafts@ietf.org To: Vladimir Olteanu , Dragos Niculescu=20 A new version of I-D, draft-olteanu-intarea-socks-6-00.txt has been successfully submitted by Vladimir Olteanu and posted to the IETF repository. Name: draft-olteanu-intarea-socks-6 Revision: 00 Title: SOCKS Protocol Version 6 Document date: 2017-06-28 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-olteanu-intare= a-socks-6-00.txt Status: https://datatracker.ietf.org/doc/draft-olteanu-intarea-so= cks-6/ Htmlized: https://tools.ietf.org/html/draft-olteanu-intarea-socks-6= -00 Htmlized: https://datatracker.ietf.org/doc/html/draft-olteanu-intar= ea-socks-6-00 Abstract: The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication. = =20 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. The IETF Secretariat --------------BA277A70D408CF2792FAB21E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,

We have submitted a draft describing a new version of the SOCKS protocol. You can find the abstract and a link to the draft below.
Best,
Vlad and Drago=C8=99

-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Dat= e: Wed, 28 Jun 2017 22:01:16 -0700
Fro= m: internet-drafts@ietf.org
To:= Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, Dragos Niculescu <dragos.niculescu@cs.pub.ro> 


A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.=
ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt
Status:         https://datatracker.ie=
tf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       https://tools.ietf.org/ht=
ml/draft-olteanu-intarea-socks-6-00
Htmlized:       https://datatra=
cker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00


Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                         =
        =20


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.

The IETF Secretariat
--------------BA277A70D408CF2792FAB21E-- From nobody Thu Jun 29 11:09:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E341C129B23 for ; Thu, 29 Jun 2017 11:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHCaqx9LvN5A for ; Thu, 29 Jun 2017 11:09:16 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 18E59126B7E for ; Thu, 29 Jun 2017 11:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498759752; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/xKMjIG/uyo5cx4NI1vpB0JnlOBm25OrnvILSav2aHY=; b=IHSbZYADJhzlphj5L1Q0DQ1BKjaB4wmAr4G/7WEqGATOGCMCrmPXQYMHReFL8aLK UwZiW/Eq8RPKYM9NnNIdWUGHjtuArVb+qq6DwvIv1JoeFCPF1FBjtihJ9fIOMQQA 1oWffGSVCfAPAls+QfLYIhXAu/ECFmba8wLe3vO0ksoUWsiuOBH5CAFFwQttRyh3 TlV5swTrX25hCAJWRtObD5rUJJ/aawIy3R3vEDczG/v0MjKjyfdtVIm+G/tEmpu2 DUdjueHtRP/PNtNoZBWHtsM4xEwNzA9ek/v0RPEaavnkXnTzelvBhjGmdQu1/n2L Gzo4diq2LJ4RzZP1iDvTqA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 5A.93.06195.84245595; Thu, 29 Jun 2017 11:09:12 -0700 (PDT) X-AuditID: 11973e16-8b5f19c000001833-ca-595542485797 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay6.apple.com (Apple SCV relay) with SMTP id 15.44.05199.84245595; Thu, 29 Jun 2017 11:09:12 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wa/9wejaAMVTE4lPJXg7Tg)" Received: from [17.234.28.37] (unknown [17.234.28.37]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSB00KTGMFCST10@koseret.apple.com>; Thu, 29 Jun 2017 11:09:12 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 29 Jun 2017 11:09:11 -0700 In-reply-to: Cc: Int-area@ietf.org To: Vladimir Olteanu References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYpevhFBpp0DXJ3OLGrJssFofampgd mDymnnzJ6rFkyU+mAKYoLpuU1JzMstQifbsEroxdCyczFvyIrmhovsfSwDjPq4uRg0NCwETi xF6WLkYuDiGB1UwS6699A3I4weJ7Fk1nh0isYpT4/msuK0iCV0BQ4sfke2BFzAJhEv+f7WGF KGpmkrgxZT07SEJYQFqi68JdVpANbAJaEgfWGEH02kjc61/HBFGiKvF29kdmEJsFyO7d+B1s JqeArcTsw3MZIeaLSuy6tQ+sRkTAUGLuns1sILaQQL3EtSPNbBCHykrcmn2JGeQGCYE9bBKL 9lxhmcAoNAvJrbOQ3DoL6CRmAXWJKVNyIcLaEk/eXWCFsNUkFv5exIQsvoCRbRWjUG5iZo5u Zp65XmJBQU6qXnJ+7iZGUCRMtxPbwfhwldUhRgEORiUe3g0aoZFCrIllxZW5hxilOViUxHm/ aIVECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA8dyRJqa9271qbk0fcONbk5Le5OpcY/Vu1 IDvQ9PO1ObpXJ8vvkb8mV7b/Ztf35sjyl71hldk7BESF/nToaj+wYVOy0nS+WZT3vnvO3ZeT fsqteejY63PKIESi8cj0tYGvf15QOLou9paaTkVR9wPpl87f07zldlqaOpZse3J7UUxYY7mf QZISS3FGoqEWc1FxIgBCsoBlZQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OXdfDKTTSYP5kI4sbs26yWBxqa2J2 YPKYevIlq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ2LZzMWPAjuqKh+R5LA+M8ry5GTg4JAROJ PYums3cxcnEICaxilPj+ay4rSIJXQFDix+R7LCA2s0CYxP9ne1ghipqZJG5MWc8OkhAWkJbo unAXKMHBwSagJXFgjRFEr43Evf51TBAlqhJvZ39kBrFZgOzejd/BZnIK2ErMPjyXEWK+qMSu W/vAakQEDCXm7tnMBmILCdRLXDvSzAZxqKzErdmXmCcw8s9Cct4sJOfNArqCWUBdYsqUXIiw tsSTdxdYIWw1iYW/FzEhiy9gZFvFKFCUmpNYaaaXWFCQk6qXnJ+7iREUug2FUTsYG5ZbHWIU 4GBU4uHdoBEaKcSaWFZcmXuIUYKDWUmEt0gdKMSbklhZlVqUH19UmpNafIhxIiPQkxOZpUST 84GRlVcSb2hiYmBibGxmbGxuYk5LYSVx3hW3gyOFBNITS1KzU1MLUotgjmLi4JRqYFTICpPe zh10XnBTgX7RU2+ZxcYbpn79rXAofUf1ZCHBhQ4hptlXvDZ/MHTZ2/Nt393w/87HCx4K/jjm fVd3agNn0pYbr5wsNq9cMZt1sfyCnjqm/6319Qt7Z+gcUbDxT4rX67witv6ys47QoehXpzLd UlYEJt4omPXLWm4jr8RHNfbSzms9v5VYijMSDbWYi4oTAY7k503QAgAA Archived-At: Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 18:09:18 -0000 --Boundary_(ID_wa/9wejaAMVTE4lPJXg7Tg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Vladimir, Thanks for writing this up, I agree SOCKS needs to be modernized and I = think your draft has a lot of good ideas. A few questions: - Why do you mimic the TFO semantics so closely? Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of = the initial data offset. The server can pull enough data for the upstream TCP SYN from its = initial window and leave the rest of the SOCKSv6 initial data there for later, instead = of resending it twice. - Does it make sense to keep sending the version number over the wire? Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, = port number) and there is no way for a SOCKSv5 server to reply "I don't speak = SOCKSv6". I'm not sure I see the value of a minor version either, as there's still = plenty of room for major versions 7-255. - Instead of having a command code enum with 3 values and a TFO enum = with 2 values, could we instead add a CONNECT_WITH_TFO command code to save a byte? We could even take that one step further and also merge in the address = type enum. - One pain point I had when implementing SOCKSv5 was the fact that the = port number was after the address which meant that it moved, would it make sense to = place it before the variable length address field to simplify and optimize parsing? - Could we make the client supported auth methods optional? Since the client is sending tentative auth proposals as options, one = could imagine making the list of supported auth methods an option, an treating it as = "I only support no auth" when it's not there - Out of curiosity, what specific use case are you using this protocol = for? Thanks, David Schinazi > On Jun 29, 2017, at 05:08, Vladimir Olteanu = wrote: >=20 > Hello, >=20 > We have submitted a draft describing a new version of the SOCKS = protocol. You can find the abstract and a link to the draft below. >=20 > Best, > Vlad and Drago=C8=99 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-olteanu-intarea-socks-6-00.txt > Date: Wed, 28 Jun 2017 22:01:16 -0700 > From: internet-drafts@ietf.org > To: Vladimir Olteanu = , Dragos Niculescu = >=20 > A new version of I-D, draft-olteanu-intarea-socks-6-00.txt > has been successfully submitted by Vladimir Olteanu and posted to the > IETF repository. >=20 > Name: draft-olteanu-intarea-socks-6 > Revision: 00 > Title: SOCKS Protocol Version 6 > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ = > Htmlized: = https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00 = >=20 >=20 > Abstract: > The SOCKS protocol is used primarily to proxy TCP connections to > arbitrary destinations via the use of a proxy server. Under the > latest version of the protocol (version 5), it takes 2 RTTs (or 3, = if > authentication is used) before data can flow between the client and > the server. >=20 > This memo proposes SOCKS version 6, which reduces the number of = RTTs > used, takes full advantage of TCP Fast Open, and adds support for > 0-RTT authentication. >=20 > = =20 >=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 > The IETF Secretariat >=20 --Boundary_(ID_wa/9wejaAMVTE4lPJXg7Tg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Vladimir,

Thanks for writing this up, I agree SOCKS needs to be = modernized and I think your draft
has a lot of good = ideas. A few questions:

- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the = meaning of the initial data offset.
The server can = pull enough data for the upstream TCP SYN from its initial = window
and leave the rest of the SOCKSv6 initial = data there for later, instead of resending it twice.

- Does it make sense to = keep sending the version number over the wire?
Proxy = protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port = number)
and there is no way for a SOCKSv5 server to = reply "I don't speak SOCKSv6".
I'm not sure I see = the value of a minor version either, as there's still plenty of = room
for major versions 7-255.

- Instead of having a = command code enum with 3 values and a TFO enum with 2 values,
could we instead add a CONNECT_WITH_TFO command code to save = a byte?
We could even take that one step further = and also merge in the address type enum.

- One pain point I had when = implementing SOCKSv5 was the fact that the port number
was after the address which meant that it moved, would it = make sense to place it before
the variable length = address field to simplify and optimize parsing?

- Could we make the client supported = auth methods optional?
Since the client is sending = tentative auth proposals as options, one could imagine
making the list of supported auth methods an option, an = treating it as "I only support
no auth" when it's = not there

- = Out of curiosity, what specific use case are you using this protocol = for?

Thanks,
David Schinazi


On = Jun 29, 2017, at 05:08, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro> wrote:

=20 =20

= Hello,

We have submitted a draft describing a new version of the SOCKS protocol. You can find the abstract and a link to the draft = below.

Best,
Vlad and Drago=C8=99



-------- Forwarded Message -------- =
Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Date: Wed, 28 Jun 2017 22:01:16 -0700
From: internet-drafts@ietf.org
To: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro&= gt;, Dragos Niculescu <dragos.niculescu@cs.pub.ro&= gt; 


A new version of I-D, =
draft-olteanu-intarea-socks-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-=
6-00.txt
Status:         h=
ttps://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       http=
s://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-=
00


Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                         =
        =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

= --Boundary_(ID_wa/9wejaAMVTE4lPJXg7Tg)-- From nobody Fri Jun 30 06:56:54 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDD41201F8 for ; Fri, 30 Jun 2017 06:56:53 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DKBEBWCFB3Jf for ; Fri, 30 Jun 2017 06:56:43 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29112EC18 for ; Fri, 30 Jun 2017 06:56:40 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AYs2TxR2Bnaugge28smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIfKPad9pjvdHbS+e9qxAeQG96KtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXXdPUNhfVyJBAY2y?= =?us-ascii?q?YYUAAOUDMulEtITyvUcCoAGkCAWwCu7iyDlFjWL2060g1OQhFBnL0wMkH90UrX?= =?us-ascii?q?vUrdD1NKYIUeuo1afIySnDYO1M1jf79YjDbxcsoe+IXb1qbMXRyEwvFwLfjlmK?= =?us-ascii?q?rozlOy+V2foXvGid8uptTv6gi3U9pwFpvzig3d0gipPOho8MzF3P6CZ3wJ4tKN?= =?us-ascii?q?GlR0N3fMSoHZhQui2AKYd6XMEvT3tmtSoizrALuYS3cSoLxZg92hLTdf+Kf5KW?= =?us-ascii?q?7h7/SeqcJypzimh/d7KlnRmy9FCtyuj7VsapzllHtjFFktzQtnAV0BzT99SHRu?= =?us-ascii?q?N9/ki/3TaP0Bje6v9BIU8ulKrbL4QtzaIrlpYJqUTDAzT5lF/sjK+Rbkkk++6o?= =?us-ascii?q?5Pr7Yrj+u5OROJJ4hhv9P6kugMCzH/o0PwoUU2WV4ei80afs/Uz9QLVElP02la?= =?us-ascii?q?zZvYjEJcQfvKG2Hg5V0oMi6xalFTum19AYnWUZI11ffhKHkpPkNE3VIPziFfe/?= =?us-ascii?q?nk+jnC1xx/DBJrHhGInCLmDfkLf9erZw81NTyBEvwtBf5pJUDKsOIfPyWkLqrt?= =?us-ascii?q?PYFgc5MwiqzOr9FNp90YYeU3qVAqCFKKPSrUOI5uU3LuePYo8VpC/xJOI/5/Hw?= =?us-ascii?q?l3A0gl4dcre13ZsZcny4Ge5mI0rKKUbr1/sID2YG9jE1TO3sgU+DGWpffH2yXq?= =?us-ascii?q?Q19DATAZq+CYqFTYeo1vjJ/SGnW5RMa2luC12QHzHvbYrXde0LbXesJsZtkzkF?= =?us-ascii?q?T/CGT5Ms3Bez/Fvkz7NrL+/V4GsfsY7u3d5oz+bI0wkv/3puCJLOgCm2U2hokz?= =?us-ascii?q?ZQFHcN16dlrBk4kw/b3A=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DSBwBdWFZZ/wPjVY1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFgEBAQMBAQEJAQEBhBEDgQuOeJBVIpgMLoVuAoNtAQEBAQEBAQECAWo?= =?us-ascii?q?ogjMkAYJAAQEBAQIBI1sLCw4DAwECAScDAgJGCQgGAQwGAgEBiiMMDLM3giYpi?= =?us-ascii?q?xcBCgEBAQEjgyeDTIIMC4JuhFQ2gnOCYQWJWQKGaoEFjTCCIIUkjkZWgQ+DZYN?= =?us-ascii?q?MI4ZVjFuIUAIPSIEKMSFXKocYcwGJKQEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DSBwBdWFZZ/wPjVY1dGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBhBEDgQuOeJBVIpgMLoVuAoNtAQEBAQEBAQECAWoogjMkAYJAAQEBA?= =?us-ascii?q?QIBI1sLCw4DAwECAScDAgJGCQgGAQwGAgEBiiMMDLM3giYpixcBCgEBAQEjgye?= =?us-ascii?q?DTIIMC4JuhFQ2gnOCYQWJWQKGaoEFjTCCIIUkjkZWgQ+DZYNMI4ZVjFuIUAIPS?= =?us-ascii?q?IEKMSFXKocYcwGJKQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,286,1496091600"; d="scan'208,217";a="864529" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 30 Jun 2017 16:56:33 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 539BB1A6018C; Fri, 30 Jun 2017 16:56:33 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2wH8sSCnosPc; Fri, 30 Jun 2017 16:56:33 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 305891A6019D; Fri, 30 Jun 2017 16:56:33 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 25AA41A6018C; Fri, 30 Jun 2017 16:56:33 +0300 (EEST) To: David Schinazi , Int-area@ietf.org References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> From: Vladimir Olteanu Message-ID: <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> Date: Fri, 30 Jun 2017 16:56:35 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12366D2363ACDA5A899F9E09" Content-Language: en-US Archived-At: Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 13:56:53 -0000 This is a multi-part message in MIME format. --------------12366D2363ACDA5A899F9E09 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hey David, Thanks for the kind words. I'll address your questions inline: On 6/29/2017 9:09 PM, David Schinazi wrote: > Hi Vladimir, > > Thanks for writing this up, I agree SOCKS needs to be modernized and I=20 > think your draft > has a lot of good ideas. A few questions: > > - Why do you mimic the TFO semantics so closely? > Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of=20 > the initial data offset. > The server can pull enough data for the upstream TCP SYN from its=20 > initial window > and leave the rest of the SOCKSv6 initial data there for later,=20 > instead of resending it twice. > The main idea is to let the client send some data before running the=20 authentication protocol. The initial data offset gives the server a=20 carte blanche as to how much of the initial data it buffers while=20 waiting for the client to authenticate. (It still must read all of it=20 from the TCP stream before getting to the part where the client proves=20 its credentials.) Were it not for the authentication phase, these fields=20 would indeed be useless. > - Does it make sense to keep sending the version number over the wire? > Proxy protocols need to be provisioned out of band (e.g. SOCKS vs=20 > HTTP, port number) > and there is no way for a SOCKSv5 server to reply "I don't speak SOCKSv= 6". > I'm not sure I see the value of a minor version either, as there's=20 > still plenty of room > for major versions 7-255. > I think version numbers still make sense. When presented with a SOCKSv6=20 request, a v5 proxy must at least know that the client is speaking some=20 other protocol. I will add a way for the proxy to signal that it doesn't=20 speak SOCKSv7+ in the next version of the draft. Version numbers in=20 operation replies don't make sense; I'll remove those. As for minor=20 versions, they might indeed be overkill, given that v6 is extensible via=20 options. > - Instead of having a command code enum with 3 values and a TFO enum=20 > with 2 values, > could we instead add a CONNECT_WITH_TFO command code to save a byte? > We could even take that one step further and also merge in the address=20 > type enum. > This is certainly worth considering. Alternatively, we could use a bit=20 field: 2-3 bits for the command code, one bit for TFO, 2 for address=20 type etc. Otherwise, we might end up with too many command codes=20 (connect/bind x TFO x address type x whatever else we want to cram in). > - One pain point I had when implementing SOCKSv5 was the fact that the=20 > port number > was after the address which meant that it moved, would it make sense=20 > to place it before > the variable length address field to simplify and optimize parsing? > I don't see why not. > - Could we make the client supported auth methods optional? > Since the client is sending tentative auth proposals as options, one=20 > could imagine > making the list of supported auth methods an option, an treating it as=20 > "I only support > no auth" when it's not there > I like this idea. A side effect of this approach is that we move another=20 variable-length field to the back of the request, further simplifying=20 parsing. > - Out of curiosity, what specific use case are you using this protocol=20 > for? > We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and=20 WiFi. Mobile data networks have high latency, hence the drive to shave=20 off as many RTTs as possible and to take advantage of TFO, at least on=20 the client-proxy leg. Cheers, Vlad > Thanks, > David Schinazi > > >> On Jun 29, 2017, at 05:08, Vladimir Olteanu=20 >> > wrote= : >> >> Hello, >> >> We have submitted a draft describing a new version of the SOCKS=20 >> protocol. You can find the abstract and a link to the draft below. >> >> Best, >> Vlad and Drago=C8=99 >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for=20 >> draft-olteanu-intarea-socks-6-00.txt >> Date: Wed, 28 Jun 2017 22:01:16 -0700 >> From: internet-drafts@ietf.org >> To: Vladimir Olteanu , Dragos Niculescu=20 >> >> >> >> >> A new version of I-D, draft-olteanu-intarea-socks-6-00.txt >> has been successfully submitted by Vladimir Olteanu and posted to the >> IETF repository. >> >> Name: draft-olteanu-intarea-socks-6 >> Revision: 00 >> Title: SOCKS Protocol Version 6 >> Document date: 2017-06-28 >> Group: Individual Submission >> Pages: 12 >> URL:https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6= -00.txt >> Status:https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ >> Htmlized:https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00 >> Htmlized:https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-s= ocks-6-00 >> >> >> Abstract: >> The SOCKS protocol is used primarily to proxy TCP connections to >> arbitrary destinations via the use of a proxy server. Under the >> latest version of the protocol (version 5), it takes 2 RTTs (or 3,= if >> authentication is used) before data can flow between the client an= d >> the server. >> >> This memo proposes SOCKS version 6, which reduces the number of RT= Ts >> used, takes full advantage of TCP Fast Open, and adds support for >> 0-RTT authentication. >> >> = =20 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available attools.ietf.org . >> >> The IETF Secretariat >> > --------------12366D2363ACDA5A899F9E09 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hey David,

Thanks for the kind words. I'll address your questions inline:

On 6/29/2017 9:09 PM, David Schinazi wrote:
Hi Vladimir,

Thanks for writing this up, I agree SOCKS needs to be modernized and I think your draft
has a lot of good ideas. A few questions:

- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of the initial data offset.
The server can pull enough data for the upstream TC= P SYN from its initial window
and leave the rest of the SOCKSv6 initial data ther= e for later, instead of resending it twice.

The main idea is to let the client send some data before running the authentication protocol. The initial data offset gives the server a carte blanche as to how much of the initial data it buffers while waiting for the client to authenticate. (It still must read all of it from the TCP stream before getting to the part where the client proves its credentials.) Were it not for the authentication phase, these fields would indeed be useless.
- Does it make sense to keep sending the version number over the wire?
Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port number)
and there is no way for a SOCKSv5 server to reply "= I don't speak SOCKSv6".
I'm not sure I see the value of a minor version either, as there's still plenty of room
for major versions 7-255.

I think version numbers still make sense. When presented with a SOCKSv6 request, a v5 proxy must at least know that the client is speaking some other protocol. I will add a way for the proxy to signal that it doesn't speak SOCKSv7+ in the next version of the draft. Version numbers in operation replies don't make sense; I'll remove those. As for minor versions, they might indeed be overkill, given that v6 is extensible via options.
- Instead of having a command code enum with 3 values and a TFO enum with 2 values,
could we instead add a CONNECT_WITH_TFO command cod= e to save a byte?
We could even take that one step further and also merge in the address type enum.

This is certainly worth considering. Alternatively, we could use a bit field: 2-3 bits for the command code, one bit for TFO, 2 for address type etc. Otherwise, we might end up with too many command codes (connect/bind x TFO x address type x whatever else we want to cram in).
- One pain point I had when implementing SOCKSv5 wa= s the fact that the port number
was after the address which meant that it moved, would it make sense to place it before
the variable length address field to simplify and optimize parsing?

I don't see why not.
- Could we make the client supported auth methods optional?
Since the client is sending tentative auth proposal= s as options, one could imagine
making the list of supported auth methods an option= , an treating it as "I only support
no auth" when it's not there

I like this idea. A side effect of this approach is that we move another variable-length field to the back of the request, further simplifying parsing.
- Out of curiosity, what specific use case are you using this protocol for?

We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg.

Cheers,
Vlad

Thanks,
David Schinazi


On Jun 29, 2017, at 05:08, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro&g= t; wrote:

Hello,

We have submitted a draft describing a new version of the SOCKS protocol. You can find the abstract and a link to the draft below.

Best,
Vlad and Drago=C8=99



-------- Forwarded Message --------
Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Date: Wed, 28 Jun 2017 22:01:16 -0700
From: internet-drafts@ietf= .org
To: Vladimir Olteanu <vladimir.olteanu= @cs.pub.ro>, Dragos Niculescu <dragos.niculescu= @cs.pub.ro> 


A new version of I-D, draft-olteanu-int=
area-socks-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-olteanu-intarea-s=
ocks-6-00.txt
Status:         https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       =
https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-soc=
ks-6-00


Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                         =
        =20


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.

The IETF Secretariat


--------------12366D2363ACDA5A899F9E09-- From nobody Fri Jun 30 11:08:59 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD58129B53 for ; Fri, 30 Jun 2017 11:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9byvyQlBa3i for ; Fri, 30 Jun 2017 11:08:53 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.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 CBE281271DF for ; Fri, 30 Jun 2017 11:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498846133; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3kaPXWOnVJCOqA84f/lTvauEdm1RPOa8/cvr6t4V3bA=; b=pPX6pS/oVCRBumJ83iruM/QBOJGL/tCVNqwwv+UG3lyLotUxYWlKMpnRIEFlRGAT TzM3DtjbEcakw32YbueDIXeZBE+ZNfA/js/FaxtQtn8z6RFjeikhQHG+rOaE/8Yp E/oFP3JRn1OOOIayp96+ZaeSkhQgp9T2ePpfsF4WBCI6LkEbGaqaKCDEFMKnxEBH YvyfnZfZ8Hu7wRs3qNbzl1jwqILYLUeHnz3Mti5Z74lcD4CSiXVcR81ESpMWndpR Mkfa0yZzz/0ZLg2MH8Wy5tuLFvdx3QFOHyxIbE8ULDyozqTGmHt0ZExBnN5T85Do n4wmj7H7uZuiPaL3Y7qf1Q==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id EF.80.07214.5B396595; Fri, 30 Jun 2017 11:08:53 -0700 (PDT) X-AuditID: 11973e11-7d2f59c000001c2e-66-595693b50994 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id 09.7C.09344.5B396595; Fri, 30 Jun 2017 11:08:53 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Bw0EzP0mIu1ImGKLMfO/7A)" Received: from da0602a-dhcp166.apple.com (da0602a-dhcp166.apple.com [17.226.23.166]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSD002YMH2SC780@jimbu.apple.com>; Fri, 30 Jun 2017 11:08:53 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Fri, 30 Jun 2017 11:08:52 -0700 In-reply-to: <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> Cc: Int-area@ietf.org To: Vladimir Olteanu References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAYobt1clikwc+J6hY3Zt1ksTjU1sTs wOQx9eRLVo8lS34yBTBFcdmkpOZklqUW6dslcGU0rLrLXLA5oWJqv2UDY5tvFyMHh4SAicSf BZFdjFwcQgKrmST+7G9h7WLkBItvW7CTCSKxjFFi1exLbCAJXgFBiR+T77GA2MwCYRJ9p14z QxTNZZI4+fcDWLewgLRE14W7rCAb2AS0JA6sMYLotZGYf+89VImqxNvZH5lBbBYge/rOBWDz OQVsJaauWgM1X1Ri1619YDUiAoYSc/dsZoPY9ZRR4vDNTcwQl8pK3Jp9CewICYEJbBKzzjez TWAUmoXk2FlIjoWwtSS+P2oFinMA2fISB8/LQoQ1JZ7d+8SOJLyAkW0Vo1BuYmaObmaekV5i QUFOql5yfu4mRlAcTLcT3MF4fJXVIUYBDkYlHt4NIWGRQqyJZcWVuYcYpTlYlMR5sxaGRgoJ pCeWpGanphakFsUXleakFh9iZOLglGpg1Hzy8WCzc0KcXK8lJ99fzkpWtqNbWPJ1o5syRLQ8 1htI8xp+rBGf3he8Tvba3U07s/5uPNGbdsxT5ozfxPchG045VG35LpGZcfrWyd0L+WQiOkyX STvlsYcJL/p+b4HvqrDjW/5asHpeM7s55cnlnTPcFyrubXHg//Fq74a9pdXSxQkqbxQeKrEU ZyQaajEXFScCAPCYdqRkAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUiON1OVXfr5LBIg8Y9yhY3Zt1ksTjU1sTs wOQx9eRLVo8lS34yBTBFcdmkpOZklqUW6dslcGU0rLrLXLA5oWJqv2UDY5tvFyMnh4SAicS2 BTuZuhi5OIQEljFKrJp9iQ0kwSsgKPFj8j0WEJtZIEyi79RrZoiiuUwSJ/9+YAVJCAtIS3Rd uAtkc3CwCWhJHFhjBNFrIzH/3nuoElWJt7M/MoPYLED29J0LwOZzCthKTF21Bmq+qMSuW/vA akQEDCXm7tnMBrHrKaPE4ZubmCEulZW4NfsS8wRG/llI7puF5D4IW0vi+6NWoDgHkC0vcfC8 LERYU+LZvU/sSMILGNlWMQoUpeYkVprqJRYU5KTqJefnbmIEBW5DYcQOxv/LrA4xCnAwKvHw bggJixRiTSwrrsw9xCjBwawkwruhESjEm5JYWZValB9fVJqTWnyIUZqDRUmc9xRISiA9sSQ1 OzW1ILUIJsvEwSnVwJgjN8nq1xpuXYWJzNcuz9zvnnmz5IOXz7Xvfv8iW6q4n4v4L5KM8FH6 vNF/mfivkqUCfB0WdSyOjUrXpxu8fu50bp2szPv/1td0FiQ4rj3/NreYNfmbw1zF6ytOHHW1 4Ep9Kz7t1NveO0b2rMc+aPwTORBStquX7+nfzqXBh17VXfdf0V4ko6HEUpyRaKjFXFScCAC4 ctQ1WAIAAA== Archived-At: Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 18:08:56 -0000 --Boundary_(ID_Bw0EzP0mIu1ImGKLMfO/7A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Vlad, Responses inline. > On Jun 30, 2017, at 06:56, Vladimir Olteanu wrote: > > Hey David, > > Thanks for the kind words. I'll address your questions inline: > On 6/29/2017 9:09 PM, David Schinazi wrote: >> Hi Vladimir, >> >> Thanks for writing this up, I agree SOCKS needs to be modernized and I think your draft >> has a lot of good ideas. A few questions: >> >> - Why do you mimic the TFO semantics so closely? >> Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of the initial data offset. >> The server can pull enough data for the upstream TCP SYN from its initial window >> and leave the rest of the SOCKSv6 initial data there for later, instead of resending it twice. >> > The main idea is to let the client send some data before running the authentication protocol. The initial data offset gives the server a carte blanche as to how much of the initial data it buffers while waiting for the client to authenticate. (It still must read all of it from the TCP stream before getting to the part where the client proves its credentials.) Were it not for the authentication phase, these fields would indeed be useless. [DS] That makes more sense, thanks! What's the benefit of sending the idempotent data before auth? The proxy's not going to send it out until it has received the last client -> proxy auth message so we may as well send the data right after that? (That said I'm not very familiar with GSSAPI or the non-standard auth methods 3-8 so I could be missing something) >> - Does it make sense to keep sending the version number over the wire? >> Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port number) >> and there is no way for a SOCKSv5 server to reply "I don't speak SOCKSv6". >> I'm not sure I see the value of a minor version either, as there's still plenty of room >> for major versions 7-255. >> > I think version numbers still make sense. When presented with a SOCKSv6 request, a v5 proxy must at least know that the client is speaking some other protocol. I will add a way for the proxy to signal that it doesn't speak SOCKSv7+ in the next version of the draft. Version numbers in operation replies don't make sense; I'll remove those. As for minor versions, they might indeed be overkill, given that v6 is extensible via options. [DS] Wouldn't it be simpler to have IANA allocate a new port number though? One byte isn't a huge win but it does make implementations simpler. >> - Instead of having a command code enum with 3 values and a TFO enum with 2 values, >> could we instead add a CONNECT_WITH_TFO command code to save a byte? >> We could even take that one step further and also merge in the address type enum. >> > This is certainly worth considering. Alternatively, we could use a bit field: 2-3 bits for the command code, one bit for TFO, 2 for address type etc. Otherwise, we might end up with too many command codes (connect/bind x TFO x address type x whatever else we want to cram in). [DS] A bit field can be very useful, but not when some combinations are not allowed. For example having both TFO and UDP does not make sense. It does make sense for TCP/UDP/TFO vs IPv4/IPv6/hostname though. >> - One pain point I had when implementing SOCKSv5 was the fact that the port number >> was after the address which meant that it moved, would it make sense to place it before >> the variable length address field to simplify and optimize parsing? >> > I don't see why not. >> - Could we make the client supported auth methods optional? >> Since the client is sending tentative auth proposals as options, one could imagine >> making the list of supported auth methods an option, an treating it as "I only support >> no auth" when it's not there >> > I like this idea. A side effect of this approach is that we move another variable-length field to the back of the request, further simplifying parsing. >> - Out of curiosity, what specific use case are you using this protocol for? >> > We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg. Thanks! This is cool work. David Schinazi --Boundary_(ID_Bw0EzP0mIu1ImGKLMfO/7A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
Hi Vlad,

Responses inline.

On Jun 30, 2017, at 06:56, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro> wrote:

Hey David,

Thanks for the kind words. I'll address your questions inline:

On 6/29/2017 9:09 PM, David Schinazi wrote:
Hi Vladimir,

Thanks for writing this up, I agree SOCKS needs to be modernized and I think your draft
has a lot of good ideas. A few questions:

- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of the initial data offset.
The server can pull enough data for the upstream TCP SYN from its initial window
and leave the rest of the SOCKSv6 initial data there for later, instead of resending it twice.

The main idea is to let the client send some data before running the authentication protocol. The initial data offset gives the server a carte blanche as to how much of the initial data it buffers while waiting for the client to authenticate. (It still must read all of it from the TCP stream before getting to the part where the client proves its credentials.) Were it not for the authentication phase, these fields would indeed be useless.

[DS] That makes more sense, thanks!
What's the benefit of sending the idempotent data before auth? The proxy's not going to send it out
until it has received the last client -> proxy auth message so we may as well send the data right after that?
(That said I'm not very familiar with GSSAPI or the non-standard auth methods 3-8 so I could be missing something)

- Does it make sense to keep sending the version number over the wire?
Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port number)
and there is no way for a SOCKSv5 server to reply "I don't speak SOCKSv6".
I'm not sure I see the value of a minor version either, as there's still plenty of room
for major versions 7-255.

I think version numbers still make sense. When presented with a SOCKSv6 request, a v5 proxy must at least know that the client is speaking some other protocol. I will add a way for the proxy to signal that it doesn't speak SOCKSv7+ in the next version of the draft. Version numbers in operation replies don't make sense; I'll remove those. As for minor versions, they might indeed be overkill, given that v6 is extensible via options.

[DS] Wouldn't it be simpler to have IANA allocate a new port number though?
One byte isn't a huge win but it does make implementations simpler.

- Instead of having a command code enum with 3 values and a TFO enum with 2 values,
could we instead add a CONNECT_WITH_TFO command code to save a byte?
We could even take that one step further and also merge in the address type enum.

This is certainly worth considering. Alternatively, we could use a bit field: 2-3 bits for the command code, one bit for TFO, 2 for address type etc. Otherwise, we might end up with too many command codes (connect/bind x TFO x address type x whatever else we want to cram in).

[DS] A bit field can be very useful, but not when some combinations are not allowed.
For example having both TFO and UDP does not make sense. It does make sense for
TCP/UDP/TFO vs IPv4/IPv6/hostname though.

- One pain point I had when implementing SOCKSv5 was the fact that the port number
was after the address which meant that it moved, would it make sense to place it before
the variable length address field to simplify and optimize parsing?

I don't see why not.
- Could we make the client supported auth methods optional?
Since the client is sending tentative auth proposals as options, one could imagine
making the list of supported auth methods an option, an treating it as "I only support
no auth" when it's not there

I like this idea. A side effect of this approach is that we move another variable-length field to the back of the request, further simplifying parsing.
- Out of curiosity, what specific use case are you using this protocol for?

We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg.

Thanks! This is cool work.

David Schinazi
--Boundary_(ID_Bw0EzP0mIu1ImGKLMfO/7A)-- From nobody Fri Jun 30 14:37:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0571E12EA97 for ; Fri, 30 Jun 2017 14:37:17 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vQxSS_CARwUD for ; Fri, 30 Jun 2017 14:37:14 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id BA447129B8D for ; Fri, 30 Jun 2017 14:37:13 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AT4qiCxC5iot9rGjl/PulUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPT8pMbcNUDSrc9gkEXOFd2CrakV1KyO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhjexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRttfWTJPAo28?= =?us-ascii?q?bIUBAeQOMulaoIbhvFYBtweyCBO2Ce/zxDJFhnn71rA63eQ7FgHG2RQtEN0KsH?= =?us-ascii?q?vOsdr1NaISUeGvzKLV1DvDa+9W1inn54jObxAqvPaBXax0ccXL1EYvFgbFjlSK?= =?us-ascii?q?qYD/ODOV0vgNvHaB4OpmSOKikHIoqxprrji328cjkZPFhpgSyl3d8yhy3YU7Jc?= =?us-ascii?q?WgRUJmbtOoDYFcuiKaOodsXM8uXWNltDw0x7EevZO2fDIGxZYmyhLFdvCLbYuF?= =?us-ascii?q?7gj9WOqNPDt1gm9udqiliBao60egz/XxVsyz0FlXsCVIisLMtnUR1xzL7ciHV+?= =?us-ascii?q?d98l+h2TmR0wDT7flJIV4xlaXBKp4hxqQ8mYYIsUjZBi/2hV75gLWMdkUj4uSo?= =?us-ascii?q?6uLnbav6ppKEKoN5hRzyPr4tl8G/G+g0LBYCUmqB9emyzLHj+Ff2QLROjv04iK?= =?us-ascii?q?nZt5XaKNwFpq69GQBaz4cj6xO+Dze8ytgYmn0HLE5bdx2diYjpJkrDL+zjDful?= =?us-ascii?q?m1SsjSxky+rcPr3mGpnNNGTMkK/9fbZh7E5R0Bc8zctD6JJUC7EBJuj8W07wtN?= =?us-ascii?q?HDFBA5KxS0w+L5B9lnyoweXmePCLeDMKzOqV+I+v4vI+6UaYEWvjb9N+Ep6OT0?= =?us-ascii?q?jXAng1AQZqip0oULaHC2BPhmJF+ZYXW/yusGREsDoAsyBNfhiFyEWCxSLyK+RK?= =?us-ascii?q?k85zcyGoOOBJ/bQo3ri7uEinSVBJpTM15CA1yNFHbyP6KAR/oFbj/adtFlmzAF?= =?us-ascii?q?ULm7DYglyRynshLSwKEhNvfevDcf48GwnONp7vHewElhvQd/CN6QhiTUFzl5?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BBBwCBw1ZZ/wPjVY1cHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhBEDgQuOeJB4mAyGHAKDcAEBAQEBAQEBAgFqKIIzJAGCQQEFJ1I?= =?us-ascii?q?QCw4KJwdGEQYNBgIBARqKFbNfOimLKAEBAQcBAQEBASODJ4NMgWErgnmEVIYKB?= =?us-ascii?q?YlZh3GFW4dVgiCTaokWI4ZVlSsCV4EKMSGBAYUTHIFpc4ZrB4I4AQEB?= X-IPAS-Result: =?us-ascii?q?A2BBBwCBw1ZZ/wPjVY1cHAEBBAEBCgEBFwEBBAEBCgEBhBE?= =?us-ascii?q?DgQuOeJB4mAyGHAKDcAEBAQEBAQEBAgFqKIIzJAGCQQEFJ1IQCw4KJwdGEQYNB?= =?us-ascii?q?gIBARqKFbNfOimLKAEBAQcBAQEBASODJ4NMgWErgnmEVIYKBYlZh3GFW4dVgiC?= =?us-ascii?q?TaokWI4ZVlSsCV4EKMSGBAYUTHIFpc4ZrB4I4AQEB?= X-IronPort-AV: E=Sophos;i="5.40,288,1496091600"; d="scan'208,217";a="865241" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 01 Jul 2017 00:37:11 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 8E3FB1A601AC; Sat, 1 Jul 2017 00:37:11 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JWlo6lEb_QyI; Sat, 1 Jul 2017 00:37:11 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id 6A88C1A601B7; Sat, 1 Jul 2017 00:37:11 +0300 (EEST) Received: from [192.168.1.70] (unknown [95.76.128.201]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 4DF5E1A601AC; Sat, 1 Jul 2017 00:37:11 +0300 (EEST) To: David Schinazi Cc: Int-area@ietf.org References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> <004b4557-a926-9128-d3cf-0b3f41bef56e@cs.pub.ro> From: Vladimir Olteanu Message-ID: <3f975b41-78b0-9f50-6c46-cc8e30007f34@cs.pub.ro> Date: Sat, 1 Jul 2017 00:37:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A04A73870DDAC7471F049954" Content-Language: en-US Archived-At: Subject: Re: [Int-area] SOCKS 6 Draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:37:17 -0000 This is a multi-part message in MIME format. --------------A04A73870DDAC7471F049954 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi David, I've also inlined my responses. On 06/30/2017 09:08 PM, David Schinazi wrote: > Hi Vlad, > > Responses inline. > >> On Jun 30, 2017, at 06:56, Vladimir Olteanu >> > wrote: >> >> Hey David, >> >> Thanks for the kind words. I'll address your questions inline: >> >> On 6/29/2017 9:09 PM, David Schinazi wrote: >>> Hi Vladimir, >>> >>> Thanks for writing this up, I agree SOCKS needs to be modernized and >>> I think your draft >>> has a lot of good ideas. A few questions: >>> >>> - Why do you mimic the TFO semantics so closely? >>> Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning >>> of the initial data offset. >>> The server can pull enough data for the upstream TCP SYN from its >>> initial window >>> and leave the rest of the SOCKSv6 initial data there for later, >>> instead of resending it twice. >>> >> The main idea is to let the client send some data before running the >> authentication protocol. The initial data offset gives the server a >> carte blanche as to how much of the initial data it buffers while >> waiting for the client to authenticate. (It still must read all of it >> from the TCP stream before getting to the part where the client >> proves its credentials.) Were it not for the authentication phase, >> these fields would indeed be useless. > > [DS] That makes more sense, thanks! > What's the benefit of sending the idempotent data before auth? The > proxy's not going to send it out > until it has received the last client -> proxy auth message so we may > as well send the data right after that? > (That said I'm not very familiar with GSSAPI or the non-standard auth > methods 3-8 so I could be missing something) > The core issue is that the client can start sending regular data only when it is sure that the server won't ask for more authentication information. If 0-RTT authentication is successful, the proxy can open the socket right after the request, but the client has to wait 1 RTT before finding out if it must go through the slow authentication process or not. >>> - Does it make sense to keep sending the version number over the wire? >>> Proxy protocols need to be provisioned out of band (e.g. SOCKS vs >>> HTTP, port number) >>> and there is no way for a SOCKSv5 server to reply "I don't speak >>> SOCKSv6". >>> I'm not sure I see the value of a minor version either, as there's >>> still plenty of room >>> for major versions 7-255. >>> >> I think version numbers still make sense. When presented with a >> SOCKSv6 request, a v5 proxy must at least know that the client is >> speaking some other protocol. I will add a way for the proxy to >> signal that it doesn't speak SOCKSv7+ in the next version of the >> draft. Version numbers in operation replies don't make sense; I'll >> remove those. As for minor versions, they might indeed be overkill, >> given that v6 is extensible via options. > > [DS] Wouldn't it be simpler to have IANA allocate a new port number > though? > One byte isn't a huge win but it does make implementations simpler. > The version byte helps with misconfiguration issues. Imagine what would happen if the client and the proxy were to speak different versions without either of them realizing. As for the amendment to the draft, it won't really complicate matters. It will consist of the proxy saying "but I speak version 6" and the client closing the connection. >>> - Instead of having a command code enum with 3 values and a TFO enum >>> with 2 values, >>> could we instead add a CONNECT_WITH_TFO command code to save a byte? >>> We could even take that one step further and also merge in the >>> address type enum. >>> >> This is certainly worth considering. Alternatively, we could use a >> bit field: 2-3 bits for the command code, one bit for TFO, 2 for >> address type etc. Otherwise, we might end up with too many command >> codes (connect/bind x TFO x address type x whatever else we want to >> cram in). > > [DS] A bit field can be very useful, but not when some combinations > are not allowed. > For example having both TFO and UDP does not make sense. It does make > sense for > TCP/UDP/TFO vs IPv4/IPv6/hostname though. > I don't really see a problem with invalid bit group combinations. There are other field combinations that also don't make sense (e.g. UDP and initial data > 0). >>> - One pain point I had when implementing SOCKSv5 was the fact that >>> the port number >>> was after the address which meant that it moved, would it make sense >>> to place it before >>> the variable length address field to simplify and optimize parsing? >>> >> I don't see why not. >>> - Could we make the client supported auth methods optional? >>> Since the client is sending tentative auth proposals as options, one >>> could imagine >>> making the list of supported auth methods an option, an treating it >>> as "I only support >>> no auth" when it's not there >>> >> I like this idea. A side effect of this approach is that we move >> another variable-length field to the back of the request, further >> simplifying parsing. >>> - Out of curiosity, what specific use case are you using this >>> protocol for? >>> >> We are looking into using MPTCP on mobile devices to "bind" 4G/LTE >> and WiFi. Mobile data networks have high latency, hence the drive to >> shave off as many RTTs as possible and to take advantage of TFO, at >> least on the client-proxy leg. > Cheers, Vlad --------------A04A73870DDAC7471F049954 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi David,

I've also inlined my responses.


On 06/30/2017 09:08 PM, David Schinazi wrote:
Hi Vlad,

Responses inline.

On Jun 30, 2017, at 06:56, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro> wrote:

Hey David,

Thanks for the kind words. I'll address your questions inline:

On 6/29/2017 9:09 PM, David Schinazi wrote:
Hi Vladimir,

Thanks for writing this up, I agree SOCKS needs to be modernized and I think your draft
has a lot of good ideas. A few questions:

- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of the initial data offset.
The server can pull enough data for the upstream TCP SYN from its initial window
and leave the rest of the SOCKSv6 initial data there for later, instead of resending it twice.

The main idea is to let the client send some data before running the authentication protocol. The initial data offset gives the server a carte blanche as to how much of the initial data it buffers while waiting for the client to authenticate. (It still must read all of it from the TCP stream before getting to the part where the client proves its credentials.) Were it not for the authentication phase, these fields would indeed be useless.

[DS] That makes more sense, thanks!
What's the benefit of sending the idempotent data before auth? The proxy's not going to send it out
until it has received the last client -> proxy auth message so we may as well send the data right after that?
(That said I'm not very familiar with GSSAPI or the non-standard auth methods 3-8 so I could be missing something)

The core issue is that the client can start sending regular data only when it is sure that the server won't ask for more authentication information. If 0-RTT authentication is successful, the proxy can open the socket right after the request, but the client has to wait 1 RTT before finding out if it must go through the slow authentication process or not.
- Does it make sense to keep sending the version number over the wire?
Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port number)
and there is no way for a SOCKSv5 server to reply "I don't speak SOCKSv6".
I'm not sure I see the value of a minor version either, as there's still plenty of room
for major versions 7-255.

I think version numbers still make sense. When presented with a SOCKSv6 request, a v5 proxy must at least know that the client is speaking some other protocol. I will add a way for the proxy to signal that it doesn't speak SOCKSv7+ in the next version of the draft. Version numbers in operation replies don't make sense; I'll remove those. As for minor versions, they might indeed be overkill, given that v6 is extensible via options.

[DS] Wouldn't it be simpler to have IANA allocate a new port number though?
One byte isn't a huge win but it does make implementations simpler.

The version byte helps with misconfiguration issues. Imagine what would happen if the client and the proxy were to speak different versions without either of them realizing. As for the amendment to the draft, it won't really complicate matters. It will consist of the proxy saying "but I speak version 6" and the client closing the connection.
- Instead of having a command code enum with 3 values and a TFO enum with 2 values,
could we instead add a CONNECT_WITH_TFO command code to save a byte?
We could even take that one step further and also merge in the address type enum.

This is certainly worth considering. Alternatively, we could use a bit field: 2-3 bits for the command code, one bit for TFO, 2 for address type etc. Otherwise, we might end up with too many command codes (connect/bind x TFO x address type x whatever else we want to cram in).

[DS] A bit field can be very useful, but not when some combinations are not allowed.
For example having both TFO and UDP does not make sense. It does make sense for
TCP/UDP/TFO vs IPv4/IPv6/hostname though.

I don't really see a problem with invalid bit group combinations. There are other field combinations that also don't make sense (e.g. UDP and initial data > 0).
- One pain point I had when implementing SOCKSv5 was the fact that the port number
was after the address which meant that it moved, would it make sense to place it before
the variable length address field to simplify and optimize parsing?

I don't see why not.
- Could we make the client supported auth methods optional?
Since the client is sending tentative auth proposals as options, one could imagine
making the list of supported auth methods an option, an treating it as "I only support
no auth" when it's not there

I like this idea. A side effect of this approach is that we move another variable-length field to the back of the request, further simplifying parsing.
- Out of curiosity, what specific use case are you using this protocol for?

We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. Mobile data networks have high latency, hence the drive to shave off as many RTTs as possible and to take advantage of TFO, at least on the client-proxy leg.

Cheers,
Vlad
--------------A04A73870DDAC7471F049954--