From dromasca@avaya.com Thu Aug 4 22:22:28 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0426C21F8A51; Thu, 4 Aug 2011 22:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gset1T2Oge8; Thu, 4 Aug 2011 22:22:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB021F8A4F; Thu, 4 Aug 2011 22:22:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFN9O07GmAcF/2dsb2JhbABChEeiMXd3gUABAQEBAxIGCw0EUQYBCA0IAgMCBgYMCwECAgMBRAcBAQUEAQQBEggarH0Cik+RPIErhAsxXwSYJYtD X-IronPort-AV: E=Sophos;i="4.67,321,1309752000"; d="scan'208";a="295397196" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Aug 2011 01:22:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2011 01:19:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 5 Aug 2011 07:22:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference Thread-Index: AcxS+Km6RbnadWQnSwSsJ6TQqXwHvAANlg1Q From: "Romascanu, Dan (Dan)" To: , , , "YANG Doctors" , "IETF DNS Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the August 11, 2011 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:22:28 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgOC8xNCB0ZWxl Y2hhdC4gUGxlYXNlIHNlbmQgbWUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzIGFuZCBjb25jZXJu cyBiZWZvcmUgOC8xMyBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2ctYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFU0cgU2VjcmV0YXJ5 DQpTdWJqZWN0OiBQUkVMSU1JTkFSWSBBZ2VuZGEgYW5kIFBhY2thZ2UgZm9yIHRoZSBBdWd1c3Qg MTEsIDIwMTEgSUVTRyBUZWxlY29uZmVyZW5jZSANCg0KLi4uDQoNCjIuIFByb3RvY29sIEFjdGlv bnMNCjIuMSBXRyBTdWJtaXNzaW9ucw0KMi4xLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRm LW1wbHMtcDJtcC1sc3AtcGluZy0xNw0KICAgIERldGVjdGluZyBEYXRhIFBsYW5lIEZhaWx1cmVz IGluIFBvaW50LXRvLU11bHRpcG9pbnQgTXVsdGlwcm90b2NvbA0KICAgIExhYmVsIFN3aXRjaGlu ZyAoTVBMUykgLSBFeHRlbnNpb25zIHRvIExTUCBQaW5nIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAg ICBOb3RlOiBSb3NzIENhbGxvbiAocmNhbGxvbkBqdW5pcGVyLm5ldCkgaXMgdGhlIGRvY3VtZW50 IHNoZXBoZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtaWV0Zi1t cGxzLWxzcC1waW5nLWVuaGFuY2VkLWRzbWFwLTEwDQogICAgTWVjaGFuaXNtIGZvciBwZXJmb3Jt aW5nIExTUC1QaW5nIG92ZXIgTVBMUyB0dW5uZWxzIChQcm9wb3NlZA0KICAgIFN0YW5kYXJkKQ0K ICAgIE5vdGU6IFJvc3MgQ2FsbG9uIChyY2FsbG9uQGp1bmlwZXIubmV0KSBpcyB0aGUgZG9jdW1l bnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFN0ZXdhcnQgQnJ5YW50DQoNCiAgbyBkcmFmdC1pZXRm LWJlaGF2ZS1mdHA2NC0xMg0KICAgIEFuIEZUUCBBTEcgZm9yIElQdjYtdG8tSVB2NCB0cmFuc2xh dGlvbiAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogRGFuIFdpbmcgKGR3aW5nQGNpc2Nv LmNvbSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5n dG9uDQoNCiAgbyBkcmFmdC1pZXRmLWNjYW1wLWFzeW1tLWJ3LWJpZGlyLWxzcHMtYmlzLTAyDQog ICAgR01QTFMgQXN5bW1ldHJpYyBCYW5kd2lkdGggQmlkaXJlY3Rpb25hbCBMYWJlbCBTd2l0Y2hl ZCBQYXRocyAoTFNQcykNCiAgICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogRGVib3Jh aCBCcmluZ2VyIChkYjM1NDZAYXR0LmNvbSkgaXMgdGhlIERvY3VtZW50DQogICAgU2hlcGhlcmQu DQogICAgVG9rZW46IEFkcmlhbiBGYXJyZWwNCg0KICBvIGRyYWZ0LWlldGYtcm9sbC1vZjAtMTUN CiAgICBSUEwgT2JqZWN0aXZlIEZ1bmN0aW9uIFplcm8gKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IEpQIFZhc3NldXIgKGpwdkBjaXNjby5jb20pIGlzIHRoZSBkb2N1bWVudCBzaGVwaGVy ZC4NCiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtaWV0Zi1tcGxzLW1sZHAt cmVjdXJzLWZlYy0wNA0KICAgIFVzaW5nIE11bHRpcG9pbnQgTERQIHdoZW4gdGhlIEJhY2tib25l IGhhcyBubyBSb3V0ZSB0byB0aGUgUm9vdA0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBO b3RlOiBMb2EgQW5kZXJzc29uIChsb2FAcGkubnUpIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZC4N CiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xp dGUtcmFkaXVzLWV4dC0wNA0KICAgIFJBRElVUyBFeHRlbnNpb25zIGZvciBEdWFsLVN0YWNrIExp dGUgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6IFlvbmcgQ3VpIChjdWl5b25nQHRzaW5n aHVhLmVkdS5jbikgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBE cm9tcw0KDQogIG8gZHJhZnQtaWV0Zi1tc2VjLWdkb2ktdXBkYXRlLTA5DQogICAgVGhlIEdyb3Vw IERvbWFpbiBvZiBJbnRlcnByZXRhdGlvbiAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTog VmluY2VudCBSb2NhICh2aW5jZW50LnJvY2FAaW5yaWEuZnIpIGlzIHRoZSBzaGVwaGVyZC4NCiAg ICBUb2tlbjogU2VhbiBUdXJuZXINCg0KMi4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0K DQoyLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucw0KMi4yLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFm dC1ndXRtYW5uLWNtcy1obWFjLWVuYy0wNQ0KICAgIFVzaW5nIE1BQy1hdXRoZW50aWNhdGVkIEVu Y3J5cHRpb24gaW4gdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZQ0KICAgIFN5bnRheCAoQ01TKSAo UHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogUGV0ZXIgR3V0bWFubiAocGd1dDAwMUBjcy5h dWNrbGFuZC5hYy5ueikgaXMgdGhlIERvY3VtZW50DQogICAgU2hlcGhlcmQuDQogICAgVG9rZW46 IFNlYW4gVHVybmVyDQoNCjIuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4gRG9j dW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1pc3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWlldGYtdHN2d2ctcnN2cC1zZWN1cml0eS1ncm91cGtleWluZy0xMA0KICAgIEFwcGxp Y2FiaWxpdHkgb2YgS2V5aW5nIE1ldGhvZHMgZm9yIFJTVlAgU2VjdXJpdHkgKEluZm9ybWF0aW9u YWwpDQogICAgTm90ZTogSmFtZXMgUG9sayAoam1wb2xrQGNpc2NvLmNvbSkgaXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5ndG9uDQoNCiAgbyBkcmFmdC1p ZXRmLWRlY2FkZS1zdXJ2ZXktMDUNCiAgICBBIFN1cnZleSBvZiBJbi1uZXR3b3JrIFN0b3JhZ2Ug U3lzdGVtcyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBIYWliaW4gU29uZyAoaGFpYmluLnNv bmdAaHVhd2VpLmNvbSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZp ZCBIYXJyaW5ndG9uDQoNCiAgbyBkcmFmdC1pZXRmLW9wc2F3Zy1vYW0tb3ZlcnZpZXctMDUNCiAg ICBBbiBPdmVydmlldyBvZiBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5h bmNlIChPQU0pDQogICAgTWVjaGFuaXNtcyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBTY290 dCBCcmFkbmVyIChzb2JAaGFydmFyZC5lZHUpIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZC4NCiAg ICBUb2tlbjogUm9uIEJvbmljYQ0KDQozLjEuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoN CjMuMiBJbmRpdmlkdWFsIFN1Ym1pc3Npb25zIFZpYSBBRA0KMy4yLjEgTmV3IEl0ZW1zDQoNCiAg byBkcmFmdC1zaGlvbW90by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1pbmctMDUNCiAgICBBZHZpY2Ug b24gV2hlbiBJdCBpcyBTYWZlIHRvIFN0YXJ0IFNlbmRpbmcgRGF0YSBvbiBMYWJlbCBTd2l0Y2hl ZA0KICAgIFBhdGhzIEVzdGFibGlzaGVkIFVzaW5nIFJTVlAtVEUgKEluZm9ybWF0aW9uYWwpDQog ICAgTm90ZTogRGFuaWVsIEtpbmcgKGRhbmllbEBvbGRkb2cuY28udWspIGlzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZC4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KICBvIGRyYWZ0LWJ1cmdp bi1pcHNlYy1zdWl0ZWItcHJvZmlsZS0wMQ0KICAgIFN1aXRlIEIgUHJvZmlsZSBmb3IgSW50ZXJu ZXQgUHJvdG9jb2wgU2VjdXJpdHkgKElQc2VjKQ0KICAgIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5v dGU6IFBhdWwgSG9mZm1hbiAocGF1bC5ob2ZmbWFuQHZwbmMub3JnKSBpcyB0aGUgZG9jdW1lbnQg c2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAgbyBkcmFmdC1sYXctcmZjNDg2 OWJpcy0wMQ0KICAgIFN1aXRlIEIgQ3J5cHRvZ3JhcGhpYyBTdWl0ZXMgZm9yIElQc2VjIChJbmZv cm1hdGlvbmFsKQ0KICAgIE5vdGU6IFBhdWwgSG9mZm1hbiAocGF1bC5ob2ZmbWFuQHZwbmMub3Jn KSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAg byBkcmFmdC1mb3J0ZS1sb3N0LWV4dGVuc2lvbnMtMDcNCiAgICBMb2NhdGlvbi10by1TZXJ2aWNl IFRyYW5zbGF0aW9uIChMb1NUKSBQcm90b2NvbCBFeHRlbnNpb25zDQogICAgKEV4cGVyaW1lbnRh bCkNCiAgICBOb3RlOiBSaWNoYXJkIEJhcm5lcyAocmJhcm5lc0BiYm4uY29tKSBpcyB0aGUgZG9j dW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJvYmVydCBTcGFya3MNCg0KMy4yLjIgUmV0dXJu aW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMgSVJURiBhbmQgSW5kZXBlbmRlbnQgU3VibWlzc2lv biBTdHJlYW0gRG9jdW1lbnRzDQozLjMuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LXNpbXBzb24t aXNpcy1wcHAtdW5pcXVlLTAxDQogICAgR2VuZXJhdGlvbiBvZiBVbmlxdWUgSVMtSVMgU3lzdGVt IElkZW50aWZpZXJzIChFeHBlcmltZW50YWwpDQogICAgTm90ZTogSVNFIFN1Ym1pc3Npb24NCiAg ICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KMy4zLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9O RQ0KDQo0LiBXb3JraW5nIEdyb3VwIEFjdGlvbnMNCjQuMSBXRyBDcmVhdGlvbg0KNC4xLjEgUHJv cG9zZWQgZm9yIElFVEYgUmV2aWV3DQoNCiAgTk9ORQ0KDQo0LjEuMiBQcm9wb3NlZCBmb3IgQXBw cm92YWwNCg0KICBOT05FDQoNCjQuMiBXRyBSZWNoYXJ0ZXJpbmcNCjQuMi4xIFVuZGVyIEV2YWx1 YXRpb24gZm9yIElFVEYgUmV2aWV3DQoNCiAgbyBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKHBj ZSkNCiAgICBUb2tlbjogQWRyaWFuDQoNCiAgbyB2Q2FyZCBhbmQgQ2FyZERBViAodmNhcmRkYXYp DQogICAgVG9rZW46IFBldGVyDQoNCg0K From dromasca@avaya.com Mon Aug 8 00:35:53 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5F221F89BA for ; Mon, 8 Aug 2011 00:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUkSBRvHQbtm for ; Mon, 8 Aug 2011 00:35:52 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0746021F898E for ; Mon, 8 Aug 2011 00:35:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcHAJyRP06HCzI1/2dsb2JhbABCmDGPB3eBPAYBAQMSHgpRARUVBgwMB1cBBBsah0WdGoN+ApsphWdfBJgoi0Q X-IronPort-AV: E=Sophos;i="4.67,336,1309752000"; d="scan'208";a="261193500" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Aug 2011 03:36:04 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Aug 2011 03:28:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2011 09:35:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-softwire-dslite-radius-ext-04 Thread-Index: AcxVndEYNAIpOJxTQOCmS/mqNCRQjQ== From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 07:35:53 -0000 Hi AAA Doctors, Did any of you review this document?=20 Thanks and Regards, Dan =20 From mark@azu.ca Mon Aug 8 07:28:11 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38521F8AD9 for ; Mon, 8 Aug 2011 07:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSNkcU0whlxH for ; Mon, 8 Aug 2011 07:28:11 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 20DBA21F8AD2 for ; Mon, 8 Aug 2011 07:28:10 -0700 (PDT) Received: by iye1 with SMTP id 1so8783304iye.27 for ; Mon, 08 Aug 2011 07:28:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.130.105 with SMTP id r41mr5669648ibs.14.1312813715348; Mon, 08 Aug 2011 07:28:35 -0700 (PDT) Received: by 10.231.206.82 with HTTP; Mon, 8 Aug 2011 07:28:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Aug 2011 10:28:35 -0400 Message-ID: From: Mark Jones To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=00163692056d28dd1504a9ff4349 Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 14:28:11 -0000 --00163692056d28dd1504a9ff4349 Content-Type: text/plain; charset=ISO-8859-1 I took a quick read of the draft. I don't claim to be a softwire expert but it was not clear to me why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. Mark On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) wrote: > Hi AAA Doctors, > > Did any of you review this document? > > Thanks and Regards, > > Dan > > > > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors > --00163692056d28dd1504a9ff4349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I took a quick read of the draft. I don't claim to be a softwire expert= but it was not clear to me why the authors needed a new AVP when the RADIU= S tunnel attributes (RFC2868) could probably be reused here.

Mark

On Mon, Aug 8, 2011 at 3:35 AM,= Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
Hi AAA Doctors,

Did any of you review this document?

Thanks and Regards,

Dan




_______________________________________________
AAA-DOCTORS mailing list
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors

--00163692056d28dd1504a9ff4349-- From aland@freeradius.org Mon Aug 8 07:51:35 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6633721F8B31 for ; Mon, 8 Aug 2011 07:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDlIDTCUY26u for ; Mon, 8 Aug 2011 07:51:34 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E821F8B22 for ; Mon, 8 Aug 2011 07:51:34 -0700 (PDT) Message-ID: <4E3FF818.5070606@freeradius.org> Date: Mon, 08 Aug 2011 10:52:08 -0400 From: Alan T DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aland@freeradius.org List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 14:51:35 -0000 Romascanu, Dan (Dan) wrote: > Hi AAA Doctors, > > Did any of you review this document? I have minor nit-picks on the format. The discussion of type/length/value at the top of page 9 doesn't follow the traditional RADIUS format. It's minor, but still.. On a related note, there's been a surge of interest recently in adding DHCP attributes to RADIUS. I registered a PEC a while back to address the issue. I created a vnedor-specific dictionary for RADIUS, which is intended to carry DHCP options: https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.freedhcp The intention is that VSAs with PEC of 34673 are duplicates of the IANA allocation DHCP options. Using this would solve a few issues. The IETF standard RADIUS space would feel less pressure, as the VSAs could be used. All of the other vendors "ad hoc" ways of carrying DHCP options in RADIUS could be replaced by using this dictionary. If people think it's worth-while, I can submit an individual draft documenting this practice. It may not help for this document, but it will help for future documents. Alan DeKok. From bernard_aboba@hotmail.com Mon Aug 8 11:11:06 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F1221F86DC for ; Mon, 8 Aug 2011 11:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpDdf4uR87AC for ; Mon, 8 Aug 2011 11:11:04 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8721F8B56 for ; Mon, 8 Aug 2011 11:11:04 -0700 (PDT) Received: from BLU152-W14 ([65.55.111.73]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 11:11:14 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_80c2c2e9-9a72-4122-b7a9-102276b1c920_" X-Originating-IP: [131.107.160.34] From: Bernard Aboba To: , "dromasca@avaya.com" Date: Mon, 8 Aug 2011 11:11:13 -0700 Importance: Normal In-Reply-To: <4E3FF818.5070606@freeradius.org> References: , <4E3FF818.5070606@freeradius.org> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2011 18:11:14.0531 (UTC) FILETIME=[8F889330:01CC55F6] Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 18:11:06 -0000 --_80c2c2e9-9a72-4122-b7a9-102276b1c920_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I found a few other issues beyond those Alan mentions below. Figure 2 shows a RADIUS exchange with no NAS present=2C or user authenticat= ion occurring.=20 As noted in RFC 5080 Section 2.1.1 describes the requirements for authoriza= tion-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute=2C which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough= detail to understand whether it is compliant with RFC 5080=2C 2865 or othe= r RADIUS protocol documents. So either this is a protocol violation=2C or = the exchange described is under-specified. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server. = Either this is a typo (e.g. it should say Access-Request) or the authors ar= e making a major change to the RADIUS protocol: This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server=3B for example if the NAS is pre-configured with a default tunnel name=2C this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different AFTR tunnel name. > Date: Mon=2C 8 Aug 2011 10:52:08 -0400 > From: aland@freeradius.org > To: dromasca@avaya.com > CC: aaa-doctors@ietf.org > Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 >=20 > Romascanu=2C Dan (Dan) wrote: > > Hi AAA Doctors=2C > >=20 > > Did any of you review this document?=20 >=20 > I have minor nit-picks on the format. The discussion of > type/length/value at the top of page 9 doesn't follow the traditional > RADIUS format. It's minor=2C but still.. >=20 > On a related note=2C there's been a surge of interest recently in addin= g > DHCP attributes to RADIUS. I registered a PEC a while back to address > the issue. I created a vendor-specific dictionary for RADIUS=2C which is > intended to carry DHCP options: >=20 > https://github.com/alandekok/freeradius-server/blob/master/share/dictiona= ry.freedhcp >=20 > The intention is that VSAs with PEC of 34673 are duplicates of the > IANA allocation DHCP options. >=20 > Using this would solve a few issues. The IETF standard RADIUS space > would feel less pressure=2C as the VSAs could be used. All of the other > vendors "ad hoc" ways of carrying DHCP options in RADIUS could be > replaced by using this dictionary. >=20 > If people think it's worth-while=2C I can submit an individual draft > documenting this practice. It may not help for this document=2C but it > will help for future documents. >=20 > Alan DeKok. >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors = --_80c2c2e9-9a72-4122-b7a9-102276b1c920_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I found a few other issues beyond those Alan mentions below.

Figure = 2 shows a RADIUS exchange with no NAS present=2C or user authentication occ= urring.

As noted in RFC 5080 Section 2.1.1 describes the requiremen= ts for authorization-only Access-Requests:

  =
 Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute=2C which can then be used in
   a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request= in enough detail to understand whether it is compliant with RFC 5080=2C 28= 65 or other RADIUS protocol documents. =3B So either this is a protocol= violation=2C or the exchange described is under-specified.

Section = 4.1 describes a NAS sending an Access-Accept to a RADIUS server. =3B&nb= sp=3B Either this is a typo (e.g. it should say Access-Request) or the auth= ors are making a major change to the RADIUS protocol:

   This attribute MAY be used in Access-Accept packets as a hint t=
o the
   RADIUS server=3B for example if the NAS is pre-configured with a
   default tunnel name=2C this name MAY be inserted in the attribute.  The
   RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
   different AFTR tunnel name.







>=3B Date: Mon=2C 8 Aug 2011 1= 0:52:08 -0400
>=3B From: aland@freeradius.org
>=3B To: dromasca@a= vaya.com
>=3B CC: aaa-doctors@ietf.org
>=3B Subject: Re: [AAA-DOC= TORS] draft-ietf-softwire-dslite-radius-ext-04
>=3B
>=3B Romasca= nu=2C Dan (Dan) wrote:
>=3B >=3B Hi AAA Doctors=2C
>=3B >=3B =
>=3B >=3B Did any of you review this document?
>=3B
>= =3B I have minor nit-picks on the format. The discussion of
>=3B ty= pe/length/value at the top of page 9 doesn't follow the traditional
>= =3B RADIUS format. It's minor=2C but still..
>=3B
>=3B On a r= elated note=2C there's been a surge of interest recently in adding
>= =3B DHCP attributes to RADIUS. I registered a PEC a while back to address<= br>>=3B the issue. I created a vendor-specific dictionary for RADIUS=2C = which is
>=3B intended to carry DHCP options:
>=3B
>=3B htt= ps://github.com/alandekok/freeradius-server/blob/master/share/dictionary.fr= eedhcp
>=3B
>=3B The intention is that VSAs with PEC of 34673 = are duplicates of the
>=3B IANA allocation DHCP options.
>=3B >=3B Using this would solve a few issues. The IETF standard RADIUS sp= ace
>=3B would feel less pressure=2C as the VSAs could be used. All o= f the other
>=3B vendors "ad hoc" ways of carrying DHCP options in RAD= IUS could be
>=3B replaced by using this dictionary.
>=3B
>= =3B If people think it's worth-while=2C I can submit an individual draft<= br>>=3B documenting this practice. It may not help for this document=2C = but it
>=3B will help for future documents.
>=3B
>=3B Ala= n DeKok.
>=3B
>=3B _____________________________________________= __
>=3B AAA-DOCTORS mailing list
>=3B AAA-DOCTORS@ietf.org
>= =3B https://www.ietf.org/mailman/listinfo/aaa-doctors
=
= --_80c2c2e9-9a72-4122-b7a9-102276b1c920_-- From bernard_aboba@hotmail.com Mon Aug 8 11:20:48 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A021F8B5E for ; Mon, 8 Aug 2011 11:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggqa9-z6Wrxl for ; Mon, 8 Aug 2011 11:20:46 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id B947621F8B5C for ; Mon, 8 Aug 2011 11:20:46 -0700 (PDT) Received: from BLU152-W27 ([65.55.111.72]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 11:21:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c09f7aca-7cf9-45eb-a9e2-fb7719a5e0a0_" X-Originating-IP: [131.107.160.182] From: Bernard Aboba To: , "dromasca@avaya.com" Date: Mon, 8 Aug 2011 11:21:12 -0700 Importance: Normal In-Reply-To: References: , <4E3FF818.5070606@freeradius.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2011 18:21:13.0103 (UTC) FILETIME=[F44F69F0:01CC55F7] Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 18:20:48 -0000 --_c09f7aca-7cf9-45eb-a9e2-fb7719a5e0a0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd also note that RFC 5176 requires that session identification attributes= not be used to request authorization changes. I am not clear whether the = DSLITE-Tunnel-Name Attribute would be classified as a session identificatio= n attribute=2C but RFC 5176 does classify other IPv6-related configuration = attributes (e.g. Framed-IPv6-Prefix) as session-identification attributes = which cannot be changed by CoA-Request packets. The reasoning is that chan= ging a host's address without notifying the host is a bad idea=2C so that i= t is better to notify the host first then initiate another Access-Request/A= ccept sequence than to send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets=2C they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g.=2C within CoA-Request packets to request authorization changes). From: bernard_aboba@hotmail.com To: aland@freeradius.org=3B dromasca@avaya.com CC: aaa-doctors@ietf.org Subject: RE: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 Date: Mon=2C 8 Aug 2011 11:11:13 -0700 I found a few other issues beyond those Alan mentions below. Figure 2 shows a RADIUS exchange with no NAS present=2C or user authenticat= ion occurring.=20 As noted in RFC 5080 Section 2.1.1 describes the requirements for authoriza= tion-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute=2C which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough= detail to understand whether it is compliant with RFC 5080=2C 2865 or othe= r RADIUS protocol documents. So either this is a protocol violation=2C or = the exchange described is under-specified. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server. = Either this is a typo (e.g. it should say Access-Request) or the authors ar= e making a major change to the RADIUS protocol: This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server=3B for example if the NAS is pre-configured with a default tunnel name=2C this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different AFTR tunnel name. > Date: Mon=2C 8 Aug 2011 10:52:08 -0400 > From: aland@freeradius.org > To: dromasca@avaya.com > CC: aaa-doctors@ietf.org > Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 >=20 > Romascanu=2C Dan (Dan) wrote: > > Hi AAA Doctors=2C > >=20 > > Did any of you review this document?=20 >=20 > I have minor nit-picks on the format. The discussion of > type/length/value at the top of page 9 doesn't follow the traditional > RADIUS format. It's minor=2C but still.. >=20 > On a related note=2C there's been a surge of interest recently in addin= g > DHCP attributes to RADIUS. I registered a PEC a while back to address > the issue. I created a vendor-specific dictionary for RADIUS=2C which is > intended to carry DHCP options: >=20 > https://github.com/alandekok/freeradius-server/blob/master/share/dictiona= ry.freedhcp >=20 > The intention is that VSAs with PEC of 34673 are duplicates of the > IANA allocation DHCP options. >=20 > Using this would solve a few issues. The IETF standard RADIUS space > would feel less pressure=2C as the VSAs could be used. All of the other > vendors "ad hoc" ways of carrying DHCP options in RADIUS could be > replaced by using this dictionary. >=20 > If people think it's worth-while=2C I can submit an individual draft > documenting this practice. It may not help for this document=2C but it > will help for future documents. >=20 > Alan DeKok. >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors = --_c09f7aca-7cf9-45eb-a9e2-fb7719a5e0a0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'd also note that RFC 5176 requires that session identification attributes= not be used to request authorization changes. I am not clear whether the = DSLITE-Tunnel-Name Attribute would be classified as a session identificatio= n attribute=2C but RFC 5176 does classify other IPv6-related configuration = attributes (e.g. Framed-IPv6-Prefix) as =3B session-identification attr= ibutes which cannot be changed by CoA-Request packets. =3B The reasonin= g is that changing a host's address without notifying the host is a bad ide= a=2C so that it is better to notify the host first then initiate another Ac= cess-Request/Accept sequence than to send a CoA-Request.

   (Note 1) Where NAS or session identification attributes are=
 included
   in Disconnect-Request or CoA-Request packets=2C they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g.=2C within CoA-Request packets
   to request authorization changes).


From: bernard_aboba@hotmail.com
To: aland@freeradius.org=3B dromasc= a@avaya.com
CC: aaa-doctors@ietf.org
Subject: RE: [AAA-DOCTORS] draft= -ietf-softwire-dslite-radius-ext-04
Date: Mon=2C 8 Aug 2011 11:11:13 -07= 00

I found a few other issues beyond those Alan mentions below.

Figure = 2 shows a RADIUS exchange with no NAS present=2C or user authentication occ= urring.

As noted in RFC 5080 Section 2.1.1 describes the requiremen= ts for authorization-only Access-Requests:

   Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute=2C which can then be used in
   a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request= in enough detail to understand whether it is compliant with RFC 5080=2C 28= 65 or other RADIUS protocol documents. =3B So either this is a protocol= violation=2C or the exchange described is under-specified.

Section = 4.1 describes a NAS sending an Access-Accept to a RADIUS server. =3B&nb= sp=3B Either this is a typo (e.g. it should say Access-Request) or the auth= ors are making a major change to the RADIUS protocol:

   This attribute MAY be used in Access-Accept packets as a hin=
t to the
   RADIUS server=3B for example if the NAS is pre-configured with a
   default tunnel name=2C this name MAY be inserted in the attribute.  The
   RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
   different AFTR tunnel name.







>=3B Date: Mon=2C 8 Aug 2011 1= 0:52:08 -0400
>=3B From: aland@freeradius.org
>=3B To: dromasca@a= vaya.com
>=3B CC: aaa-doctors@ietf.org
>=3B Subject: Re: [AAA-DOC= TORS] draft-ietf-softwire-dslite-radius-ext-04
>=3B
>=3B Romasca= nu=2C Dan (Dan) wrote:
>=3B >=3B Hi AAA Doctors=2C
>=3B >=3B =
>=3B >=3B Did any of you review this document?
>=3B
>= =3B I have minor nit-picks on the format. The discussion of
>=3B ty= pe/length/value at the top of page 9 doesn't follow the traditional
>= =3B RADIUS format. It's minor=2C but still..
>=3B
>=3B On a r= elated note=2C there's been a surge of interest recently in adding
>= =3B DHCP attributes to RADIUS. I registered a PEC a while back to address<= br>>=3B the issue. I created a vendor-specific dictionary for RADIUS=2C = which is
>=3B intended to carry DHCP options:
>=3B
>=3B htt= ps://github.com/alandekok/freeradius-server/blob/master/share/dictionary.fr= eedhcp
>=3B
>=3B The intention is that VSAs with PEC of 34673 = are duplicates of the
>=3B IANA allocation DHCP options.
>=3B >=3B Using this would solve a few issues. The IETF standard RADIUS sp= ace
>=3B would feel less pressure=2C as the VSAs could be used. All o= f the other
>=3B vendors "ad hoc" ways of carrying DHCP options in RAD= IUS could be
>=3B replaced by using this dictionary.
>=3B
>= =3B If people think it's worth-while=2C I can submit an individual draft<= br>>=3B documenting this practice. It may not help for this document=2C = but it
>=3B will help for future documents.
>=3B
>=3B Ala= n DeKok.
>=3B
>=3B _____________________________________________= __
>=3B AAA-DOCTORS mailing list
>=3B AAA-DOCTORS@ietf.org
>= =3B https://www.ietf.org/mailman/listinfo/aaa-doctors
=
= --_c09f7aca-7cf9-45eb-a9e2-fb7719a5e0a0_-- From lionel.morand@orange-ftgroup.com Mon Aug 8 15:22:04 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BFA21F8BCD for ; Mon, 8 Aug 2011 15:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i6nABfQBtTv for ; Mon, 8 Aug 2011 15:21:57 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3C21F8581 for ; Mon, 8 Aug 2011 15:21:56 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D38878C0004; Tue, 9 Aug 2011 00:23:12 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id BE6AF8D0001; Tue, 9 Aug 2011 00:23:12 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 00:22:21 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC5619.A3A73DEA" Date: Tue, 9 Aug 2011 00:22:19 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 Thread-index: AcxV16ZtNKedrYlCTYahtVYh+eB/0AAQaABA References: From: To: , X-OriginalArrivalTime: 08 Aug 2011 22:22:21.0955 (UTC) FILETIME=[A46B0530:01CC5619] Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 22:22:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5619.A3A73DEA Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC5619.A3A73DEA" ------_=_NextPart_002_01CC5619.A3A73DEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I reviewed this draft last year and I had the same comment. I even = proposed an alternative based on RFC2868 but authors argued that their = approach was better... that may be true! J =20 Lionel =20 De : aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] = De la part de Mark Jones Envoy=E9 : lundi 8 ao=FBt 2011 16:29 =C0 : Romascanu, Dan (Dan) Cc : aaa-doctors@ietf.org Objet : Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 =20 I took a quick read of the draft. I don't claim to be a softwire expert = but it was not clear to me why the authors needed a new AVP when the = RADIUS tunnel attributes (RFC2868) could probably be reused here. =20 Mark On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) = wrote: Hi AAA Doctors, Did any of you review this document? Thanks and Regards, Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors =20 ------_=_NextPart_002_01CC5619.A3A73DEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I reviewed this draft last year and I had the same comment. I even = proposed an alternative based on RFC2868 but authors argued that their = approach was better… that may be true! J

 

Lionel

 

De : = aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] De = la part de Mark Jones
Envoy=E9 : lundi 8 ao=FBt 2011 = 16:29
=C0 : Romascanu, Dan (Dan)
Cc : = aaa-doctors@ietf.org
Objet : Re: [AAA-DOCTORS] = draft-ietf-softwire-dslite-radius-ext-04

 

I took a = quick read of the draft. I don't claim to be a softwire expert but it = was not clear to me why the authors needed a new AVP when the RADIUS = tunnel attributes (RFC2868) could probably be reused = here.

 

Mark

On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) = <dromasca@avaya.com> = wrote:

Hi AAA Doctors,

Did any = of you review this document?

Thanks and = Regards,

Dan




__________________________________= _____________
AAA-DOCTORS mailing list
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors

 

------_=_NextPart_002_01CC5619.A3A73DEA-- ------_=_NextPart_001_01CC5619.A3A73DEA Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MIMEOLE: Produced By Microsoft Exchange V6.5 Received: from ftrdsmtp3.rd.francetelecom.fr ([10.192.128.48]) by ftrdmel1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 14:37:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CB33D1.DB436680" Received: from omfeda08.si.francetelecom.fr ([10.98.3.82]) by ftrdsmtp3.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 14:37:53 +0200 Received: from omfeda12.si.francetelecom.fr (unknown [10.98.77.164]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2A7D7384079 for ; Wed, 4 Aug 2010 14:37:53 +0200 (CEST) Received: from omfeda12.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfeda12.si.francetelecom.fr (ESMTP service) with SMTP id 1E6733B45AC for ; Wed, 4 Aug 2010 14:37:53 +0200 (CEST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by relais-inet.francetelecom.com (ESMTP service) with ESMTPS id E550F3B45A9 for ; Wed, 4 Aug 2010 14:37:52 +0200 (CEST) Received: from grfhub705ba020.griffon.local (10.188.101.118) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 4 Aug 2010 14:37:52 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub705ba020.griffon.local ([10.188.101.118]) with mapi; Wed, 4 Aug 2010 14:37:51 +0200 Content-class: urn:content-classes:message Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext Date: Wed, 4 Aug 2010 14:37:51 +0200 Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EACF0A5AD@GRFMBX704BA020.griffon.local> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Comment on draft-maglione-softwire-dslite-radius-ext Thread-index: AcsuL0Tki2/mLVQtSPSD9tlt+eH2wgA/R5BAASlRA2A= References: From: To: , Cc: , , This is a multi-part message in MIME format. ------_=_NextPart_003_01CB33D1.DB436680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lionel, Thanks for putting together an alternative way to address this = scenario. The difference I see comparing the two methods is that in your = proposal you just have one single attribute, the Tunnel-Server-Endpoint = that can contain either the tunnel name or the tunnel address, while in our draft we wanted to keep a 1 to 1 mapping between the RADIUS = attributes and the already specified DHCPv6 options (OPTION_DS_LITE_ADDR = and OPTION_DS_LITE_NAME). For this reason we prefer having two separate = attributes one for the DSLite tunnel name (DS-Lite-Tunnel-Name) and the = other for the DSLite tunnel address (DS-Lite-Tunnel-Addr). Best regards, Roberta -----Original Message----- From: lionel.morand@orange-ftgroup.com = [mailto:lionel.morand@orange-ftgroup.com] Sent: gioved=EC 29 luglio 2010 16.57 To: radiusext@ops.ietf.org Cc: bernard_aboba@hotmail.com; Maglione Roberta; adurand@juniper.net; = stefan.winter@restena.lu Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext Here is an example of what could be the content of tyhe draft describing = the use of the Tunnel attributes for DS-Lite Tunneling. This is based on the draft published by Alain and Roberta as well as the = RFC 2868. This kind of approach would avoid having to define a new set of = attributes. Please comment the idea based on the following draft attempt! BR, Lionel *********************** Title: Use of RADIUS Tunnel Attributes for Dual-Stack Lite Abstract This document describes the use of the set of RADIUS attributes = defined in the RFC 2868 to support establishment of Dual-Stack Lite tunnel. 1. Motivation Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix (no IPv4 address is assigned to the attachment device). One of its key components is an IPv4-over- IPv6 tunnel, but a DS-Lite Basic Bridging BroadBand (B4) will not know if the network it is attached to offers Dual-Stack Lite support, and if it did, would not know the remote end of the tunnel to establish a connection. To inform the B4 of the AFTR's location, either an IPv6 address or Fully Qualified Domain Name (FQDN) may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR's location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a Softwire Initiator. The draft draft-ietf-softwire-ds-lite-tunnel-option [I-D.ietf-softwire-ds-lite-tunnel-option] specifies two DHCPv6 options which are meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. In order to be able to populate such options the DHCPv6 Server must be pre-provisioned with the Address Family Transition Router (AFTR) address or name. In Broadband environments, customer profile may be managed by AAA servers, together with user Authentication, Authorization, and Accounting (AAA). RADIUS protocol [RFC2865] is usually used by AAA Servers to communicate with network elements. [I-D.ietf-radext-ipv6-access] describes a typical broadband network scenario in which the Network Access Server (NAS) acts as the access gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6 Server function that allows it to locally handle any DHCPv6 requests issued by the clients. Since the DS-Lite AFTR information can be stored as tunneling = information in AAA servers and the client configuration is mainly provided = through DHC protocol running between the NAS and the requesting clients, this document aims at describing the use of the RADIUS tunnel attributes defined in RFC 2868 for carrying the DS-Lite tunnel information = (DS-Lite Tunnel Name and DS-Lite Tunnel Address), this information being = populated in in DHCPv6 options already specified in = [I-D.ietf-softwire-ds-lite-tunnel-option]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS- Lite Address Family Transition Router element (AFTR) are defined in [I-D.ietf-softwire-dual-stack-lite]. 3. DS-Lite Configuration with RADIUS and DHCPv6 The Figure 1 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish DS-Lite configuration on the B4 element. B4 NAS AAA | | Server | | | | | | | |-----Access Request -------->| | | | | |<----Access Accept | | | (Tunnel-Type, | | | Tunnel-Medium-Type , | | | Tunnel-Server-Endpoint) | | | | |------DHCPv6 Request----->| | | (DS-Lite tunnel Option) | | | | | |<-----DHCPv6 Reply--------| | | (DS-Lite tunnel option) | | DHCPv6 RADIUS Figure 1: RADIUS and DHCPv6 Message Flow The Network Access Server (NAS) operates as a client of RADIUS and as DHCP Server for DHC protocol. The NAS initially sends a RADIUS Access Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client and if the request is approved, the AAA server replies with an Access Accept message including a list of attributes that describe the parameters to be used for this session. This list may also contain the RADIUS Tunnel = attributes Tunnel-Type, Tunnel-Medium-Type and Tunnel-Server-Endpoint (and Tunnel-Preference if multiple tunnels information are provided). These attirbutes are used to provide the NAS with AFTR Tunnel IPv6 Address and/or the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Options, the NAS shall use the address and/or name returned in the RADIUS Tunnel-Server-Endpoint attribute to populate the DHCPv6 OPTION_DS_LITE_ADDR option in the DHCPv6 reply message. 3. Use of the RADIUS Tunnel Attributes This section describes the RADIUS attributes defined in RFC 2868 and used to provide a NAS with DS-Lite tunnel information. The use of = these attributes shall follow the recommendations given in the RFC 2868. Any other attirbutes defined in RFC 2868 SHOULD NOT be used. 3.1. Tunnel-Type The Tunnel-Type Attribute (64) [RFC 2868] SHALL be used to indicate = the type of tunnel to be used. This document defines a new value of tunnel = type to be populated in the Value field of the Tunnel-Type attribute for = DS-Lite Tunneling information. Value Name TBD1 DS-Lite Tunneling 3.2. Tunnel-Medium-Type The Tunnel-Medium-Type Attribute (65) SHALL be used to indicate IPv6 (value 2) as transport medium for DS-Lite Tunnel. 3.4. Tunnel-Server-Endpoint The Tunnel-Server-Endpoint attribute ((67) SHALL be used to provide either the FQDN of the AFTR Tunnel or a text representation of the IPv6 address in either the preferred or alternate form [17]. If the The Tunnel-Type Attribute (64) indicates the tunnet type = "DS-Lite Tunneling" (value TBD1), at least one Tunnel-Server-Endpoint = attribute MUST be provided by the RADIUS server and at least two if the IPv6 = address and the FQDN of the AFTR Tunnel are both provided. 3.8. Tunnel-Preference If more than one set of DS-Lite tunneling attributes is returned by = the RADIUS server to the NAS, this Attribute MAY be included in each set to indicate the relative preference assigned to each tunnel. 4. Table of Attributes The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Acct-Request # Attribute 0+ 0+ 0 0 0-1 64 Tunnel-Type 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 0+ 0+ 0 0 0 83 Tunnel-Preference The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 5. Security Considerations TBD. 6. IANA Considerations This document defines a new value of tunnel type to be assigned by = the IANA. Value Name TBD1 DS-Lite Tunneling 7. References ________________________________ De : MORAND Lionel RD-CORE-ISS Envoy=E9 : mercredi 28 juillet 2010 10:31 =C0 : 'radext mailing list' Objet : Comment on draft-maglione-softwire-dslite-radius-ext Following my comment during the meeting, about (re-)using an = existing attribute to convey tunnel info for DS-Lite, what about = re-using attributes defined in RFC 2868 ??? It should be straightforward to create a new type for DS-Lite. BR, Lionel Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. ------_=_NextPart_003_01CB33D1.DB436680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comment on draft-maglione-softwire-dslite-radius-ext

Hi Lionel,
    Thanks for putting together an = alternative way to address this scenario. The difference I see comparing = the two methods is that in your proposal you just have one single = attribute, the Tunnel-Server-Endpoint that can contain either the tunnel = name or the tunnel address, while

in our draft we wanted to keep a 1 to 1 mapping = between the RADIUS attributes and the already specified DHCPv6 options = (OPTION_DS_LITE_ADDR and OPTION_DS_LITE_NAME). For this reason we prefer = having two separate attributes one for the DSLite tunnel name = (DS-Lite-Tunnel-Name) and the other for the DSLite tunnel address = (DS-Lite-Tunnel-Addr).

Best regards,
Roberta

-----Original Message-----
From: lionel.morand@orange-ftgroup.com [mailto:lionel.morand@ora= nge-ftgroup.com]
Sent: gioved=EC 29 luglio 2010 16.57
To: radiusext@ops.ietf.org
Cc: bernard_aboba@hotmail.com; Maglione Roberta; = adurand@juniper.net; stefan.winter@restena.lu
Subject: RE: Comment on = draft-maglione-softwire-dslite-radius-ext

Here is an example of what could be the content of = tyhe draft describing the use of the Tunnel attributes for DS-Lite = Tunneling.

This is based on the draft published by Alain and = Roberta as well as the RFC 2868.

This kind of approach would avoid having to define a = new set of attributes.
Please comment the idea based on the following draft = attempt!

BR,

Lionel

***********************

Title: Use of RADIUS Tunnel Attributes for Dual-Stack = Lite

Abstract

   This document describes the use of the = set of RADIUS attributes defined in the RFC 2868 to support
   establishment of Dual-Stack Lite = tunnel.

1. Motivation

   Dual-Stack Lite = [I-D.ietf-softwire-dual-stack-lite] is a solution to
   offer both IPv4 and IPv6 connectivity to = customers which are
   addressed only with an IPv6 prefix (no = IPv4 address is assigned to
   the attachment device).  One of its = key components is an IPv4-over-
   IPv6 tunnel, but a DS-Lite Basic = Bridging BroadBand (B4) will not
   know if the network it is attached to = offers Dual-Stack Lite support,
   and if it did, would not know the remote = end of the tunnel to
   establish a connection.

   To inform the B4 of the AFTR's location, = either an IPv6 address or
   Fully Qualified Domain Name (FQDN) may = be used.  Once this
   information is conveyed, the presence of = the configuration indicating
   the AFTR's location also informs a host = to initiate Dual-Stack Lite
   (DS-Lite) service and become a Softwire = Initiator.

   The draft = draft-ietf-softwire-ds-lite-tunnel-option
   = [I-D.ietf-softwire-ds-lite-tunnel-option] specifies two DHCPv6
   options which are meant to be used by a = Dual-Stack Lite client (Basic
   Bridging BroadBand element, B4) to = discover its Address Family
   Transition Router (AFTR) address.  = In order to be able to populate
   such options the DHCPv6 Server must be = pre-provisioned with the
   Address Family Transition Router (AFTR) = address or name.

   In Broadband environments, customer = profile may be managed by AAA
   servers, together with user = Authentication, Authorization, and
   Accounting (AAA).  RADIUS protocol = [RFC2865] is usually used by AAA
   Servers to communicate with network = elements.
   [I-D.ietf-radext-ipv6-access] describes = a typical broadband network
   scenario in which the Network Access = Server (NAS) acts as the access
   gateway for the users (hosts or CPEs) = and the NAS embeds a DHCPv6
   Server function that allows it to = locally handle any DHCPv6 requests
   issued by the clients.

   Since the DS-Lite AFTR information can be = stored as tunneling information
   in AAA servers and the client = configuration is mainly provided through
   DHC protocol running between the NAS and = the requesting clients, this
   document aims at describing the use of = the RADIUS tunnel attributes
   defined in RFC 2868 for carrying the = DS-Lite tunnel information (DS-Lite
   Tunnel Name and DS-Lite Tunnel Address), = this information being populated in
   in DHCPv6 options already specified in = [I-D.ietf-softwire-ds-lite-tunnel-option].

2. Terminology


   The key words "MUST", = "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
   "SHOULD", "SHOULD = NOT", "RECOMMENDED", "MAY", and = "OPTIONAL" in this
   document are to be interpreted as = described in [RFC2119].

   The terms DS-Lite Basic Bridging = BroadBand element (B4) and the DS-
   Lite Address Family Transition Router = element (AFTR) are defined in
   = [I-D.ietf-softwire-dual-stack-lite].

3. DS-Lite Configuration with RADIUS and DHCPv6


   The Figure 1 illustrates how the RADIUS = protocol and DHCPv6 work
   together to accomplish DS-Lite = configuration on the B4 element.

         = B4            = ;            = NAS           &nbs= p;            = ;   AAA
         = |            =             &= nbsp; = |            =             &= nbsp; Server
         = |            =             &= nbsp; = |            =             &= nbsp;    |
         = |            =             &= nbsp; = |            =             &= nbsp;    |
         = |            =             &= nbsp; |-----Access Request -------->|
         = |            =             &= nbsp; = |            =             &= nbsp;    |
         = |            =             &= nbsp; |<----Access = Accept           = |
         = |            =             &= nbsp; |    = (Tunnel-Type,          =   |
         = |            =             &= nbsp; |     Tunnel-Medium-Type ,    = |
         = |            =             &= nbsp; |     Tunnel-Server-Endpoint) |
         = |            =             &= nbsp; = |            =             &= nbsp;    |
         = |------DHCPv6 = Request----->|         &n= bsp;           &nb= sp;       |
         = |  (DS-Lite tunnel Option) = |            =             &= nbsp;    |
         = |            =             &= nbsp; = |            =             &= nbsp;    |
         = |<-----DHCPv6 = Reply--------|          = ;            =        |
         | = (DS-Lite tunnel option)  = |            =             &= nbsp;    |

          &nbs= p;        = DHCPv6           &= nbsp;           &n= bsp; RADIUS

          &nbs= p;      Figure 1: RADIUS and DHCPv6 Message = Flow

   The Network Access Server (NAS) operates = as a client of RADIUS and as
   DHCP Server for DHC protocol.  The = NAS initially sends a RADIUS
   Access Request message to the RADIUS = server, requesting
   authentication.  Once the RADIUS = server receives the request, it
   validates the sending client and if the = request is approved, the AAA
   server replies with an Access Accept = message including a list of
   attributes that describe the parameters = to be used for
   this session.  This list may also = contain the RADIUS Tunnel attributes
   Tunnel-Type, Tunnel-Medium-Type and = Tunnel-Server-Endpoint (and
   Tunnel-Preference if multiple tunnels = information are provided).
   These attirbutes are used to provide the = NAS with AFTR Tunnel IPv6
   Address and/or the AFTR Tunnel = Name.  When the NAS receives a
   DHCPv6 client request containing the = DS-Lite tunnel Options, the NAS
   shall use the address and/or name = returned in the RADIUS
   Tunnel-Server-Endpoint attribute to = populate the
   DHCPv6 OPTION_DS_LITE_ADDR option in the = DHCPv6 reply message.


3. Use of the RADIUS Tunnel Attributes


   This section describes the RADIUS = attributes defined in RFC 2868 and
   used to provide a NAS  with DS-Lite = tunnel information. The use of these
   attributes shall follow the = recommendations given in the RFC 2868.
   Any other attirbutes defined in RFC 2868 = SHOULD NOT be used.

3.1. Tunnel-Type

   The Tunnel-Type Attribute (64) [RFC 2868] = SHALL be used to indicate the type
   of tunnel to be used. This document = defines a new value of tunnel type
   to be populated in the Value field of = the Tunnel-Type attribute for DS-Lite
   Tunneling information.

   Value   Name
   TBD1    DS-Lite = Tunneling


3.2. Tunnel-Medium-Type


   The Tunnel-Medium-Type Attribute (65) = SHALL be used to indicate IPv6
   (value 2) as transport medium for = DS-Lite Tunnel.

3.4. Tunnel-Server-Endpoint


    The Tunnel-Server-Endpoint = attribute ((67) SHALL be used to provide
    either the FQDN of the AFTR Tunnel = or a text representation of the
    IPv6 address in either the = preferred or alternate form [17].

    If the The Tunnel-Type Attribute = (64) indicates the tunnet type "DS-Lite
    Tunneling" (value TBD1), at = least one Tunnel-Server-Endpoint attribute
    MUST be provided by the RADIUS = server and at least two if the IPv6 address
    and the FQDN of the  AFTR = Tunnel are both provided.


3.8. Tunnel-Preference


   If more than one set of DS-Lite tunneling = attributes is returned by the
   RADIUS server to the NAS, this Attribute = MAY be included in each
   set to indicate the relative preference = assigned to each tunnel.


4. Table of Attributes


   The following table provides a guide to = which of the above attributes
   may be found in which kinds of packets, = and in what quantity.

Request Accept Reject Challenge Acct-Request #  = Attribute
0+      = 0+     0      = 0         = 0-1          64 = Tunnel-Type
0+      = 0+     0      = 0         = 0-1          65 = Tunnel-Medium-Type
0+      = 0+     0      = 0         = 0-1          67 = Tunnel-Server-Endpoint
0+      = 0+     0      = 0         = 0            83 = Tunnel-Preference

   The following table defines the meaning = of the above table entries.

0 This attribute MUST NOT be present in packet.

0+    Zero or more instances of this = attribute MAY be present in packet.
0-1   Zero or one instance of this = attribute MAY be present in packet.

5. Security Considerations


   TBD.

6. IANA Considerations


   This document defines a new value of = tunnel type to be assigned by the IANA.

   Value   Name
   TBD1    DS-Lite = Tunneling


7. References


























________________________________

        De : MORAND = Lionel RD-CORE-ISS
        Envoy=E9 : = mercredi 28 juillet 2010 10:31
        =C0 : = 'radext mailing list'
        Objet : = Comment on draft-maglione-softwire-dslite-radius-ext


        Following = my comment during the meeting, about (re-)using an existing attribute to = convey tunnel info for DS-Lite, what about re-using attributes defined = in RFC 2868 ???

        It should = be straightforward to create a new type for DS-Lite.

        BR,

        = Lionel


Questo messaggio e i suoi allegati sono indirizzati = esclusivamente alle persone indicate. La diffusione, copia o qualsiasi = altra azione derivante dalla conoscenza di queste informazioni sono = rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al = mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and = may contain privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, = Thanks.

------_=_NextPart_003_01CB33D1.DB436680-- ------_=_NextPart_001_01CC5619.A3A73DEA-- From dromasca@avaya.com Thu Aug 11 02:10:11 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BBE21F855D; Thu, 11 Aug 2011 02:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4delnuLys8uK; Thu, 11 Aug 2011 02:10:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD021F8634; Thu, 11 Aug 2011 02:10:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Dan Romascanu To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811090934.10012.86859.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 02:09:34 -0700 Cc: aaa-doctors@ietf.org, draft-ietf-softwire-dslite-radius-ext@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:10:11 -0000 Dan Romascanu has entered the following ballot position for draft-ietf-softwire-dslite-radius-ext-05: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The DISCUSS and COMMENT is in part based on the reviews and discussions on = the AAA-Doctors list. = 1. As noted in RFC 5080 Section 2.1.1 describes the requirements for author= ization-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks. 2. The document does not describe the contents of the Access-Request in eno= ugh detail to understand whether it is compliant with RFC 5080, 2865 or oth= er RADIUS protocol documents. So either this is a protocol violation, or t= he exchange described is under-specified. 3. RFC 5176 requires that session identification attributes not be used to = request authorization changes. I am not clear whether the DSLITE-Tunnel-Nam= e Attribute would be classified as a session identification attribute, but = RFC 5176 does classify other IPv6-related configuration attributes (e.g. Fr= amed-IPv6-Prefix) as session-identification attributes which cannot be cha= nged by CoA-Request packets. The reasoning is that changing a host's addre= ss without notifying the host is a bad idea, so that it is better to notify= the host first then initiate another Access-Request/Accept sequence than t= o send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server. = Either this is a typo (e.g. it should say Access-Request) or the authors ar= e making a major change to the RADIUS protocol: This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server; for example if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different AFTR tunnel name. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The use of kewords in section 3 seems inconsistent. Why are the 'may' an= d 'shall' in the second paragraph of the section non-capitalized, while in = the rest of the section the keywords are capitalized. = > This list may also contain the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Option, the NAS shall use the name returned in the RADIUS DS- Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 2. I support item #2 in David's DISCUSS about the need to document the oper= ational considerations of the NAS configuration and device configuration ch= anges. = 3. Two of the AAA-Doctors made in early reviews the comment that it was not= clear why the authors needed a new AVP when the RADIUS tunnel attributes (= RFC2868) could probably be reused here. One of them even proposed an altern= ative based on RFC2868 but authors argued that their approach was better=E2= =80=A6 that may be true, but it would have been good to document the decisi= on and explain why the alternative was rejected. = From dromasca@avaya.com Thu Aug 11 02:15:39 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A419621F886A; Thu, 11 Aug 2011 02:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVd9x-kvv2jF; Thu, 11 Aug 2011 02:15:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE67621F85E3; Thu, 11 Aug 2011 02:15:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Dan Romascanu To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811091538.14186.92185.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 02:15:38 -0700 Cc: aaa-doctors@ietf.org, draft-ietf-softwire-dslite-radius-ext@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:15:39 -0000 Dan Romascanu has entered the following ballot position for draft-ietf-softwire-dslite-radius-ext-05: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Slightly edited version. Please use this one. = The DISCUSS and COMMENT is in part based on the reviews and discussions on = the AAA-Doctors list. = 1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentica= tion occurring. = As noted in RFC 5080 Section 2.1.1 describes the requirements for authoriza= tion-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough= detail to understand whether it is compliant with RFC 5080, 2865 or other = RADIUS protocol documents. So either this is a protocol violation, or the = exchange described is under-specified. 2. RFC 5176 requires that session identification attributes not be used to = request authorization changes. I am not clear whether the DSLITE-Tunnel-Nam= e Attribute would be classified as a session identification attribute, but = RFC 5176 does classify other IPv6-related configuration attributes (e.g. Fr= amed-IPv6-Prefix) as session-identification attributes which cannot be cha= nged by CoA-Request packets. The reasoning is that changing a host's addre= ss without notifying the host is a bad idea, so that it is better to notify= the host first then initiate another Access-Request/Accept sequence than t= o send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). 3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.= Either this is a typo (e.g. it should say Access-Request) or the authors= are making a major change to the RADIUS protocol: This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server; for example if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different AFTR tunnel name. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The use of kewords in section 3 seems inconsistent. Why are the 'may' an= d 'shall' in the second paragraph of the section non-capitalized, while in = the rest of the section the keywords are capitalized. = > This list may also contain the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Option, the NAS shall use the name returned in the RADIUS DS- Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 2. I support item #2 in David's DISCUSS about the need to document the oper= ational considerations of the NAS configuration and device configuration ch= anges. = 3. Two of the AAA-Doctors made in early reviews the comment that it was not= clear why the authors needed a new AVP when the RADIUS tunnel attributes (= RFC2868) could probably be reused here. One of them even proposed an altern= ative based on RFC2868 but authors argued that their approach was better=E2= =80=A6 that may be true, but it would have been good to document the decisi= on and explain why the alternative was rejected. = From roberta.maglione@telecomitalia.it Thu Aug 11 05:38:38 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4728F21F85DE; Thu, 11 Aug 2011 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3+3zCZGtQi9; Thu, 11 Aug 2011 05:38:37 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id DD43721F8546; Thu, 11 Aug 2011 05:38:36 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Aug 2011 14:39:08 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 11 Aug 2011 14:39:08 +0200 From: Maglione Roberta To: 'Dan Romascanu' , The IESG Date: Thu, 11 Aug 2011 14:39:08 +0200 Thread-Topic: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) Thread-Index: AcxYB1N8oqyl/u2PRUeW2laWdI2F3wAGIB6A Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D75@GRFMBX704BA020.griffon.local> References: <20110811091538.14186.92185.idtracker@ietfa.amsl.com> In-Reply-To: <20110811091538.14186.92185.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Aug 2011 05:39:07 -0700 Cc: "aaa-doctors@ietf.org" , "draft-ietf-softwire-dslite-radius-ext@tools.ietf.org" , "softwire-chairs@tools.ietf.org" , Ullio Mario Subject: Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:38:38 -0000 Hello, Please see answers inline [RM] Thanks, Regards, Roberta -----Original Message----- From: Dan Romascanu [mailto:dromasca@avaya.com] Sent: gioved=EC 11 agosto 2011 11.16 To: The IESG Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf-softwi= re-dslite-radius-ext@tools.ietf.org Subject: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-0= 5: (with DISCUSS and COMMENT) Dan Romascanu has entered the following ballot position for draft-ietf-softwire-dslite-radius-ext-05: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Slightly edited version. Please use this one. The DISCUSS and COMMENT is in part based on the reviews and discussions on = the AAA-Doctors list. 1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentica= tion occurring. As noted in RFC 5080 Section 2.1.1 describes the requirements for authoriza= tion-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough= detail to understand whether it is compliant with RFC 5080, 2865 or other = RADIUS protocol documents. So either this is a protocol violation, or the = exchange described is under-specified. [RM] Adding the following text after figure 2 would address this comment? "In the scenario described in figure 2 the Access-Request packet contains a= Service-Type attribute with the value Authorize Only (17), thus according = to RFC 5080 the Access-Request packet MUST contain a State attribute. 2. RFC 5176 requires that session identification attributes not be used to = request authorization changes. I am not clear whether the DSLITE-Tunnel-Nam= e Attribute would be classified as a session identification attribute, but = RFC 5176 does classify other IPv6-related configuration attributes (e.g. Fr= amed-IPv6-Prefix) as session-identification attributes which cannot be cha= nged by CoA-Request packets. The reasoning is that changing a host's addre= ss without notifying the host is a bad idea, so that it is better to notify= the host first then initiate another Access-Request/Accept sequence than t= o send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). [RM] No, the DSLITE-Tunnel-Name Attribute cannot be classified as a session= identification attribute, because the same AFTR device (hence identified b= y the same DSLITE-Tunnel-Name) can be used to terminate different IPv4 ove= r IPv6 tunnels coming from different IPv6 user's sessions. The session iden= tification in this case could be an IPv6 attribute (like for example the Fr= amed-IPv6-Prefix) or the Accounting-Session-ID of the IPv6 session. 3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.= Either this is a typo (e.g. it should say Access-Request) or the authors= are making a major change to the RADIUS protocol: This attribute MAY be used in Access-Accept packets as a hint to the RADIUS server; for example if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a different AFTR tunnel name. [RM] it's a typo, sorry I have fixed it in version -05 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The use of kewords in section 3 seems inconsistent. Why are the 'may' an= d 'shall' in the second paragraph of the section non-capitalized, while in = the rest of the section the keywords are capitalized. [RM] I'm going to change them in this paragraph. > This list may also contain the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Option, the NAS shall use the name returned in the RADIUS DS- Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 2. I support item #2 in David's DISCUSS about the need to document the oper= ational considerations of the NAS configuration and device configuration ch= anges. [RM] I tried to clarify this point in one of my previous emails, please let= me know if the explanation addresses your comment. 3. Two of the AAA-Doctors made in early reviews the comment that it was not= clear why the authors needed a new AVP when the RADIUS tunnel attributes (= RFC2868) could probably be reused here. One of them even proposed an altern= ative based on RFC2868 but authors argued that their approach was better. t= hat may be true, but it would have been good to document the decision and e= xplain why the alternative was rejected. [RM] When we first presented this draft in the RADEXT WG last year, the doc= ument contained two different attributes one for the DS-Lite-Tunnel-Name an= d another for the DS-Lite-Tunnel-Address, in order to match exactly the two= different DHCPv6 options proposed for the same purpose. The idea to have a= new AVP instead of re-using the one from RFC2868 came up in order to have = a 1:1 mapping between RADIUS AVPs and DHCPv6 options. The reason behind thi= s choice was to avoid having an extra logic implemented on the NAS required= to decide in which DHCPv6 option inserting the value received from RADIUS = AVP. After a long discussion based on DHC WG feedback, the DHCPv6 option related= to AFTR address was removed from that document and only the AFTR name DHCP= v6 option was kept, thus we updated this draft according to that decision. Thanks, Regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From dromasca@avaya.com Thu Aug 11 05:57:06 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7705221F84F9; Thu, 11 Aug 2011 05:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlYLiPLNSb4d; Thu, 11 Aug 2011 05:57:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7711F21F84E7; Thu, 11 Aug 2011 05:57:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAD3RQ07GmAcF/2dsb2JhbABBl32PSXeBQAEBAQECARIeSQUHBAIBCA0EBAEBCwYMCwEGAUUJCAEBBAESCAEZh00EoEUCnCKFaF8EhzCRB4tI X-IronPort-AV: E=Sophos;i="4.67,355,1309752000"; d="scan'208";a="201346342" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Aug 2011 08:57:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Aug 2011 08:54:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2011 14:57:26 +0200 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D75@GRFMBX704BA020.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) Thread-Index: AcxYB1N8oqyl/u2PRUeW2laWdI2F3wAGIB6AAAFN6AA= References: <20110811091538.14186.92185.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D75@GRFMBX704BA020.griffon.local> From: "Romascanu, Dan (Dan)" To: "Maglione Roberta" , "The IESG" Cc: aaa-doctors@ietf.org, draft-ietf-softwire-dslite-radius-ext@tools.ietf.org, softwire-chairs@tools.ietf.org, Ullio Mario Subject: Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:57:06 -0000 Hi Roberta, Thank you for your timely answer.=20 I will address part of your answers, and I am waiting for the original = AAA Doctors reviewers to jump in for the other.=20 See in-line. I edited out the items that I will not discuss in this = mail.=20 Regards, Dan > -----Original Message----- > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > Sent: Thursday, August 11, 2011 3:39 PM > To: Romascanu, Dan (Dan); The IESG > Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf- > softwire-dslite-radius-ext@tools.ietf.org; Ullio Mario > Subject: RE: Dan Romascanu's Discuss on draft-ietf-softwire-dslite- > radius-ext-05: (with DISCUSS and COMMENT) >=20 > Hello, > Please see answers inline [RM] > Thanks, > Regards, > Roberta >=20 > -----Original Message----- > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: gioved=EC 11 agosto 2011 11.16 > To: The IESG > Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf- > softwire-dslite-radius-ext@tools.ietf.org > Subject: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius- > ext-05: (with DISCUSS and COMMENT) >=20 > Dan Romascanu has entered the following ballot position for > draft-ietf-softwire-dslite-radius-ext-05: 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 > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 ... >=20 > 3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS > server. Either this is a typo (e.g. it should say Access-Request) or > the authors are making a major change to the RADIUS protocol: > This attribute MAY be used in Access-Accept packets as a hint to = the > RADIUS server; for example if the NAS is pre-configured with a > default tunnel name, this name MAY be inserted in the attribute. > The > RADIUS server MAY ignore the hint sent by the NAS and it MAY assign > a > different AFTR tunnel name. >=20 > [RM] it's a typo, sorry I have fixed it in version -05 >=20 >=20 [[DR]] Fine. I am editing out this item.=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. The use of kewords in section 3 seems inconsistent. Why are the > 'may' and 'shall' in the second paragraph of the section non- > capitalized, while in the rest of the section the keywords are > capitalized. >=20 > [RM] I'm going to change them in this paragraph. >=20 > > This list may also contain the AFTR Tunnel Name. When > the NAS receives a DHCPv6 client request containing the DS-Lite > tunnel Option, the NAS shall use the name returned in the RADIUS = DS- > Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME > option in the DHCPv6 reply message. >=20 [[DR]] I believe that the 'shall' needs to be capitalized, so that the = editing is consistent with the rest of the section. Is there a special = reason not to use SHALL?=20 > 2. I support item #2 in David's DISCUSS about the need to document the > operational considerations of the NAS configuration and device > configuration changes. >=20 > [RM] I tried to clarify this point in one of my previous emails, = please > let me know if the explanation addresses your comment. >=20 [[DR]] Not completely. This is still a configuration change, even if = this is related to per-session/ per-users configuration/behavior. It is = not clear to me how operators would know that such change occurred on = the NAS. I will let David (holder of the DISCUSS) on this issue decide.=20 > 3. Two of the AAA-Doctors made in early reviews the comment that it = was > not clear why the authors needed a new AVP when the RADIUS tunnel > attributes (RFC2868) could probably be reused here. One of them even > proposed an alternative based on RFC2868 but authors argued that their > approach was better. that may be true, but it would have been good to > document the decision and explain why the alternative was rejected. >=20 > [RM] When we first presented this draft in the RADEXT WG last year, = the > document contained two different attributes one for the = DS-Lite-Tunnel- > Name and another for the DS-Lite-Tunnel-Address, in order to match > exactly the two different DHCPv6 options proposed for the same = purpose. > The idea to have a new AVP instead of re-using the one from RFC2868 > came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6 > options. The reason behind this choice was to avoid having an extra > logic implemented on the NAS required to decide in which DHCPv6 option > inserting the value received from RADIUS AVP. > After a long discussion based on DHC WG feedback, the DHCPv6 option > related to AFTR address was removed from that document and only the > AFTR name DHCPv6 option was kept, thus we updated this draft according > to that decision. >=20 [[DR]] Your explanation makes sense, but as I said in the comment the = reasoning ... > The idea to have a new AVP instead of re-using the one from RFC2868 > came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6 > options. The reason behind this choice was to avoid having an extra > logic implemented on the NAS required to decide in which DHCPv6 option > inserting the value received from RADIUS AVP. ... would be useful to be included in the document.=20 > Thanks, > Regards, > Roberta From dromasca@avaya.com Thu Aug 11 05:59:40 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56E121F86AE; Thu, 11 Aug 2011 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Jk8AeT-SSu; Thu, 11 Aug 2011 05:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DE121F8596; Thu, 11 Aug 2011 05:59:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Dan Romascanu To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811125940.9802.75899.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 05:59:40 -0700 Cc: aaa-doctors@ietf.org, draft-ietf-softwire-dslite-radius-ext@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:59:40 -0000 Dan Romascanu has entered the following ballot position for draft-ietf-softwire-dslite-radius-ext-05: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated DISCUSS - taking out one issue that was resolved in draft-05. = The DISCUSS and COMMENT is in part based on the reviews and discussions on = the AAA-Doctors list. = 1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentica= tion occurring. = As noted in RFC 5080 Section 2.1.1 describes the requirements for authoriza= tion-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough= detail to understand whether it is compliant with RFC 5080, 2865 or other = RADIUS protocol documents. So either this is a protocol violation, or the = exchange described is under-specified. 2. RFC 5176 requires that session identification attributes not be used to = request authorization changes. I am not clear whether the DSLITE-Tunnel-Nam= e Attribute would be classified as a session identification attribute, but = RFC 5176 does classify other IPv6-related configuration attributes (e.g. Fr= amed-IPv6-Prefix) as session-identification attributes which cannot be cha= nged by CoA-Request packets. The reasoning is that changing a host's addre= ss without notifying the host is a bad idea, so that it is better to notify= the host first then initiate another Access-Request/Accept sequence than t= o send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The use of keywords in section 3 seems inconsistent. Why are the 'may' a= nd 'shall' in the second paragraph of the section non-capitalized, while in= the rest of the section the keywords are capitalized. = > This list may also contain the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Option, the NAS shall use the name returned in the RADIUS DS- Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 2. I support item #2 in David's DISCUSS about the need to document the oper= ational considerations of the NAS configuration and device configuration ch= anges. = 3. Two of the AAA-Doctors made in early reviews the comment that it was not= clear why the authors needed a new AVP when the RADIUS tunnel attributes (= RFC2868) could probably be reused here. One of them even proposed an altern= ative based on RFC2868 but authors argued that their approach was better=E2= =80=A6 that may be true, but it would have been good to document the decisi= on and explain why the alternative was rejected. = From roberta.maglione@telecomitalia.it Wed Aug 17 03:37:16 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A945221F84DF; Wed, 17 Aug 2011 03:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j59jkZOVuDX; Wed, 17 Aug 2011 03:37:15 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5803B21F855A; Wed, 17 Aug 2011 03:37:15 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 17 Aug 2011 12:38:03 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 17 Aug 2011 12:38:03 +0200 From: Maglione Roberta To: "'Romascanu, Dan (Dan)'" , The IESG Date: Wed, 17 Aug 2011 12:38:02 +0200 Thread-Topic: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) Thread-Index: AcxYB1N8oqyl/u2PRUeW2laWdI2F3wAGIB6AAAFN6AABKRHIcA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D7E@GRFMBX704BA020.griffon.local> References: <20110811091538.14186.92185.idtracker@ietfa.amsl.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D75@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Aug 2011 03:38:19 -0700 Cc: "aaa-doctors@ietf.org" , "draft-ietf-softwire-dslite-radius-ext@tools.ietf.org" , "softwire-chairs@tools.ietf.org" , Ullio Mario Subject: Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 10:37:16 -0000 Hi Dan, I did not receive any answer from AAA Doctors, I'm waiting for their fee= dback before updating the document and submitting the new version. Best regards, Roberta -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: gioved=EC 11 agosto 2011 14.57 To: Maglione Roberta; The IESG Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf-softwi= re-dslite-radius-ext@tools.ietf.org; Ullio Mario Subject: RE: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-e= xt-05: (with DISCUSS and COMMENT) Hi Roberta, Thank you for your timely answer. I will address part of your answers, and I am waiting for the original AAA = Doctors reviewers to jump in for the other. See in-line. I edited out the items that I will not discuss in this mail. Regards, Dan > -----Original Message----- > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > Sent: Thursday, August 11, 2011 3:39 PM > To: Romascanu, Dan (Dan); The IESG > Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf- > softwire-dslite-radius-ext@tools.ietf.org; Ullio Mario > Subject: RE: Dan Romascanu's Discuss on draft-ietf-softwire-dslite- > radius-ext-05: (with DISCUSS and COMMENT) > > Hello, > Please see answers inline [RM] > Thanks, > Regards, > Roberta > > -----Original Message----- > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: gioved=EC 11 agosto 2011 11.16 > To: The IESG > Cc: aaa-doctors@ietf.org; softwire-chairs@tools.ietf.org; draft-ietf- > softwire-dslite-radius-ext@tools.ietf.org > Subject: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius- > ext-05: (with DISCUSS and COMMENT) > > Dan Romascanu has entered the following ballot position for > draft-ietf-softwire-dslite-radius-ext-05: 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 http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > ... > > 3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS > server. Either this is a typo (e.g. it should say Access-Request) or > the authors are making a major change to the RADIUS protocol: > This attribute MAY be used in Access-Accept packets as a hint to the > RADIUS server; for example if the NAS is pre-configured with a > default tunnel name, this name MAY be inserted in the attribute. > The > RADIUS server MAY ignore the hint sent by the NAS and it MAY assign > a > different AFTR tunnel name. > > [RM] it's a typo, sorry I have fixed it in version -05 > > [[DR]] Fine. I am editing out this item. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. The use of kewords in section 3 seems inconsistent. Why are the > 'may' and 'shall' in the second paragraph of the section non- > capitalized, while in the rest of the section the keywords are > capitalized. > > [RM] I'm going to change them in this paragraph. > > > This list may also contain the AFTR Tunnel Name. When > the NAS receives a DHCPv6 client request containing the DS-Lite > tunnel Option, the NAS shall use the name returned in the RADIUS DS- > Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME > option in the DHCPv6 reply message. > [[DR]] I believe that the 'shall' needs to be capitalized, so that the edit= ing is consistent with the rest of the section. Is there a special reason n= ot to use SHALL? [RM] I'll change it to capitalized. > 2. I support item #2 in David's DISCUSS about the need to document the > operational considerations of the NAS configuration and device > configuration changes. > > [RM] I tried to clarify this point in one of my previous emails, please > let me know if the explanation addresses your comment. > [[DR]] Not completely. This is still a configuration change, even if this = is related to per-session/ per-users configuration/behavior. It is not clea= r to me how operators would know that such change occurred on the NAS. I wi= ll let David (holder of the DISCUSS) on this issue decide. > 3. Two of the AAA-Doctors made in early reviews the comment that it was > not clear why the authors needed a new AVP when the RADIUS tunnel > attributes (RFC2868) could probably be reused here. One of them even > proposed an alternative based on RFC2868 but authors argued that their > approach was better. that may be true, but it would have been good to > document the decision and explain why the alternative was rejected. > > [RM] When we first presented this draft in the RADEXT WG last year, the > document contained two different attributes one for the DS-Lite-Tunnel- > Name and another for the DS-Lite-Tunnel-Address, in order to match > exactly the two different DHCPv6 options proposed for the same purpose. > The idea to have a new AVP instead of re-using the one from RFC2868 > came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6 > options. The reason behind this choice was to avoid having an extra > logic implemented on the NAS required to decide in which DHCPv6 option > inserting the value received from RADIUS AVP. > After a long discussion based on DHC WG feedback, the DHCPv6 option > related to AFTR address was removed from that document and only the > AFTR name DHCPv6 option was kept, thus we updated this draft according > to that decision. > [[DR]] Your explanation makes sense, but as I said in the comment the reaso= ning ... > The idea to have a new AVP instead of re-using the one from RFC2868 > came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6 > options. The reason behind this choice was to avoid having an extra > logic implemented on the NAS required to decide in which DHCPv6 option > inserting the value received from RADIUS AVP. ... would be useful to be included in the document. > Thanks, > Regards, > Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From dromasca@avaya.com Fri Aug 19 00:48:32 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAA21F8581; Fri, 19 Aug 2011 00:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryTxdndqtjPl; Fri, 19 Aug 2011 00:48:31 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8621F8574; Fri, 19 Aug 2011 00:48:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAJwUTk7GmAcF/2dsb2JhbABBhEuXRIpzdneBQAEBAQEDEhENBFEGAQYCDQgFAgYGDAsBAgIDAR8lBwEGBAEEARIIGqRdAopQkUeBLIQMMV8EmD2ETIcB X-IronPort-AV: E=Sophos;i="4.68,250,1312171200"; d="scan'208";a="298383456" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Aug 2011 03:49:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Aug 2011 03:45:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Aug 2011 09:49:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference Thread-Index: Acxd8+oZjGs6sf3ESV2HUb+wglzX6gAUEMog From: "Romascanu, Dan (Dan)" To: , , "IETF DNS Directorate" , , "YANG Doctors" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 07:48:32 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgOC8yNSBJRVNH IHRlbGVjaGF0LiBQbGVhc2Ugc2VuZCBtZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNv bmNlcm5zIHJlbGF0ZWQgdG8gdGhlIGRvY3VtZW50cyBhbmQgV0cgY2hhcnRlcnMgb24gdGhlIGFn ZW5kYSBiZWZvcmUgOC8yNCBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVTRyBTZWNy ZXRhcnkNCg0KDQoNCjIuIFByb3RvY29sIEFjdGlvbnMNCjIuMSBXRyBTdWJtaXNzaW9ucw0KMi4x LjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXB3ZTMtZmF0LXB3LTA3DQogICAgRmxvdyBB d2FyZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMgb3ZlciBhbiBNUExTIFBhY2tldCBTd2l0Y2hl ZA0KICAgIE5ldHdvcmsgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6IE1hdHRoZXcgQm9j Y2kgKG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tKSBpcyB0aGUNCiAgICBkb2N1bWVu dCBzaGVwaGVyZA0KICAgIFRva2VuOiBBZHJpYW4gRmFycmVsDQoNCiAgbyBkcmFmdC1pZXRmLXNp ZHItcmVzY2VydHMtcHJvdmlzaW9uaW5nLTEwDQogICAgQSBQcm90b2NvbCBmb3IgUHJvdmlzaW9u aW5nIFJlc291cmNlIENlcnRpZmljYXRlcyAoUHJvcG9zZWQNCiAgICBTdGFuZGFyZCkNCiAgICBO b3RlOiBTYW5kcmEgTXVycGh5IChTYW5kcmEuTXVycGh5QHNwYXJ0YS5jb20pIGlzIHRoZSBkb2N1 bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJh ZnQtaWV0Zi1tcGxzLXJzdnAtdGUtbm8tcGhwLW9vYi1tYXBwaW5nLTA5DQogICAgTm9uIFBlbnVs dGltYXRlIEhvcCBQb3BwaW5nIEJlaGF2aW9yIGFuZCBvdXQtb2YtYmFuZCBtYXBwaW5nIGZvcg0K ICAgIFJTVlAtVEUgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IE1hcnRpbiBWaWdvdXJldXggKG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQu Y29tKSBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogQWRyaWFuIEZh cnJlbA0KDQogIG8gZHJhZnQtaWV0Zi15YW0tcmZjNDQwOWJpcy0wMg0KICAgIE1lc3NhZ2UgU3Vi bWlzc2lvbiBmb3IgTWFpbCAoU3RhbmRhcmQpDQogICAgTm90ZTogUyBNb29uZXNhbXkgKHNtK2ll dGZAZWxhbmRzeXMuY29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFBl dGUgUmVzbmljaw0KDQogIG8gZHJhZnQtaWV0Zi1waW0taGVsbG8taW50aWQtMDENCiAgICBBbiBJ bnRlcmZhY2UgSUQgSGVsbG8gT3B0aW9uIGZvciBQSU0gKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAg IE5vdGU6IE1pa2UgTWNCcmlkZSAobW1jYnJpZGVAY2lzY28uY29tKSBpcyB0aGUgZG9jdW1lbnQg c2hlcGhlcmQuDQogICAgVG9rZW46IEFkcmlhbiBGYXJyZWwNCg0KICBvIGRyYWZ0LWlldGYtbXBs cy10cC1vbi1kZW1hbmQtY3YtMDYNCiAgICBNUExTIE9uLWRlbWFuZCBDb25uZWN0aXZpdHkgVmVy aWZpY2F0aW9uIGFuZCBSb3V0ZSBUcmFjaW5nIChQcm9wb3NlZA0KICAgIFN0YW5kYXJkKQ0KICAg IE5vdGU6IExvYSBBbmRlcnNzb24gKGxvYUBwaS5udSkgaXMgdGhlIERvY3VtZW50IFNoZXBoZXJk Lg0KICAgIFRva2VuOiBBZHJpYW4gRmFycmVsDQoNCiAgbyBkcmFmdC1pZXRmLWtyYi13Zy1jbGVh ci10ZXh0LWNyZWQtMDINCiAgICBUaGUgVW5lbmNyeXB0ZWQgRm9ybSBPZiBLZXJiZXJvcyA1IEtS Qi1DUkVEIE1lc3NhZ2UgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogU2FtIEhh cnRtYW4gKGhhcnRtYW5zLWlldGZAbWl0LmVkdSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0K ICAgIFRva2VuOiBTdGVwaGVuIEZhcnJlbGwNCg0KMi4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAg byBkcmFmdC1pZXRmLWdyb3ctZ2VvbXJ0LTA1DQogICAgTXVsdGktdGhyZWFkZWQgUm91dGluZyBU b29sa2l0IChNUlQpIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1ApDQogICAgcm91dGluZyBp bmZvcm1hdGlvbiBleHBvcnQgZm9ybWF0IHdpdGggZ2VvLWxvY2F0aW9uIGV4dGVuc2lvbnMNCiAg ICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogQ2hyaXN0b3BoZXIgTW9ycm93IChjaHJp c3RvcGhlci5tb3Jyb3dAZ21haWwuY29tKSBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4N CiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQoyLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucw0KMi4y LjEgTmV3IEl0ZW1zDQoNCiAgTk9ORQ0KDQoyLjIuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05F DQoNCjMuIERvY3VtZW50IEFjdGlvbnMNCjMuMSBXRyBTdWJtaXNzaW9ucw0KMy4xLjEgTmV3IEl0 ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXY2b3BzLTNncHAtZXBzLTAzDQogICAgSVB2NiBpbiAzR1BQ IEV2b2x2ZWQgUGFja2V0IFN5c3RlbSAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBKb2VsIEph ZWdnbGkgKGpvZWxqYUBib2d1cy5jb20pLCB2Nm9wcyBjby1jaGFpciBpcyB0aGUNCiAgICBkb2N1 bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQogIG8gZHJhZnQtaWV0Zi1k YW5lLXVzZS1jYXNlcy0wNQ0KICAgIFVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIGZvciBETlMt YmFzZWQgQXV0aGVudGljYXRpb24gb2YgTmFtZWQNCiAgICBFbnRpdGllcyAoREFORSkgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogT25kP2VqIFN1csOvwr/CvSAob25kcmVqLnN1cnlAbmljLmN6 KSBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuDQogICAgVG9rZW46IFN0ZXBoZW4gRmFycmVsbA0K DQozLjEuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtYm13Zy1pZ3AtZGF0YXBs YW5lLWNvbnYtbWV0aC0yMw0KICAgIEJlbmNobWFya2luZyBNZXRob2RvbG9neSBmb3IgTGluay1T dGF0ZSBJR1AgRGF0YSBQbGFuZSBSb3V0ZQ0KICAgIENvbnZlcmdlbmNlIChJbmZvcm1hdGlvbmFs KQ0KICAgIE5vdGU6IEFsIE1vcnRvbiAoYWNtb3J0b25AYXR0LmNvbSkgaXMgdGhlIHNoZXBoZXJk Lg0KICAgIFRva2VuOiBSb24gQm9uaWNhDQoNCiAgbyBkcmFmdC1pZXRmLWJtd2ctaWdwLWRhdGFw bGFuZS1jb252LXRlcm0tMjMNCiAgICBUZXJtaW5vbG9neSBmb3IgQmVuY2htYXJraW5nIExpbmst U3RhdGUgSUdQIERhdGEgUGxhbmUgUm91dGUNCiAgICBDb252ZXJnZW5jZSAoSW5mb3JtYXRpb25h bCkNCiAgICBOb3RlOiBBbCBNb3J0b24gKGFjbW9ydG9uQGF0dC5jb20pIGlzIHRoZSBzaGVwaGVy ZC4NCiAgICBUb2tlbjogUm9uIEJvbmljYQ0KDQozLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucyBW aWEgQUQNCjMuMi4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtZG9yaWEtZ2VuYXJ0LWV4cGVyaWVu Y2UtMDQNCiAgICBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIEV4cGVyaWVuY2Vz IChJbmZvcm1hdGlvbmFsKQ0KICAgIFRva2VuOiBSdXNzIEhvdXNsZXkNCg0KICBvIGRyYWZ0LXll dnN0aWZleWV2LWlvbi1yZXBvcnQtMDcNCiAgICBNb3ZpbmcgUkZDIDQ2OTMgdG8gSGlzdG9yaWMg KEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46IFJ1c3MgSG91c2xleQ0KDQozLjIuMiBSZXR1cm5p bmcgSXRlbXMNCg0KICBOT05FDQoNCjMuMyBJUlRGIGFuZCBJbmRlcGVuZGVudCBTdWJtaXNzaW9u IFN0cmVhbSBEb2N1bWVudHMNCjMuMy4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtYm91Y2FkYWly LXBwcGV4dC1wb3J0cmFuZ2Utb3B0aW9uLTA2DQogICAgSHVhd2VpIFBvcnQgUmFuZ2UgQ29uZmln dXJhdGlvbiBPcHRpb25zIGZvciBQUFAgSVBDUCAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBJ U0UgU3VibWlzc2lvbg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCjMuMy4yIFJldHVybmluZyBJ dGVtcw0KDQogIE5PTkUNCg0KMy4zLjMgRm9yIEFjdGlvbg0KDQogIG8gZHJhZnQtd2VlYi1yZXNl YXJjaC10by1pbnRlcm5ldC1zdGRzLTAyDQogICAgSG93IHRvIENvbnRyaWJ1dGUgUmVzZWFyY2gg UmVzdWx0cyB0byBJbnRlcm5ldCBTdGFuZGFyZGl6YXRpb24NCiAgICAoSW5mb3JtYXRpb25hbCkN CiAgICBOb3RlOiBJU0UgU3VibWlzc2lvbg0KICAgIFRva2VuOiBSdXNzIEhvdXNsZXkNCg0KNC4g V29ya2luZyBHcm91cCBBY3Rpb25zDQo0LjEgV0cgQ3JlYXRpb24NCjQuMS4xIFByb3Bvc2VkIGZv ciBJRVRGIFJldmlldw0KDQogIG8gSmF2YXNjcmlwdCBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlw dGlvbiAoam9zZSkNCiAgICBUb2tlbjogU2Vhbg0KDQo0LjEuMiBQcm9wb3NlZCBmb3IgQXBwcm92 YWwNCg0KICBOT05FDQoNCjQuMiBXRyBSZWNoYXJ0ZXJpbmcNCjQuMi4xIFVuZGVyIEV2YWx1YXRp b24gZm9yIElFVEYgUmV2aWV3DQoNCiAgbyBMYXllciAyIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3Jr cyAobDJ2cG4pDQogICAgVG9rZW46IFN0ZXdhcnQNCg0KICBvIFNUT1JhZ2UgTWFpbnRlbmFuY2Ug KHN0b3JtKQ0KICAgIFRva2VuOiBEYXZpZA0KDQoNCg== From dromasca@avaya.com Wed Aug 31 01:23:10 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473821F8AF1; Wed, 31 Aug 2011 01:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW+zB+FNKy-f; Wed, 31 Aug 2011 01:23:10 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFEC21F8B09; Wed, 31 Aug 2011 01:23:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAHvvXU7GmAcF/2dsb2JhbABCmF2PbXeBOQcBAQEBAwEBAQ8eCi0HFwYBCA0EBAEBCwIEDAsBByYfBwEBBQQBBAESCAEZh1SZcwKcVIV1YASYUYtb X-IronPort-AV: E=Sophos;i="4.68,306,1312171200"; d="scan'208";a="204918666" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Aug 2011 04:24:31 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Aug 2011 04:20:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 10:24:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Javascript Object Signing and Encryption(jose) Thread-Index: AcxnMjrwaMVff4mKSfaUrnzkye64dwAhQiBQ From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [AAA-DOCTORS] FW: [new-work] WG Review: Javascript Object Signing and Encryption(jose) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:10 -0000 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, August 30, 2011 7:30 PM To: new-work@ietf.org Subject: [new-work] WG Review: Javascript Object Signing and Encryption(jose) A new IETF working group has been proposed in the Security Area. The=20 IESG has not made any determination as yet. The following draft charter=20 was submitted, and is provided for informational purposes only. Please=20 send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,=20 September 6, 2011 =20 Javascript Object Signing and Encryption (jose) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Status: Proposed Working Group Last updated: 2011-08-18 Chairs TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: jose@ietf.org To Subscribe: Archive: Description of Working Group ---------------------------- Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used=20 for serializing and transmitting structured data over a network=20 connection. With the increased usage of JSON in protocols in the IETF=20 and elsewhere, there is now a desire to offer security services such as=20 encryption, digital signatures, and message authentication codes (MACs)=20 for data that is being carried in JSON format. Different proposals for providing such security services have already=20 been defined and implemented. This Working Group's task is to=20 standardize two security services, integrity protection (signature and=20 MAC) and encryption, in order to increase interoperability of security=20 features between protocols that use JSON. The Working Group will base=20 its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that=20 the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured=20 integrity protection to data, including (but not limited to) JSON data=20 structures. "Integrity protection" includes public-key digital=20 signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured=20 encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as=20 JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement=20 algorithms for the other three documents. The working group may decide to address one or more of these goals in a=20 single document, in which case the concrete milestones for=20 signing/encryption below will both be satisfied by the single document. Goals and Milestones -------------------- Jan 2012 Submit JSON object integrity document as a WG item. Jan 2012 Submit JSON object encryption document as a WG item. Jan 2012 Submit JSON key format document as a WG item. Jan 2012 Submit JSON algorithm document as a WG item. Jun 2012 Start Working Group Last Call on JSON object integrity=20 document. Jun 2012 Start Working Group Last Call on JSON object encryption=20 document. Jun 2012 Start Working Group Last Call on JSON key format document. Jun 2012 Start Working Group Last Call on JSON algorithm document. Jul 2012 Submit JSON object integrity document to IESG for=20 consideration as Standards Track document. Jul 2012 Submit JSON object encryption document to IESG for=20 consideration as Standards Track document. Jul 2012 Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 Submit JSON algorithm document to IESG for consideration as Standards Track document. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dromasca@avaya.com Wed Aug 31 01:23:55 2011 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95F921F8B2B; Wed, 31 Aug 2011 01:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sop+xYWDtKO; Wed, 31 Aug 2011 01:23:55 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA28421F8B1C; Wed, 31 Aug 2011 01:23:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAHvvXU6HCzI1/2dsb2JhbAA4Cphdj213gUABAQEBAwEBAQ8eCjQXBgEIDQQBAwEBCwIEDAsBByYfAwQBAQUEAQQBEggBEgeHVJlzApxUgzCCRWAEmFGLWw X-IronPort-AV: E=Sophos;i="4.68,306,1312171200"; d="scan'208";a="300823327" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Aug 2011 04:25:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Aug 2011 04:16:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 10:25:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) Thread-Index: AcxnM125mid25wOTQ+emQJ3+knEbugAhBpAw From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , , "YANG Doctors" Subject: [AAA-DOCTORS] FW: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:56 -0000 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, August 30, 2011 7:37 PM To: new-work@ietf.org Subject: [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks(l2vpn) A modified charter has been submitted for the Layer 2 Virtual Private=20 Networks (l2vpn) working group in the Routing Area of the IETF. The=20 IESG has not made any determination as yet. The modified charter is=20 provided below for informational purposes only. Please send your=20 comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September=20 6, 2011. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Last updated: 2011-08-30 Current Status: Active Chairs: Nabil Bitar Giles Heron Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive:=20 http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements=20 driven by cloud computing services and data centers as they apply to=20 Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across a PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but=20 also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires.=20 Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN within the scope of the L2VPN Working Group. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multi-pathing between PEs interconnecting a Layer-2 service using an L2VPN across the PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/ active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RFC Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Oct 2011 Submit IP-only L2VPN solution documents to IESG Nov 2011 Submit OAM solutions for VPWS to IESG Nov 2011 Submit OAM solutions for VPLS to IESG Nov 2011 Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 Submit MIB for VPLS to IESG Nov 2011 Submit MIB for VPWS to IESG Mar 2012 Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit E-Tree requirements/framework to IESG Jul 2012 Submit MIB for IP-only L2VPN to IESG Jul 2012 Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 Submit Auto-Discovery solution for VPMS to IESG Jul 2012 Submit VPLS service convergence improvement solutions to IESG Jul 2012 Submit VPLS multi-homing solutions to IESG Jul 2012 Submit E-Tree solution to IESG Jul 2012 Submit E-VPN requirements/framework to IESG Nov 2012 Submit E-Tree OAM to IESG Dec 2012 Submit E-Tree MIB to IESG Nov 2012 Submit E-VPN solution to IESG Mar 2013 Submit E-VPN OAM to IESG Apr 2013 Submit E-VPN MIB to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work