From nobody Tue Oct 4 12:39:01 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3E5129442; Tue, 4 Oct 2016 12:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WgMgfoNOKN5c; Tue, 4 Oct 2016 12:38:59 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBDC129406; Tue, 4 Oct 2016 12:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=719; q=dns/txt; s=iport; t=1475609939; x=1476819539; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xDg7b85K34JYt6bgn7eN85JEzyrBEucYSm8WaqEfYio=; b=b6Vw/gMXQJwsyBAwL18TVCmeuU/0tQmK8hCfzHHAY0uHPCdsnEwYTxu8 Ks8DFLaGhL+sp89Y+DODW3D0f7EPCamGTLHfXPIVNKrUszGFkoWiuk0Rt SLNDStim9BLfiwrCR7ilm1+uKefu4/cUIHrl+MaCQFBVTNWvlKrhpPn8Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAgDzBPRX/xbLJq1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgz0BAQEBAXUqUo0yqyOCByaFeAKCKRQBAgEBAQEBAQFeJ4RiAQEEIxU/Egs?= =?us-ascii?q?aAiYCAlcHDAgBAYhJDrE4jHcBAQEBAQUBAQEBASKBB4U1gX2CWIdLgloBBJl5h?= =?us-ascii?q?ieJTYFuToQYgxSGCokgh04eNkAFB4RVPDQBh1gBAQE?= X-IronPort-AV: E=Sophos;i="5.31,444,1473120000"; d="scan'208";a="648980802" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2016 19:38:55 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u94Jct9v018539; Tue, 4 Oct 2016 19:38:55 GMT To: internet-drafts@ietf.org, radext@ietf.org, alissa@cooperw.in, Kathleen.Moriarty.ietf@gmail.com, ietf@kuehlewind.net, stephen.farrell@cs.tcd.ie References: <147510954303.16660.6144323548035499742.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <8b4e7bf3-cd71-31a4-6b9d-13d797071f4b@cisco.com> Date: Tue, 4 Oct 2016 21:38:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147510954303.16660.6144323548035499742.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 19:39:00 -0000 Dear authors, Thanks for the new version. Please let me know how my DISCUSS is resolved. Regards, Benoit > A new version (-12) has been submitted for draft-ietf-radext-ip-port-radius-ext: > https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-12.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-12 > > 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. > > IETF Secretariat. > > . > From nobody Tue Oct 4 23:15:33 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF612940E; Tue, 4 Oct 2016 23:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 u_rGvX01rzfo; Tue, 4 Oct 2016 23:15:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D03C126FDC; Tue, 4 Oct 2016 23:15:29 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id D1BE8C128E; Wed, 5 Oct 2016 08:15:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 9AF2D20068; Wed, 5 Oct 2016 08:15:27 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 08:15:22 +0200 From: To: Benoit Claise , The IESG Thread-Topic: Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSD0xgQjdq65EuZ0GgooanfeDea6CZdbtg Date: Wed, 5 Oct 2016 06:15:20 +0000 Message-ID: <0ac7f8a6-58aa-403a-921a-f4385c95eec5@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> In-Reply-To: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Tim.Chown@jisc.ac.uk" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 06:15:32 -0000 SGkgQmVub2l0LCANCg0KUGxlYXNlIHNlZSBpbmxpbmUgaG93IHRoZSB1cGRhdGVkIHZlcnNpb24g dGFrZXMgaW50byBhY2NvdW50IHlvdXIgcmV2aWV3Lg0KIA0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJlbm9pdCBDbGFpc2UgW21haWx0bzpi Y2xhaXNlQGNpc2NvLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAxNSBzZXB0ZW1icmUgMjAxNiAx NDoyNg0KPiDDgMKgOiBUaGUgSUVTRw0KPiBDY8KgOiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0 LXJhZGl1cy1leHRAaWV0Zi5vcmc7IHJhZGV4dEBpZXRmLm9yZzsNCj4gcmFkZXh0LWNoYWlyc0Bp ZXRmLm9yZzsgTU9SQU5EIExpb25lbCBJTVQvT0xOOyByYWRleHRAaWV0Zi5vcmc7DQo+IFRpbS5D aG93bkBqaXNjLmFjLnVrDQo+IE9iamV0wqA6IEJlbm9pdCBDbGFpc2UncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0NCj4gMTE6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+IA0KPiBCZW5vaXQgQ2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1 cy1leHQtMTE6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0K PiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQvDQo+ IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiANCj4gSSdtIGxhdGUgZm9yIG15IHJldmlldyBoZXJlLiBJZiBzb21lIHBvaW50cyBpbiBteSBE SVNDVVNTL0NPTU1FTlQgaGF2ZQ0KPiBiZWVuIGRpc2N1c3NlZCBhbHJlYWR5IGxldCBtZSBrbm93 Lg0KPiANCj4gSSdsbCBmbGFnIHRoaXMgYXMgYSBESVNDVVNTIHRvIGZvbGxvdyB1cCBvbiB0aGUg SVBGSVggaXNzdWVzLg0KPiBGaXJzdCBvZiwgSSBhcHBsYXVzZSB0aGUgYXR0ZW1wdCB0byByZXVz ZS9tYXAvY29tYmluZSBkYXRhIG1vZGVscyAoSVBGSVgNCj4gaW5mb3JtYXRpb24gZWxlbWVudCBh bmQgUkFESVVTIGF0dHJpYnV0ZSkuDQo+IA0KW01lZF0gVGhhbmsgeW91Lg0KDQo+IE5vdywgdGhl cmUgYXJlIGEgY291cGxlIG9mIGlzc3Vlcy4NCj4gVGhlIGZpcnN0IHNldCBvZiBpc3N1ZXMgaGFz IGJlZW4gc2VudCB2aWEgdGhlIElQRklYIGV4cGVydHMsIGNvcGllZCBoZXJlDQo+IGZvciB0cmFj a2luZyBwdXJwb3Nlcy4NCj4gDQo+ICAgICBEZWFyIEF1dGhvcnMsDQo+IA0KPiAgICAgVGhlIGV4 cGVydHMgZm9yIHRoZSBJUEZJWCBJRSByZWdpc3RyeSBoYXZlIHJldHVybmVkIHRoZSBmb2xsb3dp bmcNCj4gICAgIHJldmlldzoNCj4gDQo+ICAgICBJbiBnZW5lcmFsLCB0aGUgSW5mb3JtYXRpb24g RWxlbWVudHMgaW4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC0NCj4gICAgIHJhZGl1cy1leHQg YXJlIHNvIHVuZGVyc3BlY2lmaWVkIGFzIHRvIGJlIHVuaW1wbGVtZW50YWJsZS4gVGhleQ0KPiBz aG91bGQNCj4gICAgIG5vdCBiZSBhZGRlZCB0byB0aGUgcmVnaXN0cnkgaW4gdGhlaXIgcHJlc2Vu dCBmb3JtLiBUaGUgYXV0aG9ycyBhcmUNCj4gICAgIGFkdmlzZWQgdG8gcmVhZCBSRkMgNzAxMywg ZXNwZWNpYWxseSBTZWN0aW9uIDQsIHdoaWNoIHByb3ZpZGVzDQo+IHVzZWZ1bA0KPiAgICAgaW5m b3JtYXRpb24gb24gZGVmaW5pbmcgSW5mb3JtYXRpb24gRWxlbWVudHMuIFNwZWNpZmljYWxseToN Cj4gDQo+ICAgICBUaGUgSW5mb3JtYXRpb24gRWxlbWVudCB0cmFuc3BvcnRUeXBlIGlzIHVuZGVy c3BlY2lmaWVkOiAoYSkgSQ0KPiBwcmVzdW1lDQo+ICAgICB0aGlzIGlzIGluIHJlZmVyZW5jZSB0 byBzb3VyY2VUcmFuc3BvcnRQb3J0IGFuZA0KPiAgICAgZGVzdGluYXRpb25UcmFuc3BvcnRQb3J0 LCBidXQgdGhlIGRlc2NyaXB0aW9uIG11c3Qgc2F5IHRoaXMgaWYgaXQgaXMNCj4gICAgIHRoZSBj YXNlOyAoYikgSXQncyBub3QgY2xlYXIgYXQgYWxsIGZyb20gdGhlIGRlc2NyaXB0aW9uIGluIHdo YXQNCj4gICAgIGNvbnRleHQgdGhpcyBkaXN0aW5jdGlvbiBpcyB1c2VmdWw7IChjKSBXaGF0J3Mg YW4gSUNNUCBpZGVudGlmaWVyPw0KPiANCj4gICAgIEluIGFkZGl0aW9uLCB0aGUgZGVzY3JpcHRp b24gb2YgdHJhbnNwb3J0VHlwZSBhcHBlYXJzIHRvIGNyZWF0ZSBhDQo+ICAgICB0YWJsZSB3aGlj aCBzaG91bGQgcHJvYmFibHkgYmUgaGFuZGxlZCBhcyBhIHN1YnJlZ2lzdHJ5LiBTZWUgU2VlDQo+ ICAgICBSRkM3MDEzIHNlY3Rpb24gNC43LiBmb3IgYWR2aWNlIG9uIHRoZSBjcmVhdGlvbiBvZiB0 YWJsZXMgd2l0aG91dA0KPiAgICAgc3VicmVnaXN0cmllcyAoaW4gc2hvcnQsICJkb24ndCIuKQ0K PiANCg0KW01lZF0gVGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgd2FzIHVwZGF0ZWQu IEJhc2ljYWxseTogDQoqIENsYXJpZnkgdGhlIHRleHQNCiogV2UgZG9uJ3QgaGF2ZSBhbnkgbW9y ZSBzdWItcmVnaXN0cmllcyBiZWNhdXNlIHdlIGFyZSByZWx5aW5nIG9uIHRoZSBJQU5BIFByb3Rv Y29sIE51bWJlcnMNCg0KDQo+ICAgICBUaGUgSW5mb3JtYXRpb24gRWxlbWVudCBuYXRUcmFuc3Bv cnRMaW1pdCBoYXMgYW4gaW5hcHByb3ByaWF0ZSBuYW1lOw0KPiAgICAgaXQgZG9lcyBub3QgZGVz Y3JpYmUgdGhhdCB3aGljaCBpdCAocHJlc3VtYWJseSkgaXMgc3VwcG9zZWQgdG8NCj4gICAgIHJl cHJlc2VudCAoc2VlIFJGQyA3MDEzIHNlY3Rpb24gNC4xKS4gSW4gYWRkaXRpb24sIGl0IGlzDQo+ ICAgICB1bmRlcnNwZWNpZmllZC4gSXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgZnJvbSB0 aGUgZGVzY3JpcHRpb24uDQoNCltNZWRdIFRoZSBhdHRyaWJ1dGUgaXMgcmVuYW1lZCB0byAic291 cmNlVHJhbnNwb3J0UG9ydHNMaW1pdCIgKyB0ZXh0IHVwZGF0ZWQgdG8gY2xhcmlmeSB0aGUgdXNl IG9mIHRoZSBhdHRyaWJ1dGUuDQoNCj4gSXMNCj4gICAgIHRoZSBmaWVsZCBJUHY0IHNwZWNpZmlj LCBvciBpcyBJUHY2IHN1cHBvcnRlZCBhcyB3ZWxsPyAoSWYgbm90LCB3aHkNCj4gICAgIG5vdD8p DQo+IA0KDQpbTWVkXSBJdCBpcyB2YWxpZCBmb3IgYm90aCBJUHY0IGFuZCBJUHY2LiBUaGUgdGV4 dCB3YXMgdXBkYXRlZCB0byBjbGFyaWZ5IHRoYXQgcG9pbnQuDQoNCj4gICAgIFRoZSBJbmZvcm1h dGlvbiBFbGVtZW50IGxvY2FsSUQgaGFzIGFuIGluYXBwcm9wcmlhdGUgbmFtZTsgaXQgaXMgZmFy DQo+ICAgICB0b28gZ2VuZXJhbCAoc2VlIFJGQyA3MDEzIHNlY3Rpb24gNC4xKS4gSXQgdXNlcyBh biBpbmFwcHJvcHJpYXRlDQo+ICAgICBhYnN0cmFjdCBkYXRhIHR5cGUgKGFkZHJlc3NlcyBzaG91 bGQgbmV2ZXIgYmUgcmVwcmVzZW50ZWQgYXMgVVRGLTgNCj4gICAgIHN0cmluZ3MgaW4gSVBGSVgs IHNlZSBSRkMgNzAxMyBzZWN0aW9uIDQuMikuIEl0IGlzIHVuZGVyc3BlY2lmaWVkIGFzDQo+ICAg ICB3ZWxsIGFzIHBvb3JseSBkZXNpZ25lZC4gV2l0aG91dCB0aGUgYWJpbGl0eSB0byBkaXNhbWJp Z3VhdGUgdGhlDQo+IHR5cGUNCj4gICAgIG9mIGluZm9ybWF0aW9uIGluIHRoZSBmaWVsZCwgdGhp cyBpcyBub3QgYSB1c2VmdWwgSW5mb3JtYXRpb24NCj4gRWxlbWVudC4NCj4gICAgIFdpdGhvdXQg YSBjb21wbGV0ZSBlbnVtZXJhdGlvbiBvZiBwb3NzaWJsZSB0eXBlcyAobi5iLiAnZXRjLicgaW4g dGhlDQo+ICAgICBkZXNjcmlwdGlvbiksIGl0IGlzIG5vdCBhIHVzZWZ1bCBJbmZvcm1hdGlvbiBF bGVtZW50LiBJdHMgcHVycG9zZSBpcw0KPiAgICAgdW5jbGVhciBmcm9tIGl0cyBkZXNjcmlwdGlv bjsgZnVydGhlciwgaXQgYXBwZWFycyB0byB2aW9sYXRlIHRoZQ0KPiAgICAgZm9sbG93aW5nIGd1 aWRhbmNlIGluIFJGQyA3MDEzIHNlY3Rpb24gNDogIlRoZSBJbmZvcm1hdGlvbiBFbGVtZW50DQo+ ICAgICBtdXN0IGJlIHVuaXF1ZSB3aXRoaW4gdGhlIHJlZ2lzdHJ5LCBhbmQgaXRzIGRlc2NyaXB0 aW9uIG11c3QNCj4gcmVwcmVzZW50DQo+ICAgICBhIHN1YnN0YW50aWFsbHkgZGlmZmVyZW50IG1l YW5pbmcgZnJvbSB0aGF0IG9mIGFueSBleGlzdGluZw0KPiAgICAgSW5mb3JtYXRpb24gRWxlbWVu dC4gQW4gZXhpc3RpbmcgSW5mb3JtYXRpb24gRWxlbWVudCB0aGF0IGNhbiBiZQ0KPiAgICAgcmV1 c2VkIGZvciBhIGdpdmVuIHB1cnBvc2Ugc2hvdWxkIGJlIHJldXNlZC4iDQo+IA0KDQpbTWVkXSBX ZSBtYWRlIHRoZSBmb2xsb3dpbmcgY2hhbmdlczogDQoqIFdlIGNoYW5nZWQgdGhlIFZhbHVlIGZp ZWxkIHRvIGJlIHN0aWxsIGEgInN0cmluZyIgYnV0IHBlciBkZWZpbml0aW9uIG9mIGlldGYtZHJh ZnQtcmFkZXh0LWRhdGF0eXBlIGFuZCBub3QgdG8gcHJvcG9zZSBhcyBhIG5ldyBJUEZJWCBJRS4N CiogV2UgYWRkZWQgYSBuZXcgdGV4dCB0byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhlIGF0dHJp YnV0ZTogDQoNCiAgIFRoZSBwcmltYXJ5IGlzc3VlIGFkZHJlc3NlZCBieSB0aGlzIFRMViBpcyB0 aGF0IHRoZXJlIGFyZSBDR04NCiAgIGRlcGxveW1lbnRzIHRoYXQgZG8gbm90IGRpc3Rpbmd1aXNo IGludGVybmFsIGhvc3RzIGJ5IHRoZWlyIGludGVybmFsDQogICBJUCBhZGRyZXNzIGFsb25lLCBi dXQgdXNlIGZ1cnRoZXIgaWRlbnRpZmllcnMgZm9yIHVuaXF1ZSBzdWJzY3JpYmVyDQogICBpZGVu dGlmaWNhdGlvbi4gIEZvciBleGFtcGxlLCB0aGlzIGlzIHRoZSBjYXNlIGlmIGEgQ0dOIHN1cHBv cnRzDQogICBvdmVybGFwcGluZyBwcml2YXRlIG9yIHNoYXJlZCBJUCBhZGRyZXNzIHNwYWNlcyAo cmVmZXIgdG8gW1JGQzE5MThdDQogICBhbmQgW1JGQzY1OThdKSBmb3IgaW50ZXJuYWwgaG9zdHMg b2YgZGlmZmVyZW50IHN1YnNjcmliZXJzLiAgSW4gc3VjaA0KICAgY2FzZXMsIGRpZmZlcmVudCBp bnRlcm5hbCBob3N0cyBhcmUgaWRlbnRpZmllZCBhbmQgbWFwcGVkIGF0IHRoZSBDR04NCiAgIGJ5 IHRoZWlyIElQIGFkZHJlc3MgYW5kL29yIGFub3RoZXIgaWRlbnRpZmllciwgZm9yIGV4YW1wbGUs IHRoZQ0KICAgaWRlbnRpZmllciBvZiBhIHR1bm5lbCBiZXR3ZWVuIHRoZSBDR04gYW5kIHRoZSBz dWJzY3JpYmVyLiAgSW4gdGhlc2UNCiAgIHNjZW5hcmlvcyAoYW5kIHNpbWlsYXIgb25lcyksIHRo ZSBpbnRlcm5hbCBJUCBhZGRyZXNzIGlzIG5vdA0KICAgc3VmZmljaWVudCB0byBkZW11bHRpcGxl eCBjb25uZWN0aW9ucyBmcm9tIGludGVybmFsIGhvc3RzLiAgQW4NCiAgIGFkZGl0aW9uYWwgaWRl bnRpZmllciBuZWVkcyB0byBiZSBwcmVzZW50IGluIHRoZSBJUC1Qb3J0LVJhbmdlDQogICBBdHRy aWJ1dGUgYW5kIElQLVBvcnQtRm9yd2FyZGluZy1NYXBwaW5nIEF0dHJpYnV0ZSBpbiBvcmRlciB0 bw0KICAgdW5pcXVlbHkgaWRlbnRpZnkgYW4gaW50ZXJuYWwgaG9zdC4gIFRoZSBJUC1Qb3J0LUxv Y2FsLUlkIFRMViBpcyB1c2VkDQogICB0byBjYXJyeSB0aGlzIGlkZW50aWZpZXIuDQoNCj4gSSBo YXZlIHNvbWUgbW9yZSBpc3N1ZXMgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3M6DQo+IC0gc2VjdGlv biAzLjIuNSwgYXMgYW4gZXhhbXBsZSwgY29udGFpbnMgYSBsaXN0IG9mIHNvdXJjZUlQdjZBZGRy ZXNzLiBJbg0KPiBJUEZJWCwgd2Ugd291bGQgZXhwb3J0IHRob3NlIGFzIGEgbGlzdCBbUkZDIDYz MTNdDQo+IERvZXMgdGhpcyBSQURJVVMgZG9jdW1lbnQgd2FudCB0byBvbmx5IHJldXNlIHRoZSBz ZW1hbnRpYyBvZiBpbmRpdmlkdWFsDQo+IElQRklYIGluZm9ybWF0aW9uIGVsZW1lbnQ/DQo+IEFu ZCBhbHNvIHRoZSBzZW1hbnRpYyBvZiBtdWx0aXBsZSBpbmZvcm1hdGlvbiBlbGVtZW50cyBbUkZD IDYzMTNdPw0KDQpbTWVkXSBUaGUgaW50ZW50IGlzIHRvIHJldXNlIHRoZSBzZW1hbnRpYyBvZiBp bmRpdmlkdWFsIElFcy4gVGhlIHJhdGlvbmFsZSBiYXNpY2FsbHkgd2FzIHRoYXQgSVBGSVggb2Zm ZXJzIGEgcmljaCBJRSByZWdpc3RyeSB0aGF0IGNhbiBiZSByZXVzZWQgaW4gb3VyIGNvbnRleHQu DQoNCj4gQW5kIGFsc28gdGhlIElQRklYIGVuY29kaW5nPyBGb3IgZXhhbXBsZSwgc29tZSBJUEZJ WCBmaWVsZHMgYXJlICJyaWdodA0KPiBqdXN0aWZpZWQiIChzb3VyY2VUcmFuc3BvcnRQb3J0KSwg d2hpbGUgc29tZSBvdGhlcnMgYXJlIG5vdCAobG9jYWxJRCkNCj4gVGhlIGRvY3VtZW50IHNob3Vs ZCBiZSBjbGVhci4NCg0KW01lZF0gbG9jYWxJZCBpcyBub3QgZGVmaW5lZCBhcyBhbiBJUEZJWCBh dHRyaWJ1dGUuDQoNCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IC0NCj4gDQo+ICAgIDEuICBJUC1Qb3J0LUxpbWl0LUluZm86IFRoaXMg YXR0cmlidXRlIG1heSBiZSBjYXJyaWVkIGluIFJBRElVUw0KPiAgICAgICAgQWNjZXNzLUFjY2Vw dCwgQWNjZXNzLVJlcXVlc3QsIEFjY291bnRpbmctUmVxdWVzdCBvciBDb0EtUmVxdWVzdA0KPiAg ICAgICAgcGFja2V0LiAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBhdHRyaWJ1dGUgaXMgdG8gbGltaXQg dGhlIHRvdGFsDQo+ICAgICAgICBudW1iZXIgb2YgVENQL1VEUCBwb3J0cyBhbmQvb3IgSUNNUCBp ZGVudGlmaWVycyBhbGxvY2F0ZWQgdG8gYQ0KPiAgICAgICAgdXNlciwgYXNzb2NpYXRlZCB3aXRo IG9uZSBvciBtb3JlIElQdjQgYWRkcmVzc2VzLg0KPiANCj4gSSBzZWUgIm1heSBiZSBjYXJyaWVk Ii4gQ291bGQgaXQgYmUgY2FycmllZCBpbiBvdGhlciBwYWNrZXRzIC4uLiB3YXMgbXkNCj4gZmly c3QgcXVlc3Rpb24uDQo+IEl0IHdhcyBub3QgY2xlYXIgKHVudGlsIEkgcmVhZCB0aGUgcmVzdCBv ZiB0aGUgZG9jdW1lbnQpIHRoYXQgaXQncyBhIG5vbg0KPiBjb21wdWxzb3J5IGF0dHJpYnV0ZSBv bmx5IGluDQo+IEFjY2Vzcy1BY2NlcHQsIEFjY2Vzcy1SZXF1ZXN0LCBBY2NvdW50aW5nLVJlcXVl c3Qgb3IgQ29BLVJlcXVlc3QNCj4gcGFja2V0cy4NCj4gUHJvcG9zYWw6DQo+ICAgIDEuICBJUC1Q b3J0LUxpbWl0LUluZm86IFRoZSBwdXJwb3NlIG9mIHRoaXMgYXR0cmlidXRlIGlzIHRvIGxpbWl0 IHRoZQ0KPiB0b3RhbA0KPiAgICAgICAgbnVtYmVyIG9mIFRDUC9VRFAgcG9ydHMgYW5kL29yIElD TVAgaWRlbnRpZmllcnMgYWxsb2NhdGVkIHRvIGENCj4gICAgICAgIHVzZXIsIGFzc29jaWF0ZWQg d2l0aCBvbmUgb3IgbW9yZSBJUHY0IGFkZHJlc3Nlcy4gVGhpcyBhdHRyaWJ1dGUNCj4gaXMNCj4g ICAgICAgIGNhcnJpZWQgaW4gUkFESVVTIEFjY2Vzcy1BY2NlcHQsIEFjY2Vzcy1SZXF1ZXN0LA0K PiBBY2NvdW50aW5nLVJlcXVlc3Qgb3INCj4gICAgICAgIENvQS1SZXF1ZXN0IHBhY2tldHMuDQoN CltNZWRdIFRoZSBpbml0aWFsIHdvcmRpbmcgaXMgY29ycmVjdC4gSXQgaXMgYWxpZ25lZCB3aXRo IHRoZSB0ZXh0IGluIFNlY3Rpb24gMy4xLjEuDQoNCj4gDQo+IFNhbWUgcmVtYXJrIGZvciB0aGUg b3RoZXIgdHdvIHBvaW50cyBiZWxvdy4NCj4gDQo+ICAyLiAgSVAtUG9ydC1SYW5nZTogVGhpcyBh dHRyaWJ1dGUgbWF5IGJlIGNhcnJpZWQgaW4gUkFESVVTDQo+ICAgICAgICBBY2NvdW50aW5nLVJl cXVlc3QgcGFja2V0LiAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBhdHRyaWJ1dGUgaXMgdG8NCj4gICAg ICAgIHJlcG9ydCBieSBhbiBhZGRyZXNzIHNoYXJpbmcgZGV2aWNlIChlLmcuLCBhIENHTikgdG8g dGhlIFJBRElVUw0KPiAgICAgICAgc2VydmVyIHRoZSByYW5nZSBvZiBUQ1AvVURQIHBvcnRzIGFu ZC9vciBJQ01QIGlkZW50aWZpZXJzIHRoYXQNCj4gICAgICAgIGhhdmUgYmVlbiBhbGxvY2F0ZWQg b3IgZGVhbGxvY2F0ZWQgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4gSVB2NA0KPiAgICAgICAgYWRk cmVzcyBmb3IgYSB1c2VyLg0KPiANCj4gICAgMy4gIElQLVBvcnQtRm9yd2FyZGluZy1NYXA6IFRo aXMgYXR0cmlidXRlIG1heSBiZSBjYXJyaWVkIGluIFJBRElVUw0KPiAgICAgICAgQWNjZXNzLUFj Y2VwdCwgQWNjZXNzLVJlcXVlc3QsIEFjY291bnRpbmctUmVxdWVzdCBvciBDb0EtUmVxdWVzdA0K PiAgICAgICAgcGFja2V0LiAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBhdHRyaWJ1dGUgaXMgdG8gc3Bl Y2lmeSBob3cgYW4gSVB2NA0KPiAgICAgICAgYWRkcmVzcyBhbmQgYSBUQ1AvIFVEUCBwb3J0IChv ciBhbiBJQ01QIGlkZW50aWZpZXIpIGlzIG1hcHBlZCB0bw0KPiAgICAgICAgYW5vdGhlciBJUHY0 IGFkZHJlc3MgYW5kIGEgVENQL1VEUCBwb3J0IChvciBhbiBJQ01QIGlkZW50aWZpZXIpLg0KPiAN Cj4gLQ0KPiANCj4gICAgMS4gIElQLVBvcnQtTGltaXQtSW5mbzogVGhpcyBhdHRyaWJ1dGUgbWF5 IGJlIGNhcnJpZWQgaW4gUkFESVVTDQo+ICAgICAgICBBY2Nlc3MtQWNjZXB0LCBBY2Nlc3MtUmVx dWVzdCwgQWNjb3VudGluZy1SZXF1ZXN0IG9yIENvQS1SZXF1ZXN0DQo+ICAgICAgICBwYWNrZXQu ICBUaGUgcHVycG9zZSBvZiB0aGlzIGF0dHJpYnV0ZSBpcyB0byBsaW1pdCB0aGUgdG90YWwNCj4g ICAgICAgIG51bWJlciBvZiBUQ1AvVURQIHBvcnRzIGFuZC9vciBJQ01QIGlkZW50aWZpZXJzIGFs bG9jYXRlZCB0byBhDQo+ICAgICAgICB1c2VyLCBhc3NvY2lhdGVkIHdpdGggb25lIG9yIG1vcmUg SVB2NCBhZGRyZXNzZXMuDQo+IA0KPiANCj4gT25seSBmb3IgVENQL1VEUD8gSSBiZWxpZXZlIE1p cmphIGhhZCB0aGUgc2FtZSBxdWVzdGlvbi4NCg0KW01lZF0gV2UgdXBkYXRlZCB0aGUgdGV4dCBz byB0aGF0IGFueSB0cmFuc3BvcnQgcHJvdG9jb2wgY2FuIGJlIHVzZWQuIFRoZSBuZXcgdGV4dCBz YXlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIFRoZSBmb3JtYXQgb2YgSVAtUG9ydC1UeXBlIFRMViBp cyBzaG93biBpbiBGaWd1cmUgNC4gIFRoaXMgYXR0cmlidXRlDQogICBjYXJyaWVzIHRoZSBJUCB0 cmFuc3BvcnQgcHJvdG9jb2wgbnVtYmVyIGRlZmluZWQgYnkgSUFOQSAocmVmZXIgdG8NCiAgIFtQ cm90b2NvbE51bWJlcnNdKQ0KDQo+IA0KPiAtIFNlY3Rpb24gMi4gVGVybWlub2xvZ3kuDQo+IFR5 cGljYWxseSwgeW91IHdhbnQgdG8gaGF2ZSB0aGF0IG5vdGUgYXQgdGhlIGJlZ2lubmluZzoNCj4g DQo+ICAgIE5vdGUgdGhhdCB0aGUgZGVmaW5pdGlvbnMgb2YgImludGVybmFsIElQIGFkZHJlc3Mi LCAiaW50ZXJuYWwgcG9ydCIsDQo+ICAgICJpbnRlcm5hbCByZWFsbSIsICJleHRlcm5hbCBJUCBh ZGRyZXNzIiwgImV4dGVybmFsIHBvcnQiLCAiZXh0ZXJuYWwNCj4gICAgcmVhbG0iLCBhbmQgIm1h cHBpbmciIGFyZSB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFBvcnQgQ29udHJvbA0KPiAgICBQcm90 b2NvbCAoUENQKSBbUkZDNjg4N10sIGFuZCB0aGUgQ29tbW9uIFJlcXVpcmVtZW50cyBmb3IgQ2Fy cmllci0NCj4gICAgR3JhZGUgTkFUcyAoQ0dOcykgW1JGQzY4ODhdLg0KPiANCj4gSWYgSSBrbm93 IG9mIFJGQzY4ODcgYW5kIFJGQzY4ODgsIEkgZG9uJ3QgcmVhZCB0aGUgZGVmaW5pdGlvbnMuDQoN CltNZWRdIE9LLg0KDQo+IA0KPiAtIFNlY3Rpb24gMy4xLjMNCj4gDQo+ICAgIFRoaXMgYXR0cmli dXRlIGlzIG9mIHR5cGUgIlRMViIgYXMgZGVmaW5lZCBpbiB0aGUgUkFESVVTIFByb3RvY29sDQo+ ICAgIEV4dGVuc2lvbnMgW1JGQzY5MjldLiAgSXQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzdWIt YXR0cmlidXRlczoNCj4gDQo+ICAgIC4uLg0KPiANCj4gICAgbyAgZWl0aGVyIGFuIElQLVBvcnQt SW50LUlQdjQtQWRkciBUTFYgKHNlZSBTZWN0aW9uIDMuMi40KSBvciBhbiBJUC0NCj4gICAgICAg UG9ydC1Mb2NhbC1JZCBUTFYgKHNlZSBTZWN0aW9uIDMuMi4xMSksDQo+IA0KPiAgICBvICBlaXRo ZXIgYW4gSVAtUG9ydC1JbnQtSVB2Ni1BZGRyIFRMViAoc2VlIFNlY3Rpb24gMy4yLjUpIG9yIGFu IElQLQ0KPiAgICAgICBQb3J0LUxvY2FsLUlkIFRMViAoc2VlIFNlY3Rpb24gMy4yLjExKSwNCj4g DQo+IERlcGVuZGluZyBvbiB0aGUgSVAtUG9ydC1UeXBlIHZhbHVlLCBpdCdzIG9uZSBvZiB0aGUg dHdvIGFib3ZlLCBub3QNCj4gYm90aC4NCg0KW01lZF0gRmFpci4gQ2hhbmdlZCB0bzogDQoNCiAg IG8gIElmIHRoZSBpbnRlcm5hbCByZWFsbSBpcyB3aXRoIElQdjQgYWRkcmVzcyBmYW1pbHksIHRo ZSBJUC1Qb3J0LQ0KICAgICAgRm9yd2FyZGluZy1NYXAgQXR0cmlidXRlIE1VU1QgY29udGFpbiB0 aGUgSVAtUG9ydC1JbnQtSVB2NC1BZGRyDQogICAgICBUTFYgKHNlZSBTZWN0aW9uIDMuMi40KTsg aWYgdGhlIGludGVybmFsIHJlYWxtIGlzIHdpdGggSVB2Ng0KICAgICAgYWRkcmVzcyBmYW1pbHks IHRoZSBJUC1Qb3J0LUZvcndhcmRpbmctTWFwIEF0dHJpYnV0ZSBNVVNUIGNvbnRhaW4NCiAgICAg IHRoZSBJUC1Qb3J0LUludC1JUHY2LUFkZHIgVExWIChzZWUgU2VjdGlvbiAzLjIuNSkuDQoNCj4g DQo+IC0gSSBiZWxpZXZlIHRoZSBSRkMgMjExOSBrZXl3b3JkcyB1c2FnZSBpcyBzb21ldGltZXMg d2VhayAoZ2VuZXJpYw0KPiBjb21tZW50IGZvciB0aGUgZW50aXJlIGRvY3VtZW50KQ0KPiBFeGFt cGxlMTogc2VjdGlvbiAzLjEuMw0KPiANCj4gICAgVGhlIGF0dHJpYnV0ZSBjb250YWlucyBhIDIt Ynl0ZSBJUCBpbnRlcm5hbCBwb3J0IG51bWJlciB0aGF0IGlzDQo+ICAgIGFzc29jaWF0ZWQgd2l0 aCBhbiBpbnRlcm5hbCBJUHY0IG9yIElQdjYgYWRkcmVzcywgb3IgYSBsb2NhbGx5DQo+ICAgIHNp Z25pZmljYW50IGlkZW50aWZpZXIgYXQgdGhlIGN1c3RvbWVyIHNpdGUsIGFuZCBhIDItYnl0ZSBJ UCBleHRlcm5hbA0KPiAgICBwb3J0IG51bWJlciB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCBhbiBl eHRlcm5hbCBJUHY0IGFkZHJlc3MuICBUaGUNCj4gICAgaW50ZXJuYWwgSVB2NCBvciBJUHY2IGFk ZHJlc3MsIG9yIHRoZSBsb2NhbCBpZGVudGlmaWVyIG11c3QgYmUNCj4gICAgaW5jbHVkZWQ7IHRo ZSBleHRlcm5hbCBJUHY0IGFkZHJlc3MgbWF5IGFsc28gYmUgaW5jbHVkZWQuDQo+IA0KPiBOb3Qg UkZDIDIxMTkga2V5d29yZHMuIFNob3VkIHRoZXkgYmUgTVVTVCBhbmQgTUFZPw0KDQpbTWVkXSBG aXhlZC4gVGhlIE5FVyB0ZXh0IGlzIHByb3ZpZGVkIGJlbG93OiANCg0KTkVXOg0KDQogICBUaGUg YXR0cmlidXRlIGNvbnRhaW5zIGEgMi1ieXRlIElQIGludGVybmFsIHBvcnQgbnVtYmVyIGFuZCBh IDItYnl0ZQ0KICAgSVAgZXh0ZXJuYWwgcG9ydCBudW1iZXIuICBUaGUgaW50ZXJuYWwgcG9ydCBu dW1iZXIgaXMgYXNzb2NpYXRlZCB3aXRoDQogICBhbiBpbnRlcm5hbCBJUHY0IG9yIElQdjYgYWRk cmVzcyB0aGF0IE1VU1QgYWx3YXlzIGJlIGluY2x1ZGVkLiAgVGhlDQogICBleHRlcm5hbCBwb3J0 IG51bWJlciBpcyBhc3NvY2lhdGVkIHdpdGggYSBzcGVjaWZpYyBleHRlcm5hbCBJUHY0DQogICBh ZGRyZXNzIGlmIGluY2x1ZGVkLCBidXQgb3RoZXJ3aXNlIHdpdGggYWxsIGV4dGVybmFsIElQdjQg YWRkcmVzc2VzDQogICBmb3IgdGhlIGVuZCB1c2VyLg0KDQo+IEFuZCB0aGUgbmV4dCBwYXJhZ3Jh cGggY29udGFpbnMgUkZDIDIxMTkga2V5d29yZHMuDQo+IA0KPiAgICBUaGUgSVAtUG9ydC1Gb3J3 YXJkaW5nLU1hcCBBdHRyaWJ1dGUgTUFZIGFwcGVhciBpbiBhbiBBY2Nlc3MtQWNjZXB0DQo+ICAg IHBhY2tldC4gIEl0IE1BWSBhbHNvIGFwcGVhciBpbiBhbiBBY2Nlc3MtUmVxdWVzdCBwYWNrZXQg dG8gaW5kaWNhdGUgYQ0KPiAgICBwcmVmZXJyZWQgcG9ydCBtYXBwaW5nIGJ5IHRoZSBkZXZpY2Ug Y28tbG9jYXRlZCB3aXRoIE5BUy4gIEhvd2V2ZXINCj4gICAgdGhlIHNlcnZlciBpcyBub3QgcmVx dWlyZWQgdG8gaG9ub3Igc3VjaCBhIHByZWZlcmVuY2UuDQo+IA0KPiBFeGFtcGxlMjoNCj4gDQo+ ICAgIElQLVBvcnQtRXh0LUlQdjQtQWRkciBUTFYgTUFZIGJlIGluY2x1ZGVkIGluIHRoZSBmb2xs b3dpbmcNCj4gICAgQXR0cmlidXRlczoNCj4gDQo+ICAgIG8gIElQLVBvcnQtTGltaXQtSW5mbyBB dHRyaWJ1dGUsIGlkZW50aWZpZWQgYXMgMjQxLlRCRDEuMyAoc2VlDQo+ICAgICAgIFNlY3Rpb24g My4xLjEpLg0KPiANCj4gICAgbyAgSVAtUG9ydC1SYW5nZSBBdHRyaWJ1dGUsIGlkZW50aWZpZWQg YXMgMjQxLlRCRDIuMyAoc2VlDQo+ICAgICAgIFNlY3Rpb24gMy4xLjIpLg0KPiANCj4gICAgbyAg SVAtUG9ydC1Gb3J3YXJkaW5nLU1hcHBpbmcgQXR0cmlidXRlLCBpZGVudGlmaWVkIGFzIDI0MS5U QkQzLjMNCj4gICAgICAgKHNlZSBTZWN0aW9uIDMuMS4zKS4NCj4gDQo+IERvbid0IHlvdSBuZWVk IHRoZSBSRkMyMTE5IGtleXdvcmQgaW4gdGhlIHJldmVyc2Ugc2l0dWF0aW9uLCBpbiBzZWN0aW9u DQo+IDMuMS4xIChJUC1Qb3J0LUxpbWl0LUluZm8gQXR0cmlidXRlKT8NCj4gT0xEOg0KPiAgICBv ICBhbiBvcHRpb25hbCBJUC1Qb3J0LUV4dC1JUHY0LUFkZHIgVExWIChzZWUgU2VjdGlvbiAzLjIu MykuDQo+IA0KPiBORVc6DQo+ICAgIG8gVGhlIElQLVBvcnQtTGltaXQtSW5mbyBBdHRyaWJ1dGUg TUFZIGNvbnRhaW4gdGhlDQo+IElQLVBvcnQtRXh0LUlQdjQtQWRkciAoc2VlIFNlY3Rpb24gMy4y LjMpLg0KDQpbTWVkXSBGaXhlZC4NCg0KPiANCj4gVGhpcyBsb2dpYyB3b3VsZCBub3Qgb25seSBi ZSBjbGVhcmVyLCBidXQgd291bGQgYWxzbyBhdm9pZA0KPiBpbmNvbnNpc3RlbmNpZXMuDQo+IFNl ZSBzZWN0aW9uIDMuMS4zDQo+IE9MRDoNCj4gDQo+IEl0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcg c3ViLWF0dHJpYnV0ZXM6DQo+ICAgIC4uLg0KPiAgICBvICBhbiBJUC1Qb3J0LUV4dC1JUHY0LUFk ZHIgVExWIChzZWUgU2VjdGlvbiAzLjIuMykuDQo+IA0KPiANCj4gTkVXOg0KPiANCj4gSXQgY29u dGFpbnMgdGhlIGZvbGxvd2luZyBzdWItYXR0cmlidXRlczoNCj4gDQo+ICAgLi4uDQo+ICAgIG8g IGFuIG9wdGlvbmFsIElQLVBvcnQtRXh0LUlQdjQtQWRkciBUTFYgKHNlZSBTZWN0aW9uIDMuMi4z KS4NCj4gDQo+IEV4YW1wbGUgMzoNCj4gDQo+ICAgIG5hdEV2ZW50DQo+IA0KPiAgICAgICBJbnRl Z2VyLiAgVGhpcyBmaWVsZCBjb250YWlucyB0aGUgZGF0YSAodW5zaWduZWQ4KSBvZiBuYXRFdmVu dA0KPiAgICAgICAoMjMwKSBkZWZpbmVkIGluIElQRklYLCByaWdodCBqdXN0aWZpZWQsIGFuZCB1 bnVzZWQgYml0cyBtdXN0IGJlDQo+ICAgICAgIHNldCB0byB6ZXJvLiAgSXQgaW5kaWNhdGVzIHRo ZSBhbGxvY2F0aW9uIG9yIGRlYWxsb2NhdGlvbiBvZiBhDQo+ICAgICAgIHJhbmdlIG9mIElQIHBv cnRzIGFzIGZvbGxvd3M6DQo+IA0KPiBNVVNUPw0KDQpbTWVkXSBZZXMuIEZpeGVkIGluIHRoZSBu ZXcgdmVyc2lvbi4NCg0K From nobody Wed Oct 5 04:25:53 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD14129685; Wed, 5 Oct 2016 04:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hyZ6Oefy8aAb; Wed, 5 Oct 2016 04:25:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6DE127A90; Wed, 5 Oct 2016 04:25:50 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 057D5411C9; Wed, 5 Oct 2016 13:25:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id BC1161A006D; Wed, 5 Oct 2016 13:25:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 13:25:46 +0200 From: To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSDtsyHAbKMeVj7k+ngymyWawxIaCZvAeA Date: Wed, 5 Oct 2016 11:25:45 +0000 Message-ID: <3a8a57ec-72b8-460d-8de7-479a2b97e1af@OPEXCLILM5F.corporate.adroot.infra.ftgroup> References: <147389377247.29884.8510043117785245776.idtracker@ietfa.amsl.com> In-Reply-To: <147389377247.29884.8510043117785245776.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 11:25:52 -0000 RGVhciBTdGVwaGVuLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBTdGVwaGVuIEZhcnJlbGwgW21h aWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBFbnZvecOpwqA6IGpldWRpIDE1IHNl cHRlbWJyZSAyMDE2IDAwOjU2DQo+IMOAwqA6IFRoZSBJRVNHDQo+IENjwqA6IGRyYWZ0LWlldGYt cmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsgcmFkZXh0QGlldGYub3JnOw0KPiBy YWRleHQtY2hhaXJzQGlldGYub3JnOyBNT1JBTkQgTGlvbmVsIElNVC9PTE47IHJhZGV4dEBpZXRm Lm9yZw0KPiBPYmpldMKgOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt cmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0NCj4gMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQo+IA0KPiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0x MTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN Cj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC8NCj4gDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAN Cj4gU29ycnkgZm9yIG5vdCBzcG90dGluZyB0aGlzIGluIG90aGVyIGRvY3VtZW50cywgYnV0IGRv IHdlDQo+IHVuZGVyc3RhbmQgdGhlIHByaXZhY3kgY2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMgSUNN UA0KPiBpZGVudGlmaWVyPyBJdCBtYXkgd2VsbCBiZSB0aGF0IHRoZSByZXNvbHV0aW9uIG9mIHRo aXMNCj4gZGlzY3VzcyByZXF1aXJlcyBzb21lIG90aGVyIGRvY3VtZW50IHRvIGV4aXN0IChpbiB3 aGljaA0KPiBjYXNlIEknbGwgZ2V0IG91dCBvZiB0aGUgd2F5IG9mIHRoaXMgb25lKSBidXQgSSB0 aGluayB3ZQ0KPiBvdWdodCBiZSBxdWl0ZSBjYXV0aW91cyBpbiBob3cgd2UgaW50cm9kdWNlICBu ZXcgZnVuY3Rpb25zDQo+IGZvciBpZGVudGlmaWVycyB0aGF0IG1heSBiZSBwZXJzb25hbGx5IGlk ZW50aWZ5aW5nLCBzbyBJJ2QNCj4gbGlrZSB0byBjaGF0IGFib3V0IHRoaXMgYSBiaXQuIERpZCB0 aGUgV0cgZGlzY3VzcyB0aGUNCj4gcHJpdmFjeSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoaXMg aWRlbnRpZmllcj8NCj4gDQoNCltNZWRdIEFzIGEgc2lkZSBlZmZlY3Qgb2YgcHJvY2Vzc2luZyBv dGhlciBjb21tZW50cywgd2UgZG9uJ3QgaGF2ZSBhbnkgbW9yZSBzdWNoIGlkZW50aWZpZXIgaW4g dGhlIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIFRoZSBwb2ludCByYWlzZWQgaW4gdGhpcyBE SVNDVVNTIGlzIG5vdCB2YWxpZCBhbnltb3JlLiANCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBD T01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gLSB3cml0ZS11cDogWWVhaCwgbWFq b3IgeXVrcyB0byBsZWF2aW5nIGRlc2lnbiBkZWNpc2lvbnMNCj4gdG8gSUFOQS4gIFdoaWxlIHRo ZSBmb2xrcyB0aGVyZSBhcmUgcXVpdGUgY2FwYWJsZSwgdGhleQ0KPiBhcmUgbm90IGFibGUgdG8g bWFrZSBJRVRGIGNvbnNlbnN1cyBkZWNpc2lvbnMuICBJZiB0aGUgV0cNCj4gYXJlbid0IHN1cmUs IGFzayBJQU5BIHBlcnNvbm5lbCAob3Igc29tZW9uZSkgYW5kIHRoZW4NCj4gdmVyaWZ5IHRoYXQg dGhhdCBvdXRjb21lIGdhcm5lcnMgcm91Z2ggY29uc2Vuc3VzIGJhY2sgaW4NCj4gdGhlIFdHIG9y IHVzaW5nIG90aGVyIElFVEYgcHJvY2Vzc2VzLiBTbyBBbGlzc2EncyBkaXNjdXNzDQo+IHBvaW50 IzQgaXMgZW50aXJlbHksIGNvbXBsZXRlbHkgYW5kIGZ1bGx5IGNvcnJlY3QgYW5kDQo+IGEgc2hv d3N0b3BwZXIgcmVhbGx5Lg0KPiANCj4gLSBJIGFsc28gYWdyZWUgd2l0aCB0aGUgaXNzdWUgY2Fs bGVkIG91dCBpbiBKb2VsJ3MgY29tbWVudA0KPiBhYm91dCBtaXNzaW9uIGNyZWVwIGFuZCBob3cg dGhpcyBvdmVybGFwcyB3aXRoIFBDUC4gRGlkDQo+IHRoZSBXRyBjb25zaWRlciB3aGV0aGVyIG9y IG5vdCBpdCBpcyBhIGdvb2QgaWRlYSBmb3IgdGhlDQo+IElFVEYgdG8gZGVmaW5lIG11bHRpcGxl IHdheXMgaW4gd2hpY2ggc29tZSBvZiB0aGVzZQ0KPiBmZWF0dXJlcyBjYW4gYmUgYWRkZWQ/IElm IHNvLCB3aGF0IGlzIHRoZSBqdXN0aWZpY2F0aW9uDQo+IGZvciB0aGVyZSBiZWluZyBtb3JlIHRo YW4gb25lPyAoSXMgdGhhdCBzb21ld2hlcmUgaW4gdGhlDQo+IFdHIGxpc3QgYXJjaGl2ZT8gSWYg bm90LCBpdCBvdWdodCBiZS4pIEl0IG1heSB3ZWxsIGJlIHRoYXQNCj4gaGF2aW5nIGEgUkFESVVT IG1lY2hhbmlzbSBmb3IgdGhpcyBpcyBhbHNvIGEgZ29vZCBwbGFuLA0KPiBidXQgSSB0aGluayB0 aGF0IG91Z2h0IGJlIGp1c3RpZmllZC4NCj4gDQoNCltNZWRdIFdpbGwgc2tpcCB0aG9zZSBhcyB0 aG9zZSBhcmUgZGlzY3Vzc2VkIGluIG90aGVyIHRocmVhZHMuDQoNCj4gLSA0LjEuNDogdXNpbmcg cG9ydCA4MCBhcyBhbiBleGFtcGxlIGlzIHZlcnkgMTk5MCdzLiBXb3VsZA0KPiBpdCBub3QgYmUg YmV0dGVyIHRvIGJlIG1vcmUgdXAgdG8gZGF0ZT8gVGhhdCdzIG5vdCBqdXN0IGENCj4gZmFjZXRp b3VzIHBvaW50IC0gd2ViIGNhbWVyYXMgYmVpbmcgbGVmdCBvcGVuIHRvIHRoZQ0KPiBJbnRlcm5l dCBhcmUgYSBtYWpvciBzd2FtcCBmb3IgYm90bmV0IGdlc3RhdGlvbi4gQmV0dGVyIHRvDQo+IHVz ZSBhIG1vcmUgZGVzaXJhYmxlIGV4YW1wbGUgcmVhbGx5Lg0KPiANCj4gLSBUaGUgc2VjZGlyIHJl dmlldyBbMV0gYWxzbyBub3RlZCBhIGJ1bmNoIG9mIGlzc3VlcyB0aGF0DQo+IGFzIGZhciBhcyBJ IGNhbiBzZWUgcmVjZWl2ZWQgbm8gcmVzcG9uc2Ugc28gZmFyLCBidXQgdGhhdA0KPiBkbyBkZXNl cnZlIGEgcmVzcG9uc2UuIChBcG9sb2dpZXMgaWYgSSBtaXNzZWQgYSByZXNwb25zZS4pDQo+IA0K PiAgICBbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZWNkaXIvY3Vy cmVudC9tc2cwNjczNi5odG1sDQo+IA0KDQpbTWVkXSBBIHJlcGx5IGlzIGF2YWlsYWJsZSBub3cg YXQ6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQv bXNnMDY4NDYuaHRtbCANCg== From nobody Wed Oct 5 06:42:19 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A039129705; Wed, 5 Oct 2016 06:42:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147567493503.21322.15547429383361371343.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 06:42:15 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:42:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-13.txt Pages : 39 Date : 2016-10-05 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. This document defines a mapping between some RADIUS attributes and IPFIX Information Element Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 5 06:42:22 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01506129705; Wed, 5 Oct 2016 06:42:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147567493600.21322.191318142850628852.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 06:42:16 -0700 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:42:16 -0000 A new version (-13) has been submitted for draft-ietf-radext-ip-port-radius-ext: https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-13 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. IETF Secretariat. From nobody Wed Oct 5 06:56:18 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C09A1296EA; Wed, 5 Oct 2016 06:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 T9wsnpaEuNhh; Wed, 5 Oct 2016 06:56:12 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB70112970B; Wed, 5 Oct 2016 06:56:10 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B6B1EC15FD; Wed, 5 Oct 2016 15:56:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7175C1C0066; Wed, 5 Oct 2016 15:56:09 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 15:56:08 +0200 From: To: Ben Campbell Thread-Topic: Ben Campbell's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Index: AQHR+CL79RFoybOXyU604KVf75Xw46CaLGvg Date: Wed, 5 Oct 2016 13:56:07 +0000 Message-ID: <044e0fbc-e426-4a02-8977-df7a6173c975@OPEXCLILM6D.corporate.adroot.infra.ftgroup> References: <147139572703.19954.16899242977244663872.idtracker@ietfa.amsl.com> In-Reply-To: <147139572703.19954.16899242977244663872.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: The IESG , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:56:17 -0000 RGVhciBCZW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpBIG5ldyByZXZpc2lv biB0byBpbnRlZ3JhdGUgeW91ciBjb21tZW50cyBpcyBhdmFpbGFibGUgb25saW5lLiBGV0lXLCBh IGRpZmYgdG8gdHJhY2sgdGhlIGNoYW5nZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMT1kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTImdXJsMj1kcmFmdC1p ZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTMgDQoNClBsZWFzZSBzZWUgaW5saW5lIGZv ciBtb3JlIGRldGFpbHMuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZcKgOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dDQo+ IEVudm95w6nCoDogbWVyY3JlZGkgMTcgYW/Du3QgMjAxNiAwMzowMg0KPiDDgMKgOiBUaGUgSUVT Rw0KPiBDY8KgOiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHRAaWV0Zi5vcmc7 IHJhZGV4dEBpZXRmLm9yZzsNCj4gcmFkZXh0LWNoYWlyc0BpZXRmLm9yZzsgTU9SQU5EIExpb25l bCBJTVQvT0xOOyByYWRleHRAaWV0Zi5vcmcNCj4gT2JqZXTCoDogQmVuIENhbXBiZWxsJ3MgTm8g T2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLQ0KPiBleHQtMTE6 ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBCZW4gQ2FtcGJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFk aXVzLWV4dC0xMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMt ZXh0Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IEkgb3JpZ2luYWxseSBpbnRlbmRlZCB0aGUgdHdvIGNvbW1lbnRzIHVuZGVy ICJNYWpvciBJc3N1ZXMiIHRvIGJlIHBvaW50cw0KPiBmb3IgYSBESVNDVVNTIHBvc2l0aW9uLiBC dXQgSSBzZWUgQWxpc3NhIGhhcyBhbHJlYWR5IGNhcHR1cmVkIHRoZSBlc3NlbmNlDQo+IG9mIHRo ZW0gaW4gaGVyIERJU0NVU1MuIFRoZXJlZm9yZSBJIHdpbGwgYmFsbG90IE5PIE9CSkVDVElPTiBm b3Igbm93LCBhbmQNCj4gd2lsbCB3YXRjaCB0aGF0IGRpc2N1c3Npb24uDQo+IA0KPiBNYWpvciBJ c3N1ZXM6DQo+IA0KPiBUaGUgZ3VpZGFuY2UgZm9yIElQLVBvcnQtTG9jYWwtSWQgVExWIGNvbnRl bXBsYXRlcyB1c2luZyBwZXJzaXN0ZW50DQo+IGNsaWVudCBpZGVudGlmaWVycywgc3VjaCBhcyBN QUMgYWRkcmVzc2VzLiBJcyB0aGF0IG5lY2Vzc2FyeT8gSSBzdXNwZWN0DQo+IHRoZSBhbnN3ZXIg d2lsbCBiZSAieWVzIi4gQnV0IGlmIHRoYXQgIGlzIHRoZSBjYXNlLCB0aGUgZHJhZnQgcmVhbGx5 DQo+IG5lZWRzIGEgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRvIGRpc2N1c3MgdGhl IGltcGxpY2F0aW9ucyBhbmQNCj4gdHJhZGVvZmZzLg0KDQpbTWVkXSBORVcgdGV4dCB3YXMgYWRk ZWQgaW4gLTEyLiBJIHdpbGwgc2tpcCB0aGlzIHBvaW50IGFzIGl0IGlzIGRpc2N1c3NlZCBpbiBv dGhlciB0aHJlYWRzLg0KDQo+IA0KPiAtIDMuMS4xLCBwYXJhZ3JhcGggNzogIkhvd2V2ZXIsIHRo ZSBSQURJVVMgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0bw0KPiBob25vciBzdWNoIGENCj4gICAg cHJlZmVyZW5jZS4iDQo+IFBsZWFzZSBkZXNjcmliZSB3aGF0IGl0IG1lYW5zIHRvICJub3QgaG9u b3IiIHN1Y2ggYSBwcmVmZXJlbmNlPyBEb2VzIHRoZQ0KPiBzZXJ2ZXIgcmVwb3J0IGFuIGVycm9y PyBEb2VzIHRoZSB0cmFuc2FjdGlvbiBzdWNjZWVkLCBidXQgcmVwb3J0IGENCj4gZGlmZmVyZW50 IGxpbWl0PyBEb2VzIHRoZSBzZXJ2ZXIganVzdCBpZ25vcmUgdGhlIHByZWZlcmVuY2UgYW5kIGRv IGl0cw0KPiBvd24gdGhpbmc/IChJIGV4cGVjdCB0aGlzIGFwcGxpZXMgdG8gYW55IG51bWJlciBv ZiBmYWlsdXJlIGNvbmRpdGlvbnMuKQ0KPiANCg0KW01lZF0gQWN0dWFsbHksIHRoYXQgc2VudGVu Y2UgaXMgcmVkdW5kYW50IHdpdGggdGhlIHByZXZpb3VzIG9uZSB3aGljaCBleHBsaWNpdGx5IHNh eXM6ICJwcmVmZXJyZWQgbWF4aW11bSBudW1iZXIiLiBUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVu dCBtYXkgaW5kaWNhdGUgYSBwcmVmZXJlbmNlIHRoYXQgbWF5IGJlLCBieSBkZWZpbml0aW9uLCBj b25zaWRlciBvciBpZ25vcmVkIGJ5IHRoZSBSQURJVVMgc2VydmVyLiBUaGUgUkFESVVTIHNlcnZl ciBjYW4gcmV0dXJuIHRoYXQgdmFsdWUgb3IgYW5vdGhlciBvbmUgaW4gdGhlIHJlc3BvbnNlIGJh Y2sgdG8gdGhlIGNsaWVudC4gVGhlIGRvY3VtZW50IGRvZXMgbm90IGluY2x1ZGUgYW55IHRleHQg dGhpcyBhcyB0aGVyZSBpcyBub3RoaW5nIHRvIGJlIGRvbmUgYXQgdGhlIGNsaWVudCBzaWRlIG90 aGVyIHRoYW4gZW5mb3JjaW5nIHRoZSBsaW1pdCB0aGF0IHdpbGwgYmUgY29tbXVuaWNhdGVkIGJ5 IHRoZSBSQURJVVMgc2VydmVyLg0KDQo+IE1pbm9yIElzc3VlczoNCj4gDQo+IC0gUGxlYXNlIGNs YXJpZnkgdGhlIGFwcGxpY2FiaWxpdHkgdG8gSVB2NCBhbmQgSVB2Ni4gU3BlY2lmaWNhbGx5LCBJ IG5vdGUNCj4gdGhhdCB5b3UgZGVmaW5lIFRMVnMgZm9yICJpbnRlcm5hbCIgSVB2NCBhbmQgSVB2 NiBhZGRyZXNzZXMsIGJ1dCBvbmx5IGZvcg0KPiAiZXh0ZXJuYWwiIElQdjQgYWRkcmVzcy4gSSBh c3N1bWUgdGhhdCB0byBtZWFuIHRoYXQgdGhpcyBzdXBwb3J0cyBOYXQ0NA0KPiBhbmQgTmF0NjQg dXNlIGNhc2VzLCBidXQgbm90IGFueXRoaW5nIHRoYXQgdXNlcyBJUHY2IGluIHRoZSAiZXh0ZXJu YWwiDQo+IHJlYWxtPyAoV2hhdGV2ZXIgdGhlIGFuc3dlciwgaXQgd291bGQgYmUgaGVscGZ1bCB0 byBoYXZlIGEgcGFyYWdyYXBoIG9yDQo+IHR3byB0byBtYWtlIHRoYXQgZXhwbGljaXQuKQ0KDQpb TWVkXSBUaGlzIE5FVyB0ZXh0IHdhcyBhZGRlZDogDQoNCglUaGlzIGRvY3VtZW50IGZvY3VzZXMg b24gSVB2NCBhZGRyZXNzIHNoYXJpbmcuICBJUHY2IHByZWZpeCBzaGFyaW5nCQ0KCW1lY2hhbmlz bXMgKGUuZy4sIE5QVHY2KSBhcmUgb3V0IG9mIHNjb3BlLg0KDQo+IA0KPiAtMiwgZGVmaW5pdGlv biBvZiAicG9ydC1iYXNlZCBkZXZpY2UiOg0KPiBXb3VsZG7igJl0IHRoYXQgbW9yZSBwcm9wZXJs eSBiZSBjYWxsZWQgYSBwb3J0LW1hcHBpbmcgZGV2aWNlPyAoYW55dGhpbmcNCj4gdXNpbmcgVENQ IG9yIFVEUCB3b3VsZCBzZWVtIHRvIGJlIHBvcnQtYmFzZWQpDQoNCltNZWRdIGNoYW5nZWQgdG8g ImFkZHJlc3Mgc2hhcmluZyBkZXZpY2UiDQoNCj4gDQo+IC0zLjEuMSwgbGFzdCBwYXJhZ3JhcGg6 DQo+IFRoaXMgbGFuZ3VhZ2UgcHJlY2x1ZGVzIG5ldyBleHRlbnNpb24gcGFja2V0IHR5cGVzIGZy b20gdXNpbmcgdGhlDQo+IGF0dHJpYnV0ZSB3aXRob3V0IHVwZGF0aW5nIHRoaXMgZG9jdW1lbnQu IElzIHRoYXQgcmVhbGx5IHRoZSBpbnRlbnQ/DQo+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc2F5 IHNvbWV0aGluZyBsaWtlICIuLi4gTVVTVCBOT1QgYXBwZWFyIGluIGFueQ0KPiBvdGhlciBSQURJ VVMgcGFja2V0IHR5cGVzIGRlZmluZWQgYXQgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLiBJZiBh DQo+IGZ1dHVyZSBwYWNrZXQgdHlwZSB1c2VzIHRoZSBhdHRyaWJ1dGUsIHRoZSBzcGVjaWZpY2F0 aW9uIG9mIHRoYXQgcGFja2V0DQo+IHR5cGUgd2lsbCBuZWVkIHRvIGRlZmluZSBpdCdzIHVzYWdl Ij8gKE5vdGUgdGhhdCB0aGlzIGlzc3VlIHJlcGVhdHMNCj4gc2V2ZXJhbCB0aW1lcyBpbiB0aGUg ZG9jdW1lbnQuKQ0KDQpbTWVkXSBXZSBhcmUgZm9sbG93aW5nIHRoZSBzYW1lIGxhbmd1YWdlIGFz IHVzdWFsbHkgZG9uZSBpbiBSQURJVVMgc3BlY2lmaWNhdGlvbnMuIE5vIGNoYW5nZSBpcyBuZWVk ZWQsIElNSE8uDQoNCj4gDQo+IEVkaXRvcmlhbCBDb21tZW50cyBhbmQgTml0czoNCj4gDQo+IC0g VGhlIHVzZSBvZiB0aGUgdGVybSAic2Vzc2lvbiIgc2VlbXMgaW5jb25zaXN0ZW50LiBJbiBzb21l IHBsYWNlcyBpdA0KPiBzZWVtcyBsaWtlIGFuIElQRmxvdyBvciBhIE5BVCBtYXBwaW5nLCBidXQg aW4gb3RoZXIgcGxhY2VzIGl0IHNlZW1zIGxpa2UNCj4gYSBuZXR3b3JrIGNvbm5lY3Rpb24gKGku ZS4gTkFTIGF0dGFjaG1lbnQuKQ0KPiANCg0KW01lZF0gcmVwbGFjZWQgInNlc3Npb24iIHdpdGgg Im1hcHBpbmciIHdoZW4gYXBwcm9wcmlhdGUuIA0KDQo+IC0gMSwgbGlzdCBpdGVtIDE6DQo+IFNp bmd1bGFyL3BsdXJhbCBtaXNtYXRjaCBmb3IgInBhY2tldCIuIEVpdGhlciAicGFja2V0IiBzaG91 bGQgYmUNCj4gInBhY2tldHMiLCBvciB5b3UgbmVlZCBhbiBhcnRpY2xlIGJlZm9yZSBSQURJVVMu IChlLmcuIGENCj4gUkFESVVTLi4ucGFja2V0LikgTm90ZSB0aGF0IHRoaXMgZXJyb3IgcmVwZWF0 cyBtYW55IHRpbWVzIGluIHNpbWlsYXINCj4gcGF0dGVybnMgdGhyb3VnaG91dCB0aGUgZG9jdW1l bnQuDQo+IA0KDQpbTWVkXSBGaXhlZC4NCg0KPiAtMSwgbGlzdCBpdGVtIDIsIGxhc3Qgc2VudGVu Y2U6DQo+IENvbnZvbHV0ZWQgc2VudGVuY2UuIENhbiBpdCBiZSBzaW1wbGlmaWVkPw0KDQpbTWVk XSBVcGRhdGVkIHRoZSB0ZXh0IHRvOg0KDQpPTEQ6DQogICAyLiAgSVAtUG9ydC1SYW5nZTogVGhp cyBhdHRyaWJ1dGUgbWF5IGJlIGNhcnJpZWQgaW4gUkFESVVTDQogICAgICAgQWNjb3VudGluZy1S ZXF1ZXN0IHBhY2tldC4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgYXR0cmlidXRlIGlzIHRvDQogICAg ICAgcmVwb3J0IGJ5IGFuIGFkZHJlc3Mgc2hhcmluZyBkZXZpY2UgKGUuZy4sIGEgQ0dOKSB0byB0 aGUgUkFESVVTDQogICAgICAgc2VydmVyIHRoZSByYW5nZSBvZiBJUCBzb3VyY2UgdHJhbnNwb3J0 IHBvcnRzIHRoYXQgaGF2ZSBiZWVuDQogICAgICAgYWxsb2NhdGVkIG9yIGRlYWxsb2NhdGVkIGFz c29jaWF0ZWQgd2l0aCBhIGdpdmVuIElQdjQvSVB2Ng0KICAgICAgIGFkZHJlc3MgZm9yIGEgdXNl ci4NCg0KTkVXOg0KICAgMi4gIElQLVBvcnQtUmFuZ2U6IFRoaXMgYXR0cmlidXRlIG1heSBiZSBj YXJyaWVkIGluIGEgUkFESVVTDQogICAgICAgQWNjb3VudGluZy1SZXF1ZXN0IHBhY2tldC4gIFRo ZSBwdXJwb3NlIG9mIHRoaXMgYXR0cmlidXRlIGlzIGZvcg0KICAgICAgIGFuIGFkZHJlc3Mgc2hh cmluZyBkZXZpY2UgKGUuZy4sIGEgQ0dOKSB0byByZXBvcnQgdG8gdGhlIFJBRElVUw0KICAgICAg IHNlcnZlciB0aGUgcmFuZ2Ugb2YgSVAgc291cmNlIHRyYW5zcG9ydCBwb3J0cyB0aGF0IGhhdmUg YmVlbg0KICAgICAgIGFsbG9jYXRlZCBvciBkZWFsbG9jYXRlZCBmb3IgYSB1c2VyLiAgVGhlIHBv cnQgcmFuZ2UgaXMgYm91bmQgdG8NCiAgICAgICBhbiBleHRlcm5hbCBJUHY0IGFkZHJlc3MuDQoN Cj4gDQo+IC0xLCBsYXN0IHBhcmFncmFwaDoNCj4gSXQgd291bGQgYmUgaGVscGZ1bCB0byBtZW50 aW9uIHRoYXQgdGhpcyBkcmFmdCBkZWZpbmVzIElQRklYIGVsZW1lbnRzDQo+IG5lYXIgdGhlIHRv cCBvZiB0aGUgc2VjdGlvbiwgYW5kIGFsc28gaW4gdGhlIGFic3RyYWN0Lg0KPiANCg0KW01lZF0g QWRkZWQgdGhpcyBORVcgdGV4dCBpbiB0aGUgYWJzdHJhY3Q6DQoNCiAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBtYXBwaW5nIGJldHdlZW4gc29tZSBSQURJVVMgYXR0cmlidXRlcyBhbmQJDQoJ SVBGSVggSW5mb3JtYXRpb24gRWxlbWVudCBJZGVudGlmaWVycy4NCg0KPiAtMiwgZGVmaW5pdGlv biBvZiAiSW50ZXJuYWwgSVAgQWRkcmVzcyI6ICJyZWZlcnMgdG8gdGhlIElQIGFkZHJlc3MgdGhh dA0KPiBpcyB1c2VkIGFzIGENCj4gICAgICAgc291cmNlIElQIGFkZHJlc3MiDQo+IFVzZWQgYnkg d2hhdCBkZXZpY2U/DQoNCltNZWRdIFllcywgdGV4dCB1cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQo+ IA0KPiAtMiwgZGVmaW5pdGlvbiBvZiAibWFwcGluZyI6DQo+IEkgY2Fubm90IHBhcnNlIHRoZSB0 ZXh0LiAoTm90ZSB0aGF0IHdoaWxlIHRoZSBsYXN0IHBhcmFncmFwaCBpbiB0aGUNCj4gc2VjdGlv biBzYXlzIHRoaXMgaXMgdGFrZW4gZnJvbSA2ODg3IGFuZCA2ODg4LCBuZWl0aGVyIG9mIHRoZW0g c2VlbSB0bw0KPiB1c2UgdGhpcyBzcGVjaWZpYyBsYW5ndWFnZS4pDQoNCltNZWRdIENoYW5nZWQg dG86DQoNCiAgIG8gIE1hcHBpbmc6IGRlbm90ZXMgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhbiBp bnRlcm5hbCBJUCBhZGRyZXNzLA0KICAgICAgaW50ZXJuYWwgcG9ydCBhbmQgdGhlIHByb3RvY29s LCBhbmQgYW4gZXh0ZXJuYWwgSVAgYWRkcmVzcywNCiAgICAgIGV4dGVybmFsIHBvcnQsIGFuZCB0 aGUgcHJvdG9jb2wuDQoNCj4gDQo+IC00LjEsIHNlY29uZCBwYXJhZ3JhcGg6ICIgQSBDR04gZnVu Y3Rpb24gaW4gYSBicm9hZGJhbmQgbmV0d29yayB3b3VsZA0KPiBtb3N0IGxpa2VseSBjby1sb2Nh dGVkIG9uIGEgQk5HLiINCj4gVGhlcmUncyBhIG1pc3Npbmcgd29yZCBpbiB0aGVyZSBzb21ld2hl cmUuIE1heWJlIGEgImJlIiBiZWZvcmUNCj4gImNvLWxvY2F0ZWQiPw0KDQpbTWVkXSBGaXhlZC4N Cg0KPiANCj4gLTYsIGxhc3QgcGFyYWdyYXBoOg0KPiBUaGUgcGFyYWdyYXBoIGRvZXNuJ3QgcGFy c2UuIFNob3VsZCAiZGVwbG95ZWQiIGJlICJkZXBsb3ltZW50cyI/DQo+IA0KW01lZF0gRml4ZWQu IFRoYW5rIHlvdS4NCg0K From nobody Wed Oct 5 06:59:05 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE3C129717; Wed, 5 Oct 2016 06:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 54TXicc_-uHa; Wed, 5 Oct 2016 06:58:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB217129715; Wed, 5 Oct 2016 06:58:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6824F26578F; Wed, 5 Oct 2016 15:58:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.19]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3946F238071; Wed, 5 Oct 2016 15:58:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 15:58:56 +0200 From: To: Suresh Krishnan Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Index: AQHR+QQj+hLVw3tlXkWOuHlKIm5Px6CaLntg Date: Wed, 5 Oct 2016 13:58:55 +0000 Message-ID: <75698fc6-9d4d-4a62-9219-973a3019e887@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> In-Reply-To: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: The IESG , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:59:03 -0000 SGkgU3VyZXNoLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBp bmxpbmUgZm9yIG1vcmUgZGV0YWlscy4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFN1cmVzaCBLcmlzaG5hbiBbbWFpbHRvOnN1cmVzaC5r cmlzaG5hbkBlcmljc3Nvbi5jb21dDQo+IEVudm95w6nCoDogamV1ZGkgMTggYW/Du3QgMjAxNiAw NTo1NA0KPiDDgMKgOiBUaGUgSUVTRw0KPiBDY8KgOiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0 LXJhZGl1cy1leHRAaWV0Zi5vcmc7IHJhZGV4dEBpZXRmLm9yZzsNCj4gcmFkZXh0LWNoYWlyc0Bp ZXRmLm9yZzsgTU9SQU5EIExpb25lbCBJTVQvT0xOOyByYWRleHRAaWV0Zi5vcmcNCj4gT2JqZXTC oDogU3VyZXNoIEtyaXNobmFuJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlw LXBvcnQtDQo+IHJhZGl1cy1leHQtMTE6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBTdXJlc2ggS3Jp c2huYW4gaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRy YWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0xMTogTm8gT2JqZWN0aW9uDQo+IA0K PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4g DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICogV2h5IGFyZSB0aGUgdGhl IHVpbnQ4IGFuZCB1bml0MTYgYmFzZWQgdHlwZXMgZ2V0dGluZyBzdHVmZmVkIGludG8gMzINCj4g Yml0IGZpZWxkcyBpbnNpZGUgdGhlIFRMVnM/IFRoaXMgZmVlbHMgbGlrZSBhIGNvbXBsZXRlIHdh c3RlLiBJcyB0aGVyZQ0KPiBhbnkgc3BlY2lmaWMgcmVhc29uIHRoaXMgaXMgcmVxdWlyZWQ/DQoN CltNZWRdIEFkZGVkIHRoaXMgbmV3IHRleHQ6IA0KDQpUaGUgYXR0cmlidXRlIGlzIGVuY29kZWQg aW4gMzINCiAgIGJpdHMgYXMgcGVyIHRoZSByZWNvbW1lbmRhdGlvbiBpbiBBcHBlbmRpeCBBLjIu MSBvZiBbUkZDNjE1OF0uDQoNCj4gDQo+ICogRG9lcyB0aGUgSVAtUG9ydC1MaW1pdCBpbmNsdWRl IHRoZSBjb3VudCBvZiBwb3J0cyBhbHJlYWR5IGFsbG9jYXRlZA0KPiB0aHJvdWdoIHRoZSBJUC1Q b3J0LUZvcndhcmRpbmctTWFwIG9yIG5vdD8NCg0KW01lZF0gQWRkZWQgdGhpcyBjbGFyaWZpY2F0 aW9uOg0KDQogICAgICAgICBUaGlzIGxpbWl0IGFwcGxpZXMgdG8gYWxsDQogICAgICAgICBtYXBw aW5ncyB0aGF0IGNhbiBiZSBpbnN0YW50aWF0ZWQgYnkgYW4gdW5kZXJseWluZyBhZGRyZXNzDQog ICAgICAgICBzaGFyaW5nIGRldmljZSB3aXRob3V0IHNvbGljaXRpbmcgYW55IGV4dGVybmFsIGVu dGl0eS4gIEluDQogICAgICAgICBwYXJ0aWN1bGFyLCB0aGlzIGxpbWl0IGRvZXMgbm90IGluY2x1 ZGUgdGhlIHBvcnRzIHRoYXQgYXJlDQogICAgICAgICBpbnN0cnVjdGVkIGJ5IGFuIEFBQSBzZXJ2 ZXIuDQoNCkEgbmV3IHJldmlzaW9uIGludGVncmF0aW5nIHlvdXIgY29tbWVudHMgaXMgYXZhaWxh YmxlIG9ubGluZS4gRldJVywgYSBkaWZmIHRvIHRyYWNrIHRoZSBjaGFuZ2VzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMt ZXh0LTEyJnVybDI9ZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTEzICAgDQoN Cj4gDQo+ICogSSBhZ3JlZSB3aXRoIEFsaXNzYSdzIERJU0NVU1MgcG9pbnRzIGFib3V0IHRoZSBs YWNrIG9mIGVycm9yIGhhbmRsaW5nDQo+IGFuZCB0aGUgcHJpdmFjeSBpc3N1ZXMgYW5kIE1pcmph J3MgRElTQ1VTUyBwb2ludCBhYm91dCByZXN0cmljdGluZw0KPiB0cmFuc3BvcnQgcHJvdG9jb2xz IHRvIFRDUCBhbmQgVURQLg0KDQpbTWVkXSBUaG9zZSBhcmUgZGlzY3Vzc2VkIGluIG90aGVyIHRo cmVhZHMuDQoNCg== From nobody Wed Oct 5 07:05:34 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E16CA129729; Wed, 5 Oct 2016 07:05:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA1E12972D; Wed, 5 Oct 2016 07:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.614 X-Spam-Level: X-Spam-Status: No, score=-5.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 CQNM_rqsoIES; Wed, 5 Oct 2016 07:05:25 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB207129729; Wed, 5 Oct 2016 07:05:24 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 54773180FBB; Wed, 5 Oct 2016 16:05:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 1F7BE20068; Wed, 5 Oct 2016 16:05:23 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 16:05:22 +0200 From: To: Tim Chown Thread-Topic: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Thread-Index: AQHR+HEowS7Op1qTZUSXToLnElhR2aCQe3BggAm2NSA= Date: Wed, 5 Oct 2016 14:05:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E3101D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008E220CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E220CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E3101DOPEXCLILMA3corp_" MIME-Version: 1.0 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20161005140529.E16CA129729@ietfa.amsl.com> Resent-Date: Wed, 5 Oct 2016 07:05:29 -0700 (PDT) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" , Kathleen Moriarty , "ops-dir@ietf.org" Subject: Re: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:05:30 -0000 --_000_787AE7BB302AE849A7480A190F8B933008E3101DOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tim, FWIW, an updated version that takes into account your review is available o= nline. A diff is available here: https://www.ietf.org/rfcdiff?url1=3Ddraft-= ietf-radext-ip-port-radius-ext-12&url2=3Ddraft-ietf-radext-ip-port-radius-e= xt-13 Cheers, Med De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Envoy=E9 : jeudi 29 septembre 2016 14:17 =C0 : Tim Chown; ops-dir@ietf.org; draft-ietf-radext-ip-port-radius-ext.all= @ietf.org Cc : Kathleen Moriarty Objet : RE: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Hi Tim, (Apologies for the delay to answer the message) Thank you for the review. Please see inline. Cheers, Med De : Tim Chown [mailto:Tim.Chown@jisc.ac.uk] Envoy=E9 : mercredi 17 ao=FBt 2016 12:23 =C0 : ops-dir@ietf.org; draft-ietf-radext-ip-port-= radius-ext.all@ietf.org Objet : OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. T= hese comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be included i= n AD reviews during the IESG review. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicatin= g with a RADIUS server to facilitate the configuration or reporting of IP and port r= anges used with a network appliance, typically a CGN, where there is a need to constra= in the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that= while I am familiar with RADIUS (from an eduroam context) the draft is not one I wa= s familiar with or followed prior to this review. Thus these comments may hav= e already been addressed. General comments: There are at least two areas in which this document has "creep". One is tha= t it is providing an alternative method to PCP to define port forwarding mappings o= n a device. So there is an open question as to whether PCP should be the method of choi= ce for this function, or whether we wish to create a new way to establish such map= pings. [Med] PCP targets a different deployment model where an application control= s its mapping in a CPE, CGN, Firewall, etc. This document targets a deploym= ent where a AAA server is responsible de instructing NAT mappings for a giv= en subscriber. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port= -Local-Id, which allows user/device-specific information to be transmitted via RADIUS,= such as MAC address or VLAN ID. While this is intended to allow differentiation of = users for accounting/identification r, in doing so it adds an additional potential pr= ivacy concern into a new RADIUS attribute, depending on specific use cases of the= TLV. [Med] The main use case is the deployment where the internal IP address is = not sufficient to demux users. We introduced this NEW text in -12: The primary issue addressed by this TLV is that there are CGN deployments that do not distinguish internal hosts by their internal IP address alone, but use further identifiers for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces (refer to [RFC1918] and [RFC6598]) for internal hosts o= f different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another identifier, for example, the identifier of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the IP-Port-Range Attribute and IP-Port-Forwarding-Mapping Attribute in order to uniquely identify an internal host. The IP-Port-Local-Id TLV is used to carry this identifier. This is not discussed in the Security Considerations section, but probably = should be. [Med] Fair point. We added this text: The IP-Port-Local-Id TLV includes an identifier of which the type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. I note the new attributes use a number of IPFIX information elements; has t= he draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, whic= h says the "lack of a consistent way to log the data makes it difficult to write t= he collector applications that would receive this data and process it to prese= nt useful information"? This draft is introducing a new method to log such elements; = is this a concern at all? [Med] FWIW, one of the co-authors is the main editor of draft-ietf-behave-i= pfix-nat-logging. As a reminder, this draft reuses the IPFIX registry becau= se it offers a rich set of elements. Further, this draft does not focues on= NAT logging. Of course, some TLV can be used for notification purposes but= this is not logging per se. The examples of use cases of the new attributes include both NAT44 devices = and CGNs. The document could state more clearly the address sharing scenarios, perhap= s with a simplified network element diagram for each example, showing the user/host,= CPE/NAT44, and NAT444/CGN? [Med] I'm sure if this will add more clarity to the draft because there are= many deployment cases that can be cited. The draft explicitly calls out th= e CPE case and CGN. Some additional clarity here would be useful (see also comments below). Also, the term "the user" is used in many places in the document where in p= ractice "the customer's CPE" would be more appropriate. [Med] I agree that some occurrences can be replaced easily by subscriber or= customer but still "user" is accurate. For example, it is not a customer t= hat initiates a connection but a user (that may be the customer itself or a= nother person that uses the right to invoke the service). In order to avoid= overloading the document with such subtleties, we prefer to use "user" in = the whole document. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given late= r in the document. This might add useful value. [Med] Happily! We will update the text accordingly. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements = in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly = the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if = the document stated why these elements are being padded out to 32 bits. [Med] Please check https://tools.ietf.org/html/rfc6158#appendix-A.2.1 In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex= users over a smaller number of shared IPv4 addresses, rather its primary design g= oal is to facilitate access to legacy IPv4 content from IPv6-only networks. Th= e text should be clarified. [Med] I guess you are referring to "over a smaller number of shared IPv4 ad= dresses". "Smaller" is used here to indicate that the external IP address p= ool is not sufficient to assign a full IPv4 address to each internal host. = NAT64 falls into such category. RFC6146 says: "One or more public IPv4 addr= esses assigned to a NAT64 translator are shared among several IPv6-only clients." Also in 4.1.1, do users really have service agreements that state port limi= ts? [Med] There is no assumption in the draft that SLAs include port limits. If they do, I doubt users are aware of them (or care...), and the issue is = beyond the scope of this document. [Med] Agree. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Conside= rations section if you discuss privacy there (which is presumably what you mean?) [Med] Can be added, indeed. Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram= shows only the NAT44 (presumably in the CPE) and not an ISP CGN. [Med] No, the diagram shows a NAT that is collocated with a BNG. This is a = CGN case. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, wit= hout the diagram showing there may (presumably) be mappings to establish at both= the user's CPE and the ISP's CGN. [Med] Idem as above --_000_787AE7BB302AE849A7480A190F8B933008E3101DOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tim,

 

FWIW, an updated version that t= akes into account your review is available online. A diff is available here= : https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-radext-ip-port-radius-ext-12= &url2=3Ddraft-ietf-radext-ip-port-radius-ext-13

 

Cheers,

Med

 

De : moha= med.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Envoy=E9 : jeudi 29 septembre 2016 14:17
=C0 : Tim Chown; ops-dir@ietf.org; draft-ietf-radext-ip-port-ra= dius-ext.all@ietf.org
Cc : Kathleen Moriarty
Objet : RE: OPS-DIR review of draft-ietf-radext-ip-port-radius-= ext-11

 

Hi Tim,

 

(Apologies for the delay to ans= wer the message)

 

Thank you for the review.

 

Please see inline.

 

Cheers,

Med

 

 

Hi,

 =

I have reviewed t= his document as part of the Operational directorate's 

ongoing effort to= review all IETF documents being processed by the IESG.  These 

comments were wri= tten with the intent of improving the operational aspects of the =

IETF drafts. Comm= ents that are not addressed in last call may be included in AD reviews = ;

during the IESG r= eview.  Document editors and WG chairs should treat these comments&nbs= p;

just like any oth= er last call comments. 

 =

This draft define= s three new RADIUS attributes to be used when communicating with a 

RADIUS server to = facilitate the configuration or reporting of IP and port ranges used <= o:p>

with a network ap= pliance, typically a CGN, where there is a need to constrain 

the ports availab= le per customer where IP address sharing is in use.

 =

The three RADIUS = attributes are:

IP-Port-Limit-Inf= o - defines the maximum number of ports available

IP-Port-Range - t= he specific range of port numbers available

IP-Port-Forwardin= g-Map - to configure port forwarding on a NAT/CGN device<= /p>

 =

I would consider = the document to be "Ready with Issues".

 =

I have some gener= al comments, followed by some specific comments. Note that while I

am familiar with = RADIUS (from an eduroam context) the draft is not one I was 

familiar with or = followed prior to this review. Thus these comments may have already

been addressed.

 =

General comments:=

 =

There are at leas= t two areas in which this document has "creep". One is that it is=  

providing an alte= rnative method to PCP to define port forwarding mappings on a device.<= /o:p>

So there is an op= en question as to whether PCP should be the method of choice for=

this function, or= whether we wish to create a new way to establish such mappings.=

 

[Med= ] PCP targets a different deployment model where an application controls it= s mapping in a CPE, CGN, Firewall, etc. This document targets a deployment where a AAA server is responsible de instructing NAT = mappings for a given subscriber.

 

Secondly, two of = the new attributes support inclusion of a new TLV, IP-Port-Local-Id,

which allows user= /device-specific information to be transmitted via RADIUS, such as

MAC address or VL= AN ID. While this is intended to allow differentiation of users for

accounting/identi= fication r, in doing so it adds an additional potential privacy<= /span>

concern into a ne= w RADIUS attribute, depending on specific use cases of the TLV.<= /span>

 

[Med= ] The main use case is the deployment where the internal IP address is not = sufficient to demux users. We introduced this NEW text in -12:

 

   The primary issue addressed by this =
TLV is that there are CGN
   deployments that do not distinguish =
internal hosts by their internal
   IP address alone, but use further id=
entifiers for unique subscriber
   identification.  For example, t=
his is the case if a CGN supports
   overlapping private or shared IP add=
ress spaces (refer to [RFC1918]

   and [RFC6598]) for internal hosts of different subscribers.  In such


   cases, different internal hosts are =
identified and mapped at the CGN


   by their IP address and/or another i=
dentifier, for example, the


   identifier of a tunnel between the C=
GN and the subscriber.  In these


   scenarios (and similar ones), the in=
ternal IP address is not


   sufficient to demultiplex connection=
s from internal hosts.  An


   additional identifier needs to be pr=
esent in the IP-Port-Range


   Attribute and IP-Port-Forwarding-Map=
ping Attribute in order to


   uniquely identify an internal host.&=
nbsp; The IP-Port-Local-Id TLV is used


   to carry this identifier.


 


 

This is not discu= ssed in the Security Considerations section, but probably should be.

[Med= ] Fair point. We added this text:

 

   The IP-Port-Local-Id TLV includes an=
 identifier of which the type and
   length is deployment and implementat=
ion dependent.  This identifier
   might carry privacy sensitive inform=
ation.  It is therefore
   RECOMMENDED to utilize identifiers t=
hat do not have such privacy
   concerns.

 

I = note the new attributes use a number of IPFIX information elements; has the= draft

considered its re= lationship to draft-ietf-behave-ipfix-nat-logging-09, which says=

the "lack of= a consistent way to log the data makes it difficult to write the 

collector applica= tions that would receive this data and process it to present useful 

information"= ? This draft is introducing a new method to log such elements; is this=

a concern at all?=

 

[Med= ] FWIW, one of the co-authors is the main editor of draft-ietf-behave-ipfix= -nat-logging. As a reminder, this draft reuses the IPFIX registry because it offers a rich set of elements. Further, this dra= ft does not focues on NAT logging. Of course, some TLV can be used for noti= fication purposes but this is not logging per se.

 

The examples of u= se cases of the new attributes include both NAT44 devices and CGNs. 

The document coul= d state more clearly the address sharing scenarios, perhaps with a

simplified networ= k element diagram for each example, showing the user/host, CPE/NAT44,<= /o:p>

and NAT444/CGN?

 

[Med= ] I’m sure if this will add more clarity to the draft because there a= re many deployment cases that can be cited. The draft explicitly calls out the CPE case and CGN.  

 

So= me additional clarity here would be useful (see also comments below).<= /o:p>

Also, the term &q= uot;the user" is used in many places in the document where in practice=  

"the custome= r's CPE" would be more appropriate.

 

[Med= ] I agree that some occurrences can be replaced easily by subscriber or cus= tomer but still “user” is accurate. For example, it is not a customer that initiates a connection but a user (that may be the = customer itself or another person that uses the right to invoke the service= ). In order to avoid overloading the document with such subtleties, we pref= er to use “user” in the whole document.

 

 

Specific comments= :

 =

NAT64 is mentione= d as a use case at the start, but no example is given later in the 

document. This mi= ght add useful value.

 

[Med= ] Happily! We will update the text accordingly.

 

In= Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in= the 

TLV are 16 bit va= lues, but 32 bits are reserved for the element. Similarly the 

NatEvent element = is 8-bit, but has 32 bits reserved. It would be useful if the

document stated w= hy these elements are being padded out to 32 bits. <= /p>

 

[Med= ] Please check https://tool= s.ietf.org/html/rfc6158#appendix-A.2.1

 

In Section 4.1.1,= I don't think NAT64 is specifically designed to multiplex users=

over a smaller nu= mber of shared IPv4 addresses, rather its primary design goal

is to facilitate = access to legacy IPv4 content from IPv6-only networks.  The=

text should be cl= arified.

 

[Med] I guess you are refer=
ring to “over a smaller number of shared =
IPv4 addresses”. “Smaller” is=
 used here to indicate that the external IP address pool is not sufficient =
to assign a full IPv4 address to each internal host. NAT64 falls into such =
category. RFC6146 says: “One or more public IPv4 addresses ass=
igned to a NAT64
   translator are shared among several =
IPv6-only clients.”

 

Al= so in 4.1.1, do users really have service agreements that state port limits= ?

[Med= ] There is no assumption in the draft that SLAs include port limits.

 

If= they do, I doubt users are aware of them (or care...), and the issue is be= yond

the scope of this= document. 

[Med] Agree.

 =

In 4.1.2, I think= you mean "block", not "bulk"?  =

An= d the comment on "randomization" might fit better in the Security= Considerations

section if you di= scuss privacy there (which is presumably what you mean?)<= /p>

 

[Med= ] Can be added, indeed.

 

Also in 4.1.2 you= discuss the scenario as if it's CGN, but the flow diagram shows=

only the NAT44 (p= resumably in the CPE) and not an ISP CGN. 

 

[Med= ] No, the diagram shows a NAT that is collocated with a BNG. This is a CGN = case.

 

The same happens = in 4.1.3; discussion of CGN and NAT44 interchangeably, without

the diagram showi= ng there may (presumably) be mappings to establish at both the 

user's CPE and th= e ISP's CGN.

 

[Med] Idem as above=

--_000_787AE7BB302AE849A7480A190F8B933008E3101DOPEXCLILMA3corp_-- From nobody Wed Oct 5 14:16:01 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD3129474; Wed, 5 Oct 2016 14:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 JKU1EE6Yc6zV; Wed, 5 Oct 2016 14:15:53 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 A90F712944E; Wed, 5 Oct 2016 14:15:53 -0700 (PDT) X-AuditID: c618062d-72fff700000009b8-06-57f57049bbba Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 74.FD.02488.94075F75; Wed, 5 Oct 2016 23:27:39 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 17:15:50 -0400 From: Suresh Krishnan To: "mohamed.boucadair@orange.com" Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Index: AQHR+QQqdvcLhWKyI0SawtM1sGsq0Q== Date: Wed, 5 Oct 2016 21:15:50 +0000 Message-ID: References: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> <75698fc6-9d4d-4a62-9219-973a3019e887@OPEXCLILM44.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPgq53wddwg/XTJCzmTSq1mPFnIrPF 7e2ZFoffPmW3eNrxhcmi5dVMNgc2jyVLfjJ5tDw7yRbAFMVlk5Kak1mWWqRvl8CVcevuc+aC D4wVU1ZMYGtgPMrYxcjJISFgInHr3RYgm4tDSGADo8TapZ1QzjJGiSVf3jGDVLEBVW3Y+ZkJ xBYRcJSY8Wo2G0gRs0A/k0Tb66dsIAlhgQyJA0sfMUIUZUo8+DMXyOYAsvUkdrUJgYRZBFQk fr++CFbCK+Arcfl+CzvEskWMEtuXbwSbwyggJvH91BqwZcwC4hK3nsxngjhVQGLJnvPMELao xMvH/1ghbCWJOa+vMUPU60gs2P2JDcLWlli28DUzxDJBiZMzn7BMYBSZhWTsLCQts5C0zELS soCRZRUjR2lxQU5uupHBJkZgdByTYNPdwXh/uuchRgEORiUe3gX2X8OFWBPLiitzDzFKcDAr ifDuzgIK8aYkVlalFuXHF5XmpBYfYpTmYFES541bfT9cSCA9sSQ1OzW1ILUIJsvEwSnVwJiw jLtPp0exMfDczbxrm57cWR7Odt369CoR/WJjuc9pWm1v/5z7uqV3/8u+t1vKvRdLaH+sXtoU 9jzzqn/e37IHEqazz0/r8lU8XPzExGeHbaWnYKzhs8MZ719/uSwtEaXY33jrjcRZ0aevLEt+ emdKbzie+GXDz9Wva6+yaS2ftlNzVvqr5cxKLMUZiYZazEXFiQB4w59ligIAAA== Archived-At: Cc: The IESG , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 21:15:55 -0000 On 10/05/2016 09:59 AM, mohamed.boucadair@orange.com wrote:=0A= > Hi Suresh,=0A= >=0A= > Thank you for the review.=0A= =0A= Thanks for addressing my comments Med. Your changes look good to me.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Tue Oct 11 09:27:02 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B4A129642; Tue, 11 Oct 2016 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 qxipSYBKVcD6; Tue, 11 Oct 2016 09:26:59 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F248C1295D5; Tue, 11 Oct 2016 09:26:55 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id b186so25081578vkb.1; Tue, 11 Oct 2016 09:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MWQGNuGfpRu72ZiqVAgHB5H/0B6tjkYEpEewp9VnepQ=; b=gYoYtFq3blRap6h07G11efHSwQY8vQDX4bvdhov4RAdbCLpVw1hn9E/ytPjX/QBns+ FmIyrsAWmz/7wAfCvUBVHppGO6uj03wcKmfFqes4Snpod1rwNn1T+ovZbAoMinQwpRbg 0GaXFrgR93Ys3H6s5xHnJ117hLvhqVUYFHEg8DNWmmVZCTjztnncrquHawFPrToIyavF Htr76aYAhcaKVg++WADQfme5OOEdCFmyqotUQ2o/Y76N9G54QoG5MoeQcoO1bqVouq5C rXMAwJ85H+qkrqU+IIFej/XkGG0460fquLud4Ln86rbZjYH+tVz3V5Jm7oMtEFdw4QVN Q+KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MWQGNuGfpRu72ZiqVAgHB5H/0B6tjkYEpEewp9VnepQ=; b=VH4WVQH5JdxF8dqCuEynGdI+oQCq6Wj2ZyA7NO4SlUUd37VNkmCZlP04nJAyeszKxK qEIyWSRQSU4zcBaZJUkhaMh/uqWIk6v1hQMqYgBdtNVMUCd1PoyTBNUhcugNUTkytusZ o6ChVre6+XCfcVx3N3CTx1inC5pYbUa01CWzxp2Bocw0769AOUFDSbTTJyHPpGDqvsK1 XfUkqEMEHV7n6jmAwGxVWD+ZY1BqaNcjCGhMQEbnwKWAwUfHZByIwOfbjtlORTdIiyzm aDnke+jRSGy+7XTXAoz7dL6cROIYy8lPxYrxtXlLTNx7If8DOCe0xMQNTJQkClV7R5qZ Gbig== X-Gm-Message-State: AA6/9Rnvn8x7wJAsvtbWofHH6uL7t1SqnnWBQaSQy16e99rJ7+x+LbbK7jYGKTl+ApTO+vG/tlPi48+pG1Fniw== X-Received: by 10.31.73.71 with SMTP id w68mr3230602vka.13.1476203214857; Tue, 11 Oct 2016 09:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 11 Oct 2016 09:26:54 -0700 (PDT) In-Reply-To: References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 11 Oct 2016 12:26:54 -0400 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1148d00a3ced74053e9958b9 Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-datatypes@ietf.org" , Winter Stefan , Alan DeKok , The IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:27:01 -0000 --001a1148d00a3ced74053e9958b9 Content-Type: text/plain; charset=UTF-8 Hi Suresh, The new version was posted. Can you check to see if you are satisfied with the changes? Thank you, Kathleen On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Alan, > Thanks for your response. I will clear once you post a new version with > the changes. > > Thanks > Suresh > > On 08/18/2016 12:36 PM, Alan DeKok wrote: > > On Aug 17, 2016, at 5:43 AM, Suresh Krishnan < > suresh.krishnan@ericsson.com> wrote: > >> * Section 3.10 > >> > >> It is not clear from this definition how exactly a sender needs to > encode > >> this attribute on the wire. e.g. From the spec it looks like an IPv6 > >> prefix such 2001:db8:dead:beef::/64 can legally be encoded using > anywhere > >> between 8 octets and 16 octets. What exactly is the preferred encoding? > >> If you intend to allow all of the encodings can you please add an > >> explicit statement to say so. > > > > The preferred encoding should be the shortest one. I'll put some text > together. > > > >> * I am not sure why this document uses Reserved fields in sections 3.10 > >> and 3.11. Is it for alignment? Please clarify. I don't see exactly why > >> aligning a 4 octet or a 16 octet value to a 16 bit boundary would > provide > >> any value. > >> (I personally think such padding related stuff should be in the > >> definition of the radius attribute that uses the datatype and not in the > >> datatype itself but I will not block on this.) > > > > The data types in 3.10 and 3.11 are taken from previous > specifications. I'm not entirely sure why they have reserved fields, > either. > > > > We can't change the format of the data type, because implementations > use this format. The document just codifies existing practices. > > > >> * Section 3.7 > >> > >> I think this text is confusing because "octet string" and network byte > >> order do not seem to be compatible. Suggest rewording > >> > >> OLD: > >> The "ifid" data type encodes an Interface-Id as an 8-octet string in > >> network byte order > >> > >> NEW: > >> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in > >> network byte order > > > > Sounds good. > > > >> * Section 3.10 and 3.11 > >> > >> The separator between the Reserved field and the Prefix Length field is > >> off by one position. > > > > Fixed. > > > > > -- Best regards, Kathleen --001a1148d00a3ced74053e9958b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Suresh,

The new version was posted.= =C2=A0 Can you check to see if you are satisfied with the changes?

Thank you,
Kathleen

On Thu, Aug 18, 2016 at 11:01 PM, = Suresh Krishnan <suresh.krishnan@ericsson.com> wr= ote:
Hi Alan,
=C2=A0 =C2=A0Thanks for your response. I will clear once you post a new ver= sion with
the changes.

Thanks
Suresh

On 08/18/2016 12:36 PM, Alan DeKok wrote:
> On Aug 17, 2016, at 5:43 AM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
>> * Section 3.10
>>
>> It is not clear from this definition how exactly a sender needs to= encode
>> this attribute on the wire. e.g. From the spec it looks like an IP= v6
>> prefix such 2001:db8:dead:beef::/64 can legally be encoded using a= nywhere
>> between 8 octets and 16 octets. What exactly is the preferred enco= ding?
>> If you intend to allow all of the encodings can you please add an<= br> >> explicit statement to say so.
>
>=C2=A0 =C2=A0The preferred encoding should be the shortest one.=C2=A0 I= 'll put some text together.
>
>> * I am not sure why this document uses Reserved fields in sections= 3.10
>> and 3.11. Is it for alignment? Please clarify. I don't see exa= ctly why
>> aligning a 4 octet or a 16 octet value to a 16 bit boundary would = provide
>> any value.
>> (I personally think such padding related stuff should be in the >> definition of the radius attribute that uses the datatype and not = in the
>> datatype itself but I will not block on this.)
>
>=C2=A0 =C2=A0The data types in 3.10 and 3.11 are taken from previous sp= ecifications.=C2=A0 I'm not entirely sure why they have reserved fields= , either.
>
>=C2=A0 =C2=A0We can't change the format of the data type, because i= mplementations use this format.=C2=A0 The document just codifies existing p= ractices.
>
>> * Section 3.7
>>
>> I think this text is confusing because "octet string" an= d network byte
>> order do not seem to be compatible. Suggest rewording
>>
>> OLD:
>> The "ifid" data type encodes an Interface-Id as an 8-oct= et string in
>>=C2=A0 =C2=A0network byte order
>>
>> NEW:
>> The "ifid" data type encodes an 8 octet IPv6 Interface I= dentifier in
>>=C2=A0 =C2=A0network byte order
>
>=C2=A0 =C2=A0Sounds good.
>
>> * Section 3.10 and 3.11
>>
>> The separator between the Reserved field and the Prefix Length fie= ld is
>> off by one position.
>
>=C2=A0 =C2=A0Fixed.
>





--
=

Best regards,
Kathleen
--001a1148d00a3ced74053e9958b9-- From nobody Tue Oct 11 09:34:57 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6912964E; Tue, 11 Oct 2016 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ycdyqNfiW8-x; Tue, 11 Oct 2016 09:34:47 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C77129652; Tue, 11 Oct 2016 09:34:46 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id 192so24995038vkl.2; Tue, 11 Oct 2016 09:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d7WVRhgDMH3EQ1EnqW8PO9j3GdiDcN4K46GROT+K0Nc=; b=CT7id4jOoHJ/JoVEQqTFoWagg8Sul8hMlXXYmlQfGtm1OmgXo87R91kbSbs3vJeWvl a6HYZF9IlTzCZP+PqWXDQ8wub6OmKZH/hrldNYbtgA9MKXmwRD3i80oRvy/WsAqA2K03 0hTmg1bNiK4c0uppmnhI5D7x8mACeV+2eX8s7Z4zpm9YruBV4EnBDdq+EvNm79LgY+m4 FaWVH+A+xG5iQtrhiC/dAcs5vlGrEDLPnBAWGS3+4h2+9k/7ot63ALuIaYyakwTXlBkn 5XcWPwRRHAEwTI8V9y0k0XVVYCjbTUF/dxg+5oVadz9YG+qU66AUg/57W+9O6yp1LFWS 1vZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d7WVRhgDMH3EQ1EnqW8PO9j3GdiDcN4K46GROT+K0Nc=; b=CaHMvBFKEl9v/eXRrv1Pjq59HlJLQ6T+c7lOhR3J/prNBbaYKdmlMKhCLuWsu6AGhP zQxq8VN3WX6z32zcVKrPyZeUdnrBntSZmgLJ0MMAoY15ha0KmlOEd+JQyJKZWyHYhmmk DU0vHGNHVfTbVUCCtxCaV+3rU44Xip0+2FvhKuwmzSgX8nyyMAZQWseDwtZwY6QDRedK Sz+kdKV/4oJpIRUTWVbxNSx7rrcZToQ1c6QdYVdGkQyNziaq6818PA+gBoW8srD+hYrC mAHfUciRbFZ9U2LbxO3jBFjv1zGn42EIQC+6RoPk1I6fkW2Sxw+5vCBHb7pzWwFRKTYd vwaQ== X-Gm-Message-State: AA6/9Rk/VDOus4nXVTQE8RzpW1Q3WEx/rxp4kgsmhj63RldTwLeDkgMm77TsHLR4UcDUMy8LaoCQLbI9wJms/Q== X-Received: by 10.31.69.16 with SMTP id s16mr4038833vka.115.1476203684555; Tue, 11 Oct 2016 09:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 11 Oct 2016 09:34:44 -0700 (PDT) In-Reply-To: <99B00097-B852-4A46-8CEB-6265DCBEA85D@trammell.ch> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> <99B00097-B852-4A46-8CEB-6265DCBEA85D@trammell.ch> From: Kathleen Moriarty Date: Tue, 11 Oct 2016 12:34:44 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114db3ce3bf5e9053e997433 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , Jouni Korhonen , "" , "Mirja Kuehlewind \(IETF\)" , The IESG , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:34:50 -0000 --001a114db3ce3bf5e9053e997433 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Med, Can you also respond to this message, it contains the details of the IPFIX review. Thank you, Kathleen On Fri, Sep 2, 2016 at 1:07 PM, Brian Trammell wrote: > hi Kathleen, all, > > Sorry, this fell off my radar, due to the present emergency. > > Review text below: > > In general, the Information Elements in draft-ietf-radext-ip-port-radius-= ext > are so underspecified as to be unimplementable. They should not be added = to > the registry in their present form. The authors are advised to read RFC > 7013, especially Section 4, which provides useful information on defining > Information Elements. Specifically: > > The Information Element transportType is underspecified: (a) I presume > this is in reference to sourceTransportPort and destinationTransportPort, > but the description must say this if it is the case; (b) It's not clear a= t > all from the description in what context this distinction is useful; (c) > What's an ICMP identifier? > > In addition, the description of transportType appears to create a table > which should probably be handled as a subregistry. See See RFC7013 sectio= n > 4.7. for advice on the creation of tables without subregistries (in short= , > "don't".) > > The Information Element natTransportLimit has an inappropriate name; it > does not describe that which it (presumably) is supposed to represent (se= e > RFC 7013 section 4.1). In addition, it is underspecified. It is impossibl= e > to implement from the description. Is the field IPv4 specific, or is IPv6 > supported as well? (If not, why not?) > > The Information Element localID has an inappropriate name; it is far too > general (see RFC 7013 section 4.1). It uses an inappropriate abstract dat= a > type (addresses should never be represented as UTF-8 strings in IPFIX, se= e > RFC 7013 section 4.2). It is underspecified as well as poorly designed. > Without the ability to disambiguate the type of information in the field, > this is not a useful Information Element. Without a complete enumeration = of > possible types (n.b. 'etc.' in the description), it is not a useful > Information Element. Its purpose is unclear from its description; furthe= r, > it appears to violate the following guidance in RFC 7013 section 4: "The > Information Element must be unique within the registry, and its descripti= on > must represent a substantially different meaning from that of any existin= g > Information Element. An existing Information Element that can be reused > for a given purpose should be reused." > > Best regards, > > Brian Trammell (for the IE-Doctors) > > > > On 02 Sep 2016, at 18:41, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF) > > wrote: > >> Did finally send someone the review to the right people or should I > ping Brian (again)? > > > > That would be helpful, I believe we are still waiting for the review. > > > > Thanks, > > Kathleen > > > >> > >> Mirja > >> > >> > >>> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com>: > >>> > >>> Apparently, Brian did the review. I'm adding him to this thread so h= e > >>> can send the review to the draft distribution list. > >>> > >>> Thank you, > >>> Kathleen > >>> > >>> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen < > jouni.nospam@gmail.com> wrote: > >>>> Hi, > >>>> > >>>> Would it be possible to see the IE doctor's feedback? The authors > might find > >>>> it useful as well. If it has been distributed already, my apologies > if I > >>>> missed it. > >>>> > >>>> regards, > >>>> Jouni > >>>> > >>>> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: > >>>>> > >>>>> Mirja K=C3=BChlewind has entered the following ballot position for > >>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss > >>>>> > >>>>> When responding, please keep the subject line intact and reply to a= ll > >>>>> email addresses included in the To and CC lines. (Feel free to cut > this > >>>>> introductory paragraph, however.) > >>>>> > >>>>> > >>>>> Please refer to https://www.ietf.org/iesg/ > statement/discuss-criteria.html > >>>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found here: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port- > radius-ext/ > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------ > ---------- > >>>>> DISCUSS: > >>>>> ------------------------------------------------------------ > ---------- > >>>>> > >>>>> I fully support Alissa's discussion points and have two more to > >>>>> add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip- > port-radius-ext/ > >>>>> > >>>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very > >>>>> future-proof: there are other transport protocols that have ports o= r > >>>>> identifiers that may want to be supported in future. Also it is not > clear > >>>>> to me from the document why this information is needed at all in th= e > >>>>> described use cases. Therefore I see two possible ways forward: > Either > >>>>> remove the IP-Port-Type TLV or extend it to also cover other cases. > >>>>> > >>>>> Related to this point I would like to mention that RFC6887 is not > >>>>> restricted to UDP/TCP and therefore the following sentence in > section 2 > >>>>> is not correct: > >>>>> "Note that the definitions of [...] "internal port", [...] "externa= l > >>>>> port" [...] are the same as defined in Port Control Protocol (PCP) > >>>>> [RFC6887]" > >>>>> > >>>>> 2) The IE doctors have provide feedback to IANA that the Informatio= n > >>>>> Elements in this doc are underspecified (not confirm with rules in > RFC > >>>>> 7013) and should therefore be not registered. Addressing this > feedback > >>>>> could lead to a mayor rewrite of this doc, especially in the > relation to > >>>>> the use and definition of transportType and receptively IP-Port-Typ= e > TLV, > >>>>> and should therefore be done before a final IESG decision. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Best regards, > >>> Kathleen > >>> > >> > > > > > > > > -- > > > > Best regards, > > Kathleen > > --=20 Best regards, Kathleen --001a114db3ce3bf5e9053e997433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Med,

Can you also respond to this= message, it contains the details of the IPFIX review.

=
Thank you,
Kathleen
On Fri, Sep 2, 2016 at 1:07 PM, Brian Trammell= <ietf@trammell.ch> wrote:
= hi Kathleen, all,

Sorry, this fell off my radar, due to the present emergency.

Review text below:

In general, the Information Elements in draft-ietf-radext-ip-port-radi= us-ext are so underspecified as to be unimplementable. They should not be a= dded to the registry in their present form. The authors are advised to read= RFC 7013, especially Section 4, which provides useful information on defin= ing Information Elements. Specifically:

The Information Element transportType is underspecified: (a) I presume this= is in reference to sourceTransportPort and destinationTransportPort, but t= he description must say this if it is the case; (b) It's not clear at a= ll from the description in what context this distinction is useful; (c) Wha= t's an ICMP identifier?

In addition, the description of transportType appears to create a table whi= ch should probably be handled as a subregistry. See See RFC7013 section 4.7= . for advice on the creation of tables without subregistries (in short, &qu= ot;don't".)

The Information Element natTransportLimit has an inappropriate name; it doe= s not describe that which it (presumably) is supposed to represent (see RFC= 7013 section 4.1). In addition, it is underspecified. It is impossible to = implement from the description. Is the field IPv4 specific, or is IPv6 supp= orted as well? (If not, why not?)

The Information Element localID has an inappropriate name; it is far too ge= neral (see RFC 7013 section 4.1). It uses an inappropriate abstract data ty= pe (addresses should never be represented as UTF-8 strings in IPFIX, see RF= C 7013 section 4.2). It is underspecified as well as poorly designed. Witho= ut the ability to disambiguate the type of information in the field, this i= s not a useful Information Element. Without a complete enumeration of possi= ble types (n.b. 'etc.' in the description), it is not a useful Info= rmation Element.=C2=A0 Its purpose is unclear from its description; further= , it appears to violate the following guidance in RFC 7013 section 4: "= ;The Information Element must be unique within the registry, and its descri= ption must represent a substantially different meaning from that of any exi= sting Information Element.=C2=A0 An existing Information Element that can b= e reused for a given purpose should be reused."

Best regards,

Brian Trammell (for the IE-Doctors)


> On 02 Sep 2016, at 18:41, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
>
> On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF)
> <ietf@kuehlewind.net>= wrote:
>> Did finally send someone the review to the right people or should = I ping Brian (again)?
>
> That would be helpful, I believe we are still waiting for the review.<= br> >
> Thanks,
> Kathleen
>
>>
>> Mirja
>>
>>
>>> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty <kathleen.moriarty.ietf@gmail.<= wbr>com>:
>>>
>>> Apparently, Brian did the review.=C2=A0 I'm adding him to = this thread so he
>>> can send the review to the draft distribution list.
>>>
>>> Thank you,
>>> Kathleen
>>>
>>> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to see the IE doctor's feedback? = The authors might find
>>>> it useful as well. If it has been distributed already, my = apologies if I
>>>> missed it.
>>>>
>>>> regards,
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Jouni
>>>>
>>>> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti:
>>>>>
>>>>> Mirja K=C3=BChlewind has entered the following ballot = position for
>>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss<= br> >>>>>
>>>>> When responding, please keep the subject line intact a= nd reply to all
>>>>> email addresses included in the To and CC lines. (Feel= free to cut this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to https:= //www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT po= sitions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can b= e found here:
>>>>> https://d= atatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/=
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------= ---------------------
>>>>> DISCUSS:
>>>>> -------------------------------------------------= ---------------------
>>>>>
>>>>> I fully support Alissa's discussion points and hav= e two more to
>>>>> add:https= ://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/=
>>>>>
>>>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. Thi= s is not very
>>>>> future-proof: there are other transport protocols that= have ports or
>>>>> identifiers that may want to be supported in future. A= lso it is not clear
>>>>> to me from the document why this information is needed= at all in the
>>>>> described use cases. Therefore I see two possible ways= forward: Either
>>>>> remove the IP-Port-Type TLV or extend it to also cover= other cases.
>>>>>
>>>>> Related to this point I would like to mention that RFC= 6887 is not
>>>>> restricted to UDP/TCP and therefore the following sent= ence in section 2
>>>>> is not correct:
>>>>> "Note that the definitions of [...] "interna= l port", [...] "external
>>>>> port" [...] are the same as defined in Port Contr= ol Protocol (PCP)
>>>>> [RFC6887]"
>>>>>
>>>>> 2) The IE doctors have provide feedback to IANA that t= he Information
>>>>> Elements in this doc are underspecified (not confirm w= ith rules in RFC
>>>>> 7013) and should therefore be not registered.=C2=A0 Ad= dressing this feedback
>>>>> could lead to a mayor rewrite of this doc, especially = in the relation to
>>>>> the use and definition of transportType and receptivel= y IP-Port-Type TLV,
>>>>> and should therefore be done before a final IESG decis= ion.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen




--
=

Best regards,
Kathleen
--001a114db3ce3bf5e9053e997433-- From nobody Tue Oct 11 12:34:56 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6B512966C; Tue, 11 Oct 2016 12:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 lAwN7JEgi_eY; Tue, 11 Oct 2016 12:34:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B641294B7; Tue, 11 Oct 2016 12:34:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSV85542; Tue, 11 Oct 2016 19:34:45 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 11 Oct 2016 20:34:44 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 11 Oct 2016 12:34:38 -0700 From: Dean cheng To: Kathleen Moriarty , Brian Trammell Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yYWRl?= =?utf-8?Q?xt-ip-port-radius-ext-11:_(with_DISCUSS)?= Thread-Index: AQHSI91tSyFxNpDjZ0S94dnJiwK8RqCjnbTQ Date: Tue, 11 Oct 2016 19:34:37 +0000 Message-ID: References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> <99B00097-B852-4A46-8CEB-6265DCBEA85D@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.108] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F686F3008DCdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.57FD3ED7.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a8de9c3b9bcadc31ca36c9c18bbabdf Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Jouni Korhonen , "" , "Mirja Kuehlewind \(IETF\)" , The IESG , "radext-chairs@ietf.org" Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:34:54 -0000 --_000_DC7880973D477648AC15A3BA66253F686F3008DCdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4gLSB0aGFua3MgZm9yIHRoZSByZW1pbmRlci4NCg0KQnJhaW4gLSB0aGFua3MgZm9y IHRoZSBjb21tZW50cywgYW5kIHdlJ3ZlIHVwZGF0ZWQNCm91ciBkcmFmdCAoMTMudHh0KSB0byBp bmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzIHNlZQ0KYmVsb3cuDQoNCkNoZWVycywNCkRlYW4NCg0K RnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIwMTYgOTozNSBBTQ0KVG86IEJy aWFuIFRyYW1tZWxsDQpDYzogZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGll dGYub3JnOyA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgSm91bmkgS29yaG9uZW47IE1pcmph IEt1ZWhsZXdpbmQgKElFVEYpOyBUaGUgSUVTRzsgcmFkZXh0QGlldGYub3JnOyByYWRleHQtY2hh aXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBESVNDVVNTKQ0K DQpIZWxsbyBNZWQsDQoNCkNhbiB5b3UgYWxzbyByZXNwb25kIHRvIHRoaXMgbWVzc2FnZSwgaXQg Y29udGFpbnMgdGhlIGRldGFpbHMgb2YgdGhlIElQRklYIHJldmlldy4NCg0KVGhhbmsgeW91LA0K S2F0aGxlZW4NCg0KT24gRnJpLCBTZXAgMiwgMjAxNiBhdCAxOjA3IFBNLCBCcmlhbiBUcmFtbWVs bCA8aWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaD4+IHdyb3RlOg0KaGkg S2F0aGxlZW4sIGFsbCwNCg0KU29ycnksIHRoaXMgZmVsbCBvZmYgbXkgcmFkYXIsIGR1ZSB0byB0 aGUgcHJlc2VudCBlbWVyZ2VuY3kuDQoNClJldmlldyB0ZXh0IGJlbG93Og0KDQpJbiBnZW5lcmFs LCB0aGUgSW5mb3JtYXRpb24gRWxlbWVudHMgaW4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1y YWRpdXMtZXh0IGFyZSBzbyB1bmRlcnNwZWNpZmllZCBhcyB0byBiZSB1bmltcGxlbWVudGFibGUu IFRoZXkgc2hvdWxkIG5vdCBiZSBhZGRlZCB0byB0aGUgcmVnaXN0cnkgaW4gdGhlaXIgcHJlc2Vu dCBmb3JtLiBUaGUgYXV0aG9ycyBhcmUgYWR2aXNlZCB0byByZWFkIFJGQyA3MDEzLCBlc3BlY2lh bGx5IFNlY3Rpb24gNCwgd2hpY2ggcHJvdmlkZXMgdXNlZnVsIGluZm9ybWF0aW9uIG9uIGRlZmlu aW5nIEluZm9ybWF0aW9uIEVsZW1lbnRzLiBTcGVjaWZpY2FsbHk6DQoNCkRDPg0KSW4gdGhlIDEx LnR4dCwgd2UgcHJvcG9zZWQgdGhyZWUgbmV3IElQRklYIElFcyBhbmQgaW4gdGhlIDEzLnR4dCwN CndlJ3ZlIHJlbW92ZWQgb3IgdXBkYXRlZCB0aGVtIGFzIHRoZSBmb2xsb3dpbmc6DQoNCiAgICAg IDExLnR4dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEzLnR4dA0KICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgICAgdHJhbnNwb3J0VHlwZSAgICAgICAgICAgICAgICAgIHJlbW92ZWQgdGhp cyBhcyBhbiBJUEZJWCBJRQ0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgbmF0VHJhbnNwb3J0TGlt aXQgICAgICAgICAgIHJlbmFtZWQgdGhpcyBJRSBhcyAiIHNvdXJjZVRyYW5zcG9ydFBvcnRzTGlt aXQiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFs b25nIHdpdGggcmV2aXNlZCBkZXNjcmlwdGlvbi4NCiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIGxv Y2FsSUQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVtb3ZlZCB0aGlzIGFzIGFuIElQ RklYIElFDQoNClRoZSBJbmZvcm1hdGlvbiBFbGVtZW50IHRyYW5zcG9ydFR5cGUgaXMgdW5kZXJz cGVjaWZpZWQ6IChhKSBJIHByZXN1bWUgdGhpcyBpcyBpbiByZWZlcmVuY2UgdG8gc291cmNlVHJh bnNwb3J0UG9ydCBhbmQgZGVzdGluYXRpb25UcmFuc3BvcnRQb3J0LCBidXQgdGhlIGRlc2NyaXB0 aW9uIG11c3Qgc2F5IHRoaXMgaWYgaXQgaXMgdGhlIGNhc2U7IChiKSBJdCdzIG5vdCBjbGVhciBh dCBhbGwgZnJvbSB0aGUgZGVzY3JpcHRpb24gaW4gd2hhdCBjb250ZXh0IHRoaXMgZGlzdGluY3Rp b24gaXMgdXNlZnVsOyAoYykgV2hhdCdzIGFuIElDTVAgaWRlbnRpZmllcj8NCg0KREM+DQpUaGlz IElFIGFzIHByb3Bvc2VkIGluIDExLnR4dCBoYXMgYmVlbiByZW1vdmVkIGluIDEzLnR4dC4NCldl IG5vdyBpbmNsdWRlICJQcm90b2NvbC1OdW1iZXIiIGRlZmluZWQgYnkgSUFOQSwNCmkuZS4sIHRo ZSBwcm90b2NvbCBJRCwgaW4gdGhlIFZhbHVlIGZpZWxkIG9mIElQLVBvcnQtVHlwZSBUTFYuDQpQ cm90b2NvbHMgdGhhdCBkbyBub3QgdXNlIHBvcnQgbnVtYmVycyAoc3VjaCBhcyBJQ01QKQ0KYXJl IG5vdCBpbmNsdWRlZCBpbiB0aGlzIFRMVi4gUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gMy4yLjEg Zm9yIGRldGFpbHMuDQoNCkluIGFkZGl0aW9uLCB0aGUgZGVzY3JpcHRpb24gb2YgdHJhbnNwb3J0 VHlwZSBhcHBlYXJzIHRvIGNyZWF0ZSBhIHRhYmxlIHdoaWNoIHNob3VsZCBwcm9iYWJseSBiZSBo YW5kbGVkIGFzIGEgc3VicmVnaXN0cnkuIFNlZSBTZWUgUkZDNzAxMyBzZWN0aW9uIDQuNy4gZm9y IGFkdmljZSBvbiB0aGUgY3JlYXRpb24gb2YgdGFibGVzIHdpdGhvdXQgc3VicmVnaXN0cmllcyAo aW4gc2hvcnQsICJkb24ndCIuKQ0KDQpEQz4gTm8gaXNzdWUgaGVyZSBzaW5jZSB0aGVyZSBpcyBu byBwcm9wb3NlZCBJRSBoZXJlLg0KDQpUaGUgSW5mb3JtYXRpb24gRWxlbWVudCBuYXRUcmFuc3Bv cnRMaW1pdCBoYXMgYW4gaW5hcHByb3ByaWF0ZSBuYW1lOyBpdCBkb2VzIG5vdCBkZXNjcmliZSB0 aGF0IHdoaWNoIGl0IChwcmVzdW1hYmx5KSBpcyBzdXBwb3NlZCB0byByZXByZXNlbnQgKHNlZSBS RkMgNzAxMyBzZWN0aW9uIDQuMSkuIEluIGFkZGl0aW9uLCBpdCBpcyB1bmRlcnNwZWNpZmllZC4g SXQgaXMgaW1wb3NzaWJsZSB0byBpbXBsZW1lbnQgZnJvbSB0aGUgZGVzY3JpcHRpb24uIElzIHRo ZSBmaWVsZCBJUHY0IHNwZWNpZmljLCBvciBpcyBJUHY2IHN1cHBvcnRlZCBhcyB3ZWxsPyAoSWYg bm90LCB3aHkgbm90PykNCg0KREM+IFdlIGNoYW5nZWQgdGhlIG5hbWUgdG8gIiBzb3VyY2VUcmFu c3BvcnRQb3J0c0xpbWl0Ig0KYWxvbmcgd2l0aCB0aGUgZGVzY3JpcHRpb24uIEl0IGluZGljYXRl cyB0aGUgbGltaXQgaW1wb3NlZA0KdG8gYSB1c2VyIG9uIHRoZSBtYXggc291cmNlIHBvcnQgbnVt YmVyLCBhbmQgY2FuIGJlIGFzc29jaWF0ZWQNCndpdGggYW4gSVB2NCBvciBJUHY2IGFkZHJlc3Mu IFJlZmVyIHRvIFNlY3Rpb24gMy4yLjINCmFuZCA3LjEgZm9yIGRldGFpbHMuDQoNClRoZSBJbmZv cm1hdGlvbiBFbGVtZW50IGxvY2FsSUQgaGFzIGFuIGluYXBwcm9wcmlhdGUgbmFtZTsgaXQgaXMg ZmFyIHRvbyBnZW5lcmFsIChzZWUgUkZDIDcwMTMgc2VjdGlvbiA0LjEpLiBJdCB1c2VzIGFuIGlu YXBwcm9wcmlhdGUgYWJzdHJhY3QgZGF0YSB0eXBlIChhZGRyZXNzZXMgc2hvdWxkIG5ldmVyIGJl IHJlcHJlc2VudGVkIGFzIFVURi04IHN0cmluZ3MgaW4gSVBGSVgsIHNlZSBSRkMgNzAxMyBzZWN0 aW9uIDQuMikuIEl0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIHdlbGwgYXMgcG9vcmx5IGRlc2lnbmVk LiBXaXRob3V0IHRoZSBhYmlsaXR5IHRvIGRpc2FtYmlndWF0ZSB0aGUgdHlwZSBvZiBpbmZvcm1h dGlvbiBpbiB0aGUgZmllbGQsIHRoaXMgaXMgbm90IGEgdXNlZnVsIEluZm9ybWF0aW9uIEVsZW1l bnQuIFdpdGhvdXQgYSBjb21wbGV0ZSBlbnVtZXJhdGlvbiBvZiBwb3NzaWJsZSB0eXBlcyAobi5i LiAnZXRjLicgaW4gdGhlIGRlc2NyaXB0aW9uKSwgaXQgaXMgbm90IGEgdXNlZnVsIEluZm9ybWF0 aW9uIEVsZW1lbnQuICBJdHMgcHVycG9zZSBpcyB1bmNsZWFyIGZyb20gaXRzIGRlc2NyaXB0aW9u OyBmdXJ0aGVyLCBpdCBhcHBlYXJzIHRvIHZpb2xhdGUgdGhlIGZvbGxvd2luZyBndWlkYW5jZSBp biBSRkMgNzAxMyBzZWN0aW9uIDQ6ICJUaGUgSW5mb3JtYXRpb24gRWxlbWVudCBtdXN0IGJlIHVu aXF1ZSB3aXRoaW4gdGhlIHJlZ2lzdHJ5LCBhbmQgaXRzIGRlc2NyaXB0aW9uIG11c3QgcmVwcmVz ZW50IGEgc3Vic3RhbnRpYWxseSBkaWZmZXJlbnQgbWVhbmluZyBmcm9tIHRoYXQgb2YgYW55IGV4 aXN0aW5nIEluZm9ybWF0aW9uIEVsZW1lbnQuICBBbiBleGlzdGluZyBJbmZvcm1hdGlvbiBFbGVt ZW50IHRoYXQgY2FuIGJlIHJldXNlZCBmb3IgYSBnaXZlbiBwdXJwb3NlIHNob3VsZCBiZSByZXVz ZWQuIg0KDQpEQz4gV2UgcmVtb3ZlZCB0aGlzIHByb3Bvc2VkIElFIGluIDEzLnR4dC4gSW4gdGhl IFZhbHVlIGZpZWxkDQpvZiBJUC1Qb3J0LUxvY2FsLUlkIFRMViAoU2VjdGlvbiAzLjIuMTEpLCB3 ZSBub3cgaW5jbHVkZSBhICJsb2NhbElEIg0Kb2YgInN0cmluZyIgYXMgdGhlIGRhdGEgdHlwZSAo cmVmZXIgdG8gaWV0Zi1yYWRleHQtZGF0YXR5cGVzLnR4dCkuDQoNCkJlc3QgcmVnYXJkcywNCg0K QnJpYW4gVHJhbW1lbGwgKGZvciB0aGUgSUUtRG9jdG9ycykNCg0KDQo+IE9uIDAyIFNlcCAyMDE2 LCBhdCAxODo0MSwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0K Pg0KPiBPbiBGcmksIFNlcCAyLCAyMDE2IGF0IDc6NDQgQU0sIE1pcmphIEt1ZWhsZXdpbmQgKElF VEYpDQo+IDxpZXRmQGt1ZWhsZXdpbmQubmV0PG1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4g d3JvdGU6DQo+PiBEaWQgZmluYWxseSBzZW5kIHNvbWVvbmUgdGhlIHJldmlldyB0byB0aGUgcmln aHQgcGVvcGxlIG9yIHNob3VsZCBJIHBpbmcgQnJpYW4gKGFnYWluKT8NCj4NCj4gVGhhdCB3b3Vs ZCBiZSBoZWxwZnVsLCBJIGJlbGlldmUgd2UgYXJlIHN0aWxsIHdhaXRpbmcgZm9yIHRoZSByZXZp ZXcuDQo+DQo+IFRoYW5rcywNCj4gS2F0aGxlZW4NCj4NCj4+DQo+PiBNaXJqYQ0KPj4NCj4+DQo+ Pj4gQW0gMTcuMDguMjAxNiB1bSAxOToxOCBzY2hyaWViIEthdGhsZWVuIE1vcmlhcnR5IDxrYXRo bGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0 ZkBnbWFpbC5jb20+PjoNCj4+Pg0KPj4+IEFwcGFyZW50bHksIEJyaWFuIGRpZCB0aGUgcmV2aWV3 LiAgSSdtIGFkZGluZyBoaW0gdG8gdGhpcyB0aHJlYWQgc28gaGUNCj4+PiBjYW4gc2VuZCB0aGUg cmV2aWV3IHRvIHRoZSBkcmFmdCBkaXN0cmlidXRpb24gbGlzdC4NCj4+Pg0KPj4+IFRoYW5rIHlv dSwNCj4+PiBLYXRobGVlbg0KPj4+DQo+Pj4gT24gV2VkLCBBdWcgMTcsIDIwMTYgYXQgMToxMyBQ TSwgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb208bWFpbHRvOmpvdW5pLm5v c3BhbUBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4gSGksDQo+Pj4+DQo+Pj4+IFdvdWxkIGl0IGJl IHBvc3NpYmxlIHRvIHNlZSB0aGUgSUUgZG9jdG9yJ3MgZmVlZGJhY2s/IFRoZSBhdXRob3JzIG1p Z2h0IGZpbmQNCj4+Pj4gaXQgdXNlZnVsIGFzIHdlbGwuIElmIGl0IGhhcyBiZWVuIGRpc3RyaWJ1 dGVkIGFscmVhZHksIG15IGFwb2xvZ2llcyBpZiBJDQo+Pj4+IG1pc3NlZCBpdC4NCj4+Pj4NCj4+ Pj4gcmVnYXJkcywNCj4+Pj4gICAgICAgSm91bmkNCj4+Pj4NCj4+Pj4gOC8xNy8yMDE2LCA3OjA0 IEFNLCBNaXJqYSBLdWVobGV3aW5kIGtpcmpvaXR0aToNCj4+Pj4+DQo+Pj4+PiBNaXJqYSBLw7xo bGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4+ Pj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiBEaXNjdXNzDQo+Pj4+ Pg0KPj4+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+Pj4+PiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPj4+Pj4gaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCj4+Pj4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4+ Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlw LXBvcnQtcmFkaXVzLWV4dC8NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+Pj4+IERJU0NVU1M6DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4gSSBm dWxseSBzdXBwb3J0IEFsaXNzYSdzIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBoYXZlIHR3byBtb3Jl IHRvDQo+Pj4+PiBhZGQ6aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0Lw0KPj4+Pj4NCj4+Pj4+IDEpIElQLVBvcnQtVHlw ZSBUTFYgb25seSBjb3ZlcnMgVURQLCBUQ1AgYW5kIElDTVAuIFRoaXMgaXMgbm90IHZlcnkNCj4+ Pj4+IGZ1dHVyZS1wcm9vZjogdGhlcmUgYXJlIG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhh dCBoYXZlIHBvcnRzIG9yDQo+Pj4+PiBpZGVudGlmaWVycyB0aGF0IG1heSB3YW50IHRvIGJlIHN1 cHBvcnRlZCBpbiBmdXR1cmUuIEFsc28gaXQgaXMgbm90IGNsZWFyDQo+Pj4+PiB0byBtZSBmcm9t IHRoZSBkb2N1bWVudCB3aHkgdGhpcyBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgYXQgYWxsIGluIHRo ZQ0KPj4+Pj4gZGVzY3JpYmVkIHVzZSBjYXNlcy4gVGhlcmVmb3JlIEkgc2VlIHR3byBwb3NzaWJs ZSB3YXlzIGZvcndhcmQ6IEVpdGhlcg0KPj4+Pj4gcmVtb3ZlIHRoZSBJUC1Qb3J0LVR5cGUgVExW IG9yIGV4dGVuZCBpdCB0byBhbHNvIGNvdmVyIG90aGVyIGNhc2VzLg0KPj4+Pj4NCj4+Pj4+IFJl bGF0ZWQgdG8gdGhpcyBwb2ludCBJIHdvdWxkIGxpa2UgdG8gbWVudGlvbiB0aGF0IFJGQzY4ODcg aXMgbm90DQo+Pj4+PiByZXN0cmljdGVkIHRvIFVEUC9UQ1AgYW5kIHRoZXJlZm9yZSB0aGUgZm9s bG93aW5nIHNlbnRlbmNlIGluIHNlY3Rpb24gMg0KPj4+Pj4gaXMgbm90IGNvcnJlY3Q6DQo+Pj4+ PiAiTm90ZSB0aGF0IHRoZSBkZWZpbml0aW9ucyBvZiBbLi4uXSAiaW50ZXJuYWwgcG9ydCIsIFsu Li5dICJleHRlcm5hbA0KPj4+Pj4gcG9ydCIgWy4uLl0gYXJlIHRoZSBzYW1lIGFzIGRlZmluZWQg aW4gUG9ydCBDb250cm9sIFByb3RvY29sIChQQ1ApDQo+Pj4+PiBbUkZDNjg4N10iDQo+Pj4+Pg0K Pj4+Pj4gMikgVGhlIElFIGRvY3RvcnMgaGF2ZSBwcm92aWRlIGZlZWRiYWNrIHRvIElBTkEgdGhh dCB0aGUgSW5mb3JtYXRpb24NCj4+Pj4+IEVsZW1lbnRzIGluIHRoaXMgZG9jIGFyZSB1bmRlcnNw ZWNpZmllZCAobm90IGNvbmZpcm0gd2l0aCBydWxlcyBpbiBSRkMNCj4+Pj4+IDcwMTMpIGFuZCBz aG91bGQgdGhlcmVmb3JlIGJlIG5vdCByZWdpc3RlcmVkLiAgQWRkcmVzc2luZyB0aGlzIGZlZWRi YWNrDQo+Pj4+PiBjb3VsZCBsZWFkIHRvIGEgbWF5b3IgcmV3cml0ZSBvZiB0aGlzIGRvYywgZXNw ZWNpYWxseSBpbiB0aGUgcmVsYXRpb24gdG8NCj4+Pj4+IHRoZSB1c2UgYW5kIGRlZmluaXRpb24g b2YgdHJhbnNwb3J0VHlwZSBhbmQgcmVjZXB0aXZlbHkgSVAtUG9ydC1UeXBlIFRMViwNCj4+Pj4+ IGFuZCBzaG91bGQgdGhlcmVmb3JlIGJlIGRvbmUgYmVmb3JlIGEgZmluYWwgSUVTRyBkZWNpc2lv bi4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g LS0NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBLYXRobGVlbg0KPj4+DQo+Pg0KPg0KPg0K Pg0KPiAtLQ0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEthdGhsZWVuDQoNCg0KDQotLQ0KDQpCZXN0 IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_DC7880973D477648AC15A3BA66253F686F3008DCdfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LYXRobGVlbiAtIHRoYW5r cyBmb3IgdGhlIHJlbWluZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnJhaW4gLSB0aGFua3MgZm9yIHRoZSBjb21t ZW50cywgYW5kIHdlJ3ZlIHVwZGF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b3Vy IGRyYWZ0ICgxMy50eHQpIHRvIGluY29ycG9yYXRlIHlvdXIgY29tbWVudHMgc2VlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHku aWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxMSwg MjAxNiA5OjM1IEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBUcmFtbWVsbDxicj4NCjxiPkNjOjwv Yj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnOyAmbHQ7bGlv bmVsLm1vcmFuZEBvcmFuZ2UuY29tJmd0OzsgSm91bmkgS29yaG9uZW47IE1pcmphIEt1ZWhsZXdp bmQgKElFVEYpOyBUaGUgSUVTRzsgcmFkZXh0QGlldGYub3JnOyByYWRleHQtY2hhaXJzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTE6ICh3aXRoIERJU0NVU1Mp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhl bGxvIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNh biB5b3UgYWxzbyByZXNwb25kIHRvIHRoaXMgbWVzc2FnZSwgaXQgY29udGFpbnMgdGhlIGRldGFp bHMgb2YgdGhlIElQRklYIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMiwgMjAxNiBhdCAx OjA3IFBNLCBCcmlhbiBUcmFtbWVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwu Y2giIHRhcmdldD0iX2JsYW5rIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oaSBLYXRobGVlbiwgYWxsLDxicj4NCjxi cj4NClNvcnJ5LCB0aGlzIGZlbGwgb2ZmIG15IHJhZGFyLCBkdWUgdG8gdGhlIHByZXNlbnQgZW1l cmdlbmN5Ljxicj4NCjxicj4NClJldmlldyB0ZXh0IGJlbG93Ojxicj4NCjxicj4NCkluIGdlbmVy YWwsIHRoZSBJbmZvcm1hdGlvbiBFbGVtZW50cyBpbiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0 LXJhZGl1cy1leHQgYXJlIHNvIHVuZGVyc3BlY2lmaWVkIGFzIHRvIGJlIHVuaW1wbGVtZW50YWJs ZS4gVGhleSBzaG91bGQgbm90IGJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeSBpbiB0aGVpciBwcmVz ZW50IGZvcm0uIFRoZSBhdXRob3JzIGFyZSBhZHZpc2VkIHRvIHJlYWQgUkZDIDcwMTMsIGVzcGVj aWFsbHkgU2VjdGlvbiA0LCB3aGljaA0KIHByb3ZpZGVzIHVzZWZ1bCBpbmZvcm1hdGlvbiBvbiBk ZWZpbmluZyBJbmZvcm1hdGlvbiBFbGVtZW50cy4gU3BlY2lmaWNhbGx5OjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRDJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JbiB0aGUgMTEudHh0LCB3ZSBwcm9wb3NlZCB0aHJlZSBuZXcgSVBGSVggSUVzIGFuZCBp biB0aGUgMTMudHh0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj53ZSd2ZSByZW1vdmVk IG9yIHVwZGF0ZWQgdGhlbSBhcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzExLnR4dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxMy50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0cmFuc3BvcnRUeXBlJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlbW92ZWQgdGhpcyBhcyBhbiBJUEZJWCBJ RSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O25hdFRyYW5zcG9ydExpbWl0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlbmFtZWQgdGhpcyBJRSBhcyAmcXVvdDs8L3NwYW4+DQo8 c3BhbiBsYW5nPSJFTiI+c291cmNlVHJhbnNwb3J0UG9ydHNMaW1pdCZxdW90Ozwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxvbmcgd2l0aCByZXZpc2VkIGRlc2Ny aXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bG9jYWxJRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZW1vdmVkIHRoaXMg YXMgYW4gSVBGSVggSUUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBJbmZvcm1hdGlvbiBF bGVtZW50IHRyYW5zcG9ydFR5cGUgaXMgdW5kZXJzcGVjaWZpZWQ6IChhKSBJIHByZXN1bWUgdGhp cyBpcyBpbiByZWZlcmVuY2UgdG8gc291cmNlVHJhbnNwb3J0UG9ydCBhbmQgZGVzdGluYXRpb25U cmFuc3BvcnRQb3J0LCBidXQgdGhlIGRlc2NyaXB0aW9uIG11c3Qgc2F5IHRoaXMgaWYgaXQgaXMg dGhlIGNhc2U7IChiKSBJdCdzIG5vdCBjbGVhciBhdCBhbGwgZnJvbSB0aGUgZGVzY3JpcHRpb24g aW4gd2hhdCBjb250ZXh0DQogdGhpcyBkaXN0aW5jdGlvbiBpcyB1c2VmdWw7IChjKSBXaGF0J3Mg YW4gSUNNUCBpZGVudGlmaWVyPzxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzRGODFCRCI+REMmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM0RjgxQkQiPlRoaXMgSUUgYXMgcHJvcG9zZWQgaW4gMTEudHh0IGhhcyBiZWVuIHJlbW92 ZWQgaW4gMTMudHh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4MUJEIj5XZSBub3cgaW5jbHVk ZSAmcXVvdDtQcm90b2NvbC1OdW1iZXImcXVvdDsgZGVmaW5lZCBieSBJQU5BLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNEY4MUJEIj5pLmUuLCB0aGUgcHJvdG9jb2wgSUQsIGluIHRoZSBWYWx1ZSBm aWVsZCBvZiBJUC1Qb3J0LVR5cGUgVExWLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4MUJEIj5Q cm90b2NvbHMgdGhhdCBkbyBub3QgdXNlIHBvcnQgbnVtYmVycyAoc3VjaCBhcyBJQ01QKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNEY4MUJEIj5hcmUgbm90IGluY2x1ZGVkIGluIHRoaXMgVExWLiBQ bGVhc2UgcmVmZXIgdG8gU2VjdGlvbiAzLjIuMSBmb3IgZGV0YWlscy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJbiBhZGRpdGlvbiwgdGhlIGRlc2Ny aXB0aW9uIG9mIHRyYW5zcG9ydFR5cGUgYXBwZWFycyB0byBjcmVhdGUgYSB0YWJsZSB3aGljaCBz aG91bGQgcHJvYmFibHkgYmUgaGFuZGxlZCBhcyBhIHN1YnJlZ2lzdHJ5LiBTZWUgU2VlIFJGQzcw MTMgc2VjdGlvbiA0LjcuIGZvciBhZHZpY2Ugb24gdGhlIGNyZWF0aW9uIG9mIHRhYmxlcyB3aXRo b3V0IHN1YnJlZ2lzdHJpZXMgKGluIHNob3J0LCAmcXVvdDtkb24ndCZxdW90Oy4pPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4 MUJEIj5EQyZndDsgTm8gaXNzdWUgaGVyZSBzaW5jZSB0aGVyZSBpcyBubyBwcm9wb3NlZCBJRSBo ZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRo ZSBJbmZvcm1hdGlvbiBFbGVtZW50IG5hdFRyYW5zcG9ydExpbWl0IGhhcyBhbiBpbmFwcHJvcHJp YXRlIG5hbWU7IGl0IGRvZXMgbm90IGRlc2NyaWJlIHRoYXQgd2hpY2ggaXQgKHByZXN1bWFibHkp IGlzIHN1cHBvc2VkIHRvIHJlcHJlc2VudCAoc2VlIFJGQyA3MDEzIHNlY3Rpb24gNC4xKS4gSW4g YWRkaXRpb24sIGl0IGlzIHVuZGVyc3BlY2lmaWVkLiBJdCBpcyBpbXBvc3NpYmxlIHRvIGltcGxl bWVudCBmcm9tIHRoZSBkZXNjcmlwdGlvbi4NCiBJcyB0aGUgZmllbGQgSVB2NCBzcGVjaWZpYywg b3IgaXMgSVB2NiBzdXBwb3J0ZWQgYXMgd2VsbD8gKElmIG5vdCwgd2h5IG5vdD8pPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4 MUJEIj5EQyZndDsgV2UgY2hhbmdlZCB0aGUgbmFtZSB0byAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM0RjgxQkQiPg0KPHNwYW4gbGFuZz0iRU4iPnNvdXJjZVRyYW5zcG9ydFBvcnRz TGltaXQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5hbG9uZyB3aXRoIHRo ZSBkZXNjcmlwdGlvbi4gSXQgaW5kaWNhdGVzIHRoZSBsaW1pdCBpbXBvc2VkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJj b2xvcjojNEY4MUJEIj50byBhIHVzZXIgb24gdGhlIG1heCBzb3VyY2UgcG9ydCBudW1iZXIsIGFu ZCBjYW4gYmUgYXNzb2NpYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iY29sb3I6IzRGODFCRCI+d2l0aCBhbiBJUHY0 IG9yIElQdjYgYWRkcmVzcy4gUmVmZXIgdG8gU2VjdGlvbiAzLjIuMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iY29sb3I6 IzRGODFCRCI+YW5kIDcuMSBmb3IgZGV0YWlscy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM0RjgxQkQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClRoZSBJbmZvcm1hdGlvbiBFbGVtZW50IGxvY2FsSUQgaGFzIGFuIGlu YXBwcm9wcmlhdGUgbmFtZTsgaXQgaXMgZmFyIHRvbyBnZW5lcmFsIChzZWUgUkZDIDcwMTMgc2Vj dGlvbiA0LjEpLiBJdCB1c2VzIGFuIGluYXBwcm9wcmlhdGUgYWJzdHJhY3QgZGF0YSB0eXBlIChh ZGRyZXNzZXMgc2hvdWxkIG5ldmVyIGJlIHJlcHJlc2VudGVkIGFzIFVURi04IHN0cmluZ3MgaW4g SVBGSVgsIHNlZSBSRkMgNzAxMyBzZWN0aW9uIDQuMikuIEl0IGlzIHVuZGVyc3BlY2lmaWVkDQog YXMgd2VsbCBhcyBwb29ybHkgZGVzaWduZWQuIFdpdGhvdXQgdGhlIGFiaWxpdHkgdG8gZGlzYW1i aWd1YXRlIHRoZSB0eXBlIG9mIGluZm9ybWF0aW9uIGluIHRoZSBmaWVsZCwgdGhpcyBpcyBub3Qg YSB1c2VmdWwgSW5mb3JtYXRpb24gRWxlbWVudC4gV2l0aG91dCBhIGNvbXBsZXRlIGVudW1lcmF0 aW9uIG9mIHBvc3NpYmxlIHR5cGVzIChuLmIuICdldGMuJyBpbiB0aGUgZGVzY3JpcHRpb24pLCBp dCBpcyBub3QgYSB1c2VmdWwgSW5mb3JtYXRpb24NCiBFbGVtZW50LiZuYnNwOyBJdHMgcHVycG9z ZSBpcyB1bmNsZWFyIGZyb20gaXRzIGRlc2NyaXB0aW9uOyBmdXJ0aGVyLCBpdCBhcHBlYXJzIHRv IHZpb2xhdGUgdGhlIGZvbGxvd2luZyBndWlkYW5jZSBpbiBSRkMgNzAxMyBzZWN0aW9uIDQ6ICZx dW90O1RoZSBJbmZvcm1hdGlvbiBFbGVtZW50IG11c3QgYmUgdW5pcXVlIHdpdGhpbiB0aGUgcmVn aXN0cnksIGFuZCBpdHMgZGVzY3JpcHRpb24gbXVzdCByZXByZXNlbnQgYSBzdWJzdGFudGlhbGx5 IGRpZmZlcmVudCBtZWFuaW5nDQogZnJvbSB0aGF0IG9mIGFueSBleGlzdGluZyBJbmZvcm1hdGlv biBFbGVtZW50LiZuYnNwOyBBbiBleGlzdGluZyBJbmZvcm1hdGlvbiBFbGVtZW50IHRoYXQgY2Fu IGJlIHJldXNlZCBmb3IgYSBnaXZlbiBwdXJwb3NlIHNob3VsZCBiZSByZXVzZWQuJnF1b3Q7PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+REMmZ3Q7IFdlIHJlbW92ZWQgdGhp cyBwcm9wb3NlZCBJRSBpbiAxMy50eHQuIEluIHRoZSBWYWx1ZSBmaWVsZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5vZiBJUC1Qb3J0LUxvY2FsLUlkIFRMViAoU2VjdGlvbiAzLjIuMTEp LCB3ZSBub3cgaW5jbHVkZSBhICZxdW90O2xvY2FsSUQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+b2YgJnF1b3Q7c3RyaW5nJnF1b3Q7IGFzIHRoZSBkYXRhIHR5cGUgKHJlZmVy IHRvDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5pZXRmLXJh ZGV4dC1kYXRhdHlwZXMudHh0KS48L3NwYW4+PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4N Cjxicj4NCkJyaWFuIFRyYW1tZWxsIChmb3IgdGhlIElFLURvY3RvcnMpPHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJjb2xvcjojNEY4MUJEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KPGJyPg0KJmd0OyBPbiAwMiBTZXAgMjAxNiwgYXQgMTg6NDEsIEthdGhsZWVuIE1vcmlhcnR5 ICZsdDs8YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxi cj4NCiZndDsgT24gRnJpLCBTZXAgMiwgMjAxNiBhdCA3OjQ0IEFNLCBNaXJqYSBLdWVobGV3aW5k IChJRVRGKTxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0 Ij5pZXRmQGt1ZWhsZXdpbmQubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgRGlkIGZp bmFsbHkgc2VuZCBzb21lb25lIHRoZSByZXZpZXcgdG8gdGhlIHJpZ2h0IHBlb3BsZSBvciBzaG91 bGQgSSBwaW5nIEJyaWFuIChhZ2Fpbik/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhdCB3b3VsZCBi ZSBoZWxwZnVsLCBJIGJlbGlldmUgd2UgYXJlIHN0aWxsIHdhaXRpbmcgZm9yIHRoZSByZXZpZXcu PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgS2F0aGxlZW48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBNaXJqYTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQW0gMTcuMDguMjAxNiB1bSAxOToxOCBzY2hyaWViIEth dGhsZWVuIE1vcmlhcnR5ICZsdDs8YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0 ZkBnbWFpbC5jb20iPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDs6PGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFwcGFyZW50bHksIEJyaWFuIGRpZCB0 aGUgcmV2aWV3LiZuYnNwOyBJJ20gYWRkaW5nIGhpbSB0byB0aGlzIHRocmVhZCBzbyBoZTxicj4N CiZndDsmZ3Q7Jmd0OyBjYW4gc2VuZCB0aGUgcmV2aWV3IHRvIHRoZSBkcmFmdCBkaXN0cmlidXRp b24gbGlzdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhhbmsgeW91LDxi cj4NCiZndDsmZ3Q7Jmd0OyBLYXRobGVlbjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBPbiBXZWQsIEF1ZyAxNywgMjAxNiBhdCAxOjEzIFBNLCBKb3VuaSBLb3Job25lbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20iPmpvdW5pLm5vc3BhbUBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRv IHNlZSB0aGUgSUUgZG9jdG9yJ3MgZmVlZGJhY2s/IFRoZSBhdXRob3JzIG1pZ2h0IGZpbmQ8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IGl0IHVzZWZ1bCBhcyB3ZWxsLiBJZiBpdCBoYXMgYmVlbiBkaXN0 cmlidXRlZCBhbHJlYWR5LCBteSBhcG9sb2dpZXMgaWYgSTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg bWlzc2VkIGl0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJl Z2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0pv dW5pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgOC8xNy8yMDE2 LCA3OjA0IEFNLCBNaXJqYSBLdWVobGV3aW5kIGtpcmpvaXR0aTo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiBEaXNjdXNz PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWw8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh biBiZSBmb3VuZCBoZXJlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFk aXVzLWV4dC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC88L2E+PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IERJU0NVU1M6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSBmdWxseSBzdXBwb3J0IEFsaXNzYSdzIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBoYXZl IHR3byBtb3JlIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWRkOjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFk aXVzLWV4dC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQvPC9hPjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSkgSVAtUG9ydC1UeXBlIFRM ViBvbmx5IGNvdmVycyBVRFAsIFRDUCBhbmQgSUNNUC4gVGhpcyBpcyBub3QgdmVyeTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1dHVyZS1wcm9vZjogdGhlcmUgYXJlIG90aGVyIHRyYW5zcG9y dCBwcm90b2NvbHMgdGhhdCBoYXZlIHBvcnRzIG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg aWRlbnRpZmllcnMgdGhhdCBtYXkgd2FudCB0byBiZSBzdXBwb3J0ZWQgaW4gZnV0dXJlLiBBbHNv IGl0IGlzIG5vdCBjbGVhcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIG1lIGZyb20gdGhl IGRvY3VtZW50IHdoeSB0aGlzIGluZm9ybWF0aW9uIGlzIG5lZWRlZCBhdCBhbGwgaW4gdGhlPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGVzY3JpYmVkIHVzZSBjYXNlcy4gVGhlcmVmb3JlIEkg c2VlIHR3byBwb3NzaWJsZSB3YXlzIGZvcndhcmQ6IEVpdGhlcjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHJlbW92ZSB0aGUgSVAtUG9ydC1UeXBlIFRMViBvciBleHRlbmQgaXQgdG8gYWxzbyBj b3ZlciBvdGhlciBjYXNlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFJlbGF0ZWQgdG8gdGhpcyBwb2ludCBJIHdvdWxkIGxpa2UgdG8gbWVudGlv biB0aGF0IFJGQzY4ODcgaXMgbm90PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVzdHJpY3Rl ZCB0byBVRFAvVENQIGFuZCB0aGVyZWZvcmUgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpbiBzZWN0 aW9uIDI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBub3QgY29ycmVjdDo8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtOb3RlIHRoYXQgdGhlIGRlZmluaXRpb25zIG9mIFsuLi5d ICZxdW90O2ludGVybmFsIHBvcnQmcXVvdDssIFsuLi5dICZxdW90O2V4dGVybmFsPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcG9ydCZxdW90OyBbLi4uXSBhcmUgdGhlIHNhbWUgYXMgZGVmaW5l ZCBpbiBQb3J0IENvbnRyb2wgUHJvdG9jb2wgKFBDUCk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBbUkZDNjg4N10mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDIpIFRoZSBJRSBkb2N0b3JzIGhhdmUgcHJvdmlkZSBmZWVkYmFjayB0byBJ QU5BIHRoYXQgdGhlIEluZm9ybWF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRWxlbWVu dHMgaW4gdGhpcyBkb2MgYXJlIHVuZGVyc3BlY2lmaWVkIChub3QgY29uZmlybSB3aXRoIHJ1bGVz IGluIFJGQzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDcwMTMpIGFuZCBzaG91bGQgdGhlcmVm b3JlIGJlIG5vdCByZWdpc3RlcmVkLiZuYnNwOyBBZGRyZXNzaW5nIHRoaXMgZmVlZGJhY2s8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3VsZCBsZWFkIHRvIGEgbWF5b3IgcmV3cml0ZSBvZiB0 aGlzIGRvYywgZXNwZWNpYWxseSBpbiB0aGUgcmVsYXRpb24gdG88YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0aGUgdXNlIGFuZCBkZWZpbml0aW9uIG9mIHRyYW5zcG9ydFR5cGUgYW5kIHJlY2Vw dGl2ZWx5IElQLVBvcnQtVHlwZSBUTFYsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHNo b3VsZCB0aGVyZWZvcmUgYmUgZG9uZSBiZWZvcmUgYSBmaW5hbCBJRVNHIGRlY2lzaW9uLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7IEthdGhsZWVuPGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IC0tPGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgS2F0aGxl ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DC7880973D477648AC15A3BA66253F686F3008DCdfweml501mbb_-- From nobody Tue Oct 11 12:46:17 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FDA129688; Tue, 11 Oct 2016 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 eAaYCk8vRK09; Tue, 11 Oct 2016 12:46:14 -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 DB9AB1294B7; Tue, 11 Oct 2016 12:46:13 -0700 (PDT) X-AuditID: c6180641-e73ff70000000a0b-d0-57fced1dc3e6 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id C7.4B.02571.D1DECF75; Tue, 11 Oct 2016 15:46:07 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Tue, 11 Oct 2016 15:46:10 -0400 From: Suresh Krishnan To: Kathleen Moriarty Thread-Topic: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) Thread-Index: AQHR+Dl7FAHLmNalzUyGv0wDDZn0tQ== Date: Tue, 11 Oct 2016 19:46:09 +0000 Message-ID: References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonXFf+7Z9wg30LTC2aPjexW1zdN4PN YsaficwWDTvzLZ52fGGyaHk1k81iXkMjuwO7R8vRFhaPnbPusnssWfKTyWN5l08ASxSXTUpq TmZZapG+XQJXxoN/75gKpkhVLLr3h7WBcbpwFyMnh4SAicTdDSeYuxi5OIQENjBK/Nt2mR3C Wc4ocXX+L1aQKjagqg07PzOB2CICFhJrmr+xgdjMAnOZJOb+0wSxhQXyJdb/OMAOUVMgsbzj EyOErSexqusQC4jNIqAqMfXHG7AaXgFfiV8T26CWTWOS2PZ5ElgDo4CYxPdTa5ggFohL3Hoy nwniVAGJJXvOM0PYohIvH/9jhbCVJD7+ns8OUa8jsWD3J6jjtCWWLXzNDLFMUOLkzCcsExhF ZiEZOwtJyywkLbOQtCxgZFnFyFFaXJCTm25kuIkRGDvHJNgcdzDu7fU8xCjAwajEw6uw40+4 EGtiWXFl7iFGCQ5mJRHeEru/4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5r4fcDxcSSE8sSc1O TS1ILYLJMnFwSjUw2pxrtq87dfOszJfGH58/TW3b9/7F+9vH7daue8pwYL3jsQcmzI1LKh3F o3gE6tKOzSxpmcn47lid8JOGTxkWp41E8/6UeF9MP2P/qf//g3uVD+tyHQ4WnHkuIW3UKar1 WeepAdui1D6j/ytkunkfdk/dY+MrdNfL/Il3zPziZ4xLrc9W2MSdVWIpzkg01GIuKk4EAHuP VJGZAgAA Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-datatypes@ietf.org" , Winter Stefan , Alan DeKok , The IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:46:15 -0000 Hi Kathleen,=0A= I have looked at the new revision and it addresses my concerns. I have = =0A= cleared.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 10/11/2016 12:27 PM, Kathleen Moriarty wrote:=0A= > Hi Suresh,=0A= >=0A= > The new version was posted. Can you check to see if you are satisfied wi= th=0A= > the changes?=0A= >=0A= > Thank you,=0A= > Kathleen=0A= >=0A= > On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan=0A= > > wrot= e:=0A= >=0A= > Hi Alan,=0A= > Thanks for your response. I will clear once you post a new version= with=0A= > the changes.=0A= >=0A= > Thanks=0A= > Suresh=0A= >=0A= > On 08/18/2016 12:36 PM, Alan DeKok wrote:=0A= > > On Aug 17, 2016, at 5:43 AM, Suresh Krishnan=0A= > > = wrote:=0A= > >> * Section 3.10=0A= > >>=0A= > >> It is not clear from this definition how exactly a sender needs to= encode=0A= > >> this attribute on the wire. e.g. From the spec it looks like an IP= v6=0A= > >> prefix such 2001:db8:dead:beef::/64 can legally be encoded using a= nywhere=0A= > >> between 8 octets and 16 octets. What exactly is the preferred enco= ding?=0A= > >> If you intend to allow all of the encodings can you please add an= =0A= > >> explicit statement to say so.=0A= > >=0A= > > The preferred encoding should be the shortest one. I'll put some= =0A= > text together.=0A= > >=0A= > >> * I am not sure why this document uses Reserved fields in sections= 3.10=0A= > >> and 3.11. Is it for alignment? Please clarify. I don't see exactly= why=0A= > >> aligning a 4 octet or a 16 octet value to a 16 bit boundary would = provide=0A= > >> any value.=0A= > >> (I personally think such padding related stuff should be in the=0A= > >> definition of the radius attribute that uses the datatype and not = in the=0A= > >> datatype itself but I will not block on this.)=0A= > >=0A= > > The data types in 3.10 and 3.11 are taken from previous=0A= > specifications. I'm not entirely sure why they have reserved fields,= either.=0A= > >=0A= > > We can't change the format of the data type, because implementati= ons=0A= > use this format. The document just codifies existing practices.=0A= > >=0A= > >> * Section 3.7=0A= > >>=0A= > >> I think this text is confusing because "octet string" and network = byte=0A= > >> order do not seem to be compatible. Suggest rewording=0A= > >>=0A= > >> OLD:=0A= > >> The "ifid" data type encodes an Interface-Id as an 8-octet string = in=0A= > >> network byte order=0A= > >>=0A= > >> NEW:=0A= > >> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier = in=0A= > >> network byte order=0A= > >=0A= > > Sounds good.=0A= > >=0A= > >> * Section 3.10 and 3.11=0A= > >>=0A= > >> The separator between the Reserved field and the Prefix Length fie= ld is=0A= > >> off by one position.=0A= > >=0A= > > Fixed.=0A= > >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > --=0A= >=0A= > Best regards,=0A= > Kathleen=0A= =0A= From nobody Tue Oct 11 12:50:31 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D512967D; Tue, 11 Oct 2016 12:50:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147621542364.32029.9299231482276248866.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 12:50:23 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-datatypes-07: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:50:23 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-radext-datatypes-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENTs. From nobody Tue Oct 11 12:56:19 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196351294B7; Tue, 11 Oct 2016 12:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 7_kaWMa2QhNw; Tue, 11 Oct 2016 12:56:16 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E035C129400; Tue, 11 Oct 2016 12:56:15 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id b186so31360571vkb.1; Tue, 11 Oct 2016 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GbUZJDVoE6Zn1vLh8n+vii1Wo8fzny4SZxzE49OSEvo=; b=NeaT/0K2O5xGJ4MBmetXmbzIVPCqqBJA7vIPMBU8GxWmsJZ0nt6B1OtHfPW1JQ6qkv 57CvHwC17IwtyiSZ3alJgM8xyQ0zvjOSipfxXSjGmivQo1jDoFmSfW6jEqeWjglW0GLQ bC9M+JO2q7i1nbCGfbAzVl6wTsiawPoDXM4MvCwTRNAhzAo+sDlf/RtbDwrebiZk8x2b eALc3/hWPJw+y7B6kThTaNz6PFYJ5LKNSDH5/dh6WMrV1ky92CN7aEMpU7qK1Xdg+Bb6 pI4ega8OL+kHB9Ia3wSxgbkZKdo01ti8rWyg3asQOPbjbb4QZWIgdAMUVg2uR/4kmz9q axwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GbUZJDVoE6Zn1vLh8n+vii1Wo8fzny4SZxzE49OSEvo=; b=M1LvkUJ7AT5OMrPAalZB6EwefUfMrpwX58PYgb+QFUbUnpRdcx7y0UuFWCaETjSVn3 D0wr08vQzFHkw/u7rlvlG4kI1kdbko2ZfP8R3uH0ZOwmO7uoD6iaom1bt0eBQDUXcjGb XdSJWEXny+NmlF2UAJdBbPVzJOXjw+Ic2nfcB07cZ39HAW4ZXy5fiNHt41xoba63MLNM XTAjp2hvOnP9l3g9ktoPO3DiG8vitYm8ljsNhfwlYYbTMbUURFW7NyaA3XF+d30LveYr 9Y8TA1pgVAQWxY2N3Z54t/mteXh7yyiPZBNkmGEoA1ZaK0reYOnLan/MnOeCADd77hyx WhTQ== X-Gm-Message-State: AA6/9Rl+TTPExdt8BoUeeViTeyvryyPkkm6gWdT0QIfNh3VTU/DcSfWYiApdDemgMYUYf+M6N4bmq5jL00HYWQ== X-Received: by 10.31.151.78 with SMTP id z75mr4720349vkd.41.1476215774828; Tue, 11 Oct 2016 12:56:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 11 Oct 2016 12:56:13 -0700 (PDT) In-Reply-To: References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 11 Oct 2016 15:56:13 -0400 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1140e662dedf20053e9c44a5 Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-datatypes@ietf.org" , Winter Stefan , Alan DeKok , The IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:56:18 -0000 --001a1140e662dedf20053e9c44a5 Content-Type: text/plain; charset=UTF-8 Thank you, Suresh. On Tue, Oct 11, 2016 at 3:46 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Kathleen, > I have looked at the new revision and it addresses my concerns. I have > cleared. > > Regards > Suresh > > On 10/11/2016 12:27 PM, Kathleen Moriarty wrote: > > Hi Suresh, > > > > The new version was posted. Can you check to see if you are satisfied > with > > the changes? > > > > Thank you, > > Kathleen > > > > On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan > > > > wrote: > > > > Hi Alan, > > Thanks for your response. I will clear once you post a new > version with > > the changes. > > > > Thanks > > Suresh > > > > On 08/18/2016 12:36 PM, Alan DeKok wrote: > > > On Aug 17, 2016, at 5:43 AM, Suresh Krishnan > > > > wrote: > > >> * Section 3.10 > > >> > > >> It is not clear from this definition how exactly a sender needs > to encode > > >> this attribute on the wire. e.g. From the spec it looks like an > IPv6 > > >> prefix such 2001:db8:dead:beef::/64 can legally be encoded using > anywhere > > >> between 8 octets and 16 octets. What exactly is the preferred > encoding? > > >> If you intend to allow all of the encodings can you please add an > > >> explicit statement to say so. > > > > > > The preferred encoding should be the shortest one. I'll put some > > text together. > > > > > >> * I am not sure why this document uses Reserved fields in > sections 3.10 > > >> and 3.11. Is it for alignment? Please clarify. I don't see > exactly why > > >> aligning a 4 octet or a 16 octet value to a 16 bit boundary would > provide > > >> any value. > > >> (I personally think such padding related stuff should be in the > > >> definition of the radius attribute that uses the datatype and not > in the > > >> datatype itself but I will not block on this.) > > > > > > The data types in 3.10 and 3.11 are taken from previous > > specifications. I'm not entirely sure why they have reserved > fields, either. > > > > > > We can't change the format of the data type, because > implementations > > use this format. The document just codifies existing practices. > > > > > >> * Section 3.7 > > >> > > >> I think this text is confusing because "octet string" and network > byte > > >> order do not seem to be compatible. Suggest rewording > > >> > > >> OLD: > > >> The "ifid" data type encodes an Interface-Id as an 8-octet string > in > > >> network byte order > > >> > > >> NEW: > > >> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier > in > > >> network byte order > > > > > > Sounds good. > > > > > >> * Section 3.10 and 3.11 > > >> > > >> The separator between the Reserved field and the Prefix Length > field is > > >> off by one position. > > > > > > Fixed. > > > > > > > > > > > > > > > -- > > > > Best regards, > > Kathleen > > -- Best regards, Kathleen --001a1140e662dedf20053e9c44a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Suresh.

On Tue, Oct 11, 2016 at 3:46 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
Hi Kathleen,
=C2=A0 =C2=A0I have looked at the new revision and it addresses my concerns= . I have
cleared.

Regards
Suresh

On 10/11/2016 12:27 PM, Kathleen Moriarty wrote:
> Hi Suresh,
>
> The new version was posted.=C2=A0 Can you check to see if you are sati= sfied with
> the changes?
>
> Thank you,
> Kathleen
>
> On Thu, Aug 18, 2016 at 11:01 PM, Suresh Krishnan
> <suresh.krishnan@ericsson.com <mailto:suresh.krishnan@ericsson.com>&g= t; wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Alan,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for your response. I will clear once= you post a new version with
>=C2=A0 =C2=A0 =C2=A0the changes.
>
>=C2=A0 =C2=A0 =C2=A0Thanks
>=C2=A0 =C2=A0 =C2=A0Suresh
>
>=C2=A0 =C2=A0 =C2=A0On 08/18/2016 12:36 PM, Alan DeKok wrote:
>=C2=A0 =C2=A0 =C2=A0> On Aug 17, 2016, at 5:43 AM, Suresh Krishnan
>=C2=A0 =C2=A0 =C2=A0<= suresh.krishnan@ericsson.co= m <mailto:suresh.kri= shnan@ericsson.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> * Section 3.10
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> It is not clear from this definition how e= xactly a sender needs to encode
>=C2=A0 =C2=A0 =C2=A0>> this attribute on the wire. e.g. From the = spec it looks like an IPv6
>=C2=A0 =C2=A0 =C2=A0>> prefix such 2001:db8:dead:beef::/64 can le= gally be encoded using anywhere
>=C2=A0 =C2=A0 =C2=A0>> between 8 octets and 16 octets. What exact= ly is the preferred encoding?
>=C2=A0 =C2=A0 =C2=A0>> If you intend to allow all of the encoding= s can you please add an
>=C2=A0 =C2=A0 =C2=A0>> explicit statement to say so.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0The preferred encoding should be t= he shortest one.=C2=A0 I'll put some
>=C2=A0 =C2=A0 =C2=A0text together.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> * I am not sure why this document uses Res= erved fields in sections 3.10
>=C2=A0 =C2=A0 =C2=A0>> and 3.11. Is it for alignment? Please clar= ify. I don't see exactly why
>=C2=A0 =C2=A0 =C2=A0>> aligning a 4 octet or a 16 octet value to = a 16 bit boundary would provide
>=C2=A0 =C2=A0 =C2=A0>> any value.
>=C2=A0 =C2=A0 =C2=A0>> (I personally think such padding related s= tuff should be in the
>=C2=A0 =C2=A0 =C2=A0>> definition of the radius attribute that us= es the datatype and not in the
>=C2=A0 =C2=A0 =C2=A0>> datatype itself but I will not block on th= is.)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0The data types in 3.10 and 3.11 ar= e taken from previous
>=C2=A0 =C2=A0 =C2=A0specifications.=C2=A0 I'm not entirely sure why= they have reserved fields, either.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0We can't change the format of = the data type, because implementations
>=C2=A0 =C2=A0 =C2=A0use this format.=C2=A0 The document just codifies e= xisting practices.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> * Section 3.7
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I think this text is confusing because &qu= ot;octet string" and network byte
>=C2=A0 =C2=A0 =C2=A0>> order do not seem to be compatible. Sugges= t rewording
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> OLD:
>=C2=A0 =C2=A0 =C2=A0>> The "ifid" data type encodes an = Interface-Id as an 8-octet string in
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0network byte order
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> NEW:
>=C2=A0 =C2=A0 =C2=A0>> The "ifid" data type encodes an = 8 octet IPv6 Interface Identifier in
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0network byte order
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Sounds good.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> * Section 3.10 and 3.11
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> The separator between the Reserved field a= nd the Prefix Length field is
>=C2=A0 =C2=A0 =C2=A0>> off by one position.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Fixed.
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
>
>
> --
>
> Best regards,
> Kathleen




--
=

Best regards,
Kathleen
--001a1140e662dedf20053e9c44a5-- From nobody Tue Oct 11 13:17:04 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D870129471; Tue, 11 Oct 2016 13:17:02 -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, 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 10Q86Gxxw8vF; Tue, 11 Oct 2016 13:17:00 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDD9129451; Tue, 11 Oct 2016 13:17:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id CE4A21751; Tue, 11 Oct 2016 20:16:59 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7P_84MVXDZB; Tue, 11 Oct 2016 20:16:59 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 23D5F3A2; Tue, 11 Oct 2016 20:16:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 11 Oct 2016 16:16:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 20:17:02 -0000 > On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty = wrote: >=20 > Hi Alan, >=20 > I don't see responses to the No Objection messages on your draft. Can = you take care of that so I can progress the document? I didn't get the original message. > ---------- Forwarded message ---------- > From: Ben Campbell > Date: Tue, Aug 16, 2016 at 9:59 PM > Subject: Ben Campbell's No Objection on = draft-ietf-radext-datatypes-06: (with COMMENT) > To: The IESG > Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, = radext-chairs@ietf.org, radext@ietf.org ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > -2.1.2, first paragraph: "The specification may, of course, define a = new > data type and use it in the same document." > Am I correct to assume that any such definition must (or maybe MUST) = be > registered? (Maybe that's already covered in 6929?) Any such new definition MUST be registered. RFC 6929 just forbids new = data types. I think I can update the doc in the next rev, as soon as that's = required. > -4.1: I'm curious why new data types need a policy as strong as > "standards action". Is there a concern that people will get this wrong > without the full weight of the IETF consensus process? Is there a = concern > that the numbering space will run out? Would it be reasonable to have = a > "specification-required" policy, with some guidance to the designated > expert(s)? (Or is it because such data types need to be referenceable > from standards track documents, perhaps related to the guidance = against > vendor-specific types?) See RFC 6929 covers this in detail. There are few good reasons to = create new data types. There is a huge cost to creating new data types, = and very little benefit. Section 6 has guidelines for creating attributes. RFC 6158 also = contains long guidelines in Appendix A. Both sections have text = explaining why these guidelines are in place. In addition, as the draft notes, RADIUS implementations are typically = driven by a dictionary containing attribute names, assigned numbers, and = data types. This means that adding new attributes with known data types = is trivial: edit the dictionary. Adding new data types is complex, and = requires much code to be written. Another reason is practice. I'm aware of only a few data types which = have been vendor-defined in the last twenty years. One is an "ad hoc" = structure to describe firewall rules. Another is a signed integer (the = above RFCs explain why this is wrong). A few vendors defined a 64-bit = integer before the IETF did. That's really about it. So new data types are not needed, and without IETF consensus, are = generally wrong. FWIW, IPFix has a fixed set of data types, an IANA registry, and = requires standards action for update. There is a strong overlap between = the data IPFix tracks, and RADIUS accounting. So a fixed set of data = types works well in both places. Alan DeKok. From nobody Tue Oct 11 13:43:42 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFAB12959F for ; Tue, 11 Oct 2016 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 uDXvLnVAHvmR for ; Tue, 11 Oct 2016 13:43:39 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 281991294B7 for ; Tue, 11 Oct 2016 13:43:39 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9BKg5dF006111; Tue, 11 Oct 2016 13:43:35 -0700 Received: from hq1wp-exmb11.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 2615bmgaeu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Oct 2016 13:43:35 -0700 Received: from hq1wp-excas12.corp.brocade.com (10.70.38.22) by Hq1wp-exmb11.corp.brocade.com (10.70.20.185) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 13:43:32 -0700 Received: from [10.252.49.8] (10.252.49.8) by hq1wp-excas12.corp.brocade.com (10.70.38.102) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 11 Oct 2016 13:43:18 -0700 To: References: From: Paul Aitken Message-ID: <2aa8a0ae-6974-f167-21f4-249a2bc0d69a@brocade.com> Date: Tue, 11 Oct 2016 21:43:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610110340 Archived-At: Cc: "bclaise@cisco.com" , radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 20:43:40 -0000 Authors I've been waiting 2 months, yet no reply? P. On 08/11/16 17:24, Paul Aitken wrote: > Dear Authors, some questions came to mind while reviewing section 3.2 > of your draft: > > > Q1: Why define a new TLV-Type 1..11 simply to encode an IPFIX > Information Element? > > Since there's a 1:1 mapping between the TLV-Type and IPFIX Element ID, > the scheme you propose would be more extensible if the IPFIX Element > ID was used instead of the TLV-Type since it would require one less > registry. True, one additional byte would be required in the encoding. > However, the advantage is that in future anyone could encode a new TLV > by using the relevant IPFIX ID, without having to also define a new > TLV-Type for it. > > > Q2: In each TLV, the Length field is redundant since it can always be > determined from the TLV-Type: it's always 6, with special cases for > TLV-Types 5 (Length is 18) and 11 (Length could be determined by a > NULL terminator on the string). This suggests that the length is not > required in the protocol, so why not remove it entirely? > > > However, many of the descriptions say "contains the data ... right > justified, and the unused bits in this field MUST be set to zero. " > > Q3: Wouldn't it be better to limit the length of the field to an > appropriate size for the data, and encode that size in the Length? > > > For example, the transportType in 3.2.1 is just one octet long > (unsigned8) - so there's no reason to encode it in 32 bits. Why not > encode it like so: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV-Type = TBAx1 | Length | transportType | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The natEvent in 3.2.8 is also an unsigned8, so it would be encoded > similarly - except that the TLV-Type would be 230, which is the IE ID > of the IPFIX natEvent. > > > The natTransportLimit in 3.2.2 is an unsigned16 - so there's no need > to encode it in 32 bits. Why not encode it like so: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV-Type = TBAx2 | Length |natTransportLimit ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... | > +-+-+-+-+-+-+-+-+ > > 3.2.9 and 3.2.10 would be similar. The encoding of 3.2.3, 3.2.4, and > 3.2.5 would all be as shown in the draft, except that the TLV-type > would be two octets long and contain the IPFIX IE ID. The > sourceTransportPort in 3.2.6 is an unsigned16 - so there's no need to > encode it in 32 bits. Why not encode it like so: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV-Type = sourceTransportPort| Length | > sourceTransportPort ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... | > +-+-+-+-+-+-+-+-+ > > The encoding of 3.2.7 would be similar. From nobody Tue Oct 11 20:56:04 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4D129465 for ; Tue, 11 Oct 2016 20:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 I8mRpBjSlcFm for ; Tue, 11 Oct 2016 20:55:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE78129409 for ; Tue, 11 Oct 2016 20:55:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSY11888; Wed, 12 Oct 2016 03:55:55 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Oct 2016 04:55:55 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 11 Oct 2016 20:55:52 -0700 From: Dean cheng To: Paul Aitken , "draft-ietf-radext-ip-port-radius-ext@tools.ietf.org" Thread-Topic: [radext] draft-ietf-radext-ip-port-radius-ext Thread-Index: AQHSJAAu16Wv/kgYX06Go4HR8UNZ/KCkEo+g Date: Wed, 12 Oct 2016 03:55:51 +0000 Message-ID: References: <2aa8a0ae-6974-f167-21f4-249a2bc0d69a@brocade.com> In-Reply-To: <2aa8a0ae-6974-f167-21f4-249a2bc0d69a@brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.190] Content-Type: multipart/mixed; boundary="_002_DC7880973D477648AC15A3BA66253F686F302C27dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57FDB44C.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2ee7c04c7b1e85de0f45f935457a6376 Archived-At: Cc: "bclaise@cisco.com" , "radext@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 03:56:02 -0000 --_002_DC7880973D477648AC15A3BA66253F686F302C27dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, We certainly missed this email of comments, but=20 please see below. Regards Dean > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Paul Aitken > Sent: Tuesday, October 11, 2016 1:43 PM > To: draft-ietf-radext-ip-port-radius-ext@tools.ietf.org > Cc: bclaise@cisco.com; radext@ietf.org; > Kathleen.Moriarty.ietf@gmail.com > Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext >=20 > Authors I've been waiting 2 months, yet no reply? >=20 > P. >=20 >=20 > On 08/11/16 17:24, Paul Aitken wrote: > > Dear Authors, some questions came to mind while reviewing section 3.2 > > of your draft: > > > > > > Q1: Why define a new TLV-Type 1..11 simply to encode an IPFIX > > Information Element? > > > > Since there's a 1:1 mapping between the TLV-Type and IPFIX Element ID, > > the scheme you propose would be more extensible if the IPFIX Element > > ID was used instead of the TLV-Type since it would require one less > > registry. True, one additional byte would be required in the encoding. > > However, the advantage is that in future anyone could encode a new > TLV > > by using the relevant IPFIX ID, without having to also define a new > > TLV-Type for it. The definition of the TLV-Type field (refer to Section 2.3 of RFC6929) is very different than that of IPFIX IE identifiers (refer to Section 4 of RFC5102), not just the size (8 bits vs. 16 bits) but also semantics, reserved values etc. =20 > > > > > > Q2: In each TLV, the Length field is redundant since it can always be > > determined from the TLV-Type: it's always 6, with special cases for > > TLV-Types 5 (Length is 18) and 11 (Length could be determined by a > > NULL terminator on the string). This suggests that the length is not > > required in the protocol, so why not remove it entirely? The length field is the second required one in a TLV structure, refer to Section 2.3 of RFC6929. > > > > > > However, many of the descriptions say "contains the data ... right > > justified, and the unused bits in this field MUST be set to zero. " > > > > Q3: Wouldn't it be better to limit the length of the field to an > > appropriate size for the data, and encode that size in the Length? This question was also raised by Suresh Krishnan, which was=20 already answered by Alan DeKok (see the attached). > > > > > > For example, the transportType in 3.2.1 is just one octet long > > (unsigned8) - so there's no reason to encode it in 32 bits. Why not > > encode it like so: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | TLV-Type =3D TBAx1 | Length | transportType | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The natEvent in 3.2.8 is also an unsigned8, so it would be encoded > > similarly - except that the TLV-Type would be 230, which is the IE ID > > of the IPFIX natEvent. > > > > > > The natTransportLimit in 3.2.2 is an unsigned16 - so there's no need > > to encode it in 32 bits. Why not encode it like so: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | TLV-Type =3D TBAx2 | Length |natTransportLimit ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ... | > > +-+-+-+-+-+-+-+-+ > > > > 3.2.9 and 3.2.10 would be similar. The encoding of 3.2.3, 3.2.4, and > > 3.2.5 would all be as shown in the draft, except that the TLV-type > > would be two octets long and contain the IPFIX IE ID. The > > sourceTransportPort in 3.2.6 is an unsigned16 - so there's no need to > > encode it in 32 bits. Why not encode it like so: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | TLV-Type =3D sourceTransportPort| Length | > > sourceTransportPort ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ... | > > +-+-+-+-+-+-+-+-+ > > > > The encoding of 3.2.7 would be similar. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --_002_DC7880973D477648AC15A3BA66253F686F302C27dfweml501mbb_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 12 Oct 2016 03:55:50 GMT"; modification-date="Wed, 12 Oct 2016 03:55:50 GMT" Received: from SZXEML426-HUB.china.huawei.com (10.82.67.181) by SJCEML702-CHM.china.huawei.com (10.218.25.35) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 18 Aug 2016 00:34:09 -0700 Received: from szxwg02-in.huawei.com (172.24.1.112) by SZXEML426-HUB.china.huawei.com (10.82.67.181) with Microsoft SMTP Server id 14.3.235.1; Thu, 18 Aug 2016 15:34:05 +0800 Received: from mail.ietf.org (unknown [4.31.198.44]) by Websense Email with ESMTPS id 0DDDFBE4C9AE5 for ; Thu, 18 Aug 2016 15:34:00 +0800 (CST) Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3E93B12D6AE; Thu, 18 Aug 2016 00:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3E12D753; Thu, 18 Aug 2016 00:33:59 -0700 (PDT) Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwh0fA8orGsi; Thu, 18 Aug 2016 00:33:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C92BA12D6AE; Thu, 18 Aug 2016 00:33:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 218D5C15; Thu, 18 Aug 2016 07:33:56 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksDHOeQmQG72; Thu, 18 Aug 2016 07:33:56 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-57-31.w80-13.abo.wanadoo.fr [80.13.34.31]) by mail.networkradius.com (Postfix) with ESMTPSA id AD34AA76; Thu, 18 Aug 2016 07:33:55 +0000 (UTC) From: Alan DeKok To: Suresh Krishnan CC: The IESG , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "lionel.morand@orange.com" , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Topic: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Index: AQHR+QQkpL/vlWPoCkygFwgxtHAT46BOyQ2A Date: Thu, 18 Aug 2016 07:33:53 +0000 Message-ID: <1B2C6F39-6BED-45F1-BEA7-1D099CDDA9D4@deployingradius.com> References: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> In-Reply-To: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: szxeml426-hub.china.huawei.com X-MS-Has-Attach: X-MS-TNEF-Correlator: Resent-From: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 On Aug 18, 2016, at 5:53 AM, Suresh Krishnan = wrote: > * Why are the the uint8 and unit16 based types getting stuffed into 32 > bit fields inside the TLVs? This feels like a complete waste. Is there > any specific reason this is required? The limited nature of RADIUS data types. This behaviour is mandated by R= FC 6158 https://tools.ietf.org/html/rfc6158#appendix-A.2.1 --_002_DC7880973D477648AC15A3BA66253F686F302C27dfweml501mbb_-- From nobody Wed Oct 12 01:14:21 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5012949E for ; Wed, 12 Oct 2016 01:14:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 W3IuUvvy8nBm for ; Wed, 12 Oct 2016 01:14:17 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 EE24E1296E5 for ; Wed, 12 Oct 2016 01:14:15 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9C8DQcb016712; Wed, 12 Oct 2016 01:13:58 -0700 Received: from hq1wp-exmb12.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 2615bh9ygq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Oct 2016 01:13:58 -0700 Received: from hq1wp-excas14.corp.brocade.com (10.70.38.103) by HQ1WP-EXMB12.corp.brocade.com (10.70.20.186) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Oct 2016 01:13:45 -0700 Received: from [172.27.212.171] (172.27.212.171) by hq1wp-excas14.corp.brocade.com (10.70.38.101) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 12 Oct 2016 01:13:54 -0700 To: Dean cheng , "draft-ietf-radext-ip-port-radius-ext@tools.ietf.org" References: <2aa8a0ae-6974-f167-21f4-249a2bc0d69a@brocade.com> From: Paul Aitken Message-ID: <22b82c04-3712-9b98-532b-8fa81cb5219d@brocade.com> Date: Wed, 12 Oct 2016 09:13:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120128 Archived-At: Cc: "bclaise@cisco.com" , "radext@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 08:14:20 -0000 Thanks for the quick response, Dean. Please find some responses inline: On 10/12/16 04:55, Dean cheng wrote: > Paul, > > We certainly missed this email of comments, but > please see below. > > Regards > Dean > >> -----Original Message----- >> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Paul Aitken >> Sent: Tuesday, October 11, 2016 1:43 PM >> To: draft-ietf-radext-ip-port-radius-ext@tools.ietf.org >> Cc: bclaise@cisco.com; radext@ietf.org; >> Kathleen.Moriarty.ietf@gmail.com >> Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext >> >> Authors I've been waiting 2 months, yet no reply? >> >> P. >> >> >> On 08/11/16 17:24, Paul Aitken wrote: >>> Dear Authors, some questions came to mind while reviewing section 3.2 >>> of your draft: >>> >>> >>> Q1: Why define a new TLV-Type 1..11 simply to encode an IPFIX >>> Information Element? >>> >>> Since there's a 1:1 mapping between the TLV-Type and IPFIX Element ID, >>> the scheme you propose would be more extensible if the IPFIX Element >>> ID was used instead of the TLV-Type since it would require one less >>> registry. True, one additional byte would be required in the encoding. >>> However, the advantage is that in future anyone could encode a new TLV >>> by using the relevant IPFIX ID, without having to also define a new >>> TLV-Type for it. > The definition of the TLV-Type field (refer to Section 2.3 of RFC6929) > is very different than that of IPFIX IE identifiers (refer to > Section 4 of RFC5102), not just the size (8 bits vs. 16 bits) > but also semantics, reserved values etc. Nowhere in this draft says that the TLV-type field refers to RFC6929. Since there's a 1:1 mapping between the values of this field and IPFIX Information Element IDs (since most of section 3.2.x say, "This attribute carries IPFIX Information Element X"), it seems to be simply another name and another registry for the same thing. >>> Q2: In each TLV, the Length field is redundant since it can always be >>> determined from the TLV-Type: it's always 6, with special cases for >>> TLV-Types 5 (Length is 18) and 11 (Length could be determined by a >>> NULL terminator on the string). This suggests that the length is not >>> required in the protocol, so why not remove it entirely? > The length field is the second required one in a TLV structure, refer > to Section 2.3 of RFC6929. And my point is that it's redundant. >>> >>> However, many of the descriptions say "contains the data ... right >>> justified, and the unused bits in this field MUST be set to zero. " >>> >>> Q3: Wouldn't it be better to limit the length of the field to an >>> appropriate size for the data, and encode that size in the Length? > This question was also raised by Suresh Krishnan, which was > already answered by Alan DeKok (see the attached). (ie, "The limited nature of RADIUS data types. This behaviour is mandated by RFC 6158") Abstract the data type from the octets on the wire. Since the length is given in the packet (or can be infered from the TLV type per Q2 above), there's no need to transmit redundant octets. P. >>> For example, the transportType in 3.2.1 is just one octet long >>> (unsigned8) - so there's no reason to encode it in 32 bits. Why not >>> encode it like so: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV-Type = TBAx1 | Length | transportType | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> The natEvent in 3.2.8 is also an unsigned8, so it would be encoded >>> similarly - except that the TLV-Type would be 230, which is the IE ID >>> of the IPFIX natEvent. >>> >>> >>> The natTransportLimit in 3.2.2 is an unsigned16 - so there's no need >>> to encode it in 32 bits. Why not encode it like so: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV-Type = TBAx2 | Length |natTransportLimit ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ... | >>> +-+-+-+-+-+-+-+-+ >>> >>> 3.2.9 and 3.2.10 would be similar. The encoding of 3.2.3, 3.2.4, and >>> 3.2.5 would all be as shown in the draft, except that the TLV-type >>> would be two octets long and contain the IPFIX IE ID. The >>> sourceTransportPort in 3.2.6 is an unsigned16 - so there's no need to >>> encode it in 32 bits. Why not encode it like so: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV-Type = sourceTransportPort| Length | sourceTransportPort ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ... | >>> +-+-+-+-+-+-+-+-+ >>> >>> The encoding of 3.2.7 would be similar. >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_radext&d=DQIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=dEtr3XevxedcGIFIR0evA2jpVRKktTCFIE9_hDx1iO4&s=t1n5rKGP56p05NoEUsOlAkh5nDurkUeCLuNN4hVxXSU&e= From nobody Wed Oct 12 06:54:50 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCC12952F for ; Wed, 12 Oct 2016 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 bOt6TvsDcll4 for ; Wed, 12 Oct 2016 06:54:46 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1693129519 for ; Wed, 12 Oct 2016 06:54:45 -0700 (PDT) Received: (qmail 1865 invoked from network); 12 Oct 2016 15:54:43 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 12 Oct 2016 15:54:43 +0200 To: mohamed.boucadair@orange.com, The IESG References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <0172bbaa-df60-cbb1-d305-07263fd193b3@kuehlewind.net> Date: Wed, 12 Oct 2016 15:54:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "radext-chairs@ietf.org" , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:54:49 -0000 Hi Mohamed, thanks for these changes. Using the IANA protocol number seems to be the right thing to do! One tiny additional question/comment: the term "IP port" or "IP transport port" seems a little weird (because ports are in the transport header and not in the IP header). Is it important to use this term to indicate that it's IP underneath or could you simply speak about "transport ports" instead? Thanks! Mirja On 29.09.2016 08:44, mohamed.boucadair@orange.com wrote: > Dear Mirja, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : radext [mailto:radext-bounces@ietf.org] De la part de Mirja >> Kuehlewind >> Envoyé : mercredi 17 août 2016 16:04 >> À : The IESG >> Cc : draft-ietf-radext-ip-port-radius-ext@ietf.org; MORAND Lionel IMT/OLN; >> radext-chairs@ietf.org; radext@ietf.org >> Objet : [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port- >> radius-ext-11: (with DISCUSS) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-radext-ip-port-radius-ext-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I fully support Alissa's discussion points and have two more to add: >> >> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >> future-proof: there are other transport protocols that have ports or >> identifiers that may want to be supported in future. > > [Med] This is a fair comment. FWIW, only TCP/UDP/ICMP are covered initially in the draft because those are currently the only ones supported by widely deployed CGNs. > > Also it is not clear >> to me from the document why this information is needed at all in the >> described use cases. > > [Med] Because ports are bound to a transport protocol (e.g., of the port forwarding in Section 4.1.3). In modern NATs, when an (explicit/implicit) mapping is created, a port is reserved only for a given transport protocol not for all transport protocols. > > Therefore I see two possible ways forward: Either >> remove the IP-Port-Type TLV or extend it to also cover other cases. > > [Med] The new version of the draft extends the TLV to be applicable to other transport protocols. We are using the IANA protocol numbers (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). > >> >> Related to this point I would like to mention that RFC6887 is not >> restricted to UDP/TCP and therefore the following sentence in section 2 >> is not correct: >> "Note that the definitions of [...] "internal port", [...] "external >> port" [...] are the same as defined in Port Control Protocol (PCP) >> [RFC6887]" > > [Med] This is not an issue given that the new version of the draft is not restricted to TCP/UDP. > From nobody Wed Oct 12 07:03:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8BE129520; Wed, 12 Oct 2016 07:03:40 -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, 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 9T5fJH60q7do; Wed, 12 Oct 2016 07:03:38 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 79FFD129477; Wed, 12 Oct 2016 07:03:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 740B51F70; Wed, 12 Oct 2016 14:03:36 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK7WzzKTCWlk; Wed, 12 Oct 2016 14:03:36 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id C4E30A6D; Wed, 12 Oct 2016 14:03:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 12 Oct 2016 10:03:34 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4A496E2D-A2D0-4BB9-8CFE-B606BCFF1174@deployingradius.com> References: <147137707081.22859.2851427602812447816.idtracker@ietfa.amsl.com> To: IESG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:03:40 -0000 > In Section 4.1, if the registration policy is Standards Action doesn't > that obviate the need to say anything about IETF Review? Yes. I'll update the draft. Alan DeKok. From nobody Wed Oct 12 07:08:28 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9012952F; Wed, 12 Oct 2016 07:08:26 -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, 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 NRpT7SY3rcEs; Wed, 12 Oct 2016 07:08:26 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D1D6712952A; Wed, 12 Oct 2016 07:08:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 24CA41F70; Wed, 12 Oct 2016 14:08:25 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlY-sxSF6bI4; Wed, 12 Oct 2016 14:08:25 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 6BAED47A; Wed, 12 Oct 2016 14:08:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 12 Oct 2016 10:08:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C315C09-71A7-46B6-AFE5-14EA35D6F256@deployingradius.com> References: <147142512074.12181.7172134882556272250.idtracker@ietfa.amsl.com> To: IESG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-datatypes-06=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:08:27 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "As RADIUS does not encode information about data types in a packet, = the > numbers assigned to a data type will never occur in a packet." > Given the Name must be unique, I don't see why a Value field is = needed. It's not. It's just useful to do. In the future, we may want to use the numbers, so we might as well = assign them now. > Related: There is an inconsitency between section 4.1 and 6 regarding = the > use of Description/Name. Fixed, thanks.= From nobody Wed Oct 12 07:15:32 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA006129538; Wed, 12 Oct 2016 07:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AH3k6vyT5MtR; Wed, 12 Oct 2016 07:15:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0BE129535; Wed, 12 Oct 2016 07:15:15 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 9A7C6C0C66; Wed, 12 Oct 2016 16:15:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 1F5A71C006D; Wed, 12 Oct 2016 16:15:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 16:15:08 +0200 From: To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG Thread-Topic: =?utf-8?B?W3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBESVND?= =?utf-8?Q?USS)?= Thread-Index: AQHSJJAx8YBholNGtk6W3SdwKizTX6Ck206Q Date: Wed, 12 Oct 2016 14:15:07 +0000 Message-ID: References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <0172bbaa-df60-cbb1-d305-07263fd193b3@kuehlewind.net> In-Reply-To: <0172bbaa-df60-cbb1-d305-07263fd193b3@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "radext-chairs@ietf.org" , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:15:25 -0000 SGkgTWlyamEsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1pcmphIEvDvGhsZXdpbmQgW21haWx0 bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDEyIG9jdG9icmUg MjAxNiAxNTo1NQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBUaGUgSUVTRw0K PiBDY8KgOiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHRAaWV0Zi5vcmc7IE1P UkFORCBMaW9uZWwgSU1UL09MTjsNCj4gcmFkZXh0LWNoYWlyc0BpZXRmLm9yZzsgcmFkZXh0QGll dGYub3JnDQo+IE9iamV0wqA6IFJlOiBbcmFkZXh0XSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLXJhZGV4dC1pcC0NCj4gcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBE SVNDVVNTKQ0KPiANCj4gSGkgTW9oYW1lZCwNCj4gDQo+IHRoYW5rcyBmb3IgdGhlc2UgY2hhbmdl cy4gVXNpbmcgdGhlIElBTkEgcHJvdG9jb2wgbnVtYmVyIHNlZW1zIHRvIGJlIHRoZQ0KPiByaWdo dCB0aGluZyB0byBkbyENCg0KW01lZF0gR3JlYXQhDQoNCj4gDQo+IE9uZSB0aW55IGFkZGl0aW9u YWwgcXVlc3Rpb24vY29tbWVudDogdGhlIHRlcm0gIklQIHBvcnQiIG9yICJJUCB0cmFuc3BvcnQN Cj4gcG9ydCIgc2VlbXMgYSBsaXR0bGUgd2VpcmQgKGJlY2F1c2UgcG9ydHMgYXJlIGluIHRoZSB0 cmFuc3BvcnQgaGVhZGVyIGFuZA0KPiBub3QNCj4gaW4gdGhlIElQIGhlYWRlcikuIElzIGl0IGlt cG9ydGFudCB0byB1c2UgdGhpcyB0ZXJtIHRvIGluZGljYXRlIHRoYXQgaXQncw0KPiBJUA0KPiB1 bmRlcm5lYXRoIG9yIGNvdWxkIHlvdSBzaW1wbHkgc3BlYWsgYWJvdXQgInRyYW5zcG9ydCBwb3J0 cyIgaW5zdGVhZD8NCg0KW01lZF0gV2UgdXNlZCAiSVAiIG9uIHB1cnBvc2UgdG8gYXZvaWQgdGhh dCB0aGUgdGVybSAicG9ydCIgaXMgbWlzdW5kZXJzdG9vZCBhcyByZWZlcnJpbmcgdG8gYSBwaHlz aWNhbCBwb3J0LiBVc2luZyBzaW1wbHkgInRyYW5zcG9ydCBwb3J0IiBkb2VzIG5vdCBoZWxwIGVp dGhlciB0byBjbGFyaWZ5IHRoYXQgY29uZnVzaW9uLiBUaGlzIGlzIHdoeSB3ZSB3ZW50IGZvciBl eHBsaWNpdGx5IHVzaW5nICJJUCB4eHgiIHRvIG1ha2UgaXQgY2xlYXIgd2UgYXJlIGRlYWxpbmcg d2l0aCBwb3J0IG51bWJlcnMgdGhhdCBhcmUgdXNlZCBieSBwcm90b2NvbHMgdHJhbnNwb3J0ZWQg b3ZlciBJUC4NCg0KPiANCj4gVGhhbmtzIQ0KPiBNaXJqYQ0KPiANCj4gDQo+IE9uIDI5LjA5LjIw MTYgMDg6NDQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gRGVhciBN aXJqYSwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+ IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IHJh ZGV4dCBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1pcmph DQo+ID4+IEt1ZWhsZXdpbmQNCj4gPj4gRW52b3nDqSA6IG1lcmNyZWRpIDE3IGFvw7t0IDIwMTYg MTY6MDQNCj4gPj4gw4AgOiBUaGUgSUVTRw0KPiA+PiBDYyA6IGRyYWZ0LWlldGYtcmFkZXh0LWlw LXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsgTU9SQU5EIExpb25lbA0KPiBJTVQvT0xOOw0KPiA+ PiByYWRleHQtY2hhaXJzQGlldGYub3JnOyByYWRleHRAaWV0Zi5vcmcNCj4gPj4gT2JqZXQgOiBb cmFkZXh0XSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJhZGV4dC1p cC0NCj4gcG9ydC0NCj4gPj4gcmFkaXVzLWV4dC0xMTogKHdpdGggRElTQ1VTUykNCj4gPj4NCj4g Pj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gPj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiBE aXNjdXNzDQo+ID4+DQo+ID4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+PiBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiA+ PiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4NCj4gPj4NCj4gPj4gUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt DQo+IGNyaXRlcmlhLmh0bWwNCj4gPj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIGRvY3Vt ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJl Og0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhZGV4 dC1pcC1wb3J0LXJhZGl1cy1leHQvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+PiBJIGZ1bGx5 IHN1cHBvcnQgQWxpc3NhJ3MgZGlzY3Vzc2lvbiBwb2ludHMgYW5kIGhhdmUgdHdvIG1vcmUgdG8g YWRkOg0KPiA+Pg0KPiA+PiAxKSBJUC1Qb3J0LVR5cGUgVExWIG9ubHkgY292ZXJzIFVEUCwgVENQ IGFuZCBJQ01QLiBUaGlzIGlzIG5vdCB2ZXJ5DQo+ID4+IGZ1dHVyZS1wcm9vZjogdGhlcmUgYXJl IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCBoYXZlIHBvcnRzIG9yDQo+ID4+IGlkZW50 aWZpZXJzIHRoYXQgbWF5IHdhbnQgdG8gYmUgc3VwcG9ydGVkIGluIGZ1dHVyZS4NCj4gPg0KPiA+ IFtNZWRdIFRoaXMgaXMgYSBmYWlyIGNvbW1lbnQuIEZXSVcsIG9ubHkgVENQL1VEUC9JQ01QIGFy ZSBjb3ZlcmVkDQo+IGluaXRpYWxseSBpbiB0aGUgZHJhZnQgYmVjYXVzZSB0aG9zZSBhcmUgY3Vy cmVudGx5IHRoZSBvbmx5IG9uZXMgc3VwcG9ydGVkDQo+IGJ5IHdpZGVseSBkZXBsb3llZCBDR05z Lg0KPiA+DQo+ID4gIEFsc28gaXQgaXMgbm90IGNsZWFyDQo+ID4+IHRvIG1lIGZyb20gdGhlIGRv Y3VtZW50IHdoeSB0aGlzIGluZm9ybWF0aW9uIGlzIG5lZWRlZCBhdCBhbGwgaW4gdGhlDQo+ID4+ IGRlc2NyaWJlZCB1c2UgY2FzZXMuDQo+ID4NCj4gPiBbTWVkXSBCZWNhdXNlIHBvcnRzIGFyZSBi b3VuZCB0byBhIHRyYW5zcG9ydCBwcm90b2NvbCAoZS5nLiwgb2YgdGhlIHBvcnQNCj4gZm9yd2Fy ZGluZyBpbiBTZWN0aW9uIDQuMS4zKS4gSW4gbW9kZXJuIE5BVHMsIHdoZW4gYW4gKGV4cGxpY2l0 L2ltcGxpY2l0KQ0KPiBtYXBwaW5nIGlzIGNyZWF0ZWQsIGEgcG9ydCBpcyByZXNlcnZlZCBvbmx5 IGZvciBhIGdpdmVuIHRyYW5zcG9ydCBwcm90b2NvbA0KPiBub3QgZm9yIGFsbCB0cmFuc3BvcnQg cHJvdG9jb2xzLg0KPiA+DQo+ID4gIFRoZXJlZm9yZSBJIHNlZSB0d28gcG9zc2libGUgd2F5cyBm b3J3YXJkOiBFaXRoZXINCj4gPj4gcmVtb3ZlIHRoZSBJUC1Qb3J0LVR5cGUgVExWIG9yIGV4dGVu ZCBpdCB0byBhbHNvIGNvdmVyIG90aGVyIGNhc2VzLg0KPiA+DQo+ID4gW01lZF0gVGhlIG5ldyB2 ZXJzaW9uIG9mIHRoZSBkcmFmdCBleHRlbmRzIHRoZSBUTFYgdG8gYmUgYXBwbGljYWJsZSB0bw0K PiBvdGhlciB0cmFuc3BvcnQgcHJvdG9jb2xzLiBXZSBhcmUgdXNpbmcgdGhlIElBTkEgcHJvdG9j b2wgbnVtYmVycw0KPiAoaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9wcm90b2NvbC1u dW1iZXJzL3Byb3RvY29sLW51bWJlcnMueGh0bWwpLg0KPiA+DQo+ID4+DQo+ID4+IFJlbGF0ZWQg dG8gdGhpcyBwb2ludCBJIHdvdWxkIGxpa2UgdG8gbWVudGlvbiB0aGF0IFJGQzY4ODcgaXMgbm90 DQo+ID4+IHJlc3RyaWN0ZWQgdG8gVURQL1RDUCBhbmQgdGhlcmVmb3JlIHRoZSBmb2xsb3dpbmcg c2VudGVuY2UgaW4gc2VjdGlvbiAyDQo+ID4+IGlzIG5vdCBjb3JyZWN0Og0KPiA+PiAiTm90ZSB0 aGF0IHRoZSBkZWZpbml0aW9ucyBvZiBbLi4uXSAiaW50ZXJuYWwgcG9ydCIsIFsuLi5dICJleHRl cm5hbA0KPiA+PiBwb3J0IiBbLi4uXSBhcmUgdGhlIHNhbWUgYXMgZGVmaW5lZCBpbiBQb3J0IENv bnRyb2wgUHJvdG9jb2wgKFBDUCkNCj4gPj4gW1JGQzY4ODddIg0KPiA+DQo+ID4gW01lZF0gVGhp cyBpcyBub3QgYW4gaXNzdWUgZ2l2ZW4gdGhhdCB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0 IGlzDQo+IG5vdCByZXN0cmljdGVkIHRvIFRDUC9VRFAuDQo+ID4NCg== From nobody Wed Oct 12 07:21:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF8129549 for ; Wed, 12 Oct 2016 07:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 sJh6aG6RbLNr for ; Wed, 12 Oct 2016 07:20:53 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BE0129536 for ; Wed, 12 Oct 2016 07:20:53 -0700 (PDT) Received: (qmail 3406 invoked from network); 12 Oct 2016 16:20:51 +0200 Received: from public-docking-pat-etx-mapped-0029.ethz.ch (HELO ?10.2.118.142?) (195.176.110.254) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Oct 2016 16:20:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Oct 2016 16:20:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <0172bbaa-df60-cbb1-d305-07263fd193b3@kuehlewind.net> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext-chairs@ietf.org" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , The IESG , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:20:58 -0000 I=E2=80=99m okay with that. But why does =E2=80=9Etransport port=E2=80=9C = not clarify this confusion. Or maybe it should be =E2=80=9Etransport = protocol port=E2=80=9C then? Mirja > Am 12.10.2016 um 16:15 schrieb mohamed.boucadair@orange.com: >=20 > Hi Mirja,=20 >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] >> Envoy=C3=A9 : mercredi 12 octobre 2016 15:55 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; The IESG >> Cc : draft-ietf-radext-ip-port-radius-ext@ietf.org; MORAND Lionel = IMT/OLN; >> radext-chairs@ietf.org; radext@ietf.org >> Objet : Re: [radext] Mirja K=C3=BChlewind's Discuss on = draft-ietf-radext-ip- >> port-radius-ext-11: (with DISCUSS) >>=20 >> Hi Mohamed, >>=20 >> thanks for these changes. Using the IANA protocol number seems to be = the >> right thing to do! >=20 > [Med] Great! >=20 >>=20 >> One tiny additional question/comment: the term "IP port" or "IP = transport >> port" seems a little weird (because ports are in the transport header = and >> not >> in the IP header). Is it important to use this term to indicate that = it's >> IP >> underneath or could you simply speak about "transport ports" instead? >=20 > [Med] We used "IP" on purpose to avoid that the term "port" is = misunderstood as referring to a physical port. Using simply "transport = port" does not help either to clarify that confusion. This is why we = went for explicitly using "IP xxx" to make it clear we are dealing with = port numbers that are used by protocols transported over IP. >=20 >>=20 >> Thanks! >> Mirja >>=20 >>=20 >> On 29.09.2016 08:44, mohamed.boucadair@orange.com wrote: >>> Dear Mirja, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : radext [mailto:radext-bounces@ietf.org] De la part de Mirja >>>> Kuehlewind >>>> Envoy=C3=A9 : mercredi 17 ao=C3=BBt 2016 16:04 >>>> =C3=80 : The IESG >>>> Cc : draft-ietf-radext-ip-port-radius-ext@ietf.org; MORAND Lionel >> IMT/OLN; >>>> radext-chairs@ietf.org; radext@ietf.org >>>> Objet : [radext] Mirja K=C3=BChlewind's Discuss on = draft-ietf-radext-ip- >> port- >>>> radius-ext-11: (with DISCUSS) >>>>=20 >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to https://www.ietf.org/iesg/statement/discuss- >> criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I fully support Alissa's discussion points and have two more to = add: >>>>=20 >>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >>>> future-proof: there are other transport protocols that have ports = or >>>> identifiers that may want to be supported in future. >>>=20 >>> [Med] This is a fair comment. FWIW, only TCP/UDP/ICMP are covered >> initially in the draft because those are currently the only ones = supported >> by widely deployed CGNs. >>>=20 >>> Also it is not clear >>>> to me from the document why this information is needed at all in = the >>>> described use cases. >>>=20 >>> [Med] Because ports are bound to a transport protocol (e.g., of the = port >> forwarding in Section 4.1.3). In modern NATs, when an = (explicit/implicit) >> mapping is created, a port is reserved only for a given transport = protocol >> not for all transport protocols. >>>=20 >>> Therefore I see two possible ways forward: Either >>>> remove the IP-Port-Type TLV or extend it to also cover other cases. >>>=20 >>> [Med] The new version of the draft extends the TLV to be applicable = to >> other transport protocols. We are using the IANA protocol numbers >> = (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).= >>>=20 >>>>=20 >>>> Related to this point I would like to mention that RFC6887 is not >>>> restricted to UDP/TCP and therefore the following sentence in = section 2 >>>> is not correct: >>>> "Note that the definitions of [...] "internal port", [...] = "external >>>> port" [...] are the same as defined in Port Control Protocol (PCP) >>>> [RFC6887]" >>>=20 >>> [Med] This is not an issue given that the new version of the draft = is >> not restricted to TCP/UDP. >>>=20 From nobody Wed Oct 12 07:24:13 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EED4129532; Wed, 12 Oct 2016 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 W6lqISbvVgkb; Wed, 12 Oct 2016 07:24:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFE512944D; Wed, 12 Oct 2016 07:24:08 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 7CB084045B; Wed, 12 Oct 2016 16:24:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 3317D2006E; Wed, 12 Oct 2016 16:24:05 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 16:24:02 +0200 From: To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?W3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBESVND?= =?utf-8?Q?USS)?= Thread-Index: AQHSJJPWWzoL+4momkOo8LWAnHopgqCk3qCg Date: Wed, 12 Oct 2016 14:24:01 +0000 Message-ID: References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <0172bbaa-df60-cbb1-d305-07263fd193b3@kuehlewind.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "radext-chairs@ietf.org" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , The IESG , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:24:10 -0000 UmUtLA0KDQpCZWNhdXNlICJ0cmFuc3BvcnQgcG9ydCIgbWF5IGJlIChtaXMpdW5kZXJzdG9vZCBi eSB0cmFuc21pc3Npb24gcGVvcGxlIGFzIGJlaW5nIGEgdHJhbnNtaXNzaW9uIHBvcnQuIA0KDQoi dHJhbnNwb3J0IiBpcyBvbmUgb2YgdGhlc2Ugb3ZlcmxvYWRlZCB0ZXJtcy4gU2VlIGZvciBleGFt cGxlIHRoZSBvbmdvaW5nIGVmZm9ydHMgYWJvdXQgVHJhbnNwb3J0IFNETiAmIGNpZS4NCg0KQ2hl ZXJzLCANCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBNaXJq YSBLdWVobGV3aW5kIChJRVRGKSBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IEVudm95 w6nCoDogbWVyY3JlZGkgMTIgb2N0b2JyZSAyMDE2IDE2OjIxDQo+IMOAwqA6IEJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogVGhlIElFU0c7IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBv cnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsgTU9SQU5EDQo+IExpb25lbCBJTVQvT0xOOyByYWRleHQt Y2hhaXJzQGlldGYub3JnOyByYWRleHRAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtyYWRleHRd IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLQ0KPiBw b3J0LXJhZGl1cy1leHQtMTE6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBJ4oCZbSBva2F5IHdpdGgg dGhhdC4gQnV0IHdoeSBkb2VzIOKAnnRyYW5zcG9ydCBwb3J04oCcIG5vdCBjbGFyaWZ5IHRoaXMN Cj4gY29uZnVzaW9uLiBPciBtYXliZSBpdCBzaG91bGQgYmUg4oCedHJhbnNwb3J0IHByb3RvY29s IHBvcnTigJwgdGhlbj8NCj4gDQo+IE1pcmphDQo+IA0KPiANCj4gPiBBbSAxMi4xMC4yMDE2IHVt IDE2OjE1IHNjaHJpZWIgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbToNCj4gPg0KPiA+IEhp IE1pcmphLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDog TWlyamEgS8O8aGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+ID4+IEVudm95 w6kgOiBtZXJjcmVkaSAxMiBvY3RvYnJlIDIwMTYgMTU6NTUNCj4gPj4gw4AgOiBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBUaGUgSUVTRw0KPiA+PiBDYyA6IGRyYWZ0LWlldGYtcmFkZXh0LWlw LXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsgTU9SQU5EIExpb25lbA0KPiBJTVQvT0xOOw0KPiA+ PiByYWRleHQtY2hhaXJzQGlldGYub3JnOyByYWRleHRAaWV0Zi5vcmcNCj4gPj4gT2JqZXQgOiBS ZTogW3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yYWRl eHQtaXAtDQo+ID4+IHBvcnQtcmFkaXVzLWV4dC0xMTogKHdpdGggRElTQ1VTUykNCj4gPj4NCj4g Pj4gSGkgTW9oYW1lZCwNCj4gPj4NCj4gPj4gdGhhbmtzIGZvciB0aGVzZSBjaGFuZ2VzLiBVc2lu ZyB0aGUgSUFOQSBwcm90b2NvbCBudW1iZXIgc2VlbXMgdG8gYmUNCj4gdGhlDQo+ID4+IHJpZ2h0 IHRoaW5nIHRvIGRvIQ0KPiA+DQo+ID4gW01lZF0gR3JlYXQhDQo+ID4NCj4gPj4NCj4gPj4gT25l IHRpbnkgYWRkaXRpb25hbCBxdWVzdGlvbi9jb21tZW50OiB0aGUgdGVybSAiSVAgcG9ydCIgb3Ig IklQDQo+IHRyYW5zcG9ydA0KPiA+PiBwb3J0IiBzZWVtcyBhIGxpdHRsZSB3ZWlyZCAoYmVjYXVz ZSBwb3J0cyBhcmUgaW4gdGhlIHRyYW5zcG9ydCBoZWFkZXINCj4gYW5kDQo+ID4+IG5vdA0KPiA+ PiBpbiB0aGUgSVAgaGVhZGVyKS4gSXMgaXQgaW1wb3J0YW50IHRvIHVzZSB0aGlzIHRlcm0gdG8g aW5kaWNhdGUgdGhhdA0KPiBpdCdzDQo+ID4+IElQDQo+ID4+IHVuZGVybmVhdGggb3IgY291bGQg eW91IHNpbXBseSBzcGVhayBhYm91dCAidHJhbnNwb3J0IHBvcnRzIiBpbnN0ZWFkPw0KPiA+DQo+ ID4gW01lZF0gV2UgdXNlZCAiSVAiIG9uIHB1cnBvc2UgdG8gYXZvaWQgdGhhdCB0aGUgdGVybSAi cG9ydCIgaXMNCj4gbWlzdW5kZXJzdG9vZCBhcyByZWZlcnJpbmcgdG8gYSBwaHlzaWNhbCBwb3J0 LiBVc2luZyBzaW1wbHkgInRyYW5zcG9ydA0KPiBwb3J0IiBkb2VzIG5vdCBoZWxwIGVpdGhlciB0 byBjbGFyaWZ5IHRoYXQgY29uZnVzaW9uLiBUaGlzIGlzIHdoeSB3ZSB3ZW50DQo+IGZvciBleHBs aWNpdGx5IHVzaW5nICJJUCB4eHgiIHRvIG1ha2UgaXQgY2xlYXIgd2UgYXJlIGRlYWxpbmcgd2l0 aCBwb3J0DQo+IG51bWJlcnMgdGhhdCBhcmUgdXNlZCBieSBwcm90b2NvbHMgdHJhbnNwb3J0ZWQg b3ZlciBJUC4NCj4gPg0KPiA+Pg0KPiA+PiBUaGFua3MhDQo+ID4+IE1pcmphDQo+ID4+DQo+ID4+ DQo+ID4+IE9uIDI5LjA5LjIwMTYgMDg6NDQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20g d3JvdGU6DQo+ID4+PiBEZWFyIE1pcmphLA0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBzZWUgaW5saW5l Lg0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+IE1lZA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4+PiBEZSA6IHJhZGV4dCBbbWFpbHRvOnJhZGV4dC1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1pcmphDQo+ID4+Pj4gS3VlaGxld2luZA0K PiA+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAxNyBhb8O7dCAyMDE2IDE2OjA0DQo+ID4+Pj4gw4Ag OiBUaGUgSUVTRw0KPiA+Pj4+IENjIDogZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMt ZXh0QGlldGYub3JnOyBNT1JBTkQgTGlvbmVsDQo+ID4+IElNVC9PTE47DQo+ID4+Pj4gcmFkZXh0 LWNoYWlyc0BpZXRmLm9yZzsgcmFkZXh0QGlldGYub3JnDQo+ID4+Pj4gT2JqZXQgOiBbcmFkZXh0 XSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJhZGV4dC1pcC0NCj4g Pj4gcG9ydC0NCj4gPj4+PiByYWRpdXMtZXh0LTExOiAod2l0aCBESVNDVVNTKQ0KPiA+Pj4+DQo+ ID4+Pj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gPj4+PiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQt MTE6IERpc2N1c3MNCj4gPj4+Pg0KPiA+Pj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+Pj4+IGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dA0KPiB0aGlzDQo+ID4+Pj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiA+PiBjcml0ZXJpYS5odG1sDQo+ID4+Pj4gZm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+Pj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLQ0KPiBl eHQvDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4g Pj4+PiBESVNDVVNTOg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+ID4+Pj4NCj4gPj4+PiBJ IGZ1bGx5IHN1cHBvcnQgQWxpc3NhJ3MgZGlzY3Vzc2lvbiBwb2ludHMgYW5kIGhhdmUgdHdvIG1v cmUgdG8gYWRkOg0KPiA+Pj4+DQo+ID4+Pj4gMSkgSVAtUG9ydC1UeXBlIFRMViBvbmx5IGNvdmVy cyBVRFAsIFRDUCBhbmQgSUNNUC4gVGhpcyBpcyBub3QgdmVyeQ0KPiA+Pj4+IGZ1dHVyZS1wcm9v ZjogdGhlcmUgYXJlIG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCBoYXZlIHBvcnRzIG9y DQo+ID4+Pj4gaWRlbnRpZmllcnMgdGhhdCBtYXkgd2FudCB0byBiZSBzdXBwb3J0ZWQgaW4gZnV0 dXJlLg0KPiA+Pj4NCj4gPj4+IFtNZWRdIFRoaXMgaXMgYSBmYWlyIGNvbW1lbnQuIEZXSVcsIG9u bHkgVENQL1VEUC9JQ01QIGFyZSBjb3ZlcmVkDQo+ID4+IGluaXRpYWxseSBpbiB0aGUgZHJhZnQg YmVjYXVzZSB0aG9zZSBhcmUgY3VycmVudGx5IHRoZSBvbmx5IG9uZXMNCj4gc3VwcG9ydGVkDQo+ ID4+IGJ5IHdpZGVseSBkZXBsb3llZCBDR05zLg0KPiA+Pj4NCj4gPj4+IEFsc28gaXQgaXMgbm90 IGNsZWFyDQo+ID4+Pj4gdG8gbWUgZnJvbSB0aGUgZG9jdW1lbnQgd2h5IHRoaXMgaW5mb3JtYXRp b24gaXMgbmVlZGVkIGF0IGFsbCBpbiB0aGUNCj4gPj4+PiBkZXNjcmliZWQgdXNlIGNhc2VzLg0K PiA+Pj4NCj4gPj4+IFtNZWRdIEJlY2F1c2UgcG9ydHMgYXJlIGJvdW5kIHRvIGEgdHJhbnNwb3J0 IHByb3RvY29sIChlLmcuLCBvZiB0aGUNCj4gcG9ydA0KPiA+PiBmb3J3YXJkaW5nIGluIFNlY3Rp b24gNC4xLjMpLiBJbiBtb2Rlcm4gTkFUcywgd2hlbiBhbg0KPiAoZXhwbGljaXQvaW1wbGljaXQp DQo+ID4+IG1hcHBpbmcgaXMgY3JlYXRlZCwgYSBwb3J0IGlzIHJlc2VydmVkIG9ubHkgZm9yIGEg Z2l2ZW4gdHJhbnNwb3J0DQo+IHByb3RvY29sDQo+ID4+IG5vdCBmb3IgYWxsIHRyYW5zcG9ydCBw cm90b2NvbHMuDQo+ID4+Pg0KPiA+Pj4gVGhlcmVmb3JlIEkgc2VlIHR3byBwb3NzaWJsZSB3YXlz IGZvcndhcmQ6IEVpdGhlcg0KPiA+Pj4+IHJlbW92ZSB0aGUgSVAtUG9ydC1UeXBlIFRMViBvciBl eHRlbmQgaXQgdG8gYWxzbyBjb3ZlciBvdGhlciBjYXNlcy4NCj4gPj4+DQo+ID4+PiBbTWVkXSBU aGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGV4dGVuZHMgdGhlIFRMViB0byBiZSBhcHBsaWNh YmxlIHRvDQo+ID4+IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMuIFdlIGFyZSB1c2luZyB0aGUg SUFOQSBwcm90b2NvbCBudW1iZXJzDQo+ID4+IChodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL3Byb3RvY29sLW51bWJlcnMvcHJvdG9jb2wtDQo+IG51bWJlcnMueGh0bWwpLg0KPiA+Pj4N Cj4gPj4+Pg0KPiA+Pj4+IFJlbGF0ZWQgdG8gdGhpcyBwb2ludCBJIHdvdWxkIGxpa2UgdG8gbWVu dGlvbiB0aGF0IFJGQzY4ODcgaXMgbm90DQo+ID4+Pj4gcmVzdHJpY3RlZCB0byBVRFAvVENQIGFu ZCB0aGVyZWZvcmUgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpbiBzZWN0aW9uDQo+IDINCj4gPj4+ PiBpcyBub3QgY29ycmVjdDoNCj4gPj4+PiAiTm90ZSB0aGF0IHRoZSBkZWZpbml0aW9ucyBvZiBb Li4uXSAiaW50ZXJuYWwgcG9ydCIsIFsuLi5dICJleHRlcm5hbA0KPiA+Pj4+IHBvcnQiIFsuLi5d IGFyZSB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKQ0K PiA+Pj4+IFtSRkM2ODg3XSINCj4gPj4+DQo+ID4+PiBbTWVkXSBUaGlzIGlzIG5vdCBhbiBpc3N1 ZSBnaXZlbiB0aGF0IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMNCj4gPj4gbm90IHJl c3RyaWN0ZWQgdG8gVENQL1VEUC4NCj4gPj4+DQoNCg== From nobody Wed Oct 12 07:29:11 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD41612973A for ; Wed, 12 Oct 2016 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 L75kZSUY1iaE for ; Wed, 12 Oct 2016 07:29:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF1F12978B for ; Wed, 12 Oct 2016 07:29:00 -0700 (PDT) Received: (qmail 3466 invoked from network); 12 Oct 2016 16:22:17 +0200 Received: from public-docking-pat-etx-mapped-0029.ethz.ch (HELO ?10.2.118.142?) (195.176.110.254) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Oct 2016 16:22:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <3C315C09-71A7-46B6-AFE5-14EA35D6F256@deployingradius.com> Date: Wed, 12 Oct 2016 16:22:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E5B67F0-FA14-432E-8C79-92C68CDA47D7@kuehlewind.net> References: <147142512074.12181.7172134882556272250.idtracker@ietfa.amsl.com> <3C315C09-71A7-46B6-AFE5-14EA35D6F256@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , radext@ietf.org, draft-ietf-radext-datatypes@ietf.org, IESG , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-datatypes-06=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:29:05 -0000 Hi, see below. > Am 12.10.2016 um 16:08 schrieb Alan DeKok : >=20 >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> "As RADIUS does not encode information about data types in a packet, = the >> numbers assigned to a data type will never occur in a packet." >> Given the Name must be unique, I don't see why a Value field is = needed. >=20 > It's not. It's just useful to do. >=20 > In the future, we may want to use the numbers, so we might as well = assign them now. Not a big issue. However I don=E2=80=99t see a case where this could be = used in future, so I would say it is just not useful to do=E2=80=A6 Mirja >=20 >> Related: There is an inconsitency between section 4.1 and 6 regarding = the >> use of Description/Name. >=20 > Fixed, thanks. From nobody Wed Oct 12 15:29:02 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADB612954F for ; Wed, 12 Oct 2016 15:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 l1bnVa62t2pD for ; Wed, 12 Oct 2016 15:28:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8801294C9 for ; Wed, 12 Oct 2016 15:28:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTB12624; Wed, 12 Oct 2016 22:28:52 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Oct 2016 23:28:51 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 12 Oct 2016 15:28:46 -0700 From: Dean cheng To: Paul Aitken , "draft-ietf-radext-ip-port-radius-ext@tools.ietf.org" Thread-Topic: [radext] draft-ietf-radext-ip-port-radius-ext Thread-Index: AQHSJAAu16Wv/kgYX06Go4HR8UNZ/KCkEo+ggADb7YCAAASRUA== Date: Wed, 12 Oct 2016 22:28:45 +0000 Message-ID: References: <2aa8a0ae-6974-f167-21f4-249a2bc0d69a@brocade.com> <22b82c04-3712-9b98-532b-8fa81cb5219d@brocade.com> In-Reply-To: <22b82c04-3712-9b98-532b-8fa81cb5219d@brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57FEB925.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2ee7c04c7b1e85de0f45f935457a6376 Archived-At: Cc: "bclaise@cisco.com" , "radext@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:29:01 -0000 Paul, please see inline below. Thanks Dean > -----Original Message----- > From: Paul Aitken [mailto:paitken@brocade.com] > Sent: Wednesday, October 12, 2016 1:14 AM > To: Dean cheng; draft-ietf-radext-ip-port-radius-ext@tools.ietf.org > Cc: bclaise@cisco.com; radext@ietf.org; > Kathleen.Moriarty.ietf@gmail.com > Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext >=20 > Thanks for the quick response, Dean. Please find some responses inline: >=20 >=20 > On 10/12/16 04:55, Dean cheng wrote: > > Paul, > > > > We certainly missed this email of comments, but please see below. > > > > Regards > > Dean > > > >> -----Original Message----- > >> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Paul > >> Aitken > >> Sent: Tuesday, October 11, 2016 1:43 PM > >> To: draft-ietf-radext-ip-port-radius-ext@tools.ietf.org > >> Cc: bclaise@cisco.com; radext@ietf.org; > >> Kathleen.Moriarty.ietf@gmail.com > >> Subject: Re: [radext] draft-ietf-radext-ip-port-radius-ext > >> > >> Authors I've been waiting 2 months, yet no reply? > >> > >> P. > >> > >> > >> On 08/11/16 17:24, Paul Aitken wrote: > >>> Dear Authors, some questions came to mind while reviewing section > >>> 3.2 of your draft: > >>> > >>> > >>> Q1: Why define a new TLV-Type 1..11 simply to encode an IPFIX > >>> Information Element? > >>> > >>> Since there's a 1:1 mapping between the TLV-Type and IPFIX Element > >>> ID, the scheme you propose would be more extensible if the IPFIX > >>> Element ID was used instead of the TLV-Type since it would require > >>> one less registry. True, one additional byte would be required in > the encoding. > >>> However, the advantage is that in future anyone could encode a new > >>> TLV by using the relevant IPFIX ID, without having to also define a > >>> new TLV-Type for it. > > The definition of the TLV-Type field (refer to Section 2.3 of RFC6929) > > is very different than that of IPFIX IE identifiers (refer to Section > > 4 of RFC5102), not just the size (8 bits vs. 16 bits) but also > > semantics, reserved values etc. >=20 > Nowhere in this draft says that the TLV-type field refers to RFC6929. The reference to RFC6929 is repeated in Section 3.1.1, 3.1.2 and 3.1.3=20 where the proposed Radius attributes are presented, but also in the beginning of Section 3.2 before all sub-sections for individual=20 proposed TLVs. Here is the statement at the beginning of Section 3.2: =20 ....These TLVs use the format defined in [RFC6929].... =20 >=20 > Since there's a 1:1 mapping between the values of this field and IPFIX > Information Element IDs (since most of section 3.2.x say, "This > attribute carries IPFIX Information Element X"), it seems to be simply > another name and another registry for the same thing. As said, the TLV-Type field of Radius TLV (RFC6929) has totally different size and meaning than that of the IPFIX IE identifier (RFC5102), I'd consider it an engineering kludge to mingle them together. Please read Section 2.3 of RFC6929 and Section 4 of RFC5102. >=20 >=20 > >>> Q2: In each TLV, the Length field is redundant since it can always > >>> be determined from the TLV-Type: it's always 6, with special cases > >>> for TLV-Types 5 (Length is 18) and 11 (Length could be determined > by > >>> a NULL terminator on the string). This suggests that the length is > >>> not required in the protocol, so why not remove it entirely? > > The length field is the second required one in a TLV structure, refer > > to Section 2.3 of RFC6929. >=20 > And my point is that it's redundant. >=20 >=20 > >>> > >>> However, many of the descriptions say "contains the data ... right > >>> justified, and the unused bits in this field MUST be set to zero. " > >>> > >>> Q3: Wouldn't it be better to limit the length of the field to an > >>> appropriate size for the data, and encode that size in the Length? > > This question was also raised by Suresh Krishnan, which was already > > answered by Alan DeKok (see the attached). >=20 > (ie, "The limited nature of RADIUS data types. This behaviour is > mandated by RFC 6158") >=20 > Abstract the data type from the octets on the wire. Since the length is > given in the packet (or can be infered from the TLV type per Q2 above), > there's no need to transmit redundant octets. Are you saying you want to redefine TLV as TV? In this draft, we follow the TLV as defined in RFC6929 for Radius protocol, and more generally, the structure of TLV here is common across all the protocols that use TLV that I know. I'm not sure how we could redefine the TLV here. >=20 > P. >=20 > >>> For example, the transportType in 3.2.1 is just one octet long > >>> (unsigned8) - so there's no reason to encode it in 32 bits. Why not > >>> encode it like so: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>> | TLV-Type =3D TBAx1 | Length | transportType > | > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> The natEvent in 3.2.8 is also an unsigned8, so it would be encoded > >>> similarly - except that the TLV-Type would be 230, which is the IE > >>> ID of the IPFIX natEvent. > >>> > >>> > >>> The natTransportLimit in 3.2.2 is an unsigned16 - so there's no > need > >>> to encode it in 32 bits. Why not encode it like so: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>> | TLV-Type =3D TBAx2 | Length > |natTransportLimit ... > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>> ... | > >>> +-+-+-+-+-+-+-+-+ > >>> > >>> 3.2.9 and 3.2.10 would be similar. The encoding of 3.2.3, 3.2.4, > and > >>> 3.2.5 would all be as shown in the draft, except that the TLV-type > >>> would be two octets long and contain the IPFIX IE ID. The > >>> sourceTransportPort in 3.2.6 is an unsigned16 - so there's no need > >>> to encode it in 32 bits. Why not encode it like so: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>> | TLV-Type =3D sourceTransportPort| Length | > sourceTransportPort ... > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>> ... | > >>> +-+-+-+-+-+-+-+-+ > >>> > >>> The encoding of 3.2.7 would be similar. > >> _______________________________________________ > >> radext mailing list > >> radext@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mai > >> > lman_listinfo_radext&d=3DDQIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DXx9729xYDY= oC > >> > gBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=3DdEtr3XevxedcGIFIR0evA2jpVRKktTCFIE9 > >> _hDx1iO4&s=3Dt1n5rKGP56p05NoEUsOlAkh5nDurkUeCLuNN4hVxXSU&e=3D From nobody Thu Oct 13 07:23:04 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48D12990B; Thu, 13 Oct 2016 07:22:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636857916.2882.5043012494742777282.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 07:22:59 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-ip-port-radius-ext-13=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 14:23:00 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss! Here is some further feedback from the IE-Doctors: The description of the requested Information Element is still a bit vague, but acceptable; one must read the document in order to understand that binding the value to and end-user is really binding to one or more (source) addresses. The reference to section 3.2.2 (which is, IMO, not any more explanatory than the description of the IE itself) is not necessary. From nobody Fri Oct 14 00:12:52 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE71295EA; Fri, 14 Oct 2016 00:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QlU6qVCtjuSF; Fri, 14 Oct 2016 00:12:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282CE128B37; Fri, 14 Oct 2016 00:12:50 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 2766941AD6; Fri, 14 Oct 2016 09:12:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id C77F51A0082; Fri, 14 Oct 2016 09:12:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Fri, 14 Oct 2016 09:12:46 +0200 From: To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?W3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBk?= =?utf-8?B?cmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTM6ICh3aXRo?= =?utf-8?Q?_COMMENT)?= Thread-Index: AQHSJV1WepCpGDSHVkugbmJxBmfZraCniUxg Date: Fri, 14 Oct 2016 07:12:46 +0000 Message-ID: <63a50008-b617-403e-9d01-2ce3aa670125@OPEXCLILM6D.corporate.adroot.infra.ftgroup> References: <147636857916.2882.5043012494742777282.idtracker@ietfa.amsl.com> In-Reply-To: <147636857916.2882.5043012494742777282.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "radext-chairs@ietf.org" , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-ip-port-radius-ext-13=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 07:12:52 -0000 SGkgTWlyamEsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogcmFkZXh0IFttYWlsdG86cmFkZXh0LWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWlyamENCj4gS3VlaGxld2luZA0KPiBFbnZv ecOpwqA6IGpldWRpIDEzIG9jdG9icmUgMjAxNiAxNjoyMw0KPiDDgMKgOiBUaGUgSUVTRw0KPiBD Y8KgOiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHRAaWV0Zi5vcmc7IE1PUkFO RCBMaW9uZWwgSU1UL09MTjsNCj4gcmFkZXh0LWNoYWlyc0BpZXRmLm9yZzsgcmFkZXh0QGlldGYu b3JnDQo+IE9iamV0wqA6IFtyYWRleHRdIE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1yYWRleHQtaXAtDQo+IHBvcnQtcmFkaXVzLWV4dC0xMzogKHdpdGggQ09N TUVOVCkNCj4gDQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4 dC0xMzogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMN Cj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0Lw0K PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IFRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBkaXNjdXNzIQ0KPiANCj4gSGVyZSBpcyBz b21lIGZ1cnRoZXIgZmVlZGJhY2sgZnJvbSB0aGUgSUUtRG9jdG9yczoNCj4gVGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSByZXF1ZXN0ZWQgSW5mb3JtYXRpb24gRWxlbWVudCBpcyBzdGlsbCBhIGJpdA0K PiB2YWd1ZSwgYnV0IGFjY2VwdGFibGU7IG9uZSBtdXN0IHJlYWQgdGhlIGRvY3VtZW50IGluIG9y ZGVyIHRvIHVuZGVyc3RhbmQNCj4gdGhhdCBiaW5kaW5nIHRoZSB2YWx1ZSB0byBhbmQgZW5kLXVz ZXIgaXMgcmVhbGx5IGJpbmRpbmcgdG8gb25lIG9yIG1vcmUNCj4gKHNvdXJjZSkgYWRkcmVzc2Vz LiBUaGUgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMy4yLjIgKHdoaWNoIGlzLCBJTU8sIG5vdA0KPiBh bnkgbW9yZSBleHBsYW5hdG9yeSB0aGFuIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgSUUgaXRzZWxm KSBpcyBub3QNCj4gbmVjZXNzYXJ5Lg0KDQpbTWVkXSBXaGF0IGFib3V0IG1ha2luZyB0aGlzIGNo YW5nZTogDQoNCk9MRDoNCiAgICAgICogIERlc2NyaXB0aW9uOiBUaGlzIEluZm9ybWF0aW9uIEVs ZW1lbnQgY29udGFpbnMgdGhlIG1heGltdW0NCiAgICAgICAgIG51bWJlciBvZiBJUCBzb3VyY2Ug dHJhbnNwb3J0IHBvcnRzIHRoYXQgaXMgYSBsaW1pdCBmb3IgYW4gZW5kDQogICAgICAgICB1c2Vy IHRvIHVzZSBhbmQgaXMgYXNzb2NpYXRlZCB3aXRoIG9uZSBvciBtb3JlIElQdjQgb3IgSVB2Ng0K ICAgICAgICAgYWRkcmVzc2VzLg0KDQpORVc6DQogICAgICAqICBEZXNjcmlwdGlvbjogVGhpcyBJ bmZvcm1hdGlvbiBFbGVtZW50IGNvbnRhaW5zIHRoZSBtYXhpbXVtDQogICAgICAgICBudW1iZXIg b2YgSVAgc291cmNlIHRyYW5zcG9ydCBwb3J0cyB0aGF0IGNhbiBiZSB1c2VkIGJ5IGFuIGVuZA0K ICAgICAgICAgdXNlciB3aGVuIHNlbmRpbmcgSVAgcGFja2V0czsgZWFjaCB1c2VyIGlzIGFzc29j aWF0ZWQgd2l0aCBvbmUNCiAgICAgICAgIG9yIG1vcmUgKHNvdXJjZSkgSVB2NCBvciBJUHY2IGFk ZHJlc3Nlcy4gIFRoaXMgSUUgaXMNCiAgICAgICAgIHBhcnRpY3VsYXJseSB1c2VmdWwgaW4gYWRk cmVzcyBzaGFyaW5nIGRlcGxveW1lbnRzIHRoYXQgYWRoZXJlDQogICAgICAgICB0byBSRVEtNCBv ZiBbUkZDNjg4OF0uICBMaW1pdGluZyB0aGUgbnVtYmVyIG9mIHBvcnRzIGFzc2lnbmVkDQogICAg ICAgICB0byBlYWNoIHVzZXIgZW5zdXJlcyBmYWlybmVzcyBhbW9uZyB1c2VycyBhbmQgbWl0aWdh dGVzIHRoZQ0KICAgICAgICAgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIHRoYXQgYSB1c2VyIGNv dWxkIGxhdW5jaCBhZ2FpbnN0IG90aGVyDQogICAgICAgICB1c2VycyB0aHJvdWdoIHRoZSBhZGRy ZXNzIHNoYXJpbmcgZGV2aWNlIGluIG9yZGVyIHRvIGdyYWIgbW9yZQ0KICAgICAgICAgcG9ydHMu DQogIA0KDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gcmFkZXh0IG1haWxpbmcgbGlzdA0KPiByYWRleHRAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQNCg== From nobody Fri Oct 14 08:16:23 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4850B12983C; Fri, 14 Oct 2016 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PFtb2M-Lkfxu; Fri, 14 Oct 2016 08:16:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9697E129523; Fri, 14 Oct 2016 08:16:16 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9ED4C18C451; Fri, 14 Oct 2016 17:16:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.21]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 71F4E238059; Fri, 14 Oct 2016 17:16:14 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Fri, 14 Oct 2016 17:16:14 +0200 From: To: Alan DeKok Thread-Topic: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSCFDrJHPCcWo6q0uDplNMG5A9GKB3d+8HgDDR8KA= Date: Fri, 14 Oct 2016 15:16:13 +0000 Message-ID: <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> In-Reply-To: <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.14.70315 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:16:21 -0000 Hi Alan, Can you elaborate a little bit? What do you call 'appropriate parent TLV'? If a registry is defined to track allocated value for sub-TLV, how to avoid= collision if "All other TLV parents are free to specify whatever sub-TLVs = they want". Regards, Lionel > -----Message d'origine----- > De=A0: Alan DeKok [mailto:aland@deployingradius.com] > Envoy=E9=A0: mardi 13 septembre 2016 15:40 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: kathleen.moriarty.ietf@gmail.com; Alissa Cooper; draft-ietf-radext= -ip-port- > radius-ext@ietf.org; radext@ietf.org; IESG; radext-chairs@ietf.org > Objet=A0: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-po= rt-radius- > ext-11: (with DISCUSS and COMMENT) >=20 >=20 > > On Sep 13, 2016, at 9:23 AM, > wrote: > > If such a registry is defined by the WG and managed by the IANA, to ens= ure > that a newly-defined sub-TLV can be reused in any parent TLV, >=20 > No. Those sub-TLVs can only be re-used in *appropriate* parent TLVs. = The > parents need to specify that they are using the common registry. All oth= er TLV > parents are free to specify whatever sub-TLVs they want. >=20 > Alan DeKok. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Oct 14 08:43:07 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB891294A1; Fri, 14 Oct 2016 08:43:00 -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, 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 SBYgM5UPdclw; Fri, 14 Oct 2016 08:42:55 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AC39B12944D; Fri, 14 Oct 2016 08:42:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id DDFD41F81; Fri, 14 Oct 2016 15:42:54 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxTuFMnijtWG; Fri, 14 Oct 2016 15:42:54 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id ECDA31F7F; Fri, 14 Oct 2016 15:42:53 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Fri, 14 Oct 2016 11:42:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:43:00 -0000 > On Oct 14, 2016, at 11:16 AM, = wrote: > Can you elaborate a little bit? > What do you call 'appropriate parent TLV'? The idea is that if you have a TLV, it can: a) define it's own sub-TLVs b) use a pre-defined registry for sub-TLVs. That's it. If a TLV is defined to use option (a), there's no conflict with other = TLVs. It's sub-TLVs are completely independent of all other sub-TLVs. = And it *cannot* use TLVs from a registry. If a TLV is defined to use option (b), then it *cannot* define it's = own sub-TLVs. It MUST use the registry. Which means re-using sub-TLVs = from the registry. Because that's what registries are for. sub-TLVs defined in a registry can't conflict with other sub-TLVs, = because each TLV space is entirely independent... unless you define them = to overlap. > If a registry is defined to track allocated value for sub-TLV, how to = avoid collision if "All other TLV parents are free to specify whatever = sub-TLVs they want". That question is based on assumptions I don't understand. As such, it = can't really be answered other than with "it doesn't work like that". If we have a registry, fine. Use it. If we don't have a registry, = then attributes not using the registry... don't use the registry. And = there's no conflict. Because they're not using the registry. There is no more conflict here than with Service-Type and = Framed-Protocol. Both are "integer" attributes. Both define a = registry. But adding an entry to Service-Type doesn't mean that that = number is now also defined for Framed-Protocol, much less have any = special meaning for any other "integer" attribute. Perhaps you could explain why you think there would be any conflict = between sub-TLVs? =20 Alan DeKok. From nobody Fri Oct 14 10:54:23 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992CC12986D; Fri, 14 Oct 2016 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 zHtA6-tBIkpt; Fri, 14 Oct 2016 10:54:20 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11CC612986F; Fri, 14 Oct 2016 10:54:20 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id 83so99516520vkd.0; Fri, 14 Oct 2016 10:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lK1fQhPywjUz7DOnXT+SAyhtwEO/q6cW+/S0IOizAQ0=; b=Zwrc5TQUEqS9NsjhqX8Cbe/KaPf5CXT6fpVrI3DB6pizHX8YHPIRGd5jPy4BAxTH12 gfSBpSNbRSoheAe+jUAAMywKqoeEcKAkKpbWlw8A+3nH6hVF4rHTrEhO310Ts3e7nLt/ 9YP0aCu40cq9Ra4HvJHvIvlTBq8U07hxo7iD+lnzaaWIfAHTbQYnAwNsn9/Pf9I2B/uX Xtm4zVkJQ3bHDx4YhcAra99Qafpf7bbxLUKMvqkfLmZCvcQcHJF/btS3UzzuI0iwK7Zq LAnB+3DPJZuHHPZfsVO4V2+sEt+yhY9CM8JnTPazghDppLVI+ShjssZb5jVpZYOqcjnQ AADw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lK1fQhPywjUz7DOnXT+SAyhtwEO/q6cW+/S0IOizAQ0=; b=RAGfO5beRFJRjdF3QQdOQNkmyjnqJrufAtLMP/mIx/CsqJzKgY1eH6ZvpR7dIB35pF kS++l5u0hrflBJpb5Uv5m6tVxSZ2Y638mfoNiUQt6K35TFiosRrR112L4ZXtqMcniMmp Xb0NuDxbYA93i8rtBWeCYl+BemltOf8uCh+3Nqg5a6kHq2wnV9iNAoVztGi6moIA7SiQ vPLui3HtXbHZBZzAROO6jApoyPR28ZFnUGL3WCQBWshS28OqnY1OwqeW3eRfqS2CpBni TahlFo9ETLpHoY1M4jvWMkYn/zbbnyXNc5TCwPm0xf6C8Jq9MEPuMxQWhvWDo1h5APpG QiQw== X-Gm-Message-State: AA6/9RlqudqR1kGOHk0mkp+opX6aH0lEw+UZ6Ey40i9UU4xQaPZJ1OKZAahynZUfqUMuvMxMbAQSw56DC1EeKw== X-Received: by 10.31.73.71 with SMTP id w68mr7997611vka.13.1476467659184; Fri, 14 Oct 2016 10:54:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 14 Oct 2016 10:54:18 -0700 (PDT) In-Reply-To: <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> From: Kathleen Moriarty Date: Fri, 14 Oct 2016 13:54:18 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a1148d00a591ffb053ed6ea9f Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "lionel.morand@orange.com" , Alissa Cooper , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:54:22 -0000 --001a1148d00a591ffb053ed6ea9f Content-Type: text/plain; charset=UTF-8 On Fri, Oct 14, 2016 at 11:42 AM, Alan DeKok wrote: > > > On Oct 14, 2016, at 11:16 AM, < > lionel.morand@orange.com> wrote: > > Can you elaborate a little bit? > > What do you call 'appropriate parent TLV'? > > The idea is that if you have a TLV, it can: > > a) define it's own sub-TLVs > > b) use a pre-defined registry for sub-TLVs. > > That's it. > > If a TLV is defined to use option (a), there's no conflict with other > TLVs. It's sub-TLVs are completely independent of all other sub-TLVs. And > it *cannot* use TLVs from a registry. > > If a TLV is defined to use option (b), then it *cannot* define it's own > sub-TLVs. It MUST use the registry. Which means re-using sub-TLVs from > the registry. Because that's what registries are for. > > sub-TLVs defined in a registry can't conflict with other sub-TLVs, > because each TLV space is entirely independent... unless you define them to > overlap. > > > If a registry is defined to track allocated value for sub-TLV, how to > avoid collision if "All other TLV parents are free to specify whatever > sub-TLVs they want". > > That question is based on assumptions I don't understand. As such, it > can't really be answered other than with "it doesn't work like that". > > If we have a registry, fine. Use it. If we don't have a registry, then > attributes not using the registry... don't use the registry. And there's > no conflict. Because they're not using the registry. > > There is no more conflict here than with Service-Type and > Framed-Protocol. Both are "integer" attributes. Both define a registry. > But adding an entry to Service-Type doesn't mean that that number is now > also defined for Framed-Protocol, much less have any special meaning for > any other "integer" attribute. > > Perhaps you could explain why you think there would be any conflict > between sub-TLVs? > It seems the WG is just down to a preference question as I don't see how there would be conflicts except if different parties defined their own sub-TLVs and they didn't match. Could that occur? I have to dig deeper to make sure I'm not missing anything. For the future, you can ask IANA these sorts of questions via email or at meetings to work through preferences if you are looking for their opinion. I should have caught that this was an issue and am not sure why I didn't before putting it on a telechat. So, that was my fault. Thank you. > > Alan DeKok. > > -- Best regards, Kathleen --001a1148d00a591ffb053ed6ea9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 14, 2016 at 11:42 AM, Alan DeKok <aland@deployingr= adius.com> wrote:

> On Oct 14, 2016, at 11:16 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:
> Can you elaborate a little bit?
> What do you call 'appropriate parent TLV'?

=C2=A0 The idea is that if you have a TLV, it can:

a) define it's own sub-TLVs

b) use a pre-defined registry for sub-TLVs.

=C2=A0 That's it.

=C2=A0 If a TLV is defined to use option (a), there's no conflict with = other TLVs.=C2=A0 It's sub-TLVs are completely independent of all other= sub-TLVs.=C2=A0 And it *cannot* use TLVs from a registry.

=C2=A0 If a TLV is defined to use option (b), then it *cannot* define it= 9;s own sub-TLVs.=C2=A0 It MUST use the registry.=C2=A0 Which means re-usin= g sub-TLVs from the registry.=C2=A0 Because that's what registries are = for.

=C2=A0 sub-TLVs defined in a registry can't conflict with other sub-TLV= s, because each TLV space is entirely independent... unless you define them= to overlap.

> If a registry is defined to track allocated value for sub-TLV, how to = avoid collision if "All other TLV parents are free to specify whatever= sub-TLVs they want".

=C2=A0 That question is based on assumptions I don't understand.= =C2=A0 As such, it can't really be answered other than with "it do= esn't work like that".

=C2=A0 If we have a registry, fine.=C2=A0 Use it.=C2=A0 If we don't hav= e a registry, then attributes not using the registry... don't use the r= egistry.=C2=A0 And there's no conflict.=C2=A0 Because they're not u= sing the registry.

=C2=A0 There is no more conflict here than with Service-Type and Framed-Pro= tocol.=C2=A0 Both are "integer" attributes.=C2=A0 Both define a r= egistry.=C2=A0 But adding an entry to Service-Type doesn't mean that th= at number is now also defined for Framed-Protocol, much less have any speci= al meaning for any other "integer" attribute.

=C2=A0 Perhaps you could explain why you think there would be any conflict = between sub-TLVs?

It seems the WG is ju= st down to a preference question as I don't see how there would be conf= licts except if different parties defined their own sub-TLVs and they didn&= #39;t match.=C2=A0 Could that occur?=C2=A0 I have to dig deeper to make sur= e I'm not missing anything.

For the future, yo= u can ask IANA these sorts of questions via email or at meetings to work th= rough preferences if you are looking for their opinion.=C2=A0 I should have= caught that this was an issue and am not sure why I didn't before putt= ing it on a telechat.=C2=A0 So, that was my fault.

Thank you.=C2=A0

=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a1148d00a591ffb053ed6ea9f-- From nobody Fri Oct 14 11:02:26 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76101126579; Fri, 14 Oct 2016 11:02:18 -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, 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 81WYkXuHpR_q; Fri, 14 Oct 2016 11:02:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6211295CC; Fri, 14 Oct 2016 11:02:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 9840D1F70; Fri, 14 Oct 2016 18:02:15 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYCfg8sOJprQ; Fri, 14 Oct 2016 18:02:15 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id A6B481F54; Fri, 14 Oct 2016 18:02:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 14 Oct 2016 14:02:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF99484-6944-4F1D-ABE8-86BDC57C8412@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "lionel.morand@orange.com" , Alissa Cooper , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 18:02:18 -0000 On Oct 14, 2016, at 1:54 PM, Kathleen Moriarty = wrote: > It seems the WG is just down to a preference question as I don't see = how there would be conflicts except if different parties defined their = own sub-TLVs and they didn't match. Could that occur? I have to dig = deeper to make sure I'm not missing anything. If all TLV allocations go through IANA, then the registration = procedure should prevent conflict. If the IANA registration procedure is well documented, then that = procedure should prevent conflict. I don't see a big difference between allowing TLVs to be of data type = "integer", "ipv4 address", "sub-TLVs are OK", or "contents to be defined = by sub-TLV registry FOO". There is simply no way to have any kind of conflict in the allocation. > For the future, you can ask IANA these sorts of questions via email or = at meetings to work through preferences if you are looking for their = opinion. I should have caught that this was an issue and am not sure = why I didn't before putting it on a telechat. So, that was my fault. I'm not sure IANA would have an opinion here. Alan DeKok. From nobody Fri Oct 14 12:09:08 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6EE12988E; Fri, 14 Oct 2016 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ziig9w1YsEFW; Fri, 14 Oct 2016 12:09:00 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8258D1293F2; Fri, 14 Oct 2016 12:09:00 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 83so101715020vkd.0; Fri, 14 Oct 2016 12:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q7N+5T9PILmsXPDnb7Uu0Xfxea/WVVxqIoc9Ynuxs30=; b=Kkvg7t4ZAAIVaBGETWEgmg0ozYSZCL0GXmcz59kH9YKvj+4G5hSz41bakRfJRetuwI LZ3+PH9FLrazfGFrvQMtNAF2tO13zisY1hq9IUp5OkrYL7X1cHe41J1TeIXw1AO5UXaL lw1pPkiJb5+KlL7k/HCTTP0D8+G2EDszfiG8/1sA9rzdo4Cm+Zf/jBMXyV25uLl/kg7B Y/U10/P9OF1xDT97gh0U0ehBKzQiRttVmjSFFvmPPHG/SZw8HIxmAy1hvm0I88wSmAdI rQw6V8EZRvk0y9BYmgXxeKM4vVgnMy7TH5JrvLEW0YDG3DDr/9WnEWlXEp1Uuh3ppK4e 8ilA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q7N+5T9PILmsXPDnb7Uu0Xfxea/WVVxqIoc9Ynuxs30=; b=aheSuxyt/62j98oAIv4s84LmYyBCsP+lGjyeIdqGZYZhvcXOQpQlKXFCUjZdCqlFXR vE21d3ngR2nOxilsrlgxDxYWUM2KYKYZVi3XP7PnbU6WpwFDdqhYcLKwNdHEQAkqgAFH 43Eo2ReEbyh6B4fBo/8UydvbNCvWdiqvZSRaCoQFEJtqK0NFqOTvANt5V9mb39xTP2YK DYZeGLnJrLpnUCPsBnOlV8ftViLamtflFJklIHdMcF4VNQ2No2ZB1CVdoP+tFvmFQSRS oFRQ/Y/MrmaYz3ry1OhoQqG401eJDQR2NarTGjqMXt4eASEV+TY9pc98y2KmTXme0R3V XIsQ== X-Gm-Message-State: AA6/9RlIsLzjJhdqevd1swVKnf0Pen+axPIfu6THjitKQOaE9EBP5uBZQhBsmhl7Infk+QT6c8l1co39eYDSpA== X-Received: by 10.31.183.134 with SMTP id h128mr9219183vkf.124.1476472139607; Fri, 14 Oct 2016 12:08:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 14 Oct 2016 12:08:59 -0700 (PDT) In-Reply-To: <6BF99484-6944-4F1D-ABE8-86BDC57C8412@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> <6BF99484-6944-4F1D-ABE8-86BDC57C8412@deployingradius.com> From: Kathleen Moriarty Date: Fri, 14 Oct 2016 15:08:59 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a113bee226708de053ed7f5de Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "lionel.morand@orange.com" , Alissa Cooper , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 19:09:02 -0000 --001a113bee226708de053ed7f5de Content-Type: text/plain; charset=UTF-8 On Fri, Oct 14, 2016 at 2:02 PM, Alan DeKok wrote: > On Oct 14, 2016, at 1:54 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > It seems the WG is just down to a preference question as I don't see how > there would be conflicts except if different parties defined their own > sub-TLVs and they didn't match. Could that occur? I have to dig deeper to > make sure I'm not missing anything. > > If all TLV allocations go through IANA, then the registration procedure > should prevent conflict. > > If the IANA registration procedure is well documented, then that > procedure should prevent conflict. > > I don't see a big difference between allowing TLVs to be of data type > "integer", "ipv4 address", "sub-TLVs are OK", or "contents to be defined by > sub-TLV registry FOO". > > There is simply no way to have any kind of conflict in the allocation. > > > For the future, you can ask IANA these sorts of questions via email or > at meetings to work through preferences if you are looking for their > opinion. I should have caught that this was an issue and am not sure why I > didn't before putting it on a telechat. So, that was my fault. > > I'm not sure IANA would have an opinion here. > OK, so in that case I may be the tie breaker as AD, I'll just read through everything again and respond, unless the WG participants start to show a strong preference. > > Alan DeKok. > > -- Best regards, Kathleen --001a113bee226708de053ed7f5de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 14, 2016 at 2:02 PM, Alan DeKok <aland@deployingra= dius.com> wrote:
On Oct 14, 2016, at 1:54 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<= /a>> wrote:
> It seems the WG is just down to a preference question as I don't s= ee how there would be conflicts except if different parties defined their o= wn sub-TLVs and they didn't match.=C2=A0 Could that occur?=C2=A0 I have= to dig deeper to make sure I'm not missing anything.

=C2=A0 If all TLV allocations go through IANA, then the registration= procedure should prevent conflict.

=C2=A0 If the IANA registration procedure is well documented, then that pro= cedure should prevent conflict.

=C2=A0 I don't see a big difference between allowing TLVs to be of data= type "integer", "ipv4 address", "sub-TLVs are OK&= quot;, or "contents to be defined by sub-TLV registry FOO".

=C2=A0 There is simply no way to have any kind of conflict in the allocatio= n.

> For the future, you can ask IANA these sorts of questions via email or= at meetings to work through preferences if you are looking for their opini= on.=C2=A0 I should have caught that this was an issue and am not sure why I= didn't before putting it on a telechat.=C2=A0 So, that was my fault.
=C2=A0 I'm not sure IANA would have an opinion here.

OK, so in that case I may be the tie breaker as AD= , =C2=A0I'll just read through everything again and respond, unless the= WG participants start to show a strong preference.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a113bee226708de053ed7f5de-- From nobody Sun Oct 16 23:39:31 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27312956E; Sun, 16 Oct 2016 23:39:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147668636939.25787.9430106154790695.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 23:39:29 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Stephen Farrell's No Objection on draft-ietf-radext-ip-port-radius-ext-13: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 06:39:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for removing the ICMP identifier thing. OLD COMMENTS below. I'm happy to chat about 'em if we need to. - write-up: Yeah, major yuks to leaving design decisions to IANA. While the folks there are quite capable, they are not able to make IETF consensus decisions. If the WG aren't sure, ask IANA personnel (or someone) and then verify that that outcome garners rough consensus back in the WG or using other IETF processes. So Alissa's discuss point#4 is entirely, completely and fully correct and a showstopper really. - I also agree with the issue called out in Joel's comment about mission creep and how this overlaps with PCP. Did the WG consider whether or not it is a good idea for the IETF to define multiple ways in which some of these features can be added? If so, what is the justification for there being more than one? (Is that somewhere in the WG list archive? If not, it ought be.) It may well be that having a RADIUS mechanism for this is also a good plan, but I think that ought be justified. - 4.1.4: using port 80 as an example is very 1990's. Would it not be better to be more up to date? That's not just a facetious point - web cameras being left open to the Internet are a major swamp for botnet gestation. Better to use a more desirable example really. - The secdir review [1] also noted a bunch of issues that as far as I can see received no response so far, but that do deserve a response. (Apologies if I missed a response.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html From nobody Sun Oct 16 23:47:12 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0442512951F; Sun, 16 Oct 2016 23:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IBCgKeDFhy0F; Sun, 16 Oct 2016 23:47:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF7F1294D5; Sun, 16 Oct 2016 23:47:08 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 08B8A20627; Mon, 17 Oct 2016 08:47:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id CCB7F120065; Mon, 17 Oct 2016 08:47:05 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Mon, 17 Oct 2016 08:47:02 +0200 From: To: Stephen Farrell Thread-Topic: Stephen Farrell's No Objection on draft-ietf-radext-ip-port-radius-ext-13: (with COMMENT) Thread-Index: AQHSKEE4Fpp0ko40Yke/ygypXFdh16CsMjNw Date: Mon, 17 Oct 2016 06:47:01 +0000 Message-ID: <0201d407-6e81-4aba-9972-a4cf9346c731@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <147668636939.25787.9430106154790695.idtracker@ietfa.amsl.com> In-Reply-To: <147668636939.25787.9430106154790695.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , MORAND Lionel IMT/OLN , "radext-chairs@ietf.org" , "radext@ietf.org" Subject: Re: [radext] Stephen Farrell's No Objection on draft-ietf-radext-ip-port-radius-ext-13: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 06:47:10 -0000 UmUtLA0KDQpUaGFuayB5b3UuDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogU3RlcGhlbiBGYXJyZWxs IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gRW52b3nDqcKgOiBsdW5kaSAx NyBvY3RvYnJlIDIwMTYgMDg6MzkNCj4gw4DCoDogVGhlIElFU0cNCj4gQ2PCoDogZHJhZnQtaWV0 Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnOyByYWRleHRAaWV0Zi5vcmc7DQo+ IHJhZGV4dC1jaGFpcnNAaWV0Zi5vcmc7IE1PUkFORCBMaW9uZWwgSU1UL09MTjsgcmFkZXh0QGll dGYub3JnDQo+IE9iamV0wqA6IFN0ZXBoZW4gRmFycmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLXJhZGV4dC1pcC1wb3J0LQ0KPiByYWRpdXMtZXh0LTEzOiAod2l0aCBDT01NRU5UKQ0K PiANCj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTM6IE5v IE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN Cj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC8NCj4gDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAN Cj4gVGhhbmtzIGZvciByZW1vdmluZyB0aGUgSUNNUCBpZGVudGlmaWVyIHRoaW5nLg0KPiANCj4g T0xEIENPTU1FTlRTIGJlbG93LiBJJ20gaGFwcHkgdG8gY2hhdCBhYm91dCAnZW0NCj4gaWYgd2Ug bmVlZCB0by4NCj4gDQo+IC0gd3JpdGUtdXA6IFllYWgsIG1ham9yIHl1a3MgdG8gbGVhdmluZyBk ZXNpZ24gZGVjaXNpb25zDQo+IHRvIElBTkEuICBXaGlsZSB0aGUgZm9sa3MgdGhlcmUgYXJlIHF1 aXRlIGNhcGFibGUsIHRoZXkNCj4gYXJlIG5vdCBhYmxlIHRvIG1ha2UgSUVURiBjb25zZW5zdXMg ZGVjaXNpb25zLiAgSWYgdGhlIFdHDQo+IGFyZW4ndCBzdXJlLCBhc2sgSUFOQSBwZXJzb25uZWwg KG9yIHNvbWVvbmUpIGFuZCB0aGVuDQo+IHZlcmlmeSB0aGF0IHRoYXQgb3V0Y29tZSBnYXJuZXJz IHJvdWdoIGNvbnNlbnN1cyBiYWNrIGluDQo+IHRoZSBXRyBvciB1c2luZyBvdGhlciBJRVRGIHBy b2Nlc3Nlcy4gU28gQWxpc3NhJ3MgZGlzY3Vzcw0KPiBwb2ludCM0IGlzIGVudGlyZWx5LCBjb21w bGV0ZWx5IGFuZCBmdWxseSBjb3JyZWN0IGFuZA0KPiBhIHNob3dzdG9wcGVyIHJlYWxseS4NCg0K W01lZF0gVGhpcyBwb2ludCBpcyBiZWluZyBoYW5kbGVkIGluIGFub3RoZXIgdGhyZWFkLiANCg0K PiANCj4gLSBJIGFsc28gYWdyZWUgd2l0aCB0aGUgaXNzdWUgY2FsbGVkIG91dCBpbiBKb2VsJ3Mg Y29tbWVudA0KPiBhYm91dCBtaXNzaW9uIGNyZWVwIGFuZCBob3cgdGhpcyBvdmVybGFwcyB3aXRo IFBDUC4gRGlkDQo+IHRoZSBXRyBjb25zaWRlciB3aGV0aGVyIG9yIG5vdCBpdCBpcyBhIGdvb2Qg aWRlYSBmb3IgdGhlDQo+IElFVEYgdG8gZGVmaW5lIG11bHRpcGxlIHdheXMgaW4gd2hpY2ggc29t ZSBvZiB0aGVzZQ0KPiBmZWF0dXJlcyBjYW4gYmUgYWRkZWQ/IElmIHNvLCB3aGF0IGlzIHRoZSBq dXN0aWZpY2F0aW9uDQo+IGZvciB0aGVyZSBiZWluZyBtb3JlIHRoYW4gb25lPyAoSXMgdGhhdCBz b21ld2hlcmUgaW4gdGhlDQo+IFdHIGxpc3QgYXJjaGl2ZT8gSWYgbm90LCBpdCBvdWdodCBiZS4p IEl0IG1heSB3ZWxsIGJlIHRoYXQNCj4gaGF2aW5nIGEgUkFESVVTIG1lY2hhbmlzbSBmb3IgdGhp cyBpcyBhbHNvIGEgZ29vZCBwbGFuLA0KPiBidXQgSSB0aGluayB0aGF0IG91Z2h0IGJlIGp1c3Rp ZmllZC4NCj4gDQoNCltNZWRdIEFuIGFuc3dlciB0byB0aGlzIHBvaW50IHdhcyBzZW50IHRvIEpv ZWwncyByZXZpZXcuIA0KDQo+IC0gNC4xLjQ6IHVzaW5nIHBvcnQgODAgYXMgYW4gZXhhbXBsZSBp cyB2ZXJ5IDE5OTAncy4gV291bGQNCj4gaXQgbm90IGJlIGJldHRlciB0byBiZSBtb3JlIHVwIHRv IGRhdGU/IFRoYXQncyBub3QganVzdCBhDQo+IGZhY2V0aW91cyBwb2ludCAtIHdlYiBjYW1lcmFz IGJlaW5nIGxlZnQgb3BlbiB0byB0aGUNCj4gSW50ZXJuZXQgYXJlIGEgbWFqb3Igc3dhbXAgZm9y IGJvdG5ldCBnZXN0YXRpb24uIEJldHRlciB0bw0KPiB1c2UgYSBtb3JlIGRlc2lyYWJsZSBleGFt cGxlIHJlYWxseS4NCj4gDQoNCltNZWRdIEFscmVhZHkgZml4ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTMjc2VjdGlv bi00LjEuNCANCg0KPiAtIFRoZSBzZWNkaXIgcmV2aWV3IFsxXSBhbHNvIG5vdGVkIGEgYnVuY2gg b2YgaXNzdWVzIHRoYXQNCj4gYXMgZmFyIGFzIEkgY2FuIHNlZSByZWNlaXZlZCBubyByZXNwb25z ZSBzbyBmYXIsIGJ1dCB0aGF0DQo+IGRvIGRlc2VydmUgYSByZXNwb25zZS4gKEFwb2xvZ2llcyBp ZiBJIG1pc3NlZCBhIHJlc3BvbnNlLikNCj4gDQo+ICAgIFsxXSBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2NzM2Lmh0bWwNCg0KW01lZF0g QWxyZWFkeSByZXBsaWVkIHRvIHRoaXMgcmV2aWV3LiBQbGVhc2UgY2hlY2s6IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDY4NDYuaHRtbCAN Cg0K From nobody Mon Oct 17 10:07:56 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C813129482; Mon, 17 Oct 2016 10:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1nQooLCUwx-y; Mon, 17 Oct 2016 10:07:50 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03314129404; Mon, 17 Oct 2016 10:07:50 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id 2so184683866vkb.3; Mon, 17 Oct 2016 10:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MIZHB625GXTimV7bVD30LfByrQd5GwAq6PYZUt3P5+8=; b=csBNmnz33eQQHLxSNoADb3VXxO0uUc1krLGk5I81FYRHYuHYZIOUyAJyXtcnuK9Kkx +ncFVDTRsxNgEi9hCuGyDW+kBLHizVoWjkfT31hnm3u3AvVNtUEfftALwN5iOKHafKtl dpRXBSPUBP4iJgxulHsqivy/DuheSpUaxzn3wunOJ6uw+cYl1Ecl2p2wLsghCz0IX2pW 8a6zGWG7RyaWCTclLZzwRvhcjBV1c6nQGFPAUAJtuWXWONXN1xQeNKnVyWNorwgmN0OO EPSj3EbJTIBgWIyl9RZaVnHf1OSMfKxglb8l+c61qY7WtXS91ZDR9K1DXQcVeytITLJp vONw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MIZHB625GXTimV7bVD30LfByrQd5GwAq6PYZUt3P5+8=; b=YO1lAFNs6Lr+WXattQWW1RSYHqfaR+ThhknnginaCpbmwnVF/L0nY6d0+lBc1ove16 yZyMDtJsBIX/Adafcna+am7HRVuCBUaGKQAAquG92nhlLTEmwT/C9oV19spnWqLf0vw4 Rkg8uNTHQyfrFODTv2EOga3rXj/oXiGv4s5JSv3htv69UxwHmzhdgDFW7Ty5sFPADMGM HQVNtFSBcfo/XtHmb9TSSAoaQb2k/uCZMNjvETPdvjuFFumnZQVpJUXZLa4AbEAxuwlk +1XAExzTlOpThesGS+Ansx3BDJc07Mqii2OsavRjiwBuaF2oubWqKFSrxY64mke2mQFa LffA== X-Gm-Message-State: AA6/9RmJE2joesGe1+ozvf00R+8XGu5EIKIOJ6320mZMGVrYXcgyJ2q5pHGY7UmnRwQ7Pz8tV2U8+8A9JjtMPw== X-Received: by 10.31.56.204 with SMTP id f195mr18767838vka.61.1476724069068; Mon, 17 Oct 2016 10:07:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Mon, 17 Oct 2016 10:07:48 -0700 (PDT) In-Reply-To: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com> <6BF99484-6944-4F1D-ABE8-86BDC57C8412@deployingradius.com> From: Kathleen Moriarty Date: Mon, 17 Oct 2016 13:07:48 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a1144005c9173f3053f129db8 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "lionel.morand@orange.com" , Alissa Cooper , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 17:07:51 -0000 --001a1144005c9173f3053f129db8 Content-Type: text/plain; charset=UTF-8 Hello, I read through the threads again. There was not much on list discussion of this point, so I had to rely on what I had for information and I also received some private messages. With this, I am leaning towards Alan's suggestion. Unless WG members disagree (you are really the ones to make this decision, I was just asked to be a tie breaker), let's go ahead with that change in the draft after a 2 day waiting period before the updated draft is posted. I am not expecting any or much more discussion on this based on emails to date. Thank you, Kathleen On Fri, Oct 14, 2016 at 3:08 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > On Fri, Oct 14, 2016 at 2:02 PM, Alan DeKok > wrote: > >> On Oct 14, 2016, at 1:54 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> > It seems the WG is just down to a preference question as I don't see >> how there would be conflicts except if different parties defined their own >> sub-TLVs and they didn't match. Could that occur? I have to dig deeper to >> make sure I'm not missing anything. >> >> If all TLV allocations go through IANA, then the registration procedure >> should prevent conflict. >> >> If the IANA registration procedure is well documented, then that >> procedure should prevent conflict. >> >> I don't see a big difference between allowing TLVs to be of data type >> "integer", "ipv4 address", "sub-TLVs are OK", or "contents to be defined by >> sub-TLV registry FOO". >> >> There is simply no way to have any kind of conflict in the allocation. >> >> > For the future, you can ask IANA these sorts of questions via email or >> at meetings to work through preferences if you are looking for their >> opinion. I should have caught that this was an issue and am not sure why I >> didn't before putting it on a telechat. So, that was my fault. >> >> I'm not sure IANA would have an opinion here. >> > > OK, so in that case I may be the tie breaker as AD, I'll just read > through everything again and respond, unless the WG participants start to > show a strong preference. > > >> >> Alan DeKok. >> >> > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a1144005c9173f3053f129db8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I read through the threads again= .=C2=A0 There was not much on list discussion of this point, so I had to re= ly on what I had for information and I also received some private messages.= =C2=A0 With this, I am leaning towards Alan's suggestion.=C2=A0 Unless = WG members disagree (you are really the ones to make this decision, I was j= ust asked to be a tie breaker), let's go ahead with that change in the = draft after a 2 day waiting period before the updated draft is posted.=C2= =A0 I am not expecting any or much more discussion on this based on emails = to date.

Thank you,
Kathleen
=

On Fri, Oct 14, 2= 016 at 3:08 PM, Kathleen Moriarty <kathleen.moriarty.ietf@g= mail.com> wrote:


On Fri, Oct 14, 2016 at 2:02 PM, Alan DeKok = <aland@de= ployingradius.com> wrote:
<= span>On Oct 14, 2016, at 1:54 PM, Kathleen Moriarty <kathleen.moriarty.ietf@g= mail.com> wrote:
> It seems the WG is just down to a preference question as I don't s= ee how there would be conflicts except if different parties defined their o= wn sub-TLVs and they didn't match.=C2=A0 Could that occur?=C2=A0 I have= to dig deeper to make sure I'm not missing anything.

=C2=A0 If all TLV allocations go through IANA, then the registration= procedure should prevent conflict.

=C2=A0 If the IANA registration procedure is well documented, then that pro= cedure should prevent conflict.

=C2=A0 I don't see a big difference between allowing TLVs to be of data= type "integer", "ipv4 address", "sub-TLVs are OK&= quot;, or "contents to be defined by sub-TLV registry FOO".

=C2=A0 There is simply no way to have any kind of conflict in the allocatio= n.

> For the future, you can ask IANA these sorts of questions via email or= at meetings to work through preferences if you are looking for their opini= on.=C2=A0 I should have caught that this was an issue and am not sure why I= didn't before putting it on a telechat.=C2=A0 So, that was my fault.
=C2=A0 I'm not sure IANA would have an opinion here.

OK, so in that case I may be the tie breake= r as AD, =C2=A0I'll just read through everything again and respond, unl= ess the WG participants start to show a strong preference.
=C2=A0=

=C2=A0 Alan DeKok.




--

Best regards,
Kathleen



--
Best regards,
Kathleen
--001a1144005c9173f3053f129db8-- From nobody Tue Oct 18 10:26:05 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0BF129712; Tue, 18 Oct 2016 10:25:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681155104.30714.10959276190027864794.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:25:51 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-14.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:25:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-14.txt Pages : 39 Date : 2016-10-18 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. This document defines a mapping between some RADIUS attributes and IPFIX Information Element Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-14 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 Tue Oct 18 10:26:09 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D412129715; Tue, 18 Oct 2016 10:25:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681155117.30714.17481314857917669699.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:25:51 -0700 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-14.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:25:51 -0000 A new version (-14) has been submitted for draft-ietf-radext-ip-port-radius-ext: https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-14 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. IETF Secretariat. From nobody Tue Oct 18 13:13:38 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2952129857; Tue, 18 Oct 2016 13:13:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147682161372.30742.5138004680565499588.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 13:13:33 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:13:33 -0000 Placed on agenda for telechat - 2016-11-03 ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Tue Oct 18 13:19:14 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6021129861; Tue, 18 Oct 2016 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 B5zBpXa2TR2o; Tue, 18 Oct 2016 13:19:06 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67537129860; Tue, 18 Oct 2016 13:19:06 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id 83so7323239vkd.0; Tue, 18 Oct 2016 13:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lKKlAQ8JzaBXMyUKBSBQykyZp4LCxv+PM21x8UJt8Fc=; b=FzhqdkLdYpQvfxfGcG2oyZADAgBlBF901Kx4PSE5QghPxfSNkeSOToqna2SolFpDRE 8RwMUNwmRmh3eVTZk7DSzkIjSeRwpMd5+ADi9j15mRsE1sW0d4YnDvH0sdvJn2hkJqSl kL/vAe9zFgYQLNqgNB7kchMc5QixlDBUv1JRuPcQfBaHCPLHnVx1XCgUZ+mNJBPaTQZ3 jwyAoNpcacew67wrgzNCXzEospmyv9xO7tWkT53B9r7E7cYbPT61GFWDn1oSWz4Ff9fI XBPeZ6MjDK6qTGnR3TWqpFEPRj7AwNAMJGLszj8ov7Cv9aDAZE9auGiOgHqia+ybHNoG fd2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lKKlAQ8JzaBXMyUKBSBQykyZp4LCxv+PM21x8UJt8Fc=; b=DqmNvCtRmrbNH5O2E0YfokPNC8q92kaDCIRg7IkuZU9hu2rKdejqhTeRtm2rYTAdEH vW+XIASLEo1/CMMcu3Hopsh1Jy6WhhPjiTXREAbRMLWEp/uPe5PKh2OMDu2LXVCHQ1wn Oy/yQFbNZvuLetkNIjlZE585XRdaKFwys+Tc53wIfMJuWwbF2ulgnjlDdttl3IPpRPqo hGKY/Rvuenv3ZeSlinTNCXJ54nTZwZBuSRXhd8qcIxSwEEPsIjjiKA0UYLLhKWKewIUc XzbpIvm8xCDsax3x0/63JldWwqa4SwevG+yN/ungpRW9O4i+aQDzee0vzLUoVkhsmz+p t9mA== X-Gm-Message-State: AA6/9RmVpllOdiLqsDS8jS2yH8kg/asgYLaSxDqlXWQkMJ5E9Y04qi4QzLhvgG6LlKMG2ffVZCr9SEJa7FMzcg== X-Received: by 10.31.183.134 with SMTP id h128mr2569854vkf.124.1476821945555; Tue, 18 Oct 2016 13:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 18 Oct 2016 13:19:05 -0700 (PDT) In-Reply-To: <4A496E2D-A2D0-4BB9-8CFE-B606BCFF1174@deployingradius.com> References: <147137707081.22859.2851427602812447816.idtracker@ietfa.amsl.com> <4A496E2D-A2D0-4BB9-8CFE-B606BCFF1174@deployingradius.com> From: Kathleen Moriarty Date: Tue, 18 Oct 2016 16:19:05 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a113bee2276287d053f2967d4 Archived-At: Cc: Winter Stefan , "radext@ietf.org" , draft-ietf-radext-datatypes@ietf.org, IESG , radext-chairs@ietf.org Subject: Re: [radext] Alissa Cooper's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:19:08 -0000 --001a113bee2276287d053f2967d4 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 10:03 AM, Alan DeKok wrote: > > In Section 4.1, if the registration policy is Standards Action doesn't > > that obviate the need to say anything about IETF Review? > > Yes. I'll update the draft. > Thanks, Alan. Please let me know when this update has been done. > > Alan DeKok. > > -- Best regards, Kathleen --001a113bee2276287d053f2967d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 10:03 AM, Alan DeKok <aland@deployingr= adius.com> wrote:
> In Section 4.1, if the registration policy is Standards Actio= n doesn't
> that obviate the need to say anything about IETF Review?

=C2=A0Yes.=C2=A0 I'll update the draft.
Thanks, Alan.=C2=A0 Please let me know when this update has bee= n done. =C2=A0

=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a113bee2276287d053f2967d4-- From nobody Tue Oct 18 13:21:03 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E8612984F; Tue, 18 Oct 2016 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QzvFn7LIylLG; Tue, 18 Oct 2016 13:20:59 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3C61297F7; Tue, 18 Oct 2016 13:20:58 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 2so7153387vkb.3; Tue, 18 Oct 2016 13:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mDrwxbPmasjhPshsls3OwWbbSoKXkOdE+LFGGoXT3as=; b=svKjxBRtIDNweDU60CtfNwO7fvhOgZvNw1dmaqIny+JtQF1McAgLtXLzqlQ3Q3k7sQ fkIElEdIX7RRgxXcKxz8mkqMWLDOztcnodVk2vKNkl/z4UMJhNDz/gnyLlizy2PCsfqK p9KCGCGBHZdZhhLp4v+ITzoosnYiDj03aT0vmp9zkUd9dUS02Lzu4EHxpvvSRCJcRDJ4 SYu0md5KG3pcVsaxfZDqGRP2FtaY3zCGu+kEPqOCv2+pRRuhX3sLTYIYo3Giq4WonYet uRvxrLdG8RxqU0cLUobOFCc7tIgWEV1P9VoP/XpU+ayy4nxZ63BR0Uef6QIVkCeCt+2r wUXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mDrwxbPmasjhPshsls3OwWbbSoKXkOdE+LFGGoXT3as=; b=IYLSbOOnpwb2EdmvPVZijSSVcP6LJVq0is+foQQD6w4/ZCmfDHyWzF15NKIdm53qeM rFGHpsJFJ9j05FNfZBZBzI+TFDinBpYe48GoxQq08ZLifGGWd5L/w2rqCrTevwEfFw84 fSmoRVjh2E6H3QJANGV4pjI56ygp/A9grtKcpdZ3NBdcGqrm0Sc5HNU8G6RlEYmAen98 shmObtFaUvyC1fC2U8xqzQbPIRFno59+mNx2TlJiubXH2+DOKEh36mACaBJ8UrACTCgm czuQQETkgYi3skKs1Q6NSbcbDzs6Az+ocnsnw6oRzwW6Vec3xhXS7H/tETIOxm5Fj9t1 /pnQ== X-Gm-Message-State: AA6/9Rnp8mqaK6OUrgNyVi/a9WHPRgozsRwGcjm1cm7GV88WtTQGBBq11VrweB2bWJKCPuzkVNQXmlNsgm8usg== X-Received: by 10.31.73.71 with SMTP id w68mr2240560vka.13.1476822057181; Tue, 18 Oct 2016 13:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 18 Oct 2016 13:20:56 -0700 (PDT) In-Reply-To: References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 18 Oct 2016 16:20:56 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a1148d00a1d692a053f296eba Archived-At: Cc: Stefan Winter , draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, "radext@ietf.org" Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:21:01 -0000 --001a1148d00a1d692a053f296eba Content-Type: text/plain; charset=UTF-8 Hello Ben, Are you good with Alan's response and changes resulting from one of your points? Thank you, Kathleen On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok wrote: > > > On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Hi Alan, > > > > I don't see responses to the No Objection messages on your draft. Can > you take care of that so I can progress the document? > > I didn't get the original message. > > > ---------- Forwarded message ---------- > > From: Ben Campbell > > Date: Tue, Aug 16, 2016 at 9:59 PM > > Subject: Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: > (with COMMENT) > > To: The IESG > > Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, > radext-chairs@ietf.org, radext@ietf.org > ... > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > -2.1.2, first paragraph: "The specification may, of course, define a new > > data type and use it in the same document." > > Am I correct to assume that any such definition must (or maybe MUST) be > > registered? (Maybe that's already covered in 6929?) > > Any such new definition MUST be registered. RFC 6929 just forbids new > data types. > > I think I can update the doc in the next rev, as soon as that's required. > > > -4.1: I'm curious why new data types need a policy as strong as > > "standards action". Is there a concern that people will get this wrong > > without the full weight of the IETF consensus process? Is there a concern > > that the numbering space will run out? Would it be reasonable to have a > > "specification-required" policy, with some guidance to the designated > > expert(s)? (Or is it because such data types need to be referenceable > > from standards track documents, perhaps related to the guidance against > > vendor-specific types?) > > See RFC 6929 covers this in detail. There are few good reasons to > create new data types. There is a huge cost to creating new data types, > and very little benefit. > > Section 6 has guidelines for creating attributes. RFC 6158 also > contains long guidelines in Appendix A. Both sections have text explaining > why these guidelines are in place. > > In addition, as the draft notes, RADIUS implementations are typically > driven by a dictionary containing attribute names, assigned numbers, and > data types. This means that adding new attributes with known data types is > trivial: edit the dictionary. Adding new data types is complex, and > requires much code to be written. > > Another reason is practice. I'm aware of only a few data types which > have been vendor-defined in the last twenty years. One is an "ad hoc" > structure to describe firewall rules. Another is a signed integer (the > above RFCs explain why this is wrong). A few vendors defined a 64-bit > integer before the IETF did. That's really about it. > > So new data types are not needed, and without IETF consensus, are > generally wrong. > > FWIW, IPFix has a fixed set of data types, an IANA registry, and > requires standards action for update. There is a strong overlap between > the data IPFix tracks, and RADIUS accounting. So a fixed set of data types > works well in both places. > > Alan DeKok. > > -- Best regards, Kathleen --001a1148d00a1d692a053f296eba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,

Are you good with Alan's= response and changes resulting from one of your points?

Thank you,
Kathleen
=
On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok = <aland@deployingradius.com> wrote:

> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&= gt; wrote:
>
> Hi Alan,
>
> I don't see responses to the No Objection messages on your draft.= =C2=A0 Can you take care of that so I can progress the document?

=C2=A0 I didn't get the original message. <mumble smtp issues= >

> ---------- Forwarded message ----------
> From: Ben Campbell <ben@nostrum.= com>
> Date: Tue, Aug 16, 2016 at 9:59 PM
> Subject: Ben Campbell's No Objection on draft-ietf-radext-datatype= s-06: (with COMMENT)
> To: The IESG <iesg@ietf.org>= ;
> Cc: stefan.winter@restena.= lu, draft-ietf-= radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ie= tf.org
...
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> -2.1.2, first paragraph: "The specification may, of course, defin= e a new
> data type and use it in the same document."
> Am I correct to assume that any such definition must (or maybe MUST) b= e
> registered? (Maybe that's already covered in 6929?)

=C2=A0 Any such new definition MUST be registered.=C2=A0 RFC 6929 ju= st forbids new data types.

=C2=A0 I think I can update the doc in the next rev, as soon as that's = required.

> -4.1: I'm curious why new data types need a policy as strong as > "standards action". Is there a concern that people will get = this wrong
> without the full weight of the IETF consensus process? Is there a conc= ern
> that the numbering space will run out? Would it be reasonable to have = a
> "specification-required" policy, with some guidance to the d= esignated
> expert(s)? (Or is it because such data types need to be referenceable<= br> > from standards track documents, perhaps related to the guidance agains= t
> vendor-specific types?)

=C2=A0 See RFC 6929 covers this in detail.=C2=A0 There are few good = reasons to create new data types.=C2=A0 There is a huge cost to creating ne= w data types, and very little benefit.

=C2=A0 Section 6 has guidelines for creating attributes.=C2=A0 RFC 6158 als= o contains long guidelines in Appendix A.=C2=A0 Both sections have text exp= laining why these guidelines are in place.

=C2=A0 In addition, as the draft notes, RADIUS implementations are typicall= y driven by a dictionary containing attribute names, assigned numbers, and = data types.=C2=A0 This means that adding new attributes with known data typ= es is trivial: edit the dictionary.=C2=A0 Adding new data types is complex,= and requires much code to be written.

=C2=A0 Another reason is practice.=C2=A0 I'm aware of only a few data t= ypes which have been vendor-defined in the last twenty years.=C2=A0 One is = an "ad hoc" structure to describe firewall rules.=C2=A0 Another i= s a signed integer (the above RFCs explain why this is wrong).=C2=A0 A few = vendors defined a 64-bit integer before the IETF did.=C2=A0 That's real= ly about it.

=C2=A0 So new data types are not needed, and without IETF consensus, are ge= nerally wrong.

=C2=A0 FWIW, IPFix has a fixed set of data types, an IANA registry, and req= uires standards action for update.=C2=A0 There is a strong overlap between = the data IPFix tracks, and RADIUS accounting.=C2=A0 So a fixed set of data = types works well in both places.

=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a1148d00a1d692a053f296eba-- From nobody Tue Oct 18 13:22:01 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2919512985A; Tue, 18 Oct 2016 13:21:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147682211816.30798.9303561790126758072.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 13:21:58 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:21:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-08.txt Pages : 39 Date : 2016-10-18 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFC 2865, 3162, 6158, and 6572. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-08 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 Tue Oct 18 13:24:56 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA411294AE; Tue, 18 Oct 2016 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 xBHOBLPwArvZ; Tue, 18 Oct 2016 13:24:48 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58AC12947D; Tue, 18 Oct 2016 13:17:33 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id 83so7267671vkd.0; Tue, 18 Oct 2016 13:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tISXyR/4g7dWI3g8mGg2j2XNDoSGPmy/LLc3nGy5HR0=; b=oQsPziN4CuOrReQXLJTxLrminygxlj5PRfHyTIvLdhGYyEJDQgz2chFEGMlbpvDA4D eIOC1uKWR0hAQ0kQibnKbYc5lVN1QwQ7auHx4Ki/ztQQ+WTn+HAtQc9SmW2a9z0AoqML XJYYwhDUmffrBEo3wjPidqBwRl+pJGk9+ww625ZiI5c3NZPLZDC3i6MOqCKGlw0HDpkO OGnnZxSuDNbC+lQFY7Ft9oOybJTjABrvbG8Zbd/fW3IXJ1CYz+8wXRE4V0rTB17FBqP/ y4hiYqFfGfvSLb4l7DNIsl/kM30w/ifbhJD3BuCXOmR74g/aw0HfB0d8HaaqJrhfaabo 7cAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tISXyR/4g7dWI3g8mGg2j2XNDoSGPmy/LLc3nGy5HR0=; b=M2s5LUQQNi5TC5vwmLzgz7xODpYOg3MVhG7MEzONz8iI0BKiWbt7qDP27Uppg03aiF u8wed1hmfmGv61Blm4PXiQKEwmtKkM4z9gHufjuu8F9H/2Uxxc5ZowMfbYvAEVvrs34E 8kJvIkjpYzK4/oE7LwSq7cSYUZY+hoLGjaNXBQj+elnu8f8n/nT4lPw7c0c5w/7e/87y Yk+DrOaPnfCCYGK2mSyZOe4r2Sg5JIaXA7veiqnRL83Mu9I+bn0SetqqMS2z3FoPH1lz wmWtWJXFwE25SB9Ilel0hVeUBeP4xJs8vlAtBcuMCAjte6tAvb4HhrwjGR+wChND76Fq SZlA== X-Gm-Message-State: AA6/9RmVnv5CK70trfQg+gsi4UwCS/ec/Nc2lLlcWK56VNhr6jrlOqO2zTshdDEFH4g5s5629gqnIH0YZdIN+g== X-Received: by 10.31.73.71 with SMTP id w68mr2224578vka.13.1476821852796; Tue, 18 Oct 2016 13:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 18 Oct 2016 13:17:32 -0700 (PDT) In-Reply-To: <5E5B67F0-FA14-432E-8C79-92C68CDA47D7@kuehlewind.net> References: <147142512074.12181.7172134882556272250.idtracker@ietfa.amsl.com> <3C315C09-71A7-46B6-AFE5-14EA35D6F256@deployingradius.com> <5E5B67F0-FA14-432E-8C79-92C68CDA47D7@kuehlewind.net> From: Kathleen Moriarty Date: Tue, 18 Oct 2016 16:17:32 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a1148d00aeebc8f053f296123 Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-datatypes@ietf.org, Winter Stefan , Alan DeKok , IESG , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-datatypes-06=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:24:49 -0000 --001a1148d00aeebc8f053f296123 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Wed, Oct 12, 2016 at 10:22 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi, > > see below. > > > Am 12.10.2016 um 16:08 schrieb Alan DeKok : > > > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> "As RADIUS does not encode information about data types in a packet, t= he > >> numbers assigned to a data type will never occur in a packet." > >> Given the Name must be unique, I don't see why a Value field is needed= . > > > > It's not. It's just useful to do. > > > > In the future, we may want to use the numbers, so we might as well > assign them now. > > Not a big issue. However I don=E2=80=99t see a case where this could be u= sed in > future, so I would say it is just not useful to do=E2=80=A6 > OK, I see this is not a big issue and would like to confirm if this approach was working group consensus, if so, we just move on. Otherwise, we should think about this more to close the loop on Mirja's questions. Thank you, Kathleen > > Mirja > > > > > >> Related: There is an inconsitency between section 4.1 and 6 regarding > the > >> use of Description/Name. > > > > Fixed, thanks. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --=20 Best regards, Kathleen --001a1148d00aeebc8f053f296123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, Oct 12, 2016 at 10:22 AM, Mirja Kuehlewind (IETF) <ietf@= kuehlewind.net> wrote:
Hi,<= br>
see below.

> Am 12.10.2016 um 16:08 schrieb Alan DeKok <aland@deployingradius.com>:
>
>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> "As RADIUS does not encode information about data types in a = packet, the
>> numbers assigned to a data type will never occur in a packet."= ;
>> Given the Name must be unique, I don't see why a Value field i= s needed.
>
>=C2=A0 It's not.=C2=A0 It's just useful to do.
>
>=C2=A0 In the future, we may want to use the numbers, so we might as we= ll assign them now.

Not a big issue. However I don=E2=80=99t see a case where this could= be used in future, so I would say it is just not useful to do=E2=80=A6
=

OK, I see this is not a big issue and woul= d like to confirm if this approach was working group consensus, if so, we j= ust move on.=C2=A0 Otherwise, we should think about this more to close the = loop on Mirja's questions.

Thank you,
Kathleen
=C2=A0

Mirja


>
>> Related: There is an inconsitency between section 4.1 and 6 regard= ing the
>> use of Description/Name.
>
>=C2=A0 Fixed, thanks.

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



--
=

Best regards,
Kathleen
--001a1148d00aeebc8f053f296123-- From nobody Fri Oct 21 09:31:35 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216E612961D; Fri, 21 Oct 2016 09:31:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147706749113.23660.12860960495161027016.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 09:31:31 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:31:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-15.txt Pages : 39 Date : 2016-10-21 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. This document defines a mapping between some RADIUS attributes and IPFIX Information Element Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-15 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 Oct 21 09:31:40 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D558129635; Fri, 21 Oct 2016 09:31:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147706749124.23660.11413407891826442612.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 09:31:31 -0700 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:31:31 -0000 A new version (-15) has been submitted for draft-ietf-radext-ip-port-radius-ext: https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-15 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. IETF Secretariat. From nobody Fri Oct 21 16:22:16 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F31B31296DF; Fri, 21 Oct 2016 16:21:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206699.28214.4340024486210773051.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:06 -0700 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [radext] radext - Requested session has been scheduled for IETF 97 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:07 -0000 Dear Stefan Winter, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. radext Session 1 (1:30:00) Wednesday, Morning Session I 0930-1100 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: RADIUS EXTensions Area Name: Operations and Management Area Session Requester: Stefan Winter Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 20 Conflicts to Avoid: First Priority: dime 6man v6ops dmm abfab oauth saag Second Priority: spring sfc rtcweb 6lo ace httpauth mile ipsecme Special Requests: --------------------------------------------------------- From nobody Mon Oct 24 03:56:44 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2E12948F for ; Mon, 24 Oct 2016 03:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, WEIRD_PORT=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 NAudAKvc6R3m for ; Mon, 24 Oct 2016 03:56:41 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 0127A124281 for ; Mon, 24 Oct 2016 03:56:41 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4F0ED403B5 for ; Mon, 24 Oct 2016 12:56:39 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> Date: Mon, 24 Oct 2016 12:56:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RUqge2gpRrLEk3NBweNQ4OwnSMFhta4Kj" Archived-At: Subject: [radext] Meeting in Seoul - call for talking slot requests X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 10:56:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RUqge2gpRrLEk3NBweNQ4OwnSMFhta4Kj Content-Type: multipart/mixed; boundary="TWKxBHtVa8G1c1cI7ICW7S3K3aLhg2J7k"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> Subject: Meeting in Seoul - call for talking slot requests --TWKxBHtVa8G1c1cI7ICW7S3K3aLhg2J7k Content-Type: multipart/mixed; boundary="------------C223E1C282D53DC421D645A1" This is a multi-part message in MIME format. --------------C223E1C282D53DC421D645A1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, we have been given a 90 minute slot for the next IETF meeting in Seoul. We'll meet on Wednesday morning (0930 local time). https://datatracker.ietf.org/meeting/97/agenda.html Please send requests for a talking slot during the meeting to the chairs, ideally before Monday 31 Oct (preliminary agendas due date). With 30 more minutes than usual, I hope we can be a bit more generous in the slot allocation and don't have to rush things through. I hope we can repeat the refreshing vivid experience we had in Berlin at IETF 96! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------C223E1C282D53DC421D645A1 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------C223E1C282D53DC421D645A1-- --TWKxBHtVa8G1c1cI7ICW7S3K3aLhg2J7k-- --RUqge2gpRrLEk3NBweNQ4OwnSMFhta4Kj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYDejnAAoJEMDeajWKOdxmh98P/2UuAoMv/3+7ShBs5yaVV89n oxSn1B/CpF4aE07ZIkpau5f07u9bCeT7LrAaoCE4apIpyNUScsu6NlQns+Pgnlo+ TJ53EUSwfzO33c5t1X9odnKBTJlVErZ+aVbn6wPSh2y7FsfoFcUXrz6equkOXuWF q9Gfp5G1gJItqWFGkyde8YX+cPmHdnzAGkwd36YmJ8BfSzpeNzaZH3fFzr6hjeKR 7FguVW3AeWt2W+mz6ZGTJRKbgnKSTdrpAiQDk8zqo9v1Mt0PDtalcJIV/20gCBzE HvZeCg9K1+cIbV2SrSxDblEAQnF8RlCJeNeU+cf6/QqJGKKC+lEPlGhYFSs4TQjf B+rMNmxHf6BjT4jBZT+6zuu+sJaoTePzqJbglwzU9Rd24Qt2WSWRJmGaHgnqkUnU dbxkdv/6/SEWmNHbsFe4AUKBlCJRv8q1y3bka+LqAyGLcNSaR69iMZneB+mp5dHX aKGxYoxJhWrip2PEGqCQS7ao6f0txN/tdVEoskJQpb+rfizuEwtlFupZPTI/IVLM cY+pF+k4uaUBUEIS6JFN0XRkAzKx3/q9DfXpGtGldCk2yqnzrnuPvVDVfVuOpzr8 1pZ85xkqnMAfY5nxfQNJWBf6PseNWKUPj8z0+cnaQTYMCqgVV8zniyfuzfudlms+ XYHUJFZibxsJURWd9Mij =X/fr -----END PGP SIGNATURE----- --RUqge2gpRrLEk3NBweNQ4OwnSMFhta4Kj-- From nobody Mon Oct 24 03:58:54 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814A81294F9 for ; Mon, 24 Oct 2016 03:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, WEIRD_PORT=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 eXC6u0ZMkZ17 for ; Mon, 24 Oct 2016 03:58:52 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 232E212948F for ; Mon, 24 Oct 2016 03:58:52 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6A376403B5 for ; Mon, 24 Oct 2016 12:58:50 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <2035543c-aeb8-c4b7-d813-8f1932745bdf@restena.lu> Date: Mon, 24 Oct 2016 12:58:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O1UtEUJu7niCVMAgiwvwUoDPAtm9nWXjV" Archived-At: Subject: [radext] document updates X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 10:58:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O1UtEUJu7niCVMAgiwvwUoDPAtm9nWXjV Content-Type: multipart/mixed; boundary="tcsdk74HUXhbsXm0p6VAXd9xs5sORuL4F"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: <2035543c-aeb8-c4b7-d813-8f1932745bdf@restena.lu> Subject: document updates --tcsdk74HUXhbsXm0p6VAXd9xs5sORuL4F Content-Type: multipart/mixed; boundary="------------42933396A80DB19C66BE15B7" This is a multi-part message in MIME format. --------------42933396A80DB19C66BE15B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, we have a number of documents in our queue. I would like to remind everyone that the document submission cut-off is the 31st of October. We would appreciate both a) updated documents where applicable and b) discussions about those updates before the actual meeting. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------42933396A80DB19C66BE15B7 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------42933396A80DB19C66BE15B7-- --tcsdk74HUXhbsXm0p6VAXd9xs5sORuL4F-- --O1UtEUJu7niCVMAgiwvwUoDPAtm9nWXjV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYDelqAAoJEMDeajWKOdxmSsoP/3lM1tr37s4AeqeHxh3chxqo fVxTtSieYExMePXIDcQURwugzBt7EZFO/XDA5nR3oaqo9esv20t711bd/QzpYG1F UDor9S9G0x1YPjoYfx3bwA7QWVb7J5adKH+DbVH5t25oXheUGzNKbuFC0KqYYenv S7kBG1MYOU6i7Ffmplu444ID2EPo4XfFmuhH3+4UhRmRdaoeRnHp3u5UeixJ0gIf qHLjG/eHFgIhMx4xs3YbiPAmg59jeeQDanNSRiIPGQVWZOKmgEJGEU93Rl+X9EAe LB8sMbjZgdaSjCclRggXT0Ld9GjfIyulYID0KXOXELL+Dh8K3YV9bBnXzT8uRfro YV/Yztk6pzwNC2KRXHK/dkXKTjtOuCroL3QhK2TBUUQaqSqp67Fi0VEG+nNtZ0y2 JcSeuLVJVJOL02kN4Y4lcLkCTfJx18XEx+WwCIhaW+fbahqeJyNZ5RQH1OIRC5YU N+txDmF2Y8nIKZNks5xRig937PM+ZqXe/eBjJmfqaFUZ6DiXYLXF02Ih+kwwFQs3 LqpmTyG+iGhz83LAZlbQYhZ1NURAJE1XywqX+pFEVfA/VZp4UIqEx+uLG+X2BEJl 2liWki4yHkxW8qqiGOAPzY27o87urSHwTHMifjzTXwrXtn/9aqLuVq2B/KwMI1tE ZqzmMm5EIPDxqRlD3DAm =yj0p -----END PGP SIGNATURE----- --O1UtEUJu7niCVMAgiwvwUoDPAtm9nWXjV-- From nobody Mon Oct 24 04:52:25 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88FA129514 for ; Mon, 24 Oct 2016 04:52:24 -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, 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 DJjRooSWuUGn for ; Mon, 24 Oct 2016 04:52:23 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE4A1294FE for ; Mon, 24 Oct 2016 04:52:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 716ED1F74; Mon, 24 Oct 2016 11:52:22 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VncRCQsYvNvJ; Mon, 24 Oct 2016 11:52:22 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 078934E7; Mon, 24 Oct 2016 11:52:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <2035543c-aeb8-c4b7-d813-8f1932745bdf@restena.lu> Date: Mon, 24 Oct 2016 07:52:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <663B9522-3DA0-401D-8F3A-49A0786D869B@deployingradius.com> References: <2035543c-aeb8-c4b7-d813-8f1932745bdf@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] document updates X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:52:25 -0000 On Oct 24, 2016, at 6:58 AM, Stefan Winter = wrote: >=20 > we have a number of documents in our queue. I would like to remind > everyone that the document submission cut-off is the 31st of October. >=20 > We would appreciate both a) updated documents where applicable and b) > discussions about those updates before the actual meeting. data-types is pretty much done. The last revision addresses all IESG = review comments. Alan DeKok. From nobody Mon Oct 24 04:54:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8B12954B for ; Mon, 24 Oct 2016 04:54:13 -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, 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 X5z96aWN--LI for ; Mon, 24 Oct 2016 04:54:12 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1517A129514 for ; Mon, 24 Oct 2016 04:54:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 68DAE1F74; Mon, 24 Oct 2016 11:54:11 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6WXdtgqzE1D; Mon, 24 Oct 2016 11:54:11 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id F27924E7; Mon, 24 Oct 2016 11:54:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> Date: Mon, 24 Oct 2016 07:54:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E1363C3-99C4-4601-8E3E-9F697CCB12DB@deployingradius.com> References: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Meeting in Seoul - call for talking slot requests X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:54:13 -0000 On Oct 24, 2016, at 6:56 AM, Stefan Winter = wrote: > we have been given a 90 minute slot for the next IETF meeting in = Seoul. > We'll meet on Wednesday morning (0930 local time). >=20 > https://datatracker.ietf.org/meeting/97/agenda.html >=20 > Please send requests for a talking slot during the meeting to the > chairs, ideally before Monday 31 Oct (preliminary agendas due date). I'd like 10min to talk about a proxy considerations document. This = was discussed informally in Berlin. Perhaps also 5min to discuss DHCP packet signing via 802.1X. I should = have a rough draft later today. The draft will be submitted to the = security area for AD sponsorship. But it would be good to get comments = from RADEXT too, because there is some overlap. Alan DeKok. From nobody Tue Oct 25 14:54:17 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 719C6129543; Tue, 25 Oct 2016 14:54:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147743245645.29297.11230018984083210320.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 14:54:16 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 21:54:16 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Tue Oct 25 15:41:45 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E519E129608 for ; Tue, 25 Oct 2016 15:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 z-sY_FNIwj6B for ; Tue, 25 Oct 2016 15:41:42 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D2E12951D for ; Tue, 25 Oct 2016 15:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2506; q=dns/txt; s=iport; t=1477435302; x=1478644902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2CEecz+j9P4F0Ah93zeNizQplviLiTGZKTXPGoNSWMI=; b=fkkguZXZOC2DpTGtEkzhj+FESSoUhzerwX+/O2yH3h11yZcA3ZQ71AdP usowocQqja+zLyVdsQFwgp/PDX2lwf7Y7MTJx6S5U5jANkuGRxW0iG4lg b55wk5bUkU8h/iCG3QwOUd0MiOGlDTNY0wobDP3rwCsWeX0YlqBnOo7Op Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAQDY3g9Y/5ldJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMvAQEBAQEdWH0HgnqKNZZ+lD+CBxwLhEZVFUoCGoFaPxQBAgE?= =?us-ascii?q?BAQEBAQFiKIRiAQEBAwEBAQEJEQYROgsFCwIBBgIYAgImAgICJQsVEAIEDgUWB?= =?us-ascii?q?YgwCA6VOp02jHUBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQeHMwiCUIQZEQEcFwo?= =?us-ascii?q?mgj0sgi8FiE2RSQGGKYltgW6EbYkojQiEAAEeNl6FAnIBhXCBIIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,399,1473120000"; d="scan'208";a="338355751" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2016 22:41:41 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u9PMffVH013168 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Oct 2016 22:41:41 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Oct 2016 18:41:40 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Tue, 25 Oct 2016 18:41:40 -0400 From: "Brian Weis (bew)" To: Stefan Winter Thread-Topic: [radext] Meeting in Seoul - call for talking slot requests Thread-Index: AQHSLeVRIopkGtY0B0uyPfJJVeag26C6CSoA Date: Tue, 25 Oct 2016 22:41:40 +0000 Message-ID: <062260E0-9FEE-4E36-9521-1896A39A38B8@cisco.com> References: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> In-Reply-To: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.163] Content-Type: text/plain; charset="utf-8" Content-ID: <8972A9523D90B549A4FB9C459711B741@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Meeting in Seoul - call for talking slot requests X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 22:41:44 -0000 SGkgU3RlZmFuLA0KDQpJIGhhdmUgcmVjZW50bHkgcG9zdGVkIGEgbmV3IGRyYWZ0IDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2Vpcy1yYWRleHQtbXVkLTAwPiwgYW5kIGlmIHBv c3NpYmxlIEnigJlkIGFwcHJlY2lhdGUgMTAgbWludXRlcyBvciBzbyBvZiB0aGUgbWVldGluZyB0 byBpbnRyb2R1Y2UgaXQuIFRoZSBkcmFmdCBhbGxvd3MgUkFESVVTIHRvIGhlbHAgY29tcGxldGUg YSBzb2x1dGlvbiB1c2luZyB0aGUgTWFudWZhY3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uIChNVUQp IFNwZWNpZmljYXRpb24gKDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v cHNhd2ctbXVkLTAxPikuDQoNCkNvbW1lbnRzIGFyZSB3ZWxjb21lIG9uIHRoZSBsaXN0IHRvbywg b2YgY291cnNlLg0KDQpUaGFua3MsDQpCcmlhbg0KDQo+IE9uIE9jdCAyNCwgMjAxNiwgYXQgMzo1 NiBBTSwgU3RlZmFuIFdpbnRlciA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PiB3cm90ZToNCj4g DQo+IEhlbGxvLA0KPiANCj4gDQo+IHdlIGhhdmUgYmVlbiBnaXZlbiBhIDkwIG1pbnV0ZSBzbG90 IGZvciB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgaW4gU2VvdWwuDQo+IFdlJ2xsIG1lZXQgb24gV2Vk bmVzZGF5IG1vcm5pbmcgKDA5MzAgbG9jYWwgdGltZSkuDQo+IA0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvOTcvYWdlbmRhLmh0bWwNCj4gDQo+IFBsZWFzZSBzZW5kIHJl cXVlc3RzIGZvciBhIHRhbGtpbmcgc2xvdCBkdXJpbmcgdGhlIG1lZXRpbmcgdG8gdGhlDQo+IGNo YWlycywgaWRlYWxseSBiZWZvcmUgTW9uZGF5IDMxIE9jdCAocHJlbGltaW5hcnkgYWdlbmRhcyBk dWUgZGF0ZSkuDQo+IA0KPiBXaXRoIDMwIG1vcmUgbWludXRlcyB0aGFuIHVzdWFsLCBJIGhvcGUg d2UgY2FuIGJlIGEgYml0IG1vcmUgZ2VuZXJvdXMgaW4NCj4gdGhlIHNsb3QgYWxsb2NhdGlvbiBh bmQgZG9uJ3QgaGF2ZSB0byBydXNoIHRoaW5ncyB0aHJvdWdoLiBJIGhvcGUgd2UgY2FuDQo+IHJl cGVhdCB0aGUgcmVmcmVzaGluZyB2aXZpZCBleHBlcmllbmNlIHdlIGhhZCBpbiBCZXJsaW4gYXQg SUVURiA5NiENCj4gDQo+IA0KPiBHcmVldGluZ3MsDQo+IA0KPiBTdGVmYW4gV2ludGVyDQo+IA0K PiAtLSANCj4gU3RlZmFuIFdJTlRFUg0KPiBJbmdlbmlldXIgZGUgUmVjaGVyY2hlDQo+IEZvbmRh dGlvbiBSRVNURU5BIC0gUsOpc2VhdSBUw6lsw6lpbmZvcm1hdGlxdWUgZGUgbCdFZHVjYXRpb24g TmF0aW9uYWxlIGV0IGRlIGxhIFJlY2hlcmNoZQ0KPiAyLCBhdmVudWUgZGUgbCdVbml2ZXJzaXTD qQ0KPiBMLTQzNjUgRXNjaC1zdXItQWx6ZXR0ZQ0KPiANCj4gVGVsOiArMzUyIDQyNDQwOSAxDQo+ IEZheDogKzM1MiA0MjI0NzMNCj4gDQo+IFBHUCBrZXkgdXBkYXRlZCB0byA0MDk2IEJpdCBSU0Eg LSBJIHdpbGwgZW5jcnlwdCBhbGwgbWFpbHMgaWYgdGhlIHJlY2lwaWVudCdzIGtleSBpcyBrbm93 biB0byBtZQ0KPiANCj4gaHR0cDovL3BncC5taXQuZWR1OjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0 JnNlYXJjaD0weEMwREU2QTM1OEEzOURDNjYNCj4gDQo+IDwweDhBMzlEQzY2LmFzYz5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiByYWRleHQgbWFpbGlu ZyBsaXN0DQo+IHJhZGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JhZGV4dA0KDQotLSANCkJyaWFuIFdlaXMNClNlY3VyaXR5LCBDU0csIENpc2Nv IFN5c3RlbXMNClRlbGVwaG9uZTogKzEgNDA4IDUyNiA0Nzk2DQpFbWFpbDogYmV3QGNpc2NvLmNv bQ0KDQo= From nobody Wed Oct 26 16:47:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55F91296BD for ; Wed, 26 Oct 2016 16:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no 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 F4lm-ujHQLJ6 for ; Wed, 26 Oct 2016 16:47:37 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD7129A5B for ; Wed, 26 Oct 2016 16:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 1BC97C0D; Wed, 26 Oct 2016 23:47:36 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1md71eN8SCy; Wed, 26 Oct 2016 23:47:36 +0000 (UTC) Received: from [10.59.1.162] (unknown [75.98.19.132]) by mail.networkradius.com (Postfix) with ESMTPSA id 06D8E658; Wed, 26 Oct 2016 23:47:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <062260E0-9FEE-4E36-9521-1896A39A38B8@cisco.com> Date: Wed, 26 Oct 2016 19:47:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89F2AC4B-3867-4784-A830-30259D1D2261@deployingradius.com> References: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> <062260E0-9FEE-4E36-9521-1896A39A38B8@cisco.com> To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Meeting in Seoul - call for talking slot requests X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 23:47:39 -0000 > On Oct 25, 2016, at 6:41 PM, Brian Weis (bew) wrote: >=20 > Hi Stefan, >=20 > I have recently posted a new draft = , and if possible = I=E2=80=99d appreciate 10 minutes or so of the meeting to introduce it. = The draft allows RADIUS to help complete a solution using the = Manufacturer Usage Description (MUD) Specification = (). My $0.02, mostly nits. - define the new attribute as of type "string", and reference the data = types draft. This lets you remove the ASCII art - perhaps have a discussion of the security implications of MAB in = Section 5. I don't recall seeing a discussion of this before in a = RADIUS document - i.e.MAB requests rely on MAC address from the end user machine... = which can be trivially forged. What are the implications of send the = wrong MUD info to a machine which is lying to you? But the concept does seem rather simple. I think a short & clear = specification such as this is good.= From nobody Fri Oct 28 14:18:46 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0E129616; Fri, 28 Oct 2016 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ADG__1OG9QZe; Fri, 28 Oct 2016 14:18:43 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E557E12952E; Fri, 28 Oct 2016 14:18:42 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id y123so65043693vka.3; Fri, 28 Oct 2016 14:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=saX3NpoR1oD2rCYme9cBN+LldcTzD/zBZ8ergoHx3Pw=; b=pLPmRypb20hkwlIR0zd1giE5w5IuetF6TKNpWl8e7bTwNab/kmKxkLLGI/eVfpZyd/ yBPGjatzA+vwYh62TYGsO3Gm34KXuNKUZsRVizTv8fz1eiFRL0oHjFObepGueW41p8sn vVHmMgpGJqHiZkIQtIeymiaRcQdYx3WU4g5M/j4tsUE5lRnmna+Loz9jQUfxWrRr3HrN vTbReaJbHubeKILAyHnr0lKXmsxPEnF0Lo1ZcsZTVobad9ogNEIADisJl693T2Jgxesk Xmw3aGxRuIcXUU0Mf1Px0nNNDL9i0LFcdsUQ7aFOQ+mFVaih6jUNamQwH6G5pqamTh1m VLhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=saX3NpoR1oD2rCYme9cBN+LldcTzD/zBZ8ergoHx3Pw=; b=gsLtQcVMdChQ84tuRa6VLiSnJgg5Vq9a8M7oYzuUzttFxK0CyUPrh1SH5SL3/N6tjZ ZGl77+wJS2ZOb+AVmIscUztYVQALPbKLeLRGgvyZH2sNNeuWVzfALGyYEL863Rhh7WhS acWXwCFWctx74A+LzGxm+gqTl3LNkd3/P2DcV5T9d7CGXxPHO70oJmH/4LlUsG6QY40G 8nEeEQlnExACb4yDHi6Ig7X9LO7IhbZxGURrovAXQSuGchwx7PuPvBImUdd4nhsWpZKh /VgkHcdSI+qCAZx3hscEnvKpoHH4PY2a29pPLkImU5+8BNgJF1Mv69RgUIsgw05Zf2cA jOTw== X-Gm-Message-State: ABUngvcymsW6yrdxujw538qfuWF6pCIrxxxC+aCHCFVI1DokbpoAc6VQS9EUnW3IADIMnxVse3ayAAddbzZYsA== X-Received: by 10.31.151.78 with SMTP id z75mr14713965vkd.41.1477689521976; Fri, 28 Oct 2016 14:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Fri, 28 Oct 2016 14:18:41 -0700 (PDT) In-Reply-To: References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Fri, 28 Oct 2016 17:18:41 -0400 Message-ID: To: Alan DeKok , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a1140e6620bbbe4053ff36708 Archived-At: Cc: Stefan Winter , draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, "radext@ietf.org" Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 21:18:45 -0000 --001a1140e6620bbbe4053ff36708 Content-Type: text/plain; charset=UTF-8 Hello Ben, Are you okay with Alan's response? Thank you, Kathleen On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok wrote: > > > On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Hi Alan, > > > > I don't see responses to the No Objection messages on your draft. Can > you take care of that so I can progress the document? > > I didn't get the original message. > > > ---------- Forwarded message ---------- > > From: Ben Campbell > > Date: Tue, Aug 16, 2016 at 9:59 PM > > Subject: Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: > (with COMMENT) > > To: The IESG > > Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, > radext-chairs@ietf.org, radext@ietf.org > ... > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > -2.1.2, first paragraph: "The specification may, of course, define a new > > data type and use it in the same document." > > Am I correct to assume that any such definition must (or maybe MUST) be > > registered? (Maybe that's already covered in 6929?) > > Any such new definition MUST be registered. RFC 6929 just forbids new > data types. > > I think I can update the doc in the next rev, as soon as that's required. > > > -4.1: I'm curious why new data types need a policy as strong as > > "standards action". Is there a concern that people will get this wrong > > without the full weight of the IETF consensus process? Is there a concern > > that the numbering space will run out? Would it be reasonable to have a > > "specification-required" policy, with some guidance to the designated > > expert(s)? (Or is it because such data types need to be referenceable > > from standards track documents, perhaps related to the guidance against > > vendor-specific types?) > > See RFC 6929 covers this in detail. There are few good reasons to > create new data types. There is a huge cost to creating new data types, > and very little benefit. > > Section 6 has guidelines for creating attributes. RFC 6158 also > contains long guidelines in Appendix A. Both sections have text explaining > why these guidelines are in place. > > In addition, as the draft notes, RADIUS implementations are typically > driven by a dictionary containing attribute names, assigned numbers, and > data types. This means that adding new attributes with known data types is > trivial: edit the dictionary. Adding new data types is complex, and > requires much code to be written. > > Another reason is practice. I'm aware of only a few data types which > have been vendor-defined in the last twenty years. One is an "ad hoc" > structure to describe firewall rules. Another is a signed integer (the > above RFCs explain why this is wrong). A few vendors defined a 64-bit > integer before the IETF did. That's really about it. > > So new data types are not needed, and without IETF consensus, are > generally wrong. > > FWIW, IPFix has a fixed set of data types, an IANA registry, and > requires standards action for update. There is a strong overlap between > the data IPFix tracks, and RADIUS accounting. So a fixed set of data types > works well in both places. > > Alan DeKok. > > -- Best regards, Kathleen --001a1140e6620bbbe4053ff36708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,

Are you okay with Alan's= response?

Thank you,
Kathleen

On Tue, Oct 11,= 2016 at 4:16 PM, Alan DeKok <aland@deployingradius.com> wrote:

> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&= gt; wrote:
>
> Hi Alan,
>
> I don't see responses to the No Objection messages on your draft.= =C2=A0 Can you take care of that so I can progress the document?

=C2=A0 I didn't get the original message. <mumble smtp issues= >

> ---------- Forwarded message ----------
> From: Ben Campbell <ben@nostrum.= com>
> Date: Tue, Aug 16, 2016 at 9:59 PM
> Subject: Ben Campbell's No Objection on draft-ietf-radext-datatype= s-06: (with COMMENT)
> To: The IESG <iesg@ietf.org>= ;
> Cc: stefan.winter@restena.= lu, draft-ietf-= radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ie= tf.org
...
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> -2.1.2, first paragraph: "The specification may, of course, defin= e a new
> data type and use it in the same document."
> Am I correct to assume that any such definition must (or maybe MUST) b= e
> registered? (Maybe that's already covered in 6929?)

=C2=A0 Any such new definition MUST be registered.=C2=A0 RFC 6929 ju= st forbids new data types.

=C2=A0 I think I can update the doc in the next rev, as soon as that's = required.

> -4.1: I'm curious why new data types need a policy as strong as > "standards action". Is there a concern that people will get = this wrong
> without the full weight of the IETF consensus process? Is there a conc= ern
> that the numbering space will run out? Would it be reasonable to have = a
> "specification-required" policy, with some guidance to the d= esignated
> expert(s)? (Or is it because such data types need to be referenceable<= br> > from standards track documents, perhaps related to the guidance agains= t
> vendor-specific types?)

=C2=A0 See RFC 6929 covers this in detail.=C2=A0 There are few good = reasons to create new data types.=C2=A0 There is a huge cost to creating ne= w data types, and very little benefit.

=C2=A0 Section 6 has guidelines for creating attributes.=C2=A0 RFC 6158 als= o contains long guidelines in Appendix A.=C2=A0 Both sections have text exp= laining why these guidelines are in place.

=C2=A0 In addition, as the draft notes, RADIUS implementations are typicall= y driven by a dictionary containing attribute names, assigned numbers, and = data types.=C2=A0 This means that adding new attributes with known data typ= es is trivial: edit the dictionary.=C2=A0 Adding new data types is complex,= and requires much code to be written.

=C2=A0 Another reason is practice.=C2=A0 I'm aware of only a few data t= ypes which have been vendor-defined in the last twenty years.=C2=A0 One is = an "ad hoc" structure to describe firewall rules.=C2=A0 Another i= s a signed integer (the above RFCs explain why this is wrong).=C2=A0 A few = vendors defined a 64-bit integer before the IETF did.=C2=A0 That's real= ly about it.

=C2=A0 So new data types are not needed, and without IETF consensus, are ge= nerally wrong.

=C2=A0 FWIW, IPFix has a fixed set of data types, an IANA registry, and req= uires standards action for update.=C2=A0 There is a strong overlap between = the data IPFix tracks, and RADIUS accounting.=C2=A0 So a fixed set of data = types works well in both places.

=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a1140e6620bbbe4053ff36708-- From nobody Fri Oct 28 14:28:49 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E971294FB; Fri, 28 Oct 2016 14:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431] autolearn=unavailable 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 Rt8BLd7SSs3W; Fri, 28 Oct 2016 14:28:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 11CF412941A; Fri, 28 Oct 2016 14:28:36 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9SLSSZ8059173 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Oct 2016 16:28:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Kathleen Moriarty" Date: Fri, 28 Oct 2016 16:28:28 -0500 Message-ID: In-Reply-To: References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_690F5F00-519E-4C31-8761-83D099A5A64C_=" Embedded-HTML: [{"HTML":[616, 4748], "plain":[110, 3492], "uuid":"670AA438-6E6F-47E3-8761-6BCF8AC0F03B"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "radext@ietf.org" , draft-ietf-radext-datatypes@ietf.org, Stefan Winter , Alan DeKok , "iesg@ietf.org" , radext-chairs@ietf.org Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 21:28:37 -0000 --=_MailMate_690F5F00-519E-4C31-8761-83D099A5A64C_= Content-Type: text/plain; format=flowed Yes, it all looks perfectly reasonable. Thanks! Ben. On 28 Oct 2016, at 16:18, Kathleen Moriarty wrote: > Hello Ben, > > Are you okay with Alan's response? > > Thank you, > Kathleen > > On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok > > wrote: > >> >>> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> Hi Alan, >>> >>> I don't see responses to the No Objection messages on your draft. >>> Can >> you take care of that so I can progress the document? >> >> I didn't get the original message. >> >>> ---------- Forwarded message ---------- >>> From: Ben Campbell >>> Date: Tue, Aug 16, 2016 at 9:59 PM >>> Subject: Ben Campbell's No Objection on >>> draft-ietf-radext-datatypes-06: >> (with COMMENT) >>> To: The IESG >>> Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, >> radext-chairs@ietf.org, radext@ietf.org >> ... >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> -2.1.2, first paragraph: "The specification may, of course, define a >>> new >>> data type and use it in the same document." >>> Am I correct to assume that any such definition must (or maybe MUST) >>> be >>> registered? (Maybe that's already covered in 6929?) >> >> Any such new definition MUST be registered. RFC 6929 just forbids >> new >> data types. >> >> I think I can update the doc in the next rev, as soon as that's >> required. >> >>> -4.1: I'm curious why new data types need a policy as strong as >>> "standards action". Is there a concern that people will get this >>> wrong >>> without the full weight of the IETF consensus process? Is there a >>> concern >>> that the numbering space will run out? Would it be reasonable to >>> have a >>> "specification-required" policy, with some guidance to the >>> designated >>> expert(s)? (Or is it because such data types need to be >>> referenceable >>> from standards track documents, perhaps related to the guidance >>> against >>> vendor-specific types?) >> >> See RFC 6929 covers this in detail. There are few good reasons to >> create new data types. There is a huge cost to creating new data >> types, >> and very little benefit. >> >> Section 6 has guidelines for creating attributes. RFC 6158 also >> contains long guidelines in Appendix A. Both sections have text >> explaining >> why these guidelines are in place. >> >> In addition, as the draft notes, RADIUS implementations are >> typically >> driven by a dictionary containing attribute names, assigned numbers, >> and >> data types. This means that adding new attributes with known data >> types is >> trivial: edit the dictionary. Adding new data types is complex, and >> requires much code to be written. >> >> Another reason is practice. I'm aware of only a few data types >> which >> have been vendor-defined in the last twenty years. One is an "ad >> hoc" >> structure to describe firewall rules. Another is a signed integer >> (the >> above RFCs explain why this is wrong). A few vendors defined a >> 64-bit >> integer before the IETF did. That's really about it. >> >> So new data types are not needed, and without IETF consensus, are >> generally wrong. >> >> FWIW, IPFix has a fixed set of data types, an IANA registry, and >> requires standards action for update. There is a strong overlap >> between >> the data IPFix tracks, and RADIUS accounting. So a fixed set of data >> types >> works well in both places. >> >> Alan DeKok. >> >> > > -- > > Best regards, > Kathleen --=_MailMate_690F5F00-519E-4C31-8761-83D099A5A64C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, it all looks perfectly reasonable.
Thanks!
Ben.
On 28 Oct 2016, at 16:18, Kathleen Moriarty wrote= :
Hello Ben,

Are you okay with Alan's= response?

Thank you,
Kathleen

On Tue, Oct= 11, 2016 at 4:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
=
> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<= /a>> wrote:
>
> Hi Alan,
>
> I don't see responses to the No Objection messages on your draft= =2E=C2=A0 Can you take care of that so I can progress the document?

=C2=A0 I didn't get the original message. <mumble smtp issu= es>

> ---------- Forwarded message ----------
> From: Ben Campbell <ben@nostru= m.com>
> Date: Tue, Aug 16, 2016 at 9:59 PM
> Subject: Ben Campbell's No Objection on draft-ietf-radext-dataty= pes-06: (with COMMENT)
> To: The IESG <iesg@ietf.org&= gt;
> Cc: stefan.winter@resten= a.lu, draft-i= etf-radext-datatypes@ietf.org, radext-chairs@ietf.org, r= adext@ietf.org
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> -2.1.2, first paragraph: "The specification may, of course, def= ine a new
> data type and use it in the same document."
> Am I correct to assume that any such definition must (or maybe MUST)= be
> registered? (Maybe that's already covered in 6929?)

=C2=A0 Any such new definition MUST be registered.=C2=A0 RFC 6929 = just forbids new data types.

=C2=A0 I think I can update the doc in the next rev, as soon as that'= s required.

> -4.1: I'm curious why new data types need a policy as strong as<= br> > "standards action". Is there a concern that people will ge= t this wrong
> without the full weight of the IETF consensus process? Is there a co= ncern
> that the numbering space will run out? Would it be reasonable to hav= e a
> "specification-required" policy, with some guidance to the= designated
> expert(s)? (Or is it because such data types need to be referenceabl= e
> from standards track documents, perhaps related to the guidance agai= nst
> vendor-specific types?)

=C2=A0 See RFC 6929 covers this in detail.=C2=A0 There are few goo= d reasons to create new data types.=C2=A0 There is a huge cost to creatin= g new data types, and very little benefit.

=C2=A0 Section 6 has guidelines for creating attributes.=C2=A0 RFC 6158 a= lso contains long guidelines in Appendix A.=C2=A0 Both sections have text= explaining why these guidelines are in place.

=C2=A0 In addition, as the draft notes, RADIUS implementations are typica= lly driven by a dictionary containing attribute names, assigned numbers, = and data types.=C2=A0 This means that adding new attributes with known da= ta types is trivial: edit the dictionary.=C2=A0 Adding new data types is = complex, and requires much code to be written.

=C2=A0 Another reason is practice.=C2=A0 I'm aware of only a few data= types which have been vendor-defined in the last twenty years.=C2=A0 One= is an "ad hoc" structure to describe firewall rules.=C2=A0 Ano= ther is a signed integer (the above RFCs explain why this is wrong).=C2=A0= A few vendors defined a 64-bit integer before the IETF did.=C2=A0 That&#= 39;s really about it.

=C2=A0 So new data types are not needed, and without IETF consensus, are = generally wrong.

=C2=A0 FWIW, IPFix has a fixed set of data types, an IANA registry, and r= equires standards action for update.=C2=A0 There is a strong overlap betw= een the data IPFix tracks, and RADIUS accounting.=C2=A0 So a fixed set of= data types works well in both places.

=C2=A0 Alan DeKok.




-- =

Best regards,
Kathleen
=
--=_MailMate_690F5F00-519E-4C31-8761-83D099A5A64C_=-- From nobody Fri Oct 28 14:33:20 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5379D12948B for ; Fri, 28 Oct 2016 14:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 o3j4PqPccDdv for ; Fri, 28 Oct 2016 14:33:17 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86335129468 for ; Fri, 28 Oct 2016 14:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1477690397; x=1478899997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gNIO63jCEyStTAN+rOXSDtOkq0ovNvCR+OHtknUzBfo=; b=T037z2/CcJOyX4TNyDI1D3OGAgVuVWHX+zMRsdt9BHAnXB7pI/M2fPU5 8w7oXwp9fyQnD81Cm83ceJ7gjVgYNJDjOk6+oIhjGJo/6uww4YQJwWky+ AWmgsgfSFN668qzmDWfzwg8hhjUAnUKokqb8xrVfdDqk/mLyppSnWDWTo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAjwxNY/4YNJK1ZAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMqAQEBAQEfWH0HjS+Wf5Q/ggcohXsCGoFqPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEBAwEdBhFFBQsCAQgYAgImAgICMBUQAgQOBRuIMQgOsW6MaAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFgQeHM4JYhBkRATMKJoI9LIIvBYhNi22FXgGGLIl6kAS?= =?us-ascii?q?ND4QAAR42X4UKcoVKgSCBCQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,560,1473120000"; d="scan'208";a="340800145" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2016 21:33:16 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9SLXGJL023153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2016 21:33:16 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 17:33:15 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 28 Oct 2016 17:33:15 -0400 From: "Brian Weis (bew)" To: Alan DeKok Thread-Topic: [radext] Meeting in Seoul - call for talking slot requests Thread-Index: AQHSLeVRIopkGtY0B0uyPfJJVeag26C6CSoAgAGktQCAAv8sgA== Date: Fri, 28 Oct 2016 21:33:15 +0000 Message-ID: <7CAB5EA2-3CBF-49DB-B7D6-B612AAFE2020@cisco.com> References: <42a9aa91-2848-c9ae-dc45-970e6610f02a@restena.lu> <062260E0-9FEE-4E36-9521-1896A39A38B8@cisco.com> <89F2AC4B-3867-4784-A830-30259D1D2261@deployingradius.com> In-Reply-To: <89F2AC4B-3867-4784-A830-30259D1D2261@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.33.103] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Meeting in Seoul - call for talking slot requests X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 21:33:19 -0000 SGkgQWxhbiwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQo+IE9uIE9jdCAyNiwg MjAxNiwgYXQgNDo0NyBQTSwgQWxhbiBEZUtvayA8YWxhbmRAZGVwbG95aW5ncmFkaXVzLmNvbT4g d3JvdGU6DQo+IA0KPiANCj4+IE9uIE9jdCAyNSwgMjAxNiwgYXQgNjo0MSBQTSwgQnJpYW4gV2Vp cyAoYmV3KSA8YmV3QGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIFN0ZWZhbiwNCj4+IA0K Pj4gSSBoYXZlIHJlY2VudGx5IHBvc3RlZCBhIG5ldyBkcmFmdCA8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdlaXMtcmFkZXh0LW11ZC0wMD4sIGFuZCBpZiBwb3NzaWJsZSBJ4oCZ ZCBhcHByZWNpYXRlIDEwIG1pbnV0ZXMgb3Igc28gb2YgdGhlIG1lZXRpbmcgdG8gaW50cm9kdWNl IGl0LiBUaGUgZHJhZnQgYWxsb3dzIFJBRElVUyB0byBoZWxwIGNvbXBsZXRlIGEgc29sdXRpb24g dXNpbmcgdGhlIE1hbnVmYWN0dXJlciBVc2FnZSBEZXNjcmlwdGlvbiAoTVVEKSBTcGVjaWZpY2F0 aW9uICg8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW11ZC0w MT4pLg0KPiANCj4gIE15ICQwLjAyLCBtb3N0bHkgbml0cy4NCj4gDQo+IC0gZGVmaW5lIHRoZSBu ZXcgYXR0cmlidXRlIGFzIG9mIHR5cGUgInN0cmluZyIsIGFuZCByZWZlcmVuY2UgdGhlIGRhdGEg dHlwZXMgZHJhZnQuICBUaGlzIGxldHMgeW91IHJlbW92ZSB0aGUgQVNDSUkgYXJ0DQoNCkkgd2Fz buKAmXQgYXdhcmUgb2YgdGhpcyBkb2N1bWVudCwgd2lsbCBsb29rIGludG8gZG9pbmcgdGhpcyBm b3IgdGhlIG5leHQgdmVyc2lvbi4gDQoNCj4gLSBwZXJoYXBzIGhhdmUgYSBkaXNjdXNzaW9uIG9m IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgTUFCIGluIFNlY3Rpb24gNS4gIEkgZG9uJ3Qg cmVjYWxsIHNlZWluZyBhIGRpc2N1c3Npb24gb2YgdGhpcyBiZWZvcmUgaW4gYSBSQURJVVMgZG9j dW1lbnQNCj4gDQo+IC0gaS5lLk1BQiByZXF1ZXN0cyByZWx5IG9uIE1BQyBhZGRyZXNzIGZyb20g dGhlIGVuZCB1c2VyIG1hY2hpbmUuLi4gd2hpY2ggY2FuIGJlIHRyaXZpYWxseSBmb3JnZWQuICBX aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIG9mIHNlbmQgdGhlIHdyb25nIE1VRCBpbmZvIHRvIGEg bWFjaGluZSB3aGljaCBpcyBseWluZyB0byB5b3U/DQoNClRoYXTigJlzIGFuIGludGVyZXN0aW5n IHBvaW50LiBJIHRvdWNoZWQgb24gYSBhIHNpbWlsYXIgaXNzdWUgaW4gdGhlIGN1cnJlbnQgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMsIGFja25vd2xlZGdpbmcgdGhhdCB0aGUgYWN0dWFsIERIQ1Ag b3IgTExEUCBtZXNzYWdlIG1pZ2h0IGhhdmUgYmVlbiByZWNlaXZlZCBvbiB0aGUgTkFTIHVucHJv dGVjdGVkLiBCdXQgSSB0YWtlIHlvdXIgcG9pbnQgdGhhdCBzaW5lIE1BQiBpcyBtZW50aW9uZWQg dGhhdCBpbXBsaWNhdGlvbnMgb2YgYSBmb3JnZWQgIE1BQyBhZGRyZXNzIGlzIHByb2JhYmx5IGlu IHNjb3BlLiBPbmUgbWl0aWdhdGlvbiB3b3VsZCBiZSB0byByZXF1aXJlIDgwMi4xWCBhbmQgb25s eSBhY2NlcHQgTVVEIFVSSXMgaW4gcGFja2V0cyBmcm9tIHdoaWNoIHRoZSBNQUMgYWRkcmVzcyhl cykgdGhhdCBoYXZlIHN0cm9uZ2x5IGF1dGhlbnRpY2F0ZWQuIFRvIGNvbXBsZXRlbHkgbWl0aWdh dGUgdGhlIGF0dGFjaywgYWRkIE1BQ3NlYyAoSUVFRSA4MDIuMUFFKSB0byB3aXJlZCBwb3J0cy4g DQoNCkluIGFueSBjYXNlLCBNVUQgaXMgbW9zdCB2YWx1YWJsZSBpbiBoZWxwaW5nIGRldmljZXMg ZW1pdHRpbmcgYSBNVUQgVVJJIHVzaW5nIGEgTUFDIGFkZHJlc3MgdGhhdCBpdCBhY3R1YWxseSBv d25zLCBiZWNhdXNlIHRoZSBOQVMgY2FuIHByb2FjdGl2ZWx5IGluc3RhbGwgcG9saWN5IHRvIHBy b3RlY3QgdGhhdCBNQUMgYWRkcmVzcyBhZ2FpbnN0IGF0dGFja3MgaW4gdGhlIGZ1dHVyZS4gSeKA mWxsIHRoaW5rIGFib3V0IHdoYXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g c2hvdWxkIHNheSBhYm91dCB0aGUgcmFtaWZpY2F0aW9ucyBvZiBhbiBldmlsIGRldmljZSBzcGVj aWZ5aW5nIGEgZmFsc2UgTUFDIGFkZHJlc3MgZ2l2ZW4gdGhhdCwgYXMgeW91IHNheSwgcGVyaGFw cyBubyBvdGhlciBSQURJVVMgZG9jdW1lbnQgaGFzIGRvbmUgdGhhdC4NCg0KPiAgQnV0IHRoZSBj b25jZXB0IGRvZXMgc2VlbSByYXRoZXIgc2ltcGxlLiAgSSB0aGluayBhIHNob3J0ICYgY2xlYXIg c3BlY2lmaWNhdGlvbiBzdWNoIGFzIHRoaXMgaXMgZ29vZC4NCg0KRXhjZWxsZW50LCB0aGFua3Mu DQpCcmlhbiANCg0KLS0gDQpCcmlhbiBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1z DQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb20NCg0K