From dromasca@avaya.com Thu Feb 2 09:33:12 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B235721F8548 for ; Thu, 2 Feb 2012 09:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=-0.289, 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 VSMWM78K3VuX for ; Thu, 2 Feb 2012 09:33:11 -0800 (PST) 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 4A14221F84D0 for ; Thu, 2 Feb 2012 09:33:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALvHKk/GmAcF/2dsb2JhbABDrwuBBYF0AQEDEh4KPxIBFRUGDAwHVwEEGxqkH5t5i1AsBgFEAQIBgx4BgQYlBIJMYwSbHIxd X-IronPort-AV: E=Sophos;i="4.71,610,1320642000"; d="scan'208";a="229844753" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Feb 2012 12:33:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2012 12:27:33 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Feb 2012 18:33:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-radext-radsec-11 Thread-Index: Aczh0LoqRmZ84bHnQ7+UI8VG3dFzdA== From: "Romascanu, Dan (Dan)" To: "Stefan Winter" Cc: radext@ietf.org Subject: [radext] draft-ietf-radext-radsec-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 17:33:12 -0000 The IESG discussed draft-ietf-radext-radsec-11 in the telechat today and decided that a revised version is necessary to address the issues raised in DISCUSSes and COMMENTs by the ADs. Stefan, please publish the revised I-D that you are preparing whenever you believe it is ready.=20 Thanks and Regards, Dan From radext-bounces@ietf.org Thu Feb 2 09:33:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248421F8548; Thu, 2 Feb 2012 09:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328203994; bh=iEAYtAwzt8926/bcaWiRlxFpmdyRBJXlf8o8S4mZKhQ=; h=MIME-Version:Date:Message-ID:From:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=czfo818/N8RH+5rWirQyJY5CmLSYsAX3cfVyBHxFjJ7EpgYIdiVu2nc4FdHeFRNMv zIk8o9lOmbx4L86PuvfinQz/ddWzIgMFh8mXhliDhBm4sDwHBXiYpOWj1WkGtmSHZm XVuDZgpgRdV5NNNtYxyi6tIv+9FtQtTzfofgXnqk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B235721F8548 for ; Thu, 2 Feb 2012 09:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=-0.289, 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 VSMWM78K3VuX for ; Thu, 2 Feb 2012 09:33:11 -0800 (PST) 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 4A14221F84D0 for ; Thu, 2 Feb 2012 09:33:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALvHKk/GmAcF/2dsb2JhbABDrwuBBYF0AQEDEh4KPxIBFRUGDAwHVwEEGxqkH5t5i1AsBgFEAQIBgx4BgQYlBIJMYwSbHIxd X-IronPort-AV: E=Sophos;i="4.71,610,1320642000"; d="scan'208";a="229844753" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Feb 2012 12:33:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2012 12:27:33 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Feb 2012 18:33:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-radext-radsec-11 Thread-Index: Aczh0LoqRmZ84bHnQ7+UI8VG3dFzdA== From: "Romascanu, Dan (Dan)" To: "Stefan Winter" Cc: radext@ietf.org Subject: [radext] draft-ietf-radext-radsec-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org The IESG discussed draft-ietf-radext-radsec-11 in the telechat today and decided that a revised version is necessary to address the issues raised in DISCUSSes and COMMENTs by the ADs. Stefan, please publish the revised I-D that you are preparing whenever you believe it is ready. Thanks and Regards, Dan _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wwwrun@rfc-editor.org Fri Feb 3 01:57:02 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F256021F863E for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, NO_RELAYS=-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 aTA+PVZFuKpv for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7382D21F8625 for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 78CE8B1E002; Fri, 3 Feb 2012 01:53:00 -0800 (PST) To: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com, dromasca@avaya.com, rbonica@juniper.net, jouni.korhonen@nsn.com, mauricio.sanchez@hp.com From: RFC Errata System Message-Id: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Fri, 3 Feb 2012 01:53:00 -0800 (PST) X-Mailman-Approved-At: Fri, 03 Feb 2012 02:41:42 -0800 Cc: davide.magistri@gmail.com, rfc-editor@rfc-editor.org, radext@ietf.org Subject: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 09:57:02 -0000 The following errata report has been submitted for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=3103 -------------------------------------- Type: Technical Reported by: Davide Magistri Section: 7 Original Text ------------- Disconnect Request with User-Name: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Disconnect Request with Framed-IP-Address: 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 32: 0a00 0203 Corrected Text -------------- Disconnect Request with User-Name: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Notes ----- Since cardinality notation value for Framed-IP-Address attribute has now been changed in section 3.6 ("Table of Attributes") compared to previous 3576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-IP-Address" example in section 7 ("Example traces") should be removed. Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should be foreseen (just like the one related to Service-Type Attribute), such as: o Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix Attributes within a Disconnect-Request is prohibited Broadly speaking, one thing that seems to me a bit unclear is that Attributes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix are still valid session identifiers that could be present in CoA Requests, while they have been totally prohibited in Disconnect Requests ( even if they are mentioned as valid in section 3, end of page #10 ). >From my point of view, either it's misplaced the example in section 7 or cardinality notation values in Disconnect Message Table of Attributes (related to the ones mentioned above) should be changed back to "0-1" (I personally think this last option would be better). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From radext-bounces@ietf.org Fri Feb 3 02:41:43 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECD021F865F; Fri, 3 Feb 2012 02:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328265703; bh=DONxtSQqrPebJ90/3JaH4f413QWxEqkADVmHLSJm01g=; h=To:From:Message-Id:Date:Cc:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=tedcbUCxUp53Vvw8UbO5/5ohex4zqtcWb6B+JKzdzsfORNJmdlGd+Okr+lkwjxH+I 25hUXAIQRFsfQn2KUStZMeZVdo39g8TBAZzbmX5ox0VkQhQqihrYF1tLbLVhK1e0xr crjkNhmG1ZvEFeseNmLqKJqfcGbGmgNbND7zLBf4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F256021F863E for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, NO_RELAYS=-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 aTA+PVZFuKpv for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7382D21F8625 for ; Fri, 3 Feb 2012 01:57:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 78CE8B1E002; Fri, 3 Feb 2012 01:53:00 -0800 (PST) To: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com, dromasca@avaya.com, rbonica@juniper.net, jouni.korhonen@nsn.com, mauricio.sanchez@hp.com From: RFC Errata System Message-Id: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Fri, 3 Feb 2012 01:53:00 -0800 (PST) X-Mailman-Approved-At: Fri, 03 Feb 2012 02:41:42 -0800 Cc: davide.magistri@gmail.com, rfc-editor@rfc-editor.org, radext@ietf.org Subject: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org The following errata report has been submitted for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=3103 -------------------------------------- Type: Technical Reported by: Davide Magistri Section: 7 Original Text ------------- Disconnect Request with User-Name: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Disconnect Request with Framed-IP-Address: 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 32: 0a00 0203 Corrected Text -------------- Disconnect Request with User-Name: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Notes ----- Since cardinality notation value for Framed-IP-Address attribute has now been changed in section 3.6 ("Table of Attributes") compared to previous 3576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-IP-Address" example in section 7 ("Example traces") should be removed. Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should be foreseen (just like the one related to Service-Type Attribute), such as: o Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix Attributes within a Disconnect-Request is prohibited Broadly speaking, one thing that seems to me a bit unclear is that Attributes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix are still valid session identifiers that could be present in CoA Requests, while they have been totally prohibited in Disconnect Requests ( even if they are mentioned as valid in section 3, end of page #10 ). >From my point of view, either it's misplaced the example in section 7 or cardinality notation values in Disconnect Message Table of Attributes (related to the ones mentioned above) should be changed back to "0-1" (I personally think this last option would be better). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From clint.chaplin@gmail.com Fri Feb 3 13:16:58 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71E21F85CE for ; Fri, 3 Feb 2012 13:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE67y9xsCO-g for ; Fri, 3 Feb 2012 13:16:57 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D621F8591 for ; Fri, 3 Feb 2012 13:16:57 -0800 (PST) Received: by eaae12 with SMTP id e12so1540640eaa.31 for ; Fri, 03 Feb 2012 13:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pbfdmylA7IiuXZaXIVJgMXAsqKqhv73ElVIQ9mSpiyQ=; b=rbKm4yUeDnMSPvyxAszVZ4La/+akdfRqVKolYlz9rRRmrVD9CX0lxPMjwAOIGvdK6i CeYTheM3Tu4vwAPW2gnHNS+Z4Jxe2/CrINuoKo+lEXgtmlabnZmvsptRaMfoTaOsuPqi d5MQUwdhUC7S4oSYOfqtdgnsgKElJux6YreCM= MIME-Version: 1.0 Received: by 10.213.32.7 with SMTP id a7mr2616130ebd.109.1328303816070; Fri, 03 Feb 2012 13:16:56 -0800 (PST) Received: by 10.213.35.12 with HTTP; Fri, 3 Feb 2012 13:16:56 -0800 (PST) In-Reply-To: <20120203095300.78CE8B1E002@rfc-editor.org> References: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Fri, 3 Feb 2012 13:16:56 -0800 Message-ID: From: Clint Chaplin To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 04 Feb 2012 03:24:19 -0800 Cc: gdommety@cisco.com, radext@ietf.org, davide.magistri@gmail.com, rbonica@juniper.net, mauricio.sanchez@hp.com, dromasca@avaya.com, bernarda@microsoft.com, david@mitton.com, jouni.korhonen@nsn.com, meklund@cisco.com, mchiba@cisco.com Subject: Re: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:16:58 -0000 I'm not seeing it. What's the difference between the replaced text and the replacing text? On Fri, Feb 3, 2012 at 1:53 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5176, > "Dynamic Authorization Extensions to Remote Authentication Dial In User S= ervice (RADIUS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D3103 > > -------------------------------------- > Type: Technical > Reported by: Davide Magistri > > Section: 7 > > Original Text > ------------- > Disconnect Request with User-Name: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-(= ....# > =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U.= ..^.. > =A0 =A0 =A032: 6d63 6869 6261 > > Disconnect Request with Acct-Session-ID: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.(= ..... > =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......N= 8w.,. > =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 > > Disconnect Request with Framed-IP-Address: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda =A0 =A0.B....."2.(= ..... > =A0 =A0 =A016: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 =A0 =A03.v[.....*/= kQ... > =A0 =A0 =A032: 0a00 0203 > > Corrected Text > -------------- > Disconnect Request with User-Name: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-(= ....# > =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U.= ..^.. > =A0 =A0 =A032: 6d63 6869 6261 > > Disconnect Request with Acct-Session-ID: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.(= ..... > =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......N= 8w.,. > =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 > > Notes > ----- > Since cardinality notation value for Framed-IP-Address attribute has now = been changed in section 3.6 ("Table of Attributes") compared to previous 35= 76 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-= IP-Address" example in section 7 ("Example traces") should be removed. > > Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should b= e foreseen (just like the one related to Service-Type Attribute), such as: > o =A0Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Pr= efix Attributes within a Disconnect-Request is prohibited > > Broadly speaking, one thing that seems to me a bit unclear is that Attrib= utes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix = are still valid session identifiers that could be present in CoA Requests, = while they have been totally prohibited in Disconnect Requests ( even if th= ey are mentioned as valid in section 3, end of page #10 ). > From my point of view, either it's misplaced the example in section 7 or = cardinality notation values in Disconnect Message Table of Attributes (rela= ted to the ones mentioned above) should be changed back to "0-1" (I persona= lly think this last option would be better). > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5176 (draft-ietf-radext-rfc3576bis-13) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Dynamic Authorization Extensions to R= emote Authentication Dial In User Service (RADIUS) > Publication Date =A0 =A0: January 2008 > Author(s) =A0 =A0 =A0 =A0 =A0 : M. Chiba, G. Dommety, M. Eklund, D. Mitto= n, B. Aboba > Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: RADIUS EXTensions > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Clint (JOATMON) Chaplin Principal Engineer Standards & Technology Enabling Advanced Technology Lab Samsung Electronics US R&D Center From davide.magistri@gmail.com Fri Feb 3 15:11:23 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1F21F851B for ; Fri, 3 Feb 2012 15:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S6560iiMghO for ; Fri, 3 Feb 2012 15:11:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9921F8510 for ; Fri, 3 Feb 2012 15:11:22 -0800 (PST) Received: by iagf6 with SMTP id f6so6521841iag.31 for ; Fri, 03 Feb 2012 15:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W+muUksnmXUwL9SCYYTa3qiQ1hQnQXxqBjcfA5mu2vI=; b=ioZyqNVFVqoTUIQXMcBFDzvz6l+/us55SDh/MilOV9QPQjgrptRZ2hGN1HyKfqiqZp SoFG+rBB+ruGpc5nXlWcDtPN6kpWa2FfFPSj0uiOGy9iRFHv+awi4SbUz7WyASvxMeXc EwByt0UdJdhbEUjr/rq9hFS3B0ARlrE+c8elU= MIME-Version: 1.0 Received: by 10.42.117.193 with SMTP id u1mr8710804icq.24.1328310682318; Fri, 03 Feb 2012 15:11:22 -0800 (PST) Received: by 10.231.45.77 with HTTP; Fri, 3 Feb 2012 15:11:22 -0800 (PST) In-Reply-To: References: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Sat, 4 Feb 2012 00:11:22 +0100 Message-ID: From: Davide Magistri To: Clint Chaplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 04 Feb 2012 03:24:19 -0800 Cc: gdommety@cisco.com, radext@ietf.org, rbonica@juniper.net, mauricio.sanchez@hp.com, dromasca@avaya.com, bernarda@microsoft.com, david@mitton.com, jouni.korhonen@nsn.com, meklund@cisco.com, mchiba@cisco.com, RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:23:26 -0000 In the replacing text, the "Disconnect Request with Framed-IP-Address" example is missing. What I meant is that given the cardinality value contained in the "Disconnect Message Table of Attributes", the "Example Traces" section should not contain a Disconnect Request with Framed-IP-Address attribute. I just couldn't think of a better way to fill the "replaced text" and "replacing text" fields in the form. I apologize if this wasn't straightforward. On Fri, Feb 3, 2012 at 10:16 PM, Clint Chaplin wr= ote: > I'm not seeing it. =A0What's the difference between the replaced text > and the replacing text? > > On Fri, Feb 3, 2012 at 1:53 AM, RFC Errata System > wrote: >> >> The following errata report has been submitted for RFC5176, >> "Dynamic Authorization Extensions to Remote Authentication Dial In User = Service (RADIUS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D3103 >> >> -------------------------------------- >> Type: Technical >> Reported by: Davide Magistri >> >> Section: 7 >> >> Original Text >> ------------- >> Disconnect Request with User-Name: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-= (....# >> =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U= ...^.. >> =A0 =A0 =A032: 6d63 6869 6261 >> >> Disconnect Request with Acct-Session-ID: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.= (..... >> =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......= N8w.,. >> =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 >> >> Disconnect Request with Framed-IP-Address: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda =A0 =A0.B....."2.= (..... >> =A0 =A0 =A016: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 =A0 =A03.v[.....*= /kQ... >> =A0 =A0 =A032: 0a00 0203 >> >> Corrected Text >> -------------- >> Disconnect Request with User-Name: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-= (....# >> =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U= ...^.. >> =A0 =A0 =A032: 6d63 6869 6261 >> >> Disconnect Request with Acct-Session-ID: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.= (..... >> =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......= N8w.,. >> =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 >> >> Notes >> ----- >> Since cardinality notation value for Framed-IP-Address attribute has now= been changed in section 3.6 ("Table of Attributes") compared to previous 3= 576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed= -IP-Address" example in section 7 ("Example traces") should be removed. >> >> Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should = be foreseen (just like the one related to Service-Type Attribute), such as: >> o =A0Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-P= refix Attributes within a Disconnect-Request is prohibited >> >> Broadly speaking, one thing that seems to me a bit unclear is that Attri= butes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix= are still valid session identifiers that could be present in CoA Requests,= while they have been totally prohibited in Disconnect Requests ( even if t= hey are mentioned as valid in section 3, end of page #10 ). >> From my point of view, either it's misplaced the example in section 7 or= cardinality notation values in Disconnect Message Table of Attributes (rel= ated to the ones mentioned above) should be changed back to "0-1" (I person= ally think this last option would be better). >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5176 (draft-ietf-radext-rfc3576bis-13) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Dynamic Authorization Extensions to = Remote Authentication Dial In User Service (RADIUS) >> Publication Date =A0 =A0: January 2008 >> Author(s) =A0 =A0 =A0 =A0 =A0 : M. Chiba, G. Dommety, M. Eklund, D. Mitt= on, B. Aboba >> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: RADIUS EXTensions >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > > > -- > Clint (JOATMON) Chaplin > Principal Engineer > Standards & Technology Enabling > Advanced Technology Lab > Samsung Electronics US R&D Center From radext-bounces@ietf.org Sat Feb 4 03:24:20 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737D321F851B; Sat, 4 Feb 2012 03:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328354660; bh=hR9LhAemsVzeOi+ZvmAWP6MgtO2eeUtIkq6Et6dlX4Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=vH/i8LBB4ZeqiOMnWCj2Ds9bRnx0ZShTDRJjLMzbl8fkwJSwU+kgaQyCfD6wniCd7 3/lQjZ3h8ksDsWpNEpI83z7AXK4J4/bNc59//t/aGOeTXhfNy41zi/WW7a2DtTWFEn T6+umJnCbHclbt/wJTAJaTnJf+9IV3shZzGZcHfY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71E21F85CE for ; Fri, 3 Feb 2012 13:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE67y9xsCO-g for ; Fri, 3 Feb 2012 13:16:57 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D621F8591 for ; Fri, 3 Feb 2012 13:16:57 -0800 (PST) Received: by eaae12 with SMTP id e12so1540640eaa.31 for ; Fri, 03 Feb 2012 13:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pbfdmylA7IiuXZaXIVJgMXAsqKqhv73ElVIQ9mSpiyQ=; b=rbKm4yUeDnMSPvyxAszVZ4La/+akdfRqVKolYlz9rRRmrVD9CX0lxPMjwAOIGvdK6i CeYTheM3Tu4vwAPW2gnHNS+Z4Jxe2/CrINuoKo+lEXgtmlabnZmvsptRaMfoTaOsuPqi d5MQUwdhUC7S4oSYOfqtdgnsgKElJux6YreCM= MIME-Version: 1.0 Received: by 10.213.32.7 with SMTP id a7mr2616130ebd.109.1328303816070; Fri, 03 Feb 2012 13:16:56 -0800 (PST) Received: by 10.213.35.12 with HTTP; Fri, 3 Feb 2012 13:16:56 -0800 (PST) In-Reply-To: <20120203095300.78CE8B1E002@rfc-editor.org> References: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Fri, 3 Feb 2012 13:16:56 -0800 Message-ID: From: Clint Chaplin To: RFC Errata System X-Mailman-Approved-At: Sat, 04 Feb 2012 03:24:19 -0800 Cc: gdommety@cisco.com, radext@ietf.org, davide.magistri@gmail.com, rbonica@juniper.net, mauricio.sanchez@hp.com, dromasca@avaya.com, bernarda@microsoft.com, david@mitton.com, jouni.korhonen@nsn.com, meklund@cisco.com, mchiba@cisco.com Subject: Re: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org I'm not seeing it. What's the difference between the replaced text and the replacing text? On Fri, Feb 3, 2012 at 1:53 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5176, > "Dynamic Authorization Extensions to Remote Authentication Dial In User S= ervice (RADIUS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D3103 > > -------------------------------------- > Type: Technical > Reported by: Davide Magistri > > Section: 7 > > Original Text > ------------- > Disconnect Request with User-Name: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-(= ....# > =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U.= ..^.. > =A0 =A0 =A032: 6d63 6869 6261 > > Disconnect Request with Acct-Session-ID: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.(= ..... > =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......N= 8w.,. > =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 > > Disconnect Request with Framed-IP-Address: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda =A0 =A0.B....."2.(= ..... > =A0 =A0 =A016: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 =A0 =A03.v[.....*/= kQ... > =A0 =A0 =A032: 0a00 0203 > > Corrected Text > -------------- > Disconnect Request with User-Name: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-(= ....# > =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U.= ..^.. > =A0 =A0 =A032: 6d63 6869 6261 > > Disconnect Request with Acct-Session-ID: > > =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.(= ..... > =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......N= 8w.,. > =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 > > Notes > ----- > Since cardinality notation value for Framed-IP-Address attribute has now = been changed in section 3.6 ("Table of Attributes") compared to previous 35= 76 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-= IP-Address" example in section 7 ("Example traces") should be removed. > > Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should b= e foreseen (just like the one related to Service-Type Attribute), such as: > o =A0Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Pr= efix Attributes within a Disconnect-Request is prohibited > > Broadly speaking, one thing that seems to me a bit unclear is that Attrib= utes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix = are still valid session identifiers that could be present in CoA Requests, = while they have been totally prohibited in Disconnect Requests ( even if th= ey are mentioned as valid in section 3, end of page #10 ). > From my point of view, either it's misplaced the example in section 7 or = cardinality notation values in Disconnect Message Table of Attributes (rela= ted to the ones mentioned above) should be changed back to "0-1" (I persona= lly think this last option would be better). > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5176 (draft-ietf-radext-rfc3576bis-13) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Dynamic Authorization Extensions to R= emote Authentication Dial In User Service (RADIUS) > Publication Date =A0 =A0: January 2008 > Author(s) =A0 =A0 =A0 =A0 =A0 : M. Chiba, G. Dommety, M. Eklund, D. Mitto= n, B. Aboba > Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: RADIUS EXTensions > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- = Clint (JOATMON) Chaplin Principal Engineer Standards & Technology Enabling Advanced Technology Lab Samsung Electronics US R&D Center _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Sat Feb 4 03:24:20 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F1221F85AE; Sat, 4 Feb 2012 03:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328354660; bh=OpmsdGUtdKcnSwos3nLeB0HspNFA7R/ynPig99AEJyg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=sfk10LwsEOkcl6MErw5aBzisEB5N+zaVIFeD7M77W/kGw06QjUATnQeJbM17SEuBX IvJaNQ4C8w7BNKFypCXLfJsLAAU9BXGyMhnNy9GtTZA9E8ppEo50+fNUZkSatrgflT UnPhYqfGsBTeSp/EDe64rB3t4uHU5w+17NcrBXTM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1F21F851B for ; Fri, 3 Feb 2012 15:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S6560iiMghO for ; Fri, 3 Feb 2012 15:11:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9921F8510 for ; Fri, 3 Feb 2012 15:11:22 -0800 (PST) Received: by iagf6 with SMTP id f6so6521841iag.31 for ; Fri, 03 Feb 2012 15:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W+muUksnmXUwL9SCYYTa3qiQ1hQnQXxqBjcfA5mu2vI=; b=ioZyqNVFVqoTUIQXMcBFDzvz6l+/us55SDh/MilOV9QPQjgrptRZ2hGN1HyKfqiqZp SoFG+rBB+ruGpc5nXlWcDtPN6kpWa2FfFPSj0uiOGy9iRFHv+awi4SbUz7WyASvxMeXc EwByt0UdJdhbEUjr/rq9hFS3B0ARlrE+c8elU= MIME-Version: 1.0 Received: by 10.42.117.193 with SMTP id u1mr8710804icq.24.1328310682318; Fri, 03 Feb 2012 15:11:22 -0800 (PST) Received: by 10.231.45.77 with HTTP; Fri, 3 Feb 2012 15:11:22 -0800 (PST) In-Reply-To: References: <20120203095300.78CE8B1E002@rfc-editor.org> Date: Sat, 4 Feb 2012 00:11:22 +0100 Message-ID: From: Davide Magistri To: Clint Chaplin X-Mailman-Approved-At: Sat, 04 Feb 2012 03:24:19 -0800 Cc: gdommety@cisco.com, radext@ietf.org, rbonica@juniper.net, mauricio.sanchez@hp.com, dromasca@avaya.com, bernarda@microsoft.com, david@mitton.com, jouni.korhonen@nsn.com, meklund@cisco.com, mchiba@cisco.com, RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (3103) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org In the replacing text, the "Disconnect Request with Framed-IP-Address" example is missing. What I meant is that given the cardinality value contained in the "Disconnect Message Table of Attributes", the "Example Traces" section should not contain a Disconnect Request with Framed-IP-Address attribute. I just couldn't think of a better way to fill the "replaced text" and "replacing text" fields in the form. I apologize if this wasn't straightforward. On Fri, Feb 3, 2012 at 10:16 PM, Clint Chaplin wr= ote: > I'm not seeing it. =A0What's the difference between the replaced text > and the replacing text? > > On Fri, Feb 3, 2012 at 1:53 AM, RFC Errata System > wrote: >> >> The following errata report has been submitted for RFC5176, >> "Dynamic Authorization Extensions to Remote Authentication Dial In User = Service (RADIUS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D3103 >> >> -------------------------------------- >> Type: Technical >> Reported by: Davide Magistri >> >> Section: 7 >> >> Original Text >> ------------- >> Disconnect Request with User-Name: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-= (....# >> =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U= ...^.. >> =A0 =A0 =A032: 6d63 6869 6261 >> >> Disconnect Request with Acct-Session-ID: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.= (..... >> =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......= N8w.,. >> =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 >> >> Disconnect Request with Framed-IP-Address: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda =A0 =A0.B....."2.= (..... >> =A0 =A0 =A016: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 =A0 =A03.v[.....*= /kQ... >> =A0 =A0 =A032: 0a00 0203 >> >> Corrected Text >> -------------- >> Disconnect Request with User-Name: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 =A0 =A0.B.....$.-= (....# >> =A0 =A0 =A016: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 =A0 =A0bL5C..U..U= ...^.. >> =A0 =A0 =A032: 6d63 6869 6261 >> >> Disconnect Request with Acct-Session-ID: >> >> =A0 =A0 =A0 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d =A0 =A0.B..... ~.= (..... >> =A0 =A0 =A016: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a =A0 =A0.SU.......= N8w.,. >> =A0 =A0 =A032: 3930 3233 3435 3637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A090234567 >> >> Notes >> ----- >> Since cardinality notation value for Framed-IP-Address attribute has now= been changed in section 3.6 ("Table of Attributes") compared to previous 3= 576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed= -IP-Address" example in section 7 ("Example traces") should be removed. >> >> Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should = be foreseen (just like the one related to Service-Type Attribute), such as: >> o =A0Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-P= refix Attributes within a Disconnect-Request is prohibited >> >> Broadly speaking, one thing that seems to me a bit unclear is that Attri= butes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix= are still valid session identifiers that could be present in CoA Requests,= while they have been totally prohibited in Disconnect Requests ( even if t= hey are mentioned as valid in section 3, end of page #10 ). >> From my point of view, either it's misplaced the example in section 7 or= cardinality notation values in Disconnect Message Table of Attributes (rel= ated to the ones mentioned above) should be changed back to "0-1" (I person= ally think this last option would be better). >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5176 (draft-ietf-radext-rfc3576bis-13) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Dynamic Authorization Extensions to = Remote Authentication Dial In User Service (RADIUS) >> Publication Date =A0 =A0: January 2008 >> Author(s) =A0 =A0 =A0 =A0 =A0 : M. Chiba, G. Dommety, M. Eklund, D. Mitt= on, B. Aboba >> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: RADIUS EXTensions >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > > > -- > Clint (JOATMON) Chaplin > Principal Engineer > Standards & Technology Enabling > Advanced Technology Lab > Samsung Electronics US R&D Center _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Sat Feb 4 10:48:49 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE021F8495 for ; Sat, 4 Feb 2012 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 g8V370nZNglq for ; Sat, 4 Feb 2012 10:48:48 -0800 (PST) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id BB01321F8473 for ; Sat, 4 Feb 2012 10:48:48 -0800 (PST) Received: from BLU152-DS1 ([65.55.116.8]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 10:48:48 -0800 X-Originating-IP: [76.22.61.46] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Stefan Winter'" , "'Romascanu, Dan \(Dan\)'" References: <20120201180357.19470.41205.idtracker@ietfa.amsl.com><4F2A5CD2.5020407@restena.lu> <0cfc01cce1c4$6c2f71b0$448e5510$@olddog.co.uk> <4F2BAFE4.7050904@restena.lu> In-Reply-To: <4F2BAFE4.7050904@restena.lu> Date: Sat, 4 Feb 2012 10:49:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQILrcWOUT146NeK2zbwPyEaLDUYxQGQsExnAk93hGoBvFjYrgHpzMZklXNI6NA= Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2012 18:48:48.0036 (UTC) FILETIME=[A1152640:01CCE36D] Cc: radext@ietf.org, draft-ietf-radext-radsec@tools.ietf.org Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 18:48:49 -0000 The proposed text conflates manual keying with use of a shared secret. = TLS-PSK provides automated key management as well as protected ciphersuite negotiation and is a big = step forward from RFC 2865 manual=20 keying with deprecated algorithms. Given the discussion of RFC 4107 = within RFC 6421, I'd suggest that the context provided by RFC 6421 is important for understanding how RFC 4107 = would apply to RADIUS,=20 particularly given the RADEXT WG's concerns about the relevance of RFC = 4107.=20 Here is are some proposed changes:=20 "1.3. Document Status This document is an Experimental RFC. It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (described in Section 4), as well as to provide support for crypto-agility as described in "RADIUS = Crypto-Agility Requirements" [RFC6421]. The specification does not fulfill all = recommendations=20 on a AAA transport profile as per [RFC3539]; in particular, by being = based on TCP=20 as a transport layer, it does not prevent head-of-line blocking = issues. If this specification is indeed selected for advancement to standards track, the process described in [RFC6421] will need to be followed = and in particular, certificate verification options (section 2.3.2) will = need to be refined. Another experimental characteristic of this specification is the question of key management between RADIUS/TLS peers. RADIUS/UDP only allowed for manual key management, i.e. distribution of a shared secret between a client and a server. RADIUS/TLS allows manual distribution of long-term proofs of peer identity as well (by using TLS-PSK cipher suites, or identifying clients by a certificate fingerprint), but as a new feature enables use of X.509 certificates=20 in a PKIX infrastructure. It remains to be seen if one of these = methods=20 prevail, or if both will find their place in real-life deployments. = The authors can imagine pre-shared keys to be popular in small-scale deployments (SOHO or isolated enterprise deployments) where scalability is not an issue and the deployment of a CA is considered too much a hassle; but can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107].=20 It has yet to be decided whether this approach is to be chosen for standards track. One key aspect to judge whether the approach is usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments. An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam]. -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of = Stefan Winter Sent: Friday, February 03, 2012 1:59 AM To: Romascanu, Dan (Dan) Cc: adrian@olddog.co.uk; draft-ietf-radext-radsec@tools.ietf.org; The = IESG; radext-chairs@tools.ietf.org Subject: Re: Adrian Farrel's No Objection on = draft-ietf-radext-radsec-11:(with COMMENT) Hello all, > Yes, I was going to ask this during the telechat should this answer = have not come. Editors, please add some text in the revised version = after the telechat that shows that the issue was considered and what key = management methods were taken into consideration at the time of the = publication of the document. This would also provide reference for = experimentation.=20 Okay... how about the following text in "Document Status" (third para is new): 1.3. Document Status This document is an Experimental RFC. It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues. If this specification is indeed selected for advancement to standards track, certificate verification options (section 2.3.2) need to be refined. Another experimental characteristic of this specification is the question of key management between RADIUS/TLS peers. RADIUS/UDP only allowed for manual key management, i.e. distribution of a shared secret between a client and a server. RADIUS/TLS allows manual distribution of long-term proofs of peer identity as well (by using TLS-PSK cipher suites, or identifying clients by a certificate fingerprint), but as a new feature also allows automatic key management using X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods prevail, or if both will find their place in real-life deployments. The authors can imagine manual key distribution to be popular in small-scale deployments (SOHO or isolated enterprise deployments) where scalability is not an issue and the deployment of a CA is considered too much a hassle; but can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read [RFC4107]. It has yet to be decided whether this approach is to be chosen for standards track. One key aspect to judge whether the approach is usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments. An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam]. If that text is sufficient to address the COMMENT (please let me know), = I would issue -12 with it (this is the last pending comment). Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et de la Recherche 6, rue Richard = Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Sat Feb 4 10:48:51 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914221F8495; Sat, 4 Feb 2012 10:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328381331; bh=xaIlHmEuuS/H6jefvVXC1s3BC4Ezwqor+W43KWyzolM=; h=Message-ID:From:To:References:In-Reply-To:Date:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=BxSA8ZV3H/3ECq/aT2zBlJqoIv9gKDGEHEGKHzdYcbROeK7Zc96IlH9LPiU2wV3vK t+O0S1aCrUhVI/bea+cndKYp3tqyJY+bh8tmCufVxmqOzaRfXLenPIoBISBcwL0ylC BZ5z8kQwfJ64Baqf8yLN6YiR1CZT2jVFWNFr91XE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE021F8495 for ; Sat, 4 Feb 2012 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 g8V370nZNglq for ; Sat, 4 Feb 2012 10:48:48 -0800 (PST) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id BB01321F8473 for ; Sat, 4 Feb 2012 10:48:48 -0800 (PST) Received: from BLU152-DS1 ([65.55.116.8]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 10:48:48 -0800 X-Originating-IP: [76.22.61.46] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Stefan Winter'" , "'Romascanu, Dan \(Dan\)'" References: <20120201180357.19470.41205.idtracker@ietfa.amsl.com><4F2A5CD2.5020407@restena.lu> <0cfc01cce1c4$6c2f71b0$448e5510$@olddog.co.uk> <4F2BAFE4.7050904@restena.lu> In-Reply-To: <4F2BAFE4.7050904@restena.lu> Date: Sat, 4 Feb 2012 10:49:29 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-index: AQILrcWOUT146NeK2zbwPyEaLDUYxQGQsExnAk93hGoBvFjYrgHpzMZklXNI6NA= Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2012 18:48:48.0036 (UTC) FILETIME=[A1152640:01CCE36D] Cc: radext@ietf.org, draft-ietf-radext-radsec@tools.ietf.org Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org VGhlIHByb3Bvc2VkIHRleHQgY29uZmxhdGVzIG1hbnVhbCBrZXlpbmcgd2l0aCB1c2Ugb2YgYSBz aGFyZWQgc2VjcmV0LiAgIFRMUy1QU0sgcHJvdmlkZXMgYXV0b21hdGVkIGtleQptYW5hZ2VtZW50 IGFzIHdlbGwgYXMgcHJvdGVjdGVkIGNpcGhlcnN1aXRlIG5lZ290aWF0aW9uIGFuZCBpcyBhIGJp ZyBzdGVwIGZvcndhcmQgZnJvbSBSRkMgMjg2NSBtYW51YWwgCmtleWluZyB3aXRoIGRlcHJlY2F0 ZWQgYWxnb3JpdGhtcy4gIEdpdmVuIHRoZSBkaXNjdXNzaW9uIG9mIFJGQyA0MTA3IHdpdGhpbiBS RkMgNjQyMSwgSSdkIHN1Z2dlc3QgdGhhdCB0aGUKY29udGV4dCBwcm92aWRlZCBieSBSRkMgNjQy MSBpcyBpbXBvcnRhbnQgZm9yIHVuZGVyc3RhbmRpbmcgaG93IFJGQyA0MTA3IHdvdWxkIGFwcGx5 IHRvIFJBRElVUywgCnBhcnRpY3VsYXJseSBnaXZlbiB0aGUgUkFERVhUIFdHJ3MgY29uY2VybnMg YWJvdXQgdGhlIHJlbGV2YW5jZSBvZiBSRkMgNDEwNy4gCgoKSGVyZSBpcyBhcmUgc29tZSBwcm9w b3NlZCBjaGFuZ2VzOiAKCiAiMS4zLiAgRG9jdW1lbnQgU3RhdHVzCgogICBUaGlzIGRvY3VtZW50 IGlzIGFuIEV4cGVyaW1lbnRhbCBSRkMuCgogICBJdCBpcyBvbmUgb3V0IG9mIHNldmVyYWwgYXBw cm9hY2hlcyB0byBhZGRyZXNzIGtub3duIGNyeXB0b2dyYXBoaWMKICAgd2Vha25lc3NlcyBvZiB0 aGUgUkFESVVTIHByb3RvY29sIChkZXNjcmliZWQgaW4gU2VjdGlvbiA0KSwgYXMgd2VsbAogICBh cyB0byBwcm92aWRlIHN1cHBvcnQgZm9yIGNyeXB0by1hZ2lsaXR5IGFzIGRlc2NyaWJlZCBpbiAi UkFESVVTIENyeXB0by1BZ2lsaXR5CiAgIFJlcXVpcmVtZW50cyIgW1JGQzY0MjFdLiAgVGhlIHNw ZWNpZmljYXRpb24gZG9lcyBub3QgZnVsZmlsbCBhbGwgcmVjb21tZW5kYXRpb25zIAogICBvbiBh IEFBQSB0cmFuc3BvcnQgcHJvZmlsZSBhcyBwZXIgW1JGQzM1MzldOyBpbiBwYXJ0aWN1bGFyLCBi eSBiZWluZyBiYXNlZCBvbiBUQ1AgCiAgIGFzIGEgdHJhbnNwb3J0IGxheWVyLCBpdCBkb2VzIG5v dCBwcmV2ZW50IGhlYWQtb2YtbGluZSBibG9ja2luZyBpc3N1ZXMuCgogICBJZiB0aGlzIHNwZWNp ZmljYXRpb24gaXMgaW5kZWVkIHNlbGVjdGVkIGZvciBhZHZhbmNlbWVudCB0byBzdGFuZGFyZHMK ICAgdHJhY2ssIHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBpbiBbUkZDNjQyMV0gd2lsbCBuZWVkIHRv IGJlIGZvbGxvd2VkIGFuZAogICBpbiBwYXJ0aWN1bGFyLCBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRp b24gb3B0aW9ucyAoc2VjdGlvbiAyLjMuMikgd2lsbCBuZWVkIHRvIGJlCiAgIHJlZmluZWQuCgog ICBBbm90aGVyIGV4cGVyaW1lbnRhbCBjaGFyYWN0ZXJpc3RpYyBvZiB0aGlzIHNwZWNpZmljYXRp b24gaXMgdGhlCiAgIHF1ZXN0aW9uIG9mIGtleSBtYW5hZ2VtZW50IGJldHdlZW4gUkFESVVTL1RM UyBwZWVycy4gIFJBRElVUy9VRFAgb25seQogICBhbGxvd2VkIGZvciBtYW51YWwga2V5IG1hbmFn ZW1lbnQsIGkuZS4gZGlzdHJpYnV0aW9uIG9mIGEgc2hhcmVkCiAgIHNlY3JldCBiZXR3ZWVuIGEg Y2xpZW50IGFuZCBhIHNlcnZlci4gIFJBRElVUy9UTFMgYWxsb3dzIG1hbnVhbAogICBkaXN0cmli dXRpb24gb2YgbG9uZy10ZXJtIHByb29mcyBvZiBwZWVyIGlkZW50aXR5IGFzIHdlbGwgKGJ5IHVz aW5nCiAgIFRMUy1QU0sgY2lwaGVyIHN1aXRlcywgb3IgaWRlbnRpZnlpbmcgY2xpZW50cyBieSBh IGNlcnRpZmljYXRlCiAgIGZpbmdlcnByaW50KSwgYnV0IGFzIGEgbmV3IGZlYXR1cmUgZW5hYmxl cyB1c2Ugb2YgWC41MDkgY2VydGlmaWNhdGVzIAogICBpbiBhIFBLSVggaW5mcmFzdHJ1Y3R1cmUu ICBJdCByZW1haW5zIHRvIGJlIHNlZW4gaWYgb25lIG9mIHRoZXNlIG1ldGhvZHMgCiAgIHByZXZh aWwsIG9yIGlmIGJvdGggd2lsbCBmaW5kIHRoZWlyIHBsYWNlIGluIHJlYWwtbGlmZSBkZXBsb3lt ZW50cy4gIFRoZSBhdXRob3JzIGNhbiBpbWFnaW5lCiAgIHByZS1zaGFyZWQga2V5cyB0byBiZSBw b3B1bGFyIGluIHNtYWxsLXNjYWxlIGRlcGxveW1lbnRzCiAgIChTT0hPIG9yIGlzb2xhdGVkIGVu dGVycHJpc2UgZGVwbG95bWVudHMpIHdoZXJlIHNjYWxhYmlsaXR5IGlzIG5vdCBhbgogICBpc3N1 ZSBhbmQgdGhlIGRlcGxveW1lbnQgb2YgYSBDQSBpcyBjb25zaWRlcmVkIHRvbyBtdWNoIGEgaGFz c2xlOyBidXQKICAgY2FuIGFsc28gaW1hZ2luZSBsYXJnZSByb2FtaW5nIGNvbnNvcnRpYSB0byBt YWtlIHVzZSBvZiBQS0lYLgogICBSZWFkZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUgZW5j b3VyYWdlZCB0byByZWFkIHRoZSBkaXNjdXNzaW9uCiAgIG9mIGtleSBtYW5hZ2VtZW50IGlzc3Vl cyB3aXRoaW4gW1JGQzY0MjFdIGFzIHdlbGwgYXMgW1JGQzQxMDddLiAKCiAgIEl0IGhhcyB5ZXQg dG8gYmUgZGVjaWRlZCB3aGV0aGVyIHRoaXMgYXBwcm9hY2ggaXMgdG8gYmUgY2hvc2VuIGZvcgog ICBzdGFuZGFyZHMgdHJhY2suICBPbmUga2V5IGFzcGVjdCB0byBqdWRnZSB3aGV0aGVyIHRoZSBh cHByb2FjaCBpcwogICB1c2FibGUgYXQgbGFyZ2Ugc2NhbGUgaXMgYnkgb2JzZXJ2aW5nIHRoZSB1 cHRha2UsIHVzYWJpbGl0eSBhbmQKICAgb3BlcmF0aW9uYWwgYmVoYXZpb3VyIG9mIHRoZSBwcm90 b2NvbCBpbiBsYXJnZS1zY2FsZSwgcmVhbC1saWZlCiAgIGRlcGxveW1lbnRzLgoKICAgQW4gZXhh bXBsZSBmb3IgYSB3b3JsZC13aWRlIHJvYW1pbmcgZW52aXJvbm1lbnQgdGhhdCB1c2VzIFJBRElV UyBvdmVyCiAgIFRMUyB0byBzZWN1cmUgY29tbXVuaWNhdGlvbiBpcyAiZWR1cm9hbSIsIHNlZSBb ZWR1cm9hbV0uCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogaWVzZy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3Rl ZmFuIFdpbnRlcgpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAzLCAyMDEyIDE6NTkgQU0KVG86IFJv bWFzY2FudSwgRGFuIChEYW4pCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBkcmFmdC1pZXRmLXJh ZGV4dC1yYWRzZWNAdG9vbHMuaWV0Zi5vcmc7IFRoZSBJRVNHOyByYWRleHQtY2hhaXJzQHRvb2xz LmlldGYub3JnClN1YmplY3Q6IFJlOiBBZHJpYW4gRmFycmVsJ3MgTm8gT2JqZWN0aW9uIG9uIGRy YWZ0LWlldGYtcmFkZXh0LXJhZHNlYy0xMTood2l0aCBDT01NRU5UKQoKSGVsbG8gYWxsLAoKPiBZ ZXMsIEkgd2FzIGdvaW5nIHRvIGFzayB0aGlzIGR1cmluZyB0aGUgdGVsZWNoYXQgc2hvdWxkIHRo aXMgYW5zd2VyIGhhdmUgbm90IGNvbWUuIEVkaXRvcnMsIHBsZWFzZSBhZGQgc29tZSB0ZXh0IGlu IHRoZSByZXZpc2VkIHZlcnNpb24gYWZ0ZXIgdGhlIHRlbGVjaGF0IHRoYXQgc2hvd3MgdGhhdCB0 aGUgaXNzdWUgd2FzIGNvbnNpZGVyZWQgYW5kIHdoYXQga2V5IG1hbmFnZW1lbnQgbWV0aG9kcyB3 ZXJlIHRha2VuIGludG8gY29uc2lkZXJhdGlvbiBhdCB0aGUgdGltZSBvZiB0aGUgcHVibGljYXRp b24gb2YgdGhlIGRvY3VtZW50LiBUaGlzIHdvdWxkIGFsc28gcHJvdmlkZSByZWZlcmVuY2UgZm9y IGV4cGVyaW1lbnRhdGlvbi4gCgpPa2F5Li4uIGhvdyBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQg aW4gIkRvY3VtZW50IFN0YXR1cyIgKHRoaXJkIHBhcmEgaXMKbmV3KToKCjEuMy4gIERvY3VtZW50 IFN0YXR1cwoKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBFeHBlcmltZW50YWwgUkZDLgoKICAgSXQg aXMgb25lIG91dCBvZiBzZXZlcmFsIGFwcHJvYWNoZXMgdG8gYWRkcmVzcyBrbm93biBjcnlwdG9n cmFwaGljCiAgIHdlYWtuZXNzZXMgb2YgdGhlIFJBRElVUyBwcm90b2NvbCAoc2VlIGFsc28gU2Vj dGlvbiA0KS4gIFRoZQogICBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGZ1bGZpbGwgYWxsIHJlY29t bWVuZGF0aW9ucyBvbiBhIEFBQSB0cmFuc3BvcnQKICAgcHJvZmlsZSBhcyBwZXIgW1JGQzM1Mzld OyBpbiBwYXJ0aWN1bGFyLCBieSBiZWluZyBiYXNlZCBvbiBUQ1AgYXMgYQogICB0cmFuc3BvcnQg bGF5ZXIsIGl0IGRvZXMgbm90IHByZXZlbnQgaGVhZC1vZi1saW5lIGJsb2NraW5nIGlzc3Vlcy4K CiAgIElmIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbmRlZWQgc2VsZWN0ZWQgZm9yIGFkdmFuY2Vt ZW50IHRvIHN0YW5kYXJkcwogICB0cmFjaywgY2VydGlmaWNhdGUgdmVyaWZpY2F0aW9uIG9wdGlv bnMgKHNlY3Rpb24gMi4zLjIpIG5lZWQgdG8gYmUKICAgcmVmaW5lZC4KCiAgIEFub3RoZXIgZXhw ZXJpbWVudGFsIGNoYXJhY3RlcmlzdGljIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0aGUKICAg cXVlc3Rpb24gb2Yga2V5IG1hbmFnZW1lbnQgYmV0d2VlbiBSQURJVVMvVExTIHBlZXJzLiAgUkFE SVVTL1VEUCBvbmx5CiAgIGFsbG93ZWQgZm9yIG1hbnVhbCBrZXkgbWFuYWdlbWVudCwgaS5lLiBk aXN0cmlidXRpb24gb2YgYSBzaGFyZWQKICAgc2VjcmV0IGJldHdlZW4gYSBjbGllbnQgYW5kIGEg c2VydmVyLiAgUkFESVVTL1RMUyBhbGxvd3MgbWFudWFsCiAgIGRpc3RyaWJ1dGlvbiBvZiBsb25n LXRlcm0gcHJvb2ZzIG9mIHBlZXIgaWRlbnRpdHkgYXMgd2VsbCAoYnkgdXNpbmcKICAgVExTLVBT SyBjaXBoZXIgc3VpdGVzLCBvciBpZGVudGlmeWluZyBjbGllbnRzIGJ5IGEgY2VydGlmaWNhdGUK ICAgZmluZ2VycHJpbnQpLCBidXQgYXMgYSBuZXcgZmVhdHVyZSBhbHNvIGFsbG93cyBhdXRvbWF0 aWMga2V5CiAgIG1hbmFnZW1lbnQgdXNpbmcgWC41MDkgY2VydGlmaWNhdGVzIGluIGEgUEtJWCBp bmZyYXN0cnVjdHVyZS4gIEl0CiAgIHJlbWFpbnMgdG8gYmUgc2VlbiBpZiBvbmUgb2YgdGhlc2Ug bWV0aG9kcyBwcmV2YWlsLCBvciBpZiBib3RoIHdpbGwKICAgZmluZCB0aGVpciBwbGFjZSBpbiBy ZWFsLWxpZmUgZGVwbG95bWVudHMuICBUaGUgYXV0aG9ycyBjYW4gaW1hZ2luZQogICBtYW51YWwg a2V5IGRpc3RyaWJ1dGlvbiB0byBiZSBwb3B1bGFyIGluIHNtYWxsLXNjYWxlIGRlcGxveW1lbnRz CiAgIChTT0hPIG9yIGlzb2xhdGVkIGVudGVycHJpc2UgZGVwbG95bWVudHMpIHdoZXJlIHNjYWxh YmlsaXR5IGlzIG5vdCBhbgogICBpc3N1ZSBhbmQgdGhlIGRlcGxveW1lbnQgb2YgYSBDQSBpcyBj b25zaWRlcmVkIHRvbyBtdWNoIGEgaGFzc2xlOyBidXQKICAgY2FuIGFsc28gaW1hZ2luZSBsYXJn ZSByb2FtaW5nIGNvbnNvcnRpYSB0byBtYWtlIHVzZSBvZiBQS0lYLgogICBSZWFkZXJzIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiBhcmUgZW5jb3VyYWdlZCB0byByZWFkIFtSRkM0MTA3XS4KCiAgIEl0 IGhhcyB5ZXQgdG8gYmUgZGVjaWRlZCB3aGV0aGVyIHRoaXMgYXBwcm9hY2ggaXMgdG8gYmUgY2hv c2VuIGZvcgogICBzdGFuZGFyZHMgdHJhY2suICBPbmUga2V5IGFzcGVjdCB0byBqdWRnZSB3aGV0 aGVyIHRoZSBhcHByb2FjaCBpcwogICB1c2FibGUgYXQgbGFyZ2Ugc2NhbGUgaXMgYnkgb2JzZXJ2 aW5nIHRoZSB1cHRha2UsIHVzYWJpbGl0eSBhbmQKICAgb3BlcmF0aW9uYWwgYmVoYXZpb3VyIG9m IHRoZSBwcm90b2NvbCBpbiBsYXJnZS1zY2FsZSwgcmVhbC1saWZlCiAgIGRlcGxveW1lbnRzLgoK ICAgQW4gZXhhbXBsZSBmb3IgYSB3b3JsZC13aWRlIHJvYW1pbmcgZW52aXJvbm1lbnQgdGhhdCB1 c2VzIFJBRElVUyBvdmVyCiAgIFRMUyB0byBzZWN1cmUgY29tbXVuaWNhdGlvbiBpcyAiZWR1cm9h bSIsIHNlZSBbZWR1cm9hbV0uCgpJZiB0aGF0IHRleHQgaXMgc3VmZmljaWVudCB0byBhZGRyZXNz IHRoZSBDT01NRU5UIChwbGVhc2UgbGV0IG1lIGtub3cpLCBJIHdvdWxkIGlzc3VlIC0xMiB3aXRo IGl0ICh0aGlzIGlzIHRoZSBsYXN0IHBlbmRpbmcgY29tbWVudCkuCgpHcmVldGluZ3MsCgpTdGVm YW4gV2ludGVyCgotLQpTdGVmYW4gV0lOVEVSCkluZ2VuaWV1ciBkZSBSZWNoZXJjaGUKRm9uZGF0 aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0aXF1ZSBkZSBsJ0VkdWNhdGlvbiBO YXRpb25hbGUgZXQgZGUgbGEgUmVjaGVyY2hlIDYsIHJ1ZSBSaWNoYXJkIENvdWRlbmhvdmUtS2Fs ZXJnaQpMLTEzNTkgTHV4ZW1ib3VyZwoKVGVsOiArMzUyIDQyNDQwOSAxCkZheDogKzM1MiA0MjI0 NzMKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRl eHQgbWFpbGluZyBsaXN0CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JhZGV4dAo= From stefan.winter@restena.lu Fri Feb 10 02:22:47 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1021F858D for ; Fri, 10 Feb 2012 02:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 y9fTPLa8biOq for ; Fri, 10 Feb 2012 02:22:47 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D523C21F8587 for ; Fri, 10 Feb 2012 02:22:46 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8D48410581; Fri, 10 Feb 2012 11:22:45 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b04b:c7f6:b06d:9434] (unknown [IPv6:2001:a18:1:8:b04b:c7f6:b06d:9434]) by smtprelay.restena.lu (Postfix) with ESMTPS id 56B7410580; Fri, 10 Feb 2012 11:22:45 +0100 (CET) Message-ID: <4F34EFF5.8090608@restena.lu> Date: Fri, 10 Feb 2012 11:22:45 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Bernard Aboba References: <20120201180357.19470.41205.idtracker@ietfa.amsl.com><4F2A5CD2.5020407@restena.lu> <0cfc01cce1c4$6c2f71b0$448e5510$@olddog.co.uk> <4F2BAFE4.7050904@restena.lu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: "'Romascanu, Dan \(Dan\)'" , draft-ietf-radext-radsec@tools.ietf.org, radext@ietf.org Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 10:22:48 -0000 Hello, > The proposed text conflates manual keying with use of a shared secret. TLS-PSK provides automated key > management as well as protected ciphersuite negotiation and is a big step forward from RFC 2865 manual > keying with deprecated algorithms. Given the discussion of RFC 4107 within RFC 6421, I'd suggest that the > context provided by RFC 6421 is important for understanding how RFC 4107 would apply to RADIUS, > particularly given the RADEXT WG's concerns about the relevance of RFC 4107. Thanks for the text suggestions - I have updated my working copy accordingly. Greetings, Stefan Winter > > > Here is are some proposed changes: > > "1.3. Document Status > > This document is an Experimental RFC. > > It is one out of several approaches to address known cryptographic > weaknesses of the RADIUS protocol (described in Section 4), as well > as to provide support for crypto-agility as described in "RADIUS Crypto-Agility > Requirements" [RFC6421]. The specification does not fulfill all recommendations > on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP > as a transport layer, it does not prevent head-of-line blocking issues. > > If this specification is indeed selected for advancement to standards > track, the process described in [RFC6421] will need to be followed and > in particular, certificate verification options (section 2.3.2) will need to be > refined. > > Another experimental characteristic of this specification is the > question of key management between RADIUS/TLS peers. RADIUS/UDP only > allowed for manual key management, i.e. distribution of a shared > secret between a client and a server. RADIUS/TLS allows manual > distribution of long-term proofs of peer identity as well (by using > TLS-PSK cipher suites, or identifying clients by a certificate > fingerprint), but as a new feature enables use of X.509 certificates > in a PKIX infrastructure. It remains to be seen if one of these methods > prevail, or if both will find their place in real-life deployments. The authors can imagine > pre-shared keys to be popular in small-scale deployments > (SOHO or isolated enterprise deployments) where scalability is not an > issue and the deployment of a CA is considered too much a hassle; but > can also imagine large roaming consortia to make use of PKIX. > Readers of this specification are encouraged to read the discussion > of key management issues within [RFC6421] as well as [RFC4107]. > > It has yet to be decided whether this approach is to be chosen for > standards track. One key aspect to judge whether the approach is > usable at large scale is by observing the uptake, usability and > operational behaviour of the protocol in large-scale, real-life > deployments. > > An example for a world-wide roaming environment that uses RADIUS over > TLS to secure communication is "eduroam", see [eduroam]. > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Stefan Winter > Sent: Friday, February 03, 2012 1:59 AM > To: Romascanu, Dan (Dan) > Cc: adrian@olddog.co.uk; draft-ietf-radext-radsec@tools.ietf.org; The IESG; radext-chairs@tools.ietf.org > Subject: Re: Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT) > > Hello all, > >> Yes, I was going to ask this during the telechat should this answer have not come. Editors, please add some text in the revised version after the telechat that shows that the issue was considered and what key management methods were taken into consideration at the time of the publication of the document. This would also provide reference for experimentation. > > Okay... how about the following text in "Document Status" (third para is > new): > > 1.3. Document Status > > This document is an Experimental RFC. > > It is one out of several approaches to address known cryptographic > weaknesses of the RADIUS protocol (see also Section 4). The > specification does not fulfill all recommendations on a AAA transport > profile as per [RFC3539]; in particular, by being based on TCP as a > transport layer, it does not prevent head-of-line blocking issues. > > If this specification is indeed selected for advancement to standards > track, certificate verification options (section 2.3.2) need to be > refined. > > Another experimental characteristic of this specification is the > question of key management between RADIUS/TLS peers. RADIUS/UDP only > allowed for manual key management, i.e. distribution of a shared > secret between a client and a server. RADIUS/TLS allows manual > distribution of long-term proofs of peer identity as well (by using > TLS-PSK cipher suites, or identifying clients by a certificate > fingerprint), but as a new feature also allows automatic key > management using X.509 certificates in a PKIX infrastructure. It > remains to be seen if one of these methods prevail, or if both will > find their place in real-life deployments. The authors can imagine > manual key distribution to be popular in small-scale deployments > (SOHO or isolated enterprise deployments) where scalability is not an > issue and the deployment of a CA is considered too much a hassle; but > can also imagine large roaming consortia to make use of PKIX. > Readers of this specification are encouraged to read [RFC4107]. > > It has yet to be decided whether this approach is to be chosen for > standards track. One key aspect to judge whether the approach is > usable at large scale is by observing the uptake, usability and > operational behaviour of the protocol in large-scale, real-life > deployments. > > An example for a world-wide roaming environment that uses RADIUS over > TLS to secure communication is "eduroam", see [eduroam]. > > If that text is sufficient to address the COMMENT (please let me know), I would issue -12 with it (this is the last pending comment). > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Fri Feb 10 02:22:49 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA2C21F858D; Fri, 10 Feb 2012 02:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328869369; bh=MgpPzTO/uldPBxZQuLtSd26SigkxvtPtVJOfthF/vz8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=i1q65zsBlLBS44aK5uNN9uvMIuOf1PUJ8JVKmMAxdri9+/8UYEYXb1Z20eWYdZhec omwIjGY0kXKS34O5p9/qEIbP7Yuwgr8bsepx8wGjM1xmD0r1DOwiUBBwdv1J+n0hPe eXLnd6rAwufln+QsEEEbX/213/JbNWca+GWkOD84= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1021F858D for ; Fri, 10 Feb 2012 02:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 y9fTPLa8biOq for ; Fri, 10 Feb 2012 02:22:47 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D523C21F8587 for ; Fri, 10 Feb 2012 02:22:46 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8D48410581; Fri, 10 Feb 2012 11:22:45 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b04b:c7f6:b06d:9434] (unknown [IPv6:2001:a18:1:8:b04b:c7f6:b06d:9434]) by smtprelay.restena.lu (Postfix) with ESMTPS id 56B7410580; Fri, 10 Feb 2012 11:22:45 +0100 (CET) Message-ID: <4F34EFF5.8090608@restena.lu> Date: Fri, 10 Feb 2012 11:22:45 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Bernard Aboba References: <20120201180357.19470.41205.idtracker@ietfa.amsl.com><4F2A5CD2.5020407@restena.lu> <0cfc01cce1c4$6c2f71b0$448e5510$@olddog.co.uk> <4F2BAFE4.7050904@restena.lu> In-Reply-To: X-Virus-Scanned: ClamAV Cc: "'Romascanu, Dan \(Dan\)'" , draft-ietf-radext-radsec@tools.ietf.org, radext@ietf.org Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org SGVsbG8sCgoKPiBUaGUgcHJvcG9zZWQgdGV4dCBjb25mbGF0ZXMgbWFudWFsIGtleWluZyB3aXRo IHVzZSBvZiBhIHNoYXJlZCBzZWNyZXQuICAgVExTLVBTSyBwcm92aWRlcyBhdXRvbWF0ZWQga2V5 Cj4gbWFuYWdlbWVudCBhcyB3ZWxsIGFzIHByb3RlY3RlZCBjaXBoZXJzdWl0ZSBuZWdvdGlhdGlv biBhbmQgaXMgYSBiaWcgc3RlcCBmb3J3YXJkIGZyb20gUkZDIDI4NjUgbWFudWFsCj4ga2V5aW5n IHdpdGggZGVwcmVjYXRlZCBhbGdvcml0aG1zLiAgR2l2ZW4gdGhlIGRpc2N1c3Npb24gb2YgUkZD IDQxMDcgd2l0aGluIFJGQyA2NDIxLCBJJ2Qgc3VnZ2VzdCB0aGF0IHRoZQo+IGNvbnRleHQgcHJv dmlkZWQgYnkgUkZDIDY0MjEgaXMgaW1wb3J0YW50IGZvciB1bmRlcnN0YW5kaW5nIGhvdyBSRkMg NDEwNyB3b3VsZCBhcHBseSB0byBSQURJVVMsCj4gcGFydGljdWxhcmx5IGdpdmVuIHRoZSBSQURF WFQgV0cncyBjb25jZXJucyBhYm91dCB0aGUgcmVsZXZhbmNlIG9mIFJGQyA0MTA3LgoKVGhhbmtz IGZvciB0aGUgdGV4dCBzdWdnZXN0aW9ucyAtIEkgaGF2ZSB1cGRhdGVkIG15IHdvcmtpbmcgY29w eSAKYWNjb3JkaW5nbHkuCgpHcmVldGluZ3MsCgpTdGVmYW4gV2ludGVyCgo+Cj4KPiBIZXJlIGlz IGFyZSBzb21lIHByb3Bvc2VkIGNoYW5nZXM6Cj4KPiAgICIxLjMuICBEb2N1bWVudCBTdGF0dXMK Pgo+ICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIEV4cGVyaW1lbnRhbCBSRkMuCj4KPiAgICAgSXQg aXMgb25lIG91dCBvZiBzZXZlcmFsIGFwcHJvYWNoZXMgdG8gYWRkcmVzcyBrbm93biBjcnlwdG9n cmFwaGljCj4gICAgIHdlYWtuZXNzZXMgb2YgdGhlIFJBRElVUyBwcm90b2NvbCAoZGVzY3JpYmVk IGluIFNlY3Rpb24gNCksIGFzIHdlbGwKPiAgICAgYXMgdG8gcHJvdmlkZSBzdXBwb3J0IGZvciBj cnlwdG8tYWdpbGl0eSBhcyBkZXNjcmliZWQgaW4gIlJBRElVUyBDcnlwdG8tQWdpbGl0eQo+ICAg ICBSZXF1aXJlbWVudHMiIFtSRkM2NDIxXS4gIFRoZSBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGZ1 bGZpbGwgYWxsIHJlY29tbWVuZGF0aW9ucwo+ICAgICBvbiBhIEFBQSB0cmFuc3BvcnQgcHJvZmls ZSBhcyBwZXIgW1JGQzM1MzldOyBpbiBwYXJ0aWN1bGFyLCBieSBiZWluZyBiYXNlZCBvbiBUQ1AK PiAgICAgYXMgYSB0cmFuc3BvcnQgbGF5ZXIsIGl0IGRvZXMgbm90IHByZXZlbnQgaGVhZC1vZi1s aW5lIGJsb2NraW5nIGlzc3Vlcy4KPgo+ICAgICBJZiB0aGlzIHNwZWNpZmljYXRpb24gaXMgaW5k ZWVkIHNlbGVjdGVkIGZvciBhZHZhbmNlbWVudCB0byBzdGFuZGFyZHMKPiAgICAgdHJhY2ssIHRo ZSBwcm9jZXNzIGRlc2NyaWJlZCBpbiBbUkZDNjQyMV0gd2lsbCBuZWVkIHRvIGJlIGZvbGxvd2Vk IGFuZAo+ICAgICBpbiBwYXJ0aWN1bGFyLCBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb24gb3B0aW9u cyAoc2VjdGlvbiAyLjMuMikgd2lsbCBuZWVkIHRvIGJlCj4gICAgIHJlZmluZWQuCj4KPiAgICAg QW5vdGhlciBleHBlcmltZW50YWwgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u IGlzIHRoZQo+ICAgICBxdWVzdGlvbiBvZiBrZXkgbWFuYWdlbWVudCBiZXR3ZWVuIFJBRElVUy9U TFMgcGVlcnMuICBSQURJVVMvVURQIG9ubHkKPiAgICAgYWxsb3dlZCBmb3IgbWFudWFsIGtleSBt YW5hZ2VtZW50LCBpLmUuIGRpc3RyaWJ1dGlvbiBvZiBhIHNoYXJlZAo+ICAgICBzZWNyZXQgYmV0 d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuICBSQURJVVMvVExTIGFsbG93cyBtYW51YWwKPiAg ICAgZGlzdHJpYnV0aW9uIG9mIGxvbmctdGVybSBwcm9vZnMgb2YgcGVlciBpZGVudGl0eSBhcyB3 ZWxsIChieSB1c2luZwo+ICAgICBUTFMtUFNLIGNpcGhlciBzdWl0ZXMsIG9yIGlkZW50aWZ5aW5n IGNsaWVudHMgYnkgYSBjZXJ0aWZpY2F0ZQo+ICAgICBmaW5nZXJwcmludCksIGJ1dCBhcyBhIG5l dyBmZWF0dXJlIGVuYWJsZXMgdXNlIG9mIFguNTA5IGNlcnRpZmljYXRlcwo+ICAgICBpbiBhIFBL SVggaW5mcmFzdHJ1Y3R1cmUuICBJdCByZW1haW5zIHRvIGJlIHNlZW4gaWYgb25lIG9mIHRoZXNl IG1ldGhvZHMKPiAgICAgcHJldmFpbCwgb3IgaWYgYm90aCB3aWxsIGZpbmQgdGhlaXIgcGxhY2Ug aW4gcmVhbC1saWZlIGRlcGxveW1lbnRzLiAgVGhlIGF1dGhvcnMgY2FuIGltYWdpbmUKPiAgICAg cHJlLXNoYXJlZCBrZXlzIHRvIGJlIHBvcHVsYXIgaW4gc21hbGwtc2NhbGUgZGVwbG95bWVudHMK PiAgICAgKFNPSE8gb3IgaXNvbGF0ZWQgZW50ZXJwcmlzZSBkZXBsb3ltZW50cykgd2hlcmUgc2Nh bGFiaWxpdHkgaXMgbm90IGFuCj4gICAgIGlzc3VlIGFuZCB0aGUgZGVwbG95bWVudCBvZiBhIENB IGlzIGNvbnNpZGVyZWQgdG9vIG11Y2ggYSBoYXNzbGU7IGJ1dAo+ICAgICBjYW4gYWxzbyBpbWFn aW5lIGxhcmdlIHJvYW1pbmcgY29uc29ydGlhIHRvIG1ha2UgdXNlIG9mIFBLSVguCj4gICAgIFJl YWRlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGFyZSBlbmNvdXJhZ2VkIHRvIHJlYWQgdGhlIGRp c2N1c3Npb24KPiAgICAgb2Yga2V5IG1hbmFnZW1lbnQgaXNzdWVzIHdpdGhpbiBbUkZDNjQyMV0g YXMgd2VsbCBhcyBbUkZDNDEwN10uCj4KPiAgICAgSXQgaGFzIHlldCB0byBiZSBkZWNpZGVkIHdo ZXRoZXIgdGhpcyBhcHByb2FjaCBpcyB0byBiZSBjaG9zZW4gZm9yCj4gICAgIHN0YW5kYXJkcyB0 cmFjay4gIE9uZSBrZXkgYXNwZWN0IHRvIGp1ZGdlIHdoZXRoZXIgdGhlIGFwcHJvYWNoIGlzCj4g ICAgIHVzYWJsZSBhdCBsYXJnZSBzY2FsZSBpcyBieSBvYnNlcnZpbmcgdGhlIHVwdGFrZSwgdXNh YmlsaXR5IGFuZAo+ICAgICBvcGVyYXRpb25hbCBiZWhhdmlvdXIgb2YgdGhlIHByb3RvY29sIGlu IGxhcmdlLXNjYWxlLCByZWFsLWxpZmUKPiAgICAgZGVwbG95bWVudHMuCj4KPiAgICAgQW4gZXhh bXBsZSBmb3IgYSB3b3JsZC13aWRlIHJvYW1pbmcgZW52aXJvbm1lbnQgdGhhdCB1c2VzIFJBRElV UyBvdmVyCj4gICAgIFRMUyB0byBzZWN1cmUgY29tbXVuaWNhdGlvbiBpcyAiZWR1cm9hbSIsIHNl ZSBbZWR1cm9hbV0uCj4KPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogaWVz Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU3RlZmFuIFdpbnRlcgo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTIgMTo1 OSBBTQo+IFRvOiBSb21hc2NhbnUsIERhbiAoRGFuKQo+IENjOiBhZHJpYW5Ab2xkZG9nLmNvLnVr OyBkcmFmdC1pZXRmLXJhZGV4dC1yYWRzZWNAdG9vbHMuaWV0Zi5vcmc7IFRoZSBJRVNHOyByYWRl eHQtY2hhaXJzQHRvb2xzLmlldGYub3JnCj4gU3ViamVjdDogUmU6IEFkcmlhbiBGYXJyZWwncyBO byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1yYWRleHQtcmFkc2VjLTExOih3aXRoIENPTU1FTlQp Cj4KPiBIZWxsbyBhbGwsCj4KPj4gWWVzLCBJIHdhcyBnb2luZyB0byBhc2sgdGhpcyBkdXJpbmcg dGhlIHRlbGVjaGF0IHNob3VsZCB0aGlzIGFuc3dlciBoYXZlIG5vdCBjb21lLiBFZGl0b3JzLCBw bGVhc2UgYWRkIHNvbWUgdGV4dCBpbiB0aGUgcmV2aXNlZCB2ZXJzaW9uIGFmdGVyIHRoZSB0ZWxl Y2hhdCB0aGF0IHNob3dzIHRoYXQgdGhlIGlzc3VlIHdhcyBjb25zaWRlcmVkIGFuZCB3aGF0IGtl eSBtYW5hZ2VtZW50IG1ldGhvZHMgd2VyZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24gYXQgdGhl IHRpbWUgb2YgdGhlIHB1YmxpY2F0aW9uIG9mIHRoZSBkb2N1bWVudC4gVGhpcyB3b3VsZCBhbHNv IHByb3ZpZGUgcmVmZXJlbmNlIGZvciBleHBlcmltZW50YXRpb24uCj4KPiBPa2F5Li4uIGhvdyBh Ym91dCB0aGUgZm9sbG93aW5nIHRleHQgaW4gIkRvY3VtZW50IFN0YXR1cyIgKHRoaXJkIHBhcmEg aXMKPiBuZXcpOgo+Cj4gMS4zLiAgRG9jdW1lbnQgU3RhdHVzCj4KPiAgICAgVGhpcyBkb2N1bWVu dCBpcyBhbiBFeHBlcmltZW50YWwgUkZDLgo+Cj4gICAgIEl0IGlzIG9uZSBvdXQgb2Ygc2V2ZXJh bCBhcHByb2FjaGVzIHRvIGFkZHJlc3Mga25vd24gY3J5cHRvZ3JhcGhpYwo+ICAgICB3ZWFrbmVz c2VzIG9mIHRoZSBSQURJVVMgcHJvdG9jb2wgKHNlZSBhbHNvIFNlY3Rpb24gNCkuICBUaGUKPiAg ICAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBmdWxmaWxsIGFsbCByZWNvbW1lbmRhdGlvbnMgb24g YSBBQUEgdHJhbnNwb3J0Cj4gICAgIHByb2ZpbGUgYXMgcGVyIFtSRkMzNTM5XTsgaW4gcGFydGlj dWxhciwgYnkgYmVpbmcgYmFzZWQgb24gVENQIGFzIGEKPiAgICAgdHJhbnNwb3J0IGxheWVyLCBp dCBkb2VzIG5vdCBwcmV2ZW50IGhlYWQtb2YtbGluZSBibG9ja2luZyBpc3N1ZXMuCj4KPiAgICAg SWYgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluZGVlZCBzZWxlY3RlZCBmb3IgYWR2YW5jZW1lbnQg dG8gc3RhbmRhcmRzCj4gICAgIHRyYWNrLCBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb24gb3B0aW9u cyAoc2VjdGlvbiAyLjMuMikgbmVlZCB0byBiZQo+ICAgICByZWZpbmVkLgo+Cj4gICAgIEFub3Ro ZXIgZXhwZXJpbWVudGFsIGNoYXJhY3RlcmlzdGljIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0 aGUKPiAgICAgcXVlc3Rpb24gb2Yga2V5IG1hbmFnZW1lbnQgYmV0d2VlbiBSQURJVVMvVExTIHBl ZXJzLiAgUkFESVVTL1VEUCBvbmx5Cj4gICAgIGFsbG93ZWQgZm9yIG1hbnVhbCBrZXkgbWFuYWdl bWVudCwgaS5lLiBkaXN0cmlidXRpb24gb2YgYSBzaGFyZWQKPiAgICAgc2VjcmV0IGJldHdlZW4g YSBjbGllbnQgYW5kIGEgc2VydmVyLiAgUkFESVVTL1RMUyBhbGxvd3MgbWFudWFsCj4gICAgIGRp c3RyaWJ1dGlvbiBvZiBsb25nLXRlcm0gcHJvb2ZzIG9mIHBlZXIgaWRlbnRpdHkgYXMgd2VsbCAo YnkgdXNpbmcKPiAgICAgVExTLVBTSyBjaXBoZXIgc3VpdGVzLCBvciBpZGVudGlmeWluZyBjbGll bnRzIGJ5IGEgY2VydGlmaWNhdGUKPiAgICAgZmluZ2VycHJpbnQpLCBidXQgYXMgYSBuZXcgZmVh dHVyZSBhbHNvIGFsbG93cyBhdXRvbWF0aWMga2V5Cj4gICAgIG1hbmFnZW1lbnQgdXNpbmcgWC41 MDkgY2VydGlmaWNhdGVzIGluIGEgUEtJWCBpbmZyYXN0cnVjdHVyZS4gIEl0Cj4gICAgIHJlbWFp bnMgdG8gYmUgc2VlbiBpZiBvbmUgb2YgdGhlc2UgbWV0aG9kcyBwcmV2YWlsLCBvciBpZiBib3Ro IHdpbGwKPiAgICAgZmluZCB0aGVpciBwbGFjZSBpbiByZWFsLWxpZmUgZGVwbG95bWVudHMuICBU aGUgYXV0aG9ycyBjYW4gaW1hZ2luZQo+ICAgICBtYW51YWwga2V5IGRpc3RyaWJ1dGlvbiB0byBi ZSBwb3B1bGFyIGluIHNtYWxsLXNjYWxlIGRlcGxveW1lbnRzCj4gICAgIChTT0hPIG9yIGlzb2xh dGVkIGVudGVycHJpc2UgZGVwbG95bWVudHMpIHdoZXJlIHNjYWxhYmlsaXR5IGlzIG5vdCBhbgo+ ICAgICBpc3N1ZSBhbmQgdGhlIGRlcGxveW1lbnQgb2YgYSBDQSBpcyBjb25zaWRlcmVkIHRvbyBt dWNoIGEgaGFzc2xlOyBidXQKPiAgICAgY2FuIGFsc28gaW1hZ2luZSBsYXJnZSByb2FtaW5nIGNv bnNvcnRpYSB0byBtYWtlIHVzZSBvZiBQS0lYLgo+ICAgICBSZWFkZXJzIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiBhcmUgZW5jb3VyYWdlZCB0byByZWFkIFtSRkM0MTA3XS4KPgo+ICAgICBJdCBoYXMg eWV0IHRvIGJlIGRlY2lkZWQgd2hldGhlciB0aGlzIGFwcHJvYWNoIGlzIHRvIGJlIGNob3NlbiBm b3IKPiAgICAgc3RhbmRhcmRzIHRyYWNrLiAgT25lIGtleSBhc3BlY3QgdG8ganVkZ2Ugd2hldGhl ciB0aGUgYXBwcm9hY2ggaXMKPiAgICAgdXNhYmxlIGF0IGxhcmdlIHNjYWxlIGlzIGJ5IG9ic2Vy dmluZyB0aGUgdXB0YWtlLCB1c2FiaWxpdHkgYW5kCj4gICAgIG9wZXJhdGlvbmFsIGJlaGF2aW91 ciBvZiB0aGUgcHJvdG9jb2wgaW4gbGFyZ2Utc2NhbGUsIHJlYWwtbGlmZQo+ICAgICBkZXBsb3lt ZW50cy4KPgo+ICAgICBBbiBleGFtcGxlIGZvciBhIHdvcmxkLXdpZGUgcm9hbWluZyBlbnZpcm9u bWVudCB0aGF0IHVzZXMgUkFESVVTIG92ZXIKPiAgICAgVExTIHRvIHNlY3VyZSBjb21tdW5pY2F0 aW9uIGlzICJlZHVyb2FtIiwgc2VlIFtlZHVyb2FtXS4KPgo+IElmIHRoYXQgdGV4dCBpcyBzdWZm aWNpZW50IHRvIGFkZHJlc3MgdGhlIENPTU1FTlQgKHBsZWFzZSBsZXQgbWUga25vdyksIEkgd291 bGQgaXNzdWUgLTEyIHdpdGggaXQgKHRoaXMgaXMgdGhlIGxhc3QgcGVuZGluZyBjb21tZW50KS4K Pgo+IEdyZWV0aW5ncywKPgo+IFN0ZWZhbiBXaW50ZXIKPgo+IC0tCj4gU3RlZmFuIFdJTlRFUgo+ IEluZ2VuaWV1ciBkZSBSZWNoZXJjaGUKPiBGb25kYXRpb24gUkVTVEVOQSAtIFLDqXNlYXUgVMOp bMOpaW5mb3JtYXRpcXVlIGRlIGwnRWR1Y2F0aW9uIE5hdGlvbmFsZSBldCBkZSBsYSBSZWNoZXJj aGUgNiwgcnVlIFJpY2hhcmQgQ291ZGVuaG92ZS1LYWxlcmdpCj4gTC0xMzU5IEx1eGVtYm91cmcK Pgo+IFRlbDogKzM1MiA0MjQ0MDkgMQo+IEZheDogKzM1MiA0MjI0NzMKPgo+CgoKLS0gClN0ZWZh biBXSU5URVIKSW5nZW5pZXVyIGRlIFJlY2hlcmNoZQpGb25kYXRpb24gUkVTVEVOQSAtIFLDqXNl YXUgVMOpbMOpaW5mb3JtYXRpcXVlIGRlIGwnRWR1Y2F0aW9uIE5hdGlvbmFsZSBldCAKZGUgbGEg UmVjaGVyY2hlCjYsIHJ1ZSBSaWNoYXJkIENvdWRlbmhvdmUtS2FsZXJnaQpMLTEzNTkgTHV4ZW1i b3VyZwoKVGVsOiArMzUyIDQyNDQwOSAxCkZheDogKzM1MiA0MjI0NzMKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApyYWRl eHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQK From internet-drafts@ietf.org Mon Feb 13 22:52:29 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0129C21E8013; Mon, 13 Feb 2012 22:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 HA-XneZFKHsz; Mon, 13 Feb 2012 22:52:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF021F86EE; Mon, 13 Feb 2012 22:52:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 22:52:06 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 06:52:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : Transport Layer Security (TLS) encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-12.txt Pages : 23 Date : 2012-02-13 This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt From radext-bounces@ietf.org Mon Feb 13 22:52:33 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752CC21E8025; Mon, 13 Feb 2012 22:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329202353; bh=Z8oAklMMhv+MOfuZiuDpufb1LFNuCTcmEutjqZBxVi8=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=eHttIQbrMX0MX38oOUKUtrMB3OflmEHWNKzKF2ni6Q9W8N0iAZ0n1E+kRyXgmPRJA d+vI5AfjYNQy6M3frBFknOlR/Xwkl+9nPsH8n/vfxmVDHvLi0BSgbVmzUFQfRL9fJL nMHhNUWmpB+vM0Ff0Fdn58lAv3C+7IOHksYXfJPo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0129C21E8013; Mon, 13 Feb 2012 22:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 HA-XneZFKHsz; Mon, 13 Feb 2012 22:52:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF021F86EE; Mon, 13 Feb 2012 22:52:06 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 22:52:06 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Transport Layer Security (TLS) encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-12.txt Pages : 23 Date : 2012-02-13 This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Mon Feb 13 22:58:17 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3BA21E803C for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 SBq3yFCPeRYe for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8021E8040 for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 046A61057F for ; Tue, 14 Feb 2012 07:58:16 +0100 (CET) Received: from [IPv6:2001:a18:1:8:95da:6258:fbd1:df07] (unknown [IPv6:2001:a18:1:8:95da:6258:fbd1:df07]) by smtprelay.restena.lu (Postfix) with ESMTPS id E93AA1057D for ; Tue, 14 Feb 2012 07:58:15 +0100 (CET) Message-ID: <4F3A0607.30108@restena.lu> Date: Tue, 14 Feb 2012 07:58:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> In-Reply-To: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 06:58:17 -0000 Hello, this draft is the result of the IESG review phase; it addresses the DISCUSSes and COMMENTs that came up during the review. If you're interested in the text changes, please take a look at the diff! Greetings, Stefan Winter > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : Transport Layer Security (TLS) encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-12.txt > Pages : 23 > Date : 2012-02-13 > > This document specifies a transport profile for RADIUS using > Transport Layer Security (TLS) over TCP as the transport protocol. > This enables dynamic trust relationships between RADIUS servers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Mon Feb 13 22:58:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC94121E8040; Mon, 13 Feb 2012 22:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329202698; bh=J0VAJZgATY5QKVUj49DFnRde1S2KV0BtVmx0sG/GAD8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=zYz/XmMJBAqvdJXUO3N3Bwsg7MxxajiMSvD7HzkUDOJ5Ry6i4oPJeKkxXQase7QaW pgQ6lz54hd0qTtmgSajNQHyfQ2NNfsVkeagXuNPeDSLIocWadMYw3xGEc9iPrXICOy N3UAJItCl8oL80fPf0J+YAhTaZzVvd92f50XXnaY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3BA21E803C for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 SBq3yFCPeRYe for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8021E8040 for ; Mon, 13 Feb 2012 22:58:17 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 046A61057F for ; Tue, 14 Feb 2012 07:58:16 +0100 (CET) Received: from [IPv6:2001:a18:1:8:95da:6258:fbd1:df07] (unknown [IPv6:2001:a18:1:8:95da:6258:fbd1:df07]) by smtprelay.restena.lu (Postfix) with ESMTPS id E93AA1057D for ; Tue, 14 Feb 2012 07:58:15 +0100 (CET) Message-ID: <4F3A0607.30108@restena.lu> Date: Tue, 14 Feb 2012 07:58:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> In-Reply-To: <20120214065206.11507.11972.idtracker@ietfa.amsl.com> X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hello, this draft is the result of the IESG review phase; it addresses the = DISCUSSes and COMMENTs that came up during the review. If you're = interested in the text changes, please take a look at the diff! Greetings, Stefan Winter > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the RADIUS EXTensions Working Group of = the IETF. > > Title : Transport Layer Security (TLS) encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-12.txt > Pages : 23 > Date : 2012-02-13 > > This document specifies a transport profile for RADIUS using > Transport Layer Security (TLS) over TCP as the transport protocol. > This enables dynamic trust relationships between RADIUS servers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-12.txt > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et = de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Wed Feb 15 03:25:39 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5031C21F87D7 for ; Wed, 15 Feb 2012 03:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.811 X-Spam-Level: X-Spam-Status: No, score=-6.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqxOguTrW1ap for ; Wed, 15 Feb 2012 03:25:38 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3F30C21F85A4 for ; Wed, 15 Feb 2012 03:25:24 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF006TRMAYUZ@szxga04-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:23:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00HMBMAY7X@szxga04-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:23:22 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD27911; Wed, 15 Feb 2012 19:23:19 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 19:23:12 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 19:23:11 +0800 Date: Wed, 15 Feb 2012 11:23:11 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 11:25:39 -0000 The following might be Editorial Errata against RFC6158. Section 2.1, Original Text: Note that the length limitations for VSAs of type String and Text are less than 253 octets, due to the additional overhead of the Vendor- Specific encoding. Corrected Text -1 might be: 'Note that the length limitations for VSAs of type String and Text are less than 247 octets, due to the additional overhead of the Vendor- Specific encoding.' If it complies with the text, 'For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute.', in section 3.2.1 of RFC6158. Corrected Text -2 might be: 'Note that the length limitations for VSAs of type String and Text are less than 249 octets, due to the additional overhead of the Vendor- Specific encoding.' If it complies with the definition of VAS in section 5.26 of RFC2865. Corrected Text -3 might be: 'Note that the length limitations for VSAs of type String and Text are less than 248 octets, due to the additional overhead of the Vendor- Specific encoding.' If it adopts the format meaningfully in the section of 4.1 of draft-ietf-radext-radius-extensions-04.txt. Right? Best Regards, Leaf From radext-bounces@ietf.org Wed Feb 15 03:25:40 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C721F87DB; Wed, 15 Feb 2012 03:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329305140; bh=FyXhr9MX/xwF88oqpvz7dwibQDRf1PWn6fwwxwCJOKM=; h=Date:From:To:Message-id:MIME-version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=lRTS+0jWQ5P16eyNYwWPFU6TsGz5cG28NyJhGubXMNuk39I15wxsnEOcrhg2MBhaH 6NHeaQzhxtoPR9OrEbyj9I6lZoxLKbrebionyyablntKZ05t0UUUVddNnAYd41RFy4 A1RY9TduQRmD7Fc23CbWc6WJ323LIKT2qFuRMGlM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5031C21F87D7 for ; Wed, 15 Feb 2012 03:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.811 X-Spam-Level: X-Spam-Status: No, score=-6.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqxOguTrW1ap for ; Wed, 15 Feb 2012 03:25:38 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3F30C21F85A4 for ; Wed, 15 Feb 2012 03:25:24 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF006TRMAYUZ@szxga04-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:23:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00HMBMAY7X@szxga04-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:23:22 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD27911; Wed, 15 Feb 2012 19:23:19 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 19:23:12 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 19:23:11 +0800 Date: Wed, 15 Feb 2012 11:23:11 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org The following might be Editorial Errata against RFC6158. Section 2.1, Original Text: Note that the length limitations for VSAs of type String and Text are less than 253 octets, due to the additional overhead of the Vendor- Specific encoding. Corrected Text -1 might be: 'Note that the length limitations for VSAs of type String and Text are less than 247 octets, due to the additional overhead of the Vendor- Specific encoding.' If it complies with the text, 'For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute.', in section 3.2.1 of RFC6158. Corrected Text -2 might be: 'Note that the length limitations for VSAs of type String and Text are less than 249 octets, due to the additional overhead of the Vendor- Specific encoding.' If it complies with the definition of VAS in section 5.26 of RFC2865. Corrected Text -3 might be: 'Note that the length limitations for VSAs of type String and Text are less than 248 octets, due to the additional overhead of the Vendor- Specific encoding.' If it adopts the format meaningfully in the section of 4.1 of draft-ietf-radext-radius-extensions-04.txt. Right? Best Regards, Leaf _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Wed Feb 15 03:27:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9C21F85C3 for ; Wed, 15 Feb 2012 03:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.788 X-Spam-Level: X-Spam-Status: No, score=-6.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXrMOG8LoZkH for ; Wed, 15 Feb 2012 03:27:42 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7151E21F85B7 for ; Wed, 15 Feb 2012 03:27:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF003NLMEEAC@szxga03-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:25:26 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00H2ZMEDS7@szxga03-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:25:26 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD27989; Wed, 15 Feb 2012 19:24:30 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 19:24:25 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 19:24:23 +0800 Date: Wed, 15 Feb 2012 11:24:22 +0000 From: Leaf yeh In-reply-to: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> Cc: "radext@ietf.org" , Wojciech Dec , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 11:27:46 -0000 After reading and employed the RFC6158, Radius Design Guidelines, could it be concluded the attribute of Route-IPv6-Information defined in the draft-ietf-radext-ipv6-access-06 shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix-Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Prefix (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20; typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. is creating a new 'Complex Data Type', which has multi-fields, and is not recommended? Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, November 14, 2011 9:48 AM To: i-d-announce@ietf.org Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Benoit Lourdelet Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Filename : draft-ietf-radext-ipv6-access-06.txt Pages : 15 Date : 2011-11-13 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-06.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Feb 15 03:27:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002D421F85C3; Wed, 15 Feb 2012 03:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329305268; bh=4boQhkoYzcpuYJ5w+LYubqFtnJhk6ycvoemYoQooAqY=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aUde7Hy67vNVztL8d6G2b/TnEr2vBAjz656/g405n3scrkuNu20kgMzaCwZOs4+tn 7RomPMvPxruDGhJZsb8coxBO0a3BeQvdoqf/XKNpZJCoAD1qOOPbv5E9R69VZgX+ej 6fGp5fcg/QMAaNlMF8WX3kNprX4iJT8P1y5WZxh8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9C21F85C3 for ; Wed, 15 Feb 2012 03:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.788 X-Spam-Level: X-Spam-Status: No, score=-6.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXrMOG8LoZkH for ; Wed, 15 Feb 2012 03:27:42 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7151E21F85B7 for ; Wed, 15 Feb 2012 03:27:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF003NLMEEAC@szxga03-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:25:26 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00H2ZMEDS7@szxga03-in.huawei.com> for radext@ietf.org; Wed, 15 Feb 2012 19:25:26 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD27989; Wed, 15 Feb 2012 19:24:30 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 19:24:25 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 19:24:23 +0800 Date: Wed, 15 Feb 2012 11:24:22 +0000 From: Leaf yeh In-reply-to: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> Cc: "radext@ietf.org" , Wojciech Dec , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org After reading and employed the RFC6158, Radius Design Guidelines, could it be concluded the attribute of Route-IPv6-Information defined in the draft-ietf-radext-ipv6-access-06 shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix-Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Prefix (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20; typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. is creating a new 'Complex Data Type', which has multi-fields, and is not recommended? Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, November 14, 2011 9:48 AM To: i-d-announce@ietf.org Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Benoit Lourdelet Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Filename : draft-ietf-radext-ipv6-access-06.txt Pages : 15 Date : 2011-11-13 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-06.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Feb 15 03:58:32 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF2621F87AE; Wed, 15 Feb 2012 03:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329307112; bh=oKczUai1scMxb00SdZlUoeB4l8lAWWrKYyQa+MS4l6w=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RvZQsidQ3yHbmzCC2miP1GF7YmpompkK+O47gmYFfO1V2RCerwZrVC4/YijC8zyUU 4pIJvvbNpP9qCRob/1BlXX4vCXDmBH31xYMY76PX7uH0QbUCrs7K/jAT0Go+7Lp/Sc e51aOUqDnhsyL+oq2Kj9mOD48+vzdOt18fEzvxOI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5D21F87AE for ; Wed, 15 Feb 2012 03:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 1pTN3I3fAGM7 for ; Wed, 15 Feb 2012 03:58:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CA94021F87A1 for ; Wed, 15 Feb 2012 03:58:30 -0800 (PST) Message-ID: <4F3B9DC7.8050607@deployingradius.com> Date: Wed, 15 Feb 2012 12:57:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > The following might be Editorial Errata against RFC6158. > > Section 2.1, Original Text: > > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. > > > Corrected Text -1 might be: First, what's wrong with the text? It's factually accurate. The context of the text is important. The line before it says about Basic Data Types: * UTF-8 text [RFC3629], totaling 253 octets or less in length. So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. There is no need for that section to enumerate all of the possible length limitations of attributes. There is *absolutely* no need for RFC 6158 to note length limitations based on the extensions draft. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Wed Feb 15 03:58:31 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5D21F87AE for ; Wed, 15 Feb 2012 03:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 1pTN3I3fAGM7 for ; Wed, 15 Feb 2012 03:58:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CA94021F87A1 for ; Wed, 15 Feb 2012 03:58:30 -0800 (PST) Message-ID: <4F3B9DC7.8050607@deployingradius.com> Date: Wed, 15 Feb 2012 12:57:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 11:58:31 -0000 Leaf yeh wrote: > The following might be Editorial Errata against RFC6158. > > Section 2.1, Original Text: > > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. > > > Corrected Text -1 might be: First, what's wrong with the text? It's factually accurate. The context of the text is important. The line before it says about Basic Data Types: * UTF-8 text [RFC3629], totaling 253 octets or less in length. So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. There is no need for that section to enumerate all of the possible length limitations of attributes. There is *absolutely* no need for RFC 6158 to note length limitations based on the extensions draft. Alan DeKok. From aland@deployingradius.com Wed Feb 15 04:06:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4C521F86CA for ; Wed, 15 Feb 2012 04:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 TGtp6jKoWGii for ; Wed, 15 Feb 2012 04:06:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4F21F86B4 for ; Wed, 15 Feb 2012 04:06:08 -0800 (PST) Message-ID: <4F3B9F95.3030804@deployingradius.com> Date: Wed, 15 Feb 2012 13:05:41 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , Wojciech Dec , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:06:11 -0000 Leaf yeh wrote: > After reading and employed the RFC6158, Radius Design Guidelines, could it be concluded the attribute of Route-IPv6-Information defined in the draft-ietf-radext-ipv6-access-06 shown as follows: .. > is creating a new 'Complex Data Type', which has multi-fields, and is not recommended? That is what the document says. > Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? No. I could explain here, but there's no need. Read RFC 6158. It thoroughly details the rationale behind the design guidelines. Alan DeKok. From radext-bounces@ietf.org Wed Feb 15 04:06:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8821F86CA; Wed, 15 Feb 2012 04:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329307572; bh=1saQVpJG7MAGcVYGndNcYw/ji+UZ2UIzB9Oy7nQHQVI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QT4pAny3XFEXA8rgtoAlsFgD59Wc1Njdks4e4tbDWB7fxZu/SEo9AbIjua48t6roD PTKuv6MdUUlA1QjWnnHtpVjYwpMqnGwCaU2OMORr/abhEUYjQaFD0sDvurSf5S/KYv fOTrYnLuCt3iNpbkJtGCLczpDpYKLdgjTnva1+j4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4C521F86CA for ; Wed, 15 Feb 2012 04:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 TGtp6jKoWGii for ; Wed, 15 Feb 2012 04:06:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4F21F86B4 for ; Wed, 15 Feb 2012 04:06:08 -0800 (PST) Message-ID: <4F3B9F95.3030804@deployingradius.com> Date: Wed, 15 Feb 2012 13:05:41 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , Wojciech Dec , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > After reading and employed the RFC6158, Radius Design Guidelines, could it be concluded the attribute of Route-IPv6-Information defined in the draft-ietf-radext-ipv6-access-06 shown as follows: .. > is creating a new 'Complex Data Type', which has multi-fields, and is not recommended? That is what the document says. > Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? No. I could explain here, but there's no need. Read RFC 6158. It thoroughly details the rationale behind the design guidelines. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Feb 15 04:24:06 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410DE21F86A8; Wed, 15 Feb 2012 04:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329308646; bh=yy0HjkX7utu5XytZ4PsE1ZqHp59tz1b9+TrJ/6NKats=; h=Date:From:To:Message-ID:In-Reply-To:Mime-version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=umJoOsv/CuiDMQLEiKCZOx6XOJcm6SdliANdwjZFMXBWfWCEoBpZE55mbI2wzzyHc H8PrmUa5JMjqoRIKnVBKh5/Caa/r8zWIbjbFLip7FWq1MLQpNYNOfQaQcWNlXsYWv+ nmdH9Kmb0j1LQKwe6cM525TbiatNb0eVa3B9MliI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3021F86BD for ; Wed, 15 Feb 2012 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 vxhoVyledh-r for ; Wed, 15 Feb 2012 04:24:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF621F86B6 for ; Wed, 15 Feb 2012 04:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1013; q=dns/txt; s=iport; t=1329308641; x=1330518241; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=8KlLM+MY2+Xea5NAc+1VAxSxC3/kb0gBBBk+R0mrtb0=; b=MEbFF59kr4XVafBp06qpCJztcUqnkL16x9PrfHoJjAt9WL1ivhtDrVAh zB/vVBg/n3K4JDKXdQGG9ZTcSjhilCho7agzB2m9BTuUOZVT0+oSsIzmz vclD6GlgVr/DYJ3rQlimFVCv+rd/xHvfK/ZEFRGGSGIyLyChiYnJRxPnf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANaiO0+Q/khR/2dsb2JhbABDsEyBB4FyAQEBAwESAScCATwFDQEIGIEFAQEEAQ0FIoddCZpwAZ5UjC4BAiwGAQgIA4NxBwYDCAmDMQSVNpJp X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="129488348" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2012 12:23:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1FCNvHl017501; Wed, 15 Feb 2012 12:23:57 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 13:23:57 +0100 Received: from 10.55.82.53 ([10.55.82.53]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Feb 2012 12:23:56 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 15 Feb 2012 13:23:54 +0100 From: Wojciech Dec To: Alan DeKok , Leaf yeh Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Aczr3K6CdMIMk/f+9Eu4fcUZaUaGTg== In-Reply-To: <4F3B9F95.3030804@deployingradius.com> Mime-version: 1.0 X-OriginalArrivalTime: 15 Feb 2012 12:23:57.0084 (UTC) FILETIME=[B058BDC0:01CCEBDC] Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Just as an FYI, the Route-IPv6-Information attribute changed from its previous "non complex" to the current form between draft 04 and 05, based on WG review/feedback: http://trac.tools.ietf.org/wg/radext/trac/ticket/71 -Wojciech. On 15/02/2012 13:05, "Alan DeKok" wrote: > Leaf yeh wrote: >> After reading and employed the RFC6158, Radius Design Guidelines, could it be >> concluded the attribute of Route-IPv6-Information defined in the >> draft-ietf-radext-ipv6-access-06 shown as follows: > .. >> is creating a new 'Complex Data Type', which has multi-fields, and is not >> recommended? > > That is what the document says. > >> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and >> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? > > No. > > I could explain here, but there's no need. Read RFC 6158. It > thoroughly details the rationale behind the design guidelines. > > Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wdec@cisco.com Wed Feb 15 04:24:05 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3021F86BD for ; Wed, 15 Feb 2012 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 vxhoVyledh-r for ; Wed, 15 Feb 2012 04:24:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF621F86B6 for ; Wed, 15 Feb 2012 04:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1013; q=dns/txt; s=iport; t=1329308641; x=1330518241; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=8KlLM+MY2+Xea5NAc+1VAxSxC3/kb0gBBBk+R0mrtb0=; b=MEbFF59kr4XVafBp06qpCJztcUqnkL16x9PrfHoJjAt9WL1ivhtDrVAh zB/vVBg/n3K4JDKXdQGG9ZTcSjhilCho7agzB2m9BTuUOZVT0+oSsIzmz vclD6GlgVr/DYJ3rQlimFVCv+rd/xHvfK/ZEFRGGSGIyLyChiYnJRxPnf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANaiO0+Q/khR/2dsb2JhbABDsEyBB4FyAQEBAwESAScCATwFDQEIGIEFAQEEAQ0FIoddCZpwAZ5UjC4BAiwGAQgIA4NxBwYDCAmDMQSVNpJp X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="129488348" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2012 12:23:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1FCNvHl017501; Wed, 15 Feb 2012 12:23:57 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 13:23:57 +0100 Received: from 10.55.82.53 ([10.55.82.53]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Feb 2012 12:23:56 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 15 Feb 2012 13:23:54 +0100 From: Wojciech Dec To: Alan DeKok , Leaf yeh Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Aczr3K6CdMIMk/f+9Eu4fcUZaUaGTg== In-Reply-To: <4F3B9F95.3030804@deployingradius.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Feb 2012 12:23:57.0084 (UTC) FILETIME=[B058BDC0:01CCEBDC] Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:24:05 -0000 Just as an FYI, the Route-IPv6-Information attribute changed from its previous "non complex" to the current form between draft 04 and 05, based on WG review/feedback: http://trac.tools.ietf.org/wg/radext/trac/ticket/71 -Wojciech. On 15/02/2012 13:05, "Alan DeKok" wrote: > Leaf yeh wrote: >> After reading and employed the RFC6158, Radius Design Guidelines, could it be >> concluded the attribute of Route-IPv6-Information defined in the >> draft-ietf-radext-ipv6-access-06 shown as follows: > .. >> is creating a new 'Complex Data Type', which has multi-fields, and is not >> recommended? > > That is what the document says. > >> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and >> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158? > > No. > > I could explain here, but there's no need. Read RFC 6158. It > thoroughly details the rationale behind the design guidelines. > > Alan DeKok. From aland@deployingradius.com Wed Feb 15 05:29:57 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1A21F8531 for ; Wed, 15 Feb 2012 05:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 jO5euymCZRnE for ; Wed, 15 Feb 2012 05:29:53 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB14F21F87E1 for ; Wed, 15 Feb 2012 05:28:27 -0800 (PST) Message-ID: <4F3BB2DC.5020600@deployingradius.com> Date: Wed, 15 Feb 2012 14:27:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Wojciech Dec References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Leaf yeh , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:29:57 -0000 Wojciech Dec wrote: > Just as an FYI, the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 Sure... then there's no need to ask the question again. I don't remember every nuance of each draft. I expect the authors to do that. Alan DeKok. From radext-bounces@ietf.org Wed Feb 15 05:30:00 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFA921F8567; Wed, 15 Feb 2012 05:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329312599; bh=prPypRr6jJ6sWoOhOT1De0TZixsXtu2H5eBZoL2BHBY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=y3IDmVdCSzSn9aEWSBxSJaTxSUlpS0MpedRmuHrqeRx0QUAYkUn4ZJGHrGYDYoSct maRhnJRQ517IHYIDIJ2O781uVnxHFiTy+o1WBrvDe2j0MDovT4fTqQv1cB0ctXYKGM qgeIXeRvhPL5hTFEg8xm4HC9MRwcMN83dmLTcRaA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1A21F8531 for ; Wed, 15 Feb 2012 05:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 jO5euymCZRnE for ; Wed, 15 Feb 2012 05:29:53 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB14F21F87E1 for ; Wed, 15 Feb 2012 05:28:27 -0800 (PST) Message-ID: <4F3BB2DC.5020600@deployingradius.com> Date: Wed, 15 Feb 2012 14:27:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Wojciech Dec References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Leaf yeh , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Wojciech Dec wrote: > Just as an FYI, the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 Sure... then there's no need to ask the question again. I don't remember every nuance of each draft. I expect the authors to do that. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Feb 15 17:29:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672821E80B5; Wed, 15 Feb 2012 17:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329355759; bh=iVhZ0CFwp4xTy1W9zLjUnXNiGoz+Lt9o1zWvi2q4KbY=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=tt4/uHSK32RpEw9obFr0SDxgoOZcgMNW/HwFSSXD0JzJ8bQVjErsQzSH3R+ijDH9Y bYPAQFbZ9rvTi6Lvb7mDX0JBHcZKrsAgjEAWXkmRL2bxkMLGH+hG4GBNY9odYLvAQr VgBA7r1UAC9CBvTgpAZtBwV0dzBz4ZPxibGhPp/w= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7A21E80AC for ; Wed, 15 Feb 2012 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.769 X-Spam-Level: X-Spam-Status: No, score=-6.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsFybO6CEpPj for ; Wed, 15 Feb 2012 17:29:15 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9F21E800E for ; Wed, 15 Feb 2012 17:29:15 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZG00CTNPGMAY@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 09:29:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZG00GMXPGMWO@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 09:29:10 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW25751; Thu, 16 Feb 2012 09:27:30 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 09:27:18 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 09:27:22 +0800 Date: Thu, 16 Feb 2012 01:27:22 +0000 From: Leaf yeh In-reply-to: <4F3B9DC7.8050607@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvv//g5yA//6bu0A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9DC7.8050607@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan - So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. especially for the part of '..., due to the additional overhead of the Vendor Specific encoding.' I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute. Alan - It's factually accurate. The text is factually 'right', because 247 is less than 253, but the logic above seems wrong. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, February 15, 2012 7:58 PM To: Leaf yeh Cc: radext@ietf.org; fine_sz@huawei.com Subject: Re: [radext] Q on RFC6158 Leaf yeh wrote: > The following might be Editorial Errata against RFC6158. > > Section 2.1, Original Text: > > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. > > > Corrected Text -1 might be: First, what's wrong with the text? It's factually accurate. The context of the text is important. The line before it says about Basic Data Types: * UTF-8 text [RFC3629], totaling 253 octets or less in length. So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. There is no need for that section to enumerate all of the possible length limitations of attributes. There is *absolutely* no need for RFC 6158 to note length limitations based on the extensions draft. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Wed Feb 15 17:29:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7A21E80AC for ; Wed, 15 Feb 2012 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.769 X-Spam-Level: X-Spam-Status: No, score=-6.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsFybO6CEpPj for ; Wed, 15 Feb 2012 17:29:15 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9F21E800E for ; Wed, 15 Feb 2012 17:29:15 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZG00CTNPGMAY@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 09:29:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZG00GMXPGMWO@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 09:29:10 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW25751; Thu, 16 Feb 2012 09:27:30 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 09:27:18 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 09:27:22 +0800 Date: Thu, 16 Feb 2012 01:27:22 +0000 From: Leaf yeh In-reply-to: <4F3B9DC7.8050607@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvv//g5yA//6bu0A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9DC7.8050607@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 01:29:19 -0000 Alan - So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. especially for the part of '..., due to the additional overhead of the Vendor Specific encoding.' I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute. Alan - It's factually accurate. The text is factually 'right', because 247 is less than 253, but the logic above seems wrong. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, February 15, 2012 7:58 PM To: Leaf yeh Cc: radext@ietf.org; fine_sz@huawei.com Subject: Re: [radext] Q on RFC6158 Leaf yeh wrote: > The following might be Editorial Errata against RFC6158. > > Section 2.1, Original Text: > > Note that the length limitations for VSAs of type String and Text are > less than 253 octets, due to the additional overhead of the Vendor- > Specific encoding. > > > Corrected Text -1 might be: First, what's wrong with the text? It's factually accurate. The context of the text is important. The line before it says about Basic Data Types: * UTF-8 text [RFC3629], totaling 253 octets or less in length. So... the paragraph following notes that VSAs have a limit of less than 253 octets of textual data. There is no need for that section to enumerate all of the possible length limitations of attributes. There is *absolutely* no need for RFC 6158 to note length limitations based on the extensions draft. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Feb 16 00:00:38 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684CE21E802B for ; Thu, 16 Feb 2012 00:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 fpSUZOA9eN8R for ; Thu, 16 Feb 2012 00:00:36 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2121E8017 for ; Thu, 16 Feb 2012 00:00:36 -0800 (PST) Message-ID: <4F3CB787.4070004@deployingradius.com> Date: Thu, 16 Feb 2012 09:00:07 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4F3B9DC7.8050607@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:00:38 -0000 Leaf yeh wrote: > If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, If we follow that logic, much of RFC 5080 is unnecessary, because the correct behavior is obvious. Sadly, not everyone sees the obvious. > I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: How will this *improve* the document? i.e. how is the text an errata, and how is the change a solution to the errata? Alan DeKok. From radext-bounces@ietf.org Thu Feb 16 00:00:39 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90C921E802E; Thu, 16 Feb 2012 00:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329379239; bh=a3jtaSemR7oGlWjZA6sSCDFG/NOsXM9ZdnHiL5jiSBE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=drbOf2YdWyzcbp24KedBCcbupN7zPGi62gZ2K8ff3tVP1DyyIqu+8U3ZvKXswwKqs 5eCGfWF4uu8rT00EX7JR2GCnMorB8Y9n6yeuKkh01vEBrKKMTa3oz4PuCEicGoKUVM kHvTfQqU94TN7Fq2gL6tA2SBFX9SpO1Yxj70aff8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684CE21E802B for ; Thu, 16 Feb 2012 00:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 fpSUZOA9eN8R for ; Thu, 16 Feb 2012 00:00:36 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2121E8017 for ; Thu, 16 Feb 2012 00:00:36 -0800 (PST) Message-ID: <4F3CB787.4070004@deployingradius.com> Date: Thu, 16 Feb 2012 09:00:07 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4F3B9DC7.8050607@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, If we follow that logic, much of RFC 5080 is unnecessary, because the correct behavior is obvious. Sadly, not everyone sees the obvious. > I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: How will this *improve* the document? i.e. how is the text an errata, and how is the change a solution to the errata? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Feb 16 00:19:44 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB57A21E802B; Thu, 16 Feb 2012 00:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329380384; bh=2/E2cfFq/6LraXKxx2K+QbzfguEuo5p50M4ddU79x5U=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QWY+D4AzQ4nwAW5GYiGMDRV2LdzLZOMjb/fEiT8gUjmPNGkMr3Ubdn6GXMjZ+MS0a zaH1WuVzcNarKnXFQ41bNMfuJpIRA6s4YG8uT6l8d8BMrjkErz709J96Wb5+UDiV97 cqBlFsbWakkV/6sU8NR7hdlkK7NXHvQSXqTV8X48= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57121E802B for ; Thu, 16 Feb 2012 00:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.753 X-Spam-Level: X-Spam-Status: No, score=-6.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTeLeVcH4H41 for ; Thu, 16 Feb 2012 00:19:41 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5464721E8013 for ; Thu, 16 Feb 2012 00:19:38 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH003568GFO5@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 16:19:27 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00BVJ8GBMY@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 16:19:27 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW60198; Thu, 16 Feb 2012 16:19:26 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 16:19:13 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 16:19:14 +0800 Date: Thu, 16 Feb 2012 08:19:13 +0000 From: Leaf yeh In-reply-to: <4F3CB787.4070004@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvv//g5yA//6bu0CAArQkgP//dlrA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9DC7.8050607@deployingradius.com> <4F3CB787.4070004@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan - How will this *improve* the document? The Typo or the Editorial Errata could result in the 'Corrected Text' -1 written as: 'Note that the length limitations for VSAs of type String and Text are less than 247 octets, due to the additional overhead of the Vendor- Specific encoding. Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Thursday, February 16, 2012 4:00 PM To: Leaf yeh Cc: radext@ietf.org; fine_sz@huawei.com Subject: Re: [radext] Q on RFC6158 Leaf yeh wrote: > If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, If we follow that logic, much of RFC 5080 is unnecessary, because the correct behavior is obvious. Sadly, not everyone sees the obvious. > I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: How will this *improve* the document? i.e. how is the text an errata, and how is the change a solution to the errata? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Feb 16 00:19:42 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57121E802B for ; Thu, 16 Feb 2012 00:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.753 X-Spam-Level: X-Spam-Status: No, score=-6.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTeLeVcH4H41 for ; Thu, 16 Feb 2012 00:19:41 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5464721E8013 for ; Thu, 16 Feb 2012 00:19:38 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH003568GFO5@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 16:19:27 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00BVJ8GBMY@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 16:19:27 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW60198; Thu, 16 Feb 2012 16:19:26 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 16:19:13 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 16:19:14 +0800 Date: Thu, 16 Feb 2012 08:19:13 +0000 From: Leaf yeh In-reply-to: <4F3CB787.4070004@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] Q on RFC6158 Thread-index: Aczr1DNAv+wsoOgTSpOMnGRuZDlJvv//g5yA//6bu0CAArQkgP//dlrA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9DC7.8050607@deployingradius.com> <4F3CB787.4070004@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] Q on RFC6158 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:19:42 -0000 Alan - How will this *improve* the document? The Typo or the Editorial Errata could result in the 'Corrected Text' -1 written as: 'Note that the length limitations for VSAs of type String and Text are less than 247 octets, due to the additional overhead of the Vendor- Specific encoding. Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Thursday, February 16, 2012 4:00 PM To: Leaf yeh Cc: radext@ietf.org; fine_sz@huawei.com Subject: Re: [radext] Q on RFC6158 Leaf yeh wrote: > If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158, If we follow that logic, much of RFC 5080 is unnecessary, because the correct behavior is obvious. Sadly, not everyone sees the obvious. > I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows: How will this *improve* the document? i.e. how is the text an errata, and how is the change a solution to the errata? Alan DeKok. From radext-bounces@ietf.org Thu Feb 16 04:06:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFA521F87C0; Thu, 16 Feb 2012 04:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329393974; bh=UF34qfBvFIykiVfEW7ddxdxxcTS4XePjA/vlnwu4/fo=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=v+VNzPtlloARgNAaiGLtvp5MK5A1CLt/CvJTjk6hfAWPLydamoyZ2PL0+IA08CEmO VU1NBm6s56q19RJlckDUCWKZfGgzXeW1JEdc0Qaqe9jqwTeJrOeyz54tpGke66d2ki dQpvDpF9WhRi0E1ZWvXEYBD964RdgzEFeQrLlON8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637BD21F8793 for ; Thu, 16 Feb 2012 04:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRtZ-qF6LcRq for ; Thu, 16 Feb 2012 04:06:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F10A221F871A for ; Thu, 16 Feb 2012 04:06:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00JUNIY1D2@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:06:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00H2HIXAHG@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:06:01 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW80544; Thu, 16 Feb 2012 20:05:52 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:05:38 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:05:46 +0800 Date: Thu, 16 Feb 2012 12:05:44 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec , Bernard Aboba Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9F95.3030804@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org V29qY2llY2ggLSB0aGUgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBm cm9tIGl0cw0KcHJldmlvdXMgIm5vbiBjb21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdl ZW4gZHJhZnQgMDQgYW5kIDA1LCBiYXNlZCBvbg0KV0cgcmV2aWV3L2ZlZWRiYWNrOg0KaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxDQoNCg0KQXMgcGVy IHRoZSByZXF1aXJlbWVudCBpbiB0aGUgc2VjdGlvbiAyLjEgb2YgUkZDNjE1OCwgDQoNCjxxdW90 ZT5TaW5jZSB0aGVyZSBhcmUgbm8gImhhcmQgYW5kIGZhc3QiDQpydWxlcyBmb3Igd2hlcmUgY29t cGxleGl0eSBpcyBiZXN0IGxvY2F0ZWQsIGVhY2ggc2l0dWF0aW9uIGhhcyB0byBiZQ0KZGVjaWRl ZCBvbiBhIGNhc2UtYnktY2FzZSBiYXNpcy4uLldoZXJlIGEgY29tcGxleCBkYXRhIHR5cGUgaXMg c2VsZWN0ZWQsIGFuDQpleHBsYW5hdGlvbiBTSE9VTEQgYmUgb2ZmZXJlZCBhcyB0byB3aHkgdGhp cyB3YXMgbmVjZXNzYXJ5LjwvcXVvdGU+DQoNCndvdWxkIHlvdSBjbGFyaWZ5IHRoZSByZWFzb24g Zm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUgJ2NvbXBsZXggZGF0YSB0eXBlJyBpbiB0aGUgZGVmaW5p dGlvbiBvZiBhdHRyaWJ1dGUsIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24/DQoNCkkgY2Fu4oCZdCBm aW5kIHRoZSBhbnN3ZXIgaW4gdGhlIGZvbGxvd2luZyBsaW5rczogaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxICYgaHR0cDovL3Rvb2xzLmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNSAuDQoNClRoZSBk ZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdv aycgd2l0aCBtZSBwZXJzb25hbGx5LCBidXQgUkZDNjE1OCAoJiBpdHMgc2VjdGlvbiBBLjIuMSkg c2VlbXMgbm90IHJlY29tbWVuZGVkIGl0LiANCg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBo ZXJlPw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxMiA4OjI0IFBNDQpUbzogQWxhbiBEZUtvazsgTGVh ZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5vcmc7IFN0ZWZhbiBXaW50ZXI7IGZpbmVfc3pAaHVhd2Vp LmNvbQ0KU3ViamVjdDogUmU6IFtyYWRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzLTA2LnR4dA0KDQpKdXN0IGFzIGFuIEZZSSwgdGhlIFJvdXRlLUlQdjYtSW5m b3JtYXRpb24gYXR0cmlidXRlIGNoYW5nZWQgZnJvbSBpdHMNCnByZXZpb3VzICJub24gY29tcGxl eCIgdG8gdGhlIGN1cnJlbnQgZm9ybSBiZXR3ZWVuIGRyYWZ0IDA0IGFuZCAwNSwgYmFzZWQgb24N CldHIHJldmlldy9mZWVkYmFjazoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JhZGV4 dC90cmFjL3RpY2tldC83MQ0KDQotV29qY2llY2guDQoNCg0KDQpPbiAxNS8wMi8yMDEyIDEzOjA1 LCAiQWxhbiBEZUtvayIgPGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KDQo+IExl YWYgeWVoIHdyb3RlOg0KPj4gQWZ0ZXIgcmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJGQzYxNTgs IFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5lcywgY291bGQgaXQgYmUNCj4+IGNvbmNsdWRlZCB0aGUg YXR0cmlidXRlIG9mIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24gZGVmaW5lZCBpbiB0aGUNCj4+IGRy YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2IHNob3duIGFzIGZvbGxvd3M6DQo+IC4uDQo+ PiBpcyBjcmVhdGluZyBhIG5ldyAnQ29tcGxleCBEYXRhIFR5cGUnLCB3aGljaCBoYXMgbXVsdGkt ZmllbGRzLCBhbmQgaXMgbm90DQo+PiByZWNvbW1lbmRlZD8gDQo+IA0KPiAgIFRoYXQgaXMgd2hh dCB0aGUgZG9jdW1lbnQgc2F5cy4NCj4gDQo+PiBXaWxsIGl0IGdldCB0aGUgc2FtZSAnYWNjZXB0 YWJsZScgYXMgdGhhdCBvZiBGcmFtZS1JUHY2LVByZWZpeCAoOTcpIGFuZA0KPj4gRGVsZWdhdGVk LUlQdjYtUHJlZml4KDEyMyksIHdoaWNoIGlzIG1lbnRpb25lZCBpbiBTZWN0aW9uIEIuNyBvZiBS RkM2MTU4Pw0KPiANCj4gICBOby4NCj4gDQo+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1dCB0 aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJGQyA2MTU4LiAgSXQNCj4gdGhvcm91Z2hseSBkZXRhaWxz IHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBkZXNpZ24gZ3VpZGVsaW5lcy4NCj4gDQo+ICAgQWxh biBEZUtvay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KcmFkZXh0IG1haWxpbmcgbGlzdApyYWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQK From leaf.y.yeh@huawei.com Thu Feb 16 04:06:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637BD21F8793 for ; Thu, 16 Feb 2012 04:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRtZ-qF6LcRq for ; Thu, 16 Feb 2012 04:06:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F10A221F871A for ; Thu, 16 Feb 2012 04:06:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00JUNIY1D2@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:06:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00H2HIXAHG@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:06:01 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW80544; Thu, 16 Feb 2012 20:05:52 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:05:38 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:05:46 +0800 Date: Thu, 16 Feb 2012 12:05:44 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec , Bernard Aboba Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9F95.3030804@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:06:13 -0000 V29qY2llY2ggLSB0aGUgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBm cm9tIGl0cw0KcHJldmlvdXMgIm5vbiBjb21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdl ZW4gZHJhZnQgMDQgYW5kIDA1LCBiYXNlZCBvbg0KV0cgcmV2aWV3L2ZlZWRiYWNrOg0KaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxDQoNCg0KQXMgcGVy IHRoZSByZXF1aXJlbWVudCBpbiB0aGUgc2VjdGlvbiAyLjEgb2YgUkZDNjE1OCwgDQoNCjxxdW90 ZT5TaW5jZSB0aGVyZSBhcmUgbm8gImhhcmQgYW5kIGZhc3QiDQpydWxlcyBmb3Igd2hlcmUgY29t cGxleGl0eSBpcyBiZXN0IGxvY2F0ZWQsIGVhY2ggc2l0dWF0aW9uIGhhcyB0byBiZQ0KZGVjaWRl ZCBvbiBhIGNhc2UtYnktY2FzZSBiYXNpcy4uLldoZXJlIGEgY29tcGxleCBkYXRhIHR5cGUgaXMg c2VsZWN0ZWQsIGFuDQpleHBsYW5hdGlvbiBTSE9VTEQgYmUgb2ZmZXJlZCBhcyB0byB3aHkgdGhp cyB3YXMgbmVjZXNzYXJ5LjwvcXVvdGU+DQoNCndvdWxkIHlvdSBjbGFyaWZ5IHRoZSByZWFzb24g Zm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUgJ2NvbXBsZXggZGF0YSB0eXBlJyBpbiB0aGUgZGVmaW5p dGlvbiBvZiBhdHRyaWJ1dGUsIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24/DQoNCkkgY2Fu4oCZdCBm aW5kIHRoZSBhbnN3ZXIgaW4gdGhlIGZvbGxvd2luZyBsaW5rczogaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxICYgaHR0cDovL3Rvb2xzLmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNSAuDQoNClRoZSBk ZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdv aycgd2l0aCBtZSBwZXJzb25hbGx5LCBidXQgUkZDNjE1OCAoJiBpdHMgc2VjdGlvbiBBLjIuMSkg c2VlbXMgbm90IHJlY29tbWVuZGVkIGl0LiANCg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBo ZXJlPw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxMiA4OjI0IFBNDQpUbzogQWxhbiBEZUtvazsgTGVh ZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5vcmc7IFN0ZWZhbiBXaW50ZXI7IGZpbmVfc3pAaHVhd2Vp LmNvbQ0KU3ViamVjdDogUmU6IFtyYWRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzLTA2LnR4dA0KDQpKdXN0IGFzIGFuIEZZSSwgdGhlIFJvdXRlLUlQdjYtSW5m b3JtYXRpb24gYXR0cmlidXRlIGNoYW5nZWQgZnJvbSBpdHMNCnByZXZpb3VzICJub24gY29tcGxl eCIgdG8gdGhlIGN1cnJlbnQgZm9ybSBiZXR3ZWVuIGRyYWZ0IDA0IGFuZCAwNSwgYmFzZWQgb24N CldHIHJldmlldy9mZWVkYmFjazoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JhZGV4 dC90cmFjL3RpY2tldC83MQ0KDQotV29qY2llY2guDQoNCg0KDQpPbiAxNS8wMi8yMDEyIDEzOjA1 LCAiQWxhbiBEZUtvayIgPGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KDQo+IExl YWYgeWVoIHdyb3RlOg0KPj4gQWZ0ZXIgcmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJGQzYxNTgs IFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5lcywgY291bGQgaXQgYmUNCj4+IGNvbmNsdWRlZCB0aGUg YXR0cmlidXRlIG9mIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24gZGVmaW5lZCBpbiB0aGUNCj4+IGRy YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2IHNob3duIGFzIGZvbGxvd3M6DQo+IC4uDQo+ PiBpcyBjcmVhdGluZyBhIG5ldyAnQ29tcGxleCBEYXRhIFR5cGUnLCB3aGljaCBoYXMgbXVsdGkt ZmllbGRzLCBhbmQgaXMgbm90DQo+PiByZWNvbW1lbmRlZD8gDQo+IA0KPiAgIFRoYXQgaXMgd2hh dCB0aGUgZG9jdW1lbnQgc2F5cy4NCj4gDQo+PiBXaWxsIGl0IGdldCB0aGUgc2FtZSAnYWNjZXB0 YWJsZScgYXMgdGhhdCBvZiBGcmFtZS1JUHY2LVByZWZpeCAoOTcpIGFuZA0KPj4gRGVsZWdhdGVk LUlQdjYtUHJlZml4KDEyMyksIHdoaWNoIGlzIG1lbnRpb25lZCBpbiBTZWN0aW9uIEIuNyBvZiBS RkM2MTU4Pw0KPiANCj4gICBOby4NCj4gDQo+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1dCB0 aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJGQyA2MTU4LiAgSXQNCj4gdGhvcm91Z2hseSBkZXRhaWxz IHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBkZXNpZ24gZ3VpZGVsaW5lcy4NCj4gDQo+ICAgQWxh biBEZUtvay4NCg0K From radext-bounces@ietf.org Thu Feb 16 04:24:52 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D6121F875D; Thu, 16 Feb 2012 04:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329395092; bh=4NPo2mYe1KHSlfEJQ0/vIqz56ISxL0VZE04mRwMbi2Q=; h=Date:From:To:Message-id:MIME-version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=V5CAy9luiEKIrmqgCFNPmDHrYcX6to6gCunVjgDMc/1dciDJYnP1F5GDDX0fC3lSZ lGc7jPCYAcB1xgRqRUnna+aloUkxbK62XDK5mn/V6OAnwNHl2dcHvsK7D3DPxMuA8H Q7ssewJQmguzjmDrKYP75N3xoGp7avFDwCeXY21A= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96B21F875D for ; Thu, 16 Feb 2012 04:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.73 X-Spam-Level: X-Spam-Status: No, score=-6.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq968eT+KUOx for ; Thu, 16 Feb 2012 04:24:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33B21F8746 for ; Thu, 16 Feb 2012 04:24:50 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00N4TJT92V@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:24:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00EGHJT9RX@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:24:45 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHE08096; Thu, 16 Feb 2012 20:24:44 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:24:37 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:24:44 +0800 Date: Thu, 16 Feb 2012 12:24:42 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 & draft-ietf-radext-ipv6-access Thread-index: AczspfXxOFK0UWW6TO6CivB8paiq/Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: Bernard Aboba , "radext@ietf.org" , Wojciech Dec , Stefan Winter Subject: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Is it the same as the basic data type of 'IPv6 address'? BTW, there has some words about the 'prefix' in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 shown as follows: Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? Best Regards, Leaf _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Feb 16 04:24:51 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96B21F875D for ; Thu, 16 Feb 2012 04:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.73 X-Spam-Level: X-Spam-Status: No, score=-6.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq968eT+KUOx for ; Thu, 16 Feb 2012 04:24:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33B21F8746 for ; Thu, 16 Feb 2012 04:24:50 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00N4TJT92V@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:24:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00EGHJT9RX@szxga05-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:24:45 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHE08096; Thu, 16 Feb 2012 20:24:44 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:24:37 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:24:44 +0800 Date: Thu, 16 Feb 2012 12:24:42 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 & draft-ietf-radext-ipv6-access Thread-index: AczspfXxOFK0UWW6TO6CivB8paiq/Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: Bernard Aboba , "radext@ietf.org" , Wojciech Dec , Stefan Winter Subject: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:24:51 -0000 What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Is it the same as the basic data type of 'IPv6 address'? BTW, there has some words about the 'prefix' in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 shown as follows: Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? Best Regards, Leaf From radext-bounces@ietf.org Thu Feb 16 04:31:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABF721F87DF; Thu, 16 Feb 2012 04:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329395473; bh=YvUr5VVaFR9I1rzrLseJu/rcoiKQv7yQhiLgHuF4Ncs=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=g2Wp55Usw9+pjZizcZ98+V3JktgrN6QFjNCTD4ygvg0I3OHBNsSM1fHUSBiQsfN/Y pSbdBfxJZDc/wQHingwmnEw/Pom4sM6GuRGGxXpKBEe515t22bzf82JqFawyCVgFqM KtidsYKFLAQPw/CwqLj4vxw8ZVxjjKMR83ErjKfw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82C721F87DE for ; Thu, 16 Feb 2012 04:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.72 X-Spam-Level: X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5bqnaL0tshg for ; Thu, 16 Feb 2012 04:31:12 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DF00A21F87C8 for ; Thu, 16 Feb 2012 04:31:11 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH007U5K35E8@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:30:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00GWOK2MK6@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:30:41 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW81956; Thu, 16 Feb 2012 20:30:41 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:30:30 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:30:32 +0800 Date: Thu, 16 Feb 2012 12:30:32 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec , Bernard Aboba Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAALTdA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9F95.3030804@deployingradius.com> Cc: "radext@ietf.org" , Alan DeKok , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org TGVhZiAtIFRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgd2l0aG91dCBtdWx0aS1maWVs ZHMgc291bmRzICdvaycgd2l0aCBtZSBwZXJzb25hbGx5LCBidXQgUkZDNjE1OCAoJiBpdHMgc2Vj dGlvbiBBLjIuMSkgc2VlbXMgbm90IHJlY29tbWVuZGVkIGl0Lg0KDQpTb3JyeSBmb3IgdGhlIHR5 cG86ICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgYXR0cmlidXRlIHdpdGggbXVsdGktZmllbGRzIHNv dW5kcyAnb2snIHdpdGggbWUgcGVyc29uYWxseSwgYnV0IFJGQzYxNTggKCYgaXRzIHNlY3Rpb24g QS4yLjEpIHNlZW1zIG5vdCByZWNvbW1lbmQgaXQuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tXSANClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiA4OjA2IFBNDQpUbzogV29qY2llY2ggRGVj OyBCZXJuYXJkIEFib2JhDQpDYzogcmFkZXh0QGlldGYub3JnOyBTdGVmYW4gV2ludGVyOyBmaW5l X3N6QGh1YXdlaS5jb20NClN1YmplY3Q6IFJFOiBbcmFkZXh0XSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNi50eHQNCg0KV29qY2llY2ggLSB0aGUgUm91dGUtSVB2 Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBmcm9tIGl0cw0KcHJldmlvdXMgIm5vbiBj b21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdlZW4gZHJhZnQgMDQgYW5kIDA1LCBiYXNl ZCBvbg0KV0cgcmV2aWV3L2ZlZWRiYWNrOg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cv cmFkZXh0L3RyYWMvdGlja2V0LzcxDQoNCg0KQXMgcGVyIHRoZSByZXF1aXJlbWVudCBpbiB0aGUg c2VjdGlvbiAyLjEgb2YgUkZDNjE1OCwgDQoNCjxxdW90ZT5TaW5jZSB0aGVyZSBhcmUgbm8gImhh cmQgYW5kIGZhc3QiDQpydWxlcyBmb3Igd2hlcmUgY29tcGxleGl0eSBpcyBiZXN0IGxvY2F0ZWQs IGVhY2ggc2l0dWF0aW9uIGhhcyB0byBiZQ0KZGVjaWRlZCBvbiBhIGNhc2UtYnktY2FzZSBiYXNp cy4uLldoZXJlIGEgY29tcGxleCBkYXRhIHR5cGUgaXMgc2VsZWN0ZWQsIGFuDQpleHBsYW5hdGlv biBTSE9VTEQgYmUgb2ZmZXJlZCBhcyB0byB3aHkgdGhpcyB3YXMgbmVjZXNzYXJ5LjwvcXVvdGU+ DQoNCndvdWxkIHlvdSBjbGFyaWZ5IHRoZSByZWFzb24gZm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUg J2NvbXBsZXggZGF0YSB0eXBlJyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBhdHRyaWJ1dGUsIFJvdXRl LUlQdjYtSW5mb3JtYXRpb24/DQoNCkkgY2Fu4oCZdCBmaW5kIHRoZSBhbnN3ZXIgaW4gdGhlIGZv bGxvd2luZyBsaW5rczogaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMv dGlja2V0LzcxICYgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2Vzcy0wNSAuDQoNClRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1 dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdvaycgd2l0aCBtZSBwZXJzb25hbGx5LCBi dXQgUkZDNjE1OCAoJiBpdHMgc2VjdGlvbiBBLjIuMSkgc2VlbXMgbm90IHJlY29tbWVuZGVkIGl0 LiANCg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBoZXJlPw0KDQoNCkJlc3QgUmVnYXJkcywN CkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV29qY2llY2ggRGVj IFttYWlsdG86d2RlY0BjaXNjby5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwg MjAxMiA4OjI0IFBNDQpUbzogQWxhbiBEZUtvazsgTGVhZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5v cmc7IFN0ZWZhbiBXaW50ZXI7IGZpbmVfc3pAaHVhd2VpLmNvbQ0KU3ViamVjdDogUmU6IFtyYWRl eHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2LnR4dA0KDQpK dXN0IGFzIGFuIEZZSSwgdGhlIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24gYXR0cmlidXRlIGNoYW5n ZWQgZnJvbSBpdHMNCnByZXZpb3VzICJub24gY29tcGxleCIgdG8gdGhlIGN1cnJlbnQgZm9ybSBi ZXR3ZWVuIGRyYWZ0IDA0IGFuZCAwNSwgYmFzZWQgb24NCldHIHJldmlldy9mZWVkYmFjazoNCmh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JhZGV4dC90cmFjL3RpY2tldC83MQ0KDQotV29q Y2llY2guDQoNCg0KDQpPbiAxNS8wMi8yMDEyIDEzOjA1LCAiQWxhbiBEZUtvayIgPGFsYW5kQGRl cGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KDQo+IExlYWYgeWVoIHdyb3RlOg0KPj4gQWZ0ZXIg cmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJGQzYxNTgsIFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5l cywgY291bGQgaXQgYmUNCj4+IGNvbmNsdWRlZCB0aGUgYXR0cmlidXRlIG9mIFJvdXRlLUlQdjYt SW5mb3JtYXRpb24gZGVmaW5lZCBpbiB0aGUNCj4+IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzLTA2IHNob3duIGFzIGZvbGxvd3M6DQo+IC4uDQo+PiBpcyBjcmVhdGluZyBhIG5ldyAnQ29t cGxleCBEYXRhIFR5cGUnLCB3aGljaCBoYXMgbXVsdGktZmllbGRzLCBhbmQgaXMgbm90DQo+PiBy ZWNvbW1lbmRlZD8gDQo+IA0KPiAgIFRoYXQgaXMgd2hhdCB0aGUgZG9jdW1lbnQgc2F5cy4NCj4g DQo+PiBXaWxsIGl0IGdldCB0aGUgc2FtZSAnYWNjZXB0YWJsZScgYXMgdGhhdCBvZiBGcmFtZS1J UHY2LVByZWZpeCAoOTcpIGFuZA0KPj4gRGVsZWdhdGVkLUlQdjYtUHJlZml4KDEyMyksIHdoaWNo IGlzIG1lbnRpb25lZCBpbiBTZWN0aW9uIEIuNyBvZiBSRkM2MTU4Pw0KPiANCj4gICBOby4NCj4g DQo+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1dCB0aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJG QyA2MTU4LiAgSXQNCj4gdGhvcm91Z2hseSBkZXRhaWxzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRo ZSBkZXNpZ24gZ3VpZGVsaW5lcy4NCj4gDQo+ICAgQWxhbiBEZUtvay4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApy YWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRl eHQK From leaf.y.yeh@huawei.com Thu Feb 16 04:31:12 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82C721F87DE for ; Thu, 16 Feb 2012 04:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.72 X-Spam-Level: X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5bqnaL0tshg for ; Thu, 16 Feb 2012 04:31:12 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DF00A21F87C8 for ; Thu, 16 Feb 2012 04:31:11 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH007U5K35E8@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:30:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00GWOK2MK6@szxga03-in.huawei.com> for radext@ietf.org; Thu, 16 Feb 2012 20:30:41 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW81956; Thu, 16 Feb 2012 20:30:41 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 20:30:30 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 20:30:32 +0800 Date: Thu, 16 Feb 2012 12:30:32 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec , Bernard Aboba Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAALTdA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3B9F95.3030804@deployingradius.com> Cc: "radext@ietf.org" , Alan DeKok , "fine_sz@huawei.com" , Stefan Winter Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:31:13 -0000 TGVhZiAtIFRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgd2l0aG91dCBtdWx0aS1maWVs ZHMgc291bmRzICdvaycgd2l0aCBtZSBwZXJzb25hbGx5LCBidXQgUkZDNjE1OCAoJiBpdHMgc2Vj dGlvbiBBLjIuMSkgc2VlbXMgbm90IHJlY29tbWVuZGVkIGl0Lg0KDQpTb3JyeSBmb3IgdGhlIHR5 cG86ICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgYXR0cmlidXRlIHdpdGggbXVsdGktZmllbGRzIHNv dW5kcyAnb2snIHdpdGggbWUgcGVyc29uYWxseSwgYnV0IFJGQzYxNTggKCYgaXRzIHNlY3Rpb24g QS4yLjEpIHNlZW1zIG5vdCByZWNvbW1lbmQgaXQuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tXSANClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiA4OjA2IFBNDQpUbzogV29qY2llY2ggRGVj OyBCZXJuYXJkIEFib2JhDQpDYzogcmFkZXh0QGlldGYub3JnOyBTdGVmYW4gV2ludGVyOyBmaW5l X3N6QGh1YXdlaS5jb20NClN1YmplY3Q6IFJFOiBbcmFkZXh0XSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNi50eHQNCg0KV29qY2llY2ggLSB0aGUgUm91dGUtSVB2 Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBmcm9tIGl0cw0KcHJldmlvdXMgIm5vbiBj b21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdlZW4gZHJhZnQgMDQgYW5kIDA1LCBiYXNl ZCBvbg0KV0cgcmV2aWV3L2ZlZWRiYWNrOg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cv cmFkZXh0L3RyYWMvdGlja2V0LzcxDQoNCg0KQXMgcGVyIHRoZSByZXF1aXJlbWVudCBpbiB0aGUg c2VjdGlvbiAyLjEgb2YgUkZDNjE1OCwgDQoNCjxxdW90ZT5TaW5jZSB0aGVyZSBhcmUgbm8gImhh cmQgYW5kIGZhc3QiDQpydWxlcyBmb3Igd2hlcmUgY29tcGxleGl0eSBpcyBiZXN0IGxvY2F0ZWQs IGVhY2ggc2l0dWF0aW9uIGhhcyB0byBiZQ0KZGVjaWRlZCBvbiBhIGNhc2UtYnktY2FzZSBiYXNp cy4uLldoZXJlIGEgY29tcGxleCBkYXRhIHR5cGUgaXMgc2VsZWN0ZWQsIGFuDQpleHBsYW5hdGlv biBTSE9VTEQgYmUgb2ZmZXJlZCBhcyB0byB3aHkgdGhpcyB3YXMgbmVjZXNzYXJ5LjwvcXVvdGU+ DQoNCndvdWxkIHlvdSBjbGFyaWZ5IHRoZSByZWFzb24gZm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUg J2NvbXBsZXggZGF0YSB0eXBlJyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBhdHRyaWJ1dGUsIFJvdXRl LUlQdjYtSW5mb3JtYXRpb24/DQoNCkkgY2Fu4oCZdCBmaW5kIHRoZSBhbnN3ZXIgaW4gdGhlIGZv bGxvd2luZyBsaW5rczogaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMv dGlja2V0LzcxICYgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2Vzcy0wNSAuDQoNClRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1 dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdvaycgd2l0aCBtZSBwZXJzb25hbGx5LCBi dXQgUkZDNjE1OCAoJiBpdHMgc2VjdGlvbiBBLjIuMSkgc2VlbXMgbm90IHJlY29tbWVuZGVkIGl0 LiANCg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBoZXJlPw0KDQoNCkJlc3QgUmVnYXJkcywN CkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV29qY2llY2ggRGVj IFttYWlsdG86d2RlY0BjaXNjby5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwg MjAxMiA4OjI0IFBNDQpUbzogQWxhbiBEZUtvazsgTGVhZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5v cmc7IFN0ZWZhbiBXaW50ZXI7IGZpbmVfc3pAaHVhd2VpLmNvbQ0KU3ViamVjdDogUmU6IFtyYWRl eHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2LnR4dA0KDQpK dXN0IGFzIGFuIEZZSSwgdGhlIFJvdXRlLUlQdjYtSW5mb3JtYXRpb24gYXR0cmlidXRlIGNoYW5n ZWQgZnJvbSBpdHMNCnByZXZpb3VzICJub24gY29tcGxleCIgdG8gdGhlIGN1cnJlbnQgZm9ybSBi ZXR3ZWVuIGRyYWZ0IDA0IGFuZCAwNSwgYmFzZWQgb24NCldHIHJldmlldy9mZWVkYmFjazoNCmh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JhZGV4dC90cmFjL3RpY2tldC83MQ0KDQotV29q Y2llY2guDQoNCg0KDQpPbiAxNS8wMi8yMDEyIDEzOjA1LCAiQWxhbiBEZUtvayIgPGFsYW5kQGRl cGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KDQo+IExlYWYgeWVoIHdyb3RlOg0KPj4gQWZ0ZXIg cmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJGQzYxNTgsIFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5l cywgY291bGQgaXQgYmUNCj4+IGNvbmNsdWRlZCB0aGUgYXR0cmlidXRlIG9mIFJvdXRlLUlQdjYt SW5mb3JtYXRpb24gZGVmaW5lZCBpbiB0aGUNCj4+IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzLTA2IHNob3duIGFzIGZvbGxvd3M6DQo+IC4uDQo+PiBpcyBjcmVhdGluZyBhIG5ldyAnQ29t cGxleCBEYXRhIFR5cGUnLCB3aGljaCBoYXMgbXVsdGktZmllbGRzLCBhbmQgaXMgbm90DQo+PiBy ZWNvbW1lbmRlZD8gDQo+IA0KPiAgIFRoYXQgaXMgd2hhdCB0aGUgZG9jdW1lbnQgc2F5cy4NCj4g DQo+PiBXaWxsIGl0IGdldCB0aGUgc2FtZSAnYWNjZXB0YWJsZScgYXMgdGhhdCBvZiBGcmFtZS1J UHY2LVByZWZpeCAoOTcpIGFuZA0KPj4gRGVsZWdhdGVkLUlQdjYtUHJlZml4KDEyMyksIHdoaWNo IGlzIG1lbnRpb25lZCBpbiBTZWN0aW9uIEIuNyBvZiBSRkM2MTU4Pw0KPiANCj4gICBOby4NCj4g DQo+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1dCB0aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJG QyA2MTU4LiAgSXQNCj4gdGhvcm91Z2hseSBkZXRhaWxzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRo ZSBkZXNpZ24gZ3VpZGVsaW5lcy4NCj4gDQo+ICAgQWxhbiBEZUtvay4NCg0K From aland@deployingradius.com Thu Feb 16 04:54:25 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6F21F85CE for ; Thu, 16 Feb 2012 04:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 LVX2b7cjxZdH for ; Thu, 16 Feb 2012 04:54:24 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2821F85C5 for ; Thu, 16 Feb 2012 04:54:24 -0800 (PST) Message-ID: <4F3CFC65.8030307@deployingradius.com> Date: Thu, 16 Feb 2012 13:53:57 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "radext@ietf.org" , Wojciech Dec , Stefan Winter Subject: Re: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:54:25 -0000 Leaf yeh wrote: > What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? See the existing RFCs. Specifically, "RADIUS and IPv6" > Is it the same as the basic data type of 'IPv6 address'? No. > Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? See RFC 3162 for the definition of IPv6 prefix. Alan DeKok. From radext-bounces@ietf.org Thu Feb 16 04:54:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0DA21F85CE; Thu, 16 Feb 2012 04:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329396867; bh=h65RUrG07xGiofr6CT5ijJfBqD09k2xa6iE3ALsRKaE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lGDsGV7x+wXIQyVpl4kFlDbvEKQee/87V/lde5bXcNvZ6aHuz1PGT4iraa9Cp3AbV czl5UHitr8dBlGSrg7Z/yV0DpS6MZjvsFRhRJ19JGE2LtQJjMX4sxUIp8YoV779Lwj zbvaoVDMKEU6p71igJpjPrSXQPGlxzN/41Q7iFtI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6F21F85CE for ; Thu, 16 Feb 2012 04:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 LVX2b7cjxZdH for ; Thu, 16 Feb 2012 04:54:24 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2821F85C5 for ; Thu, 16 Feb 2012 04:54:24 -0800 (PST) Message-ID: <4F3CFC65.8030307@deployingradius.com> Date: Thu, 16 Feb 2012 13:53:57 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , "radext@ietf.org" , Wojciech Dec , Stefan Winter Subject: Re: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? See the existing RFCs. Specifically, "RADIUS and IPv6" > Is it the same as the basic data type of 'IPv6 address'? No. > Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? See RFC 3162 for the definition of IPv6 prefix. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Feb 16 19:46:54 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9527821E8056 for ; Thu, 16 Feb 2012 19:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.712 X-Spam-Level: X-Spam-Status: No, score=-6.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYc4q1JEP4hO for ; Thu, 16 Feb 2012 19:46:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 536DB21E806E for ; Thu, 16 Feb 2012 19:46:50 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZI006XNQFB3E@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 11:45:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZI00HFSQF9OH@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 11:45:11 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX12594; Fri, 17 Feb 2012 11:45:03 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 11:44:52 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 11:45:01 +0800 Date: Fri, 17 Feb 2012 03:45:00 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 & draft-ietf-radext-ipv6-access Thread-index: AczspfXxOFK0UWW6TO6CivB8paiq/QAbOfrw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Bernard Aboba , "radext@ietf.org" , Alan DeKok , Stefan Winter Subject: Re: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 03:46:54 -0000 Leaf - What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Alan- See the existing RFCs. Specifically, "RADIUS and IPv6" Leaf - Is it the same as the basic data type of 'IPv6 address'? Alan - No. I guess the following text in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. have some errors as per the section 2.3 of RFC3162, RADIUS and IPv6. a. Typo - The value shall range from 0 to 128. b. The prefix field is not necessary to be 0, 8 or 16 octets. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Leaf yeh Sent: Thursday, February 16, 2012 8:25 PM To: Alan DeKok Cc: Bernard Aboba; radext@ietf.org; Wojciech Dec; Stefan Winter Subject: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Is it the same as the basic data type of 'IPv6 address'? BTW, there has some words about the 'prefix' in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 shown as follows: Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? Best Regards, Leaf _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Feb 16 19:46:56 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1D21E806E; Thu, 16 Feb 2012 19:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329450416; bh=wZWaRPSwxyvFONfc9Nm4ZOP/cjuKX9zKDUd1afc2fKg=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=qrqPVuDznp6ZtOUn24R0YGwoyYuuTX0k88jaP86ApO6pWjUG3kWgCx/VfFTodxBiQ 8E10cPkytkMM14rR43+Q2a1ViSZiLUarFHEMjU6ujgt1xzxL37rBjjXOWwL8SZ/iO5 GE6P868XEGAG27fdMj6maqteAh1PzEhGJNNMHuck= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9527821E8056 for ; Thu, 16 Feb 2012 19:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.712 X-Spam-Level: X-Spam-Status: No, score=-6.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYc4q1JEP4hO for ; Thu, 16 Feb 2012 19:46:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 536DB21E806E for ; Thu, 16 Feb 2012 19:46:50 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZI006XNQFB3E@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 11:45:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZI00HFSQF9OH@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 11:45:11 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX12594; Fri, 17 Feb 2012 11:45:03 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 11:44:52 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 11:45:01 +0800 Date: Fri, 17 Feb 2012 03:45:00 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on RFC6158 & draft-ietf-radext-ipv6-access Thread-index: AczspfXxOFK0UWW6TO6CivB8paiq/QAbOfrw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Bernard Aboba , "radext@ietf.org" , Alan DeKok , Stefan Winter Subject: Re: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf - What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Alan- See the existing RFCs. Specifically, "RADIUS and IPv6" Leaf - Is it the same as the basic data type of 'IPv6 address'? Alan - No. I guess the following text in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. have some errors as per the section 2.3 of RFC3162, RADIUS and IPv6. a. Typo - The value shall range from 0 to 128. b. The prefix field is not necessary to be 0, 8 or 16 octets. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Leaf yeh Sent: Thursday, February 16, 2012 8:25 PM To: Alan DeKok Cc: Bernard Aboba; radext@ietf.org; Wojciech Dec; Stefan Winter Subject: [radext] Q on RFC6158 & draft-ietf-radext-ipv6-access What is the definition of the 'IPv6 prefix' (basic data type) in the section 2.1 of RFC6158? Is it the same as the basic data type of 'IPv6 address'? BTW, there has some words about the 'prefix' in the definition of 'Route-IPv6-Information' (attribute), section 3.3 of draft-ietf-radext-ipv6-access-06 shown as follows: Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 1. The prefix field is 0, 8 or 16 octets depending on Length. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does the above prefix comply with the basic data type of 'IPv6 prefix' mentioned in RFC6158? Best Regards, Leaf _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Fri Feb 17 03:14:25 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2621F8535 for ; Fri, 17 Feb 2012 03:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.705 X-Spam-Level: X-Spam-Status: No, score=-6.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6S+Ioh0P8MN for ; Fri, 17 Feb 2012 03:14:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 00FAD21F844B for ; Fri, 17 Feb 2012 03:14:23 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ002C3B707B@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 19:13:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ00IHIB6V21@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 19:13:48 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHE68034; Fri, 17 Feb 2012 19:13:23 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 19:12:57 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 19:13:07 +0800 Date: Fri, 17 Feb 2012 11:13:06 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: "Sanchez, Mauricio (HP Networking)" , "jouni.korhonen@nsn.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] RADEXT recharter Thread-index: AczaG/xDKiJT9gNoRwm22tOW8sfaJAAdk5+wBKV1s9A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "Romascanu, Dan \(Dan\)" , Stefan Winter , "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:14:25 -0000 As per the MM of Radext session, IETF82-Taipei, http://www.ietf.org/proceedings/82/minutes/radext.txt 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh -Chair: Is anyone against having an accounting document? No objection. Ask authors to work out a single proposal. Need to determine if we bring into a new charter. ... -Chair: Consensus check on adding this topic to the re-charter: Show of hands on who is interested and will participate in the effort? 4 - yes, 0 - against. Will take to list, strong consensus to update the charter and make this a working group item. Ask authors to work towards a unified proposal.... -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. I suggest to add 'RADIUS Accounting Extensions for Traffic Statistics' as the work item in the charter. The following text against the revision on the WG charter are for your reference and the further discussion. Work Item .... RADIUS Accounting Extensions for Traffic Statistics: This document specifies the dedicated RADIUS attributes on IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server. Goals and Milestones ... Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC OTOH, as per the MM of Radext session, 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh http://www.ietf.org/proceedings/82/slides/radext-2.pptx ... -AD: before we develop the contributions, ask authors to put together pros and cons of options, remaining points of disagreement. See if we can get agreement on a baseline proposal -Chair: ...Ask authors to work towards a unified proposal. and the discussion in the ML about draft-ietf-radext-radius-extensions and RFC6158, I will trigger a discussion on this attribute design soon again, then update the draft with Stefan for a 'baseline proposal'. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, January 24, 2012 8:21 PM To: Sanchez, Mauricio (HP Networking); radext@ietf.org Subject: Re: [radext] RADEXT recharter Hi, As Dave Nelson already pointed out, two of the documents in the charter were already approved as RFCs. Also the milestones need to be revisited in case the discussions of this new charter continue until IETF-83 (end of March 2012) because most of them target January - March 2012. Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Sanchez, Mauricio (HP Networking) > Sent: Tuesday, January 24, 2012 12:11 AM > To: radext@ietf.org > Subject: [radext] RADEXT recharter > > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items > that the WG believes relevant, as well as recalibrating dates on > several committed goals. > > Below is the new proposed WG charter that your chairs and AD agreed > upon. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your > changes and justify why. > > Our aim is to have this re-chartering discussion completed by next IETF > meeting. > > - Mauricio and Jouni > > > --------- > > Description of Working Group > > The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol required to expand and enrich the standard attribute > space, address cryptographic algorithm agility, use of new secure > transports and clarify its usage and definition. > > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter > will be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, > the following restrictions are imposed on extensions considered by the > RADEXT > WG: > > - All documents produced MUST specify means of interoperation with > legacy RADIUS and, if possible, be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668- > 4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, > be compatible with RFC 3539. > > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should > be included in the specification. > > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. > > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > > -RADIUS attribute space extension. The standard RADIUS attribute space > is currently being depleted. This document will provide additional > standard attribute space, while maintaining backward compatibility with > existing attributes. > > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > relied on MD5 for both per-packet integrity and authentication as well > as attribute confidentiality. Given the increasingly successful attacks > being mounted against MD5, the ability to support alternative > algorithms is required. This work item will include documentation of > RADIUS crypto-agility requirements, as well as development of one or > more Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > > -IEEE 802 attributes. New attributes have been proposed to support IEEE > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. A reliable transport profile for RADIUS will > be developed, as well as specifications for Secure transports, > including TCP/TLS (RADSEC) and UDP/DTLS. > > - Documentation of Status-Server usage. A document describing usage of > the Status-Server facility will be developed. > > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with > RFC4282 in two phases. In first phase, RFC4282bis will be issued to > eliminate fundamental incompatibilities with RADIUS around character > encoding and NAI modifications by proxies. In second phase, a fresh > review of NAI internationalization requirements and behavior will be > undertaken with a clear goal of maintaining compatibility with RADIUS. > > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > Done SIP RADIUS authentication draft submitted as a Proposed > Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a > Proposed > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as > an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out > from Issues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed > Standard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a > Proposed > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > Proposed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Feb 17 03:14:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51C21F8535; Fri, 17 Feb 2012 03:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329477267; bh=YbP7EBi+52RFahJLcZa32fyBMfLMec2SbQ/tk5ayi4U=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=VFnIMmmmQNU0f2JbWbnVY7PydkONmiVsqYd0no9sNfLJZtQtwZ56Iy0sR4/6uddZF bh2cy0i9d8xlycoaDgXDD+/F7hl+UEryYtFd46XdtQnHUbiGv0yAOFlMq69b3lZcS8 6KHFGxaMt2DC7C7YCIeySqvwIffL0TGPwdh8B/ks= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2621F8535 for ; Fri, 17 Feb 2012 03:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.705 X-Spam-Level: X-Spam-Status: No, score=-6.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6S+Ioh0P8MN for ; Fri, 17 Feb 2012 03:14:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 00FAD21F844B for ; Fri, 17 Feb 2012 03:14:23 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ002C3B707B@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 19:13:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZJ00IHIB6V21@szxga05-in.huawei.com> for radext@ietf.org; Fri, 17 Feb 2012 19:13:48 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHE68034; Fri, 17 Feb 2012 19:13:23 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 19:12:57 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 19:13:07 +0800 Date: Fri, 17 Feb 2012 11:13:06 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: "Sanchez, Mauricio (HP Networking)" , "jouni.korhonen@nsn.com" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] RADEXT recharter Thread-index: AczaG/xDKiJT9gNoRwm22tOW8sfaJAAdk5+wBKV1s9A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "Romascanu, Dan \(Dan\)" , Stefan Winter , "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org As per the MM of Radext session, IETF82-Taipei, http://www.ietf.org/proceedings/82/minutes/radext.txt 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh -Chair: Is anyone against having an accounting document? No objection. Ask authors to work out a single proposal. Need to determine if we bring into a new charter. ... -Chair: Consensus check on adding this topic to the re-charter: Show of hands on who is interested and will participate in the effort? 4 - yes, 0 - against. Will take to list, strong consensus to update the charter and make this a working group item. Ask authors to work towards a unified proposal.... -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. I suggest to add 'RADIUS Accounting Extensions for Traffic Statistics' as the work item in the charter. The following text against the revision on the WG charter are for your reference and the further discussion. Work Item .... RADIUS Accounting Extensions for Traffic Statistics: This document specifies the dedicated RADIUS attributes on IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server. Goals and Milestones ... Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC OTOH, as per the MM of Radext session, 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh http://www.ietf.org/proceedings/82/slides/radext-2.pptx ... -AD: before we develop the contributions, ask authors to put together pros and cons of options, remaining points of disagreement. See if we can get agreement on a baseline proposal -Chair: ...Ask authors to work towards a unified proposal. and the discussion in the ML about draft-ietf-radext-radius-extensions and RFC6158, I will trigger a discussion on this attribute design soon again, then update the draft with Stefan for a 'baseline proposal'. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, January 24, 2012 8:21 PM To: Sanchez, Mauricio (HP Networking); radext@ietf.org Subject: Re: [radext] RADEXT recharter Hi, As Dave Nelson already pointed out, two of the documents in the charter were already approved as RFCs. Also the milestones need to be revisited in case the discussions of this new charter continue until IETF-83 (end of March 2012) because most of them target January - March 2012. Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Sanchez, Mauricio (HP Networking) > Sent: Tuesday, January 24, 2012 12:11 AM > To: radext@ietf.org > Subject: [radext] RADEXT recharter > > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items > that the WG believes relevant, as well as recalibrating dates on > several committed goals. > > Below is the new proposed WG charter that your chairs and AD agreed > upon. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your > changes and justify why. > > Our aim is to have this re-chartering discussion completed by next IETF > meeting. > > - Mauricio and Jouni > > > --------- > > Description of Working Group > > The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol required to expand and enrich the standard attribute > space, address cryptographic algorithm agility, use of new secure > transports and clarify its usage and definition. > > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter > will be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, > the following restrictions are imposed on extensions considered by the > RADEXT > WG: > > - All documents produced MUST specify means of interoperation with > legacy RADIUS and, if possible, be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668- > 4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, > be compatible with RFC 3539. > > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should > be included in the specification. > > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. > > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > > -RADIUS attribute space extension. The standard RADIUS attribute space > is currently being depleted. This document will provide additional > standard attribute space, while maintaining backward compatibility with > existing attributes. > > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > relied on MD5 for both per-packet integrity and authentication as well > as attribute confidentiality. Given the increasingly successful attacks > being mounted against MD5, the ability to support alternative > algorithms is required. This work item will include documentation of > RADIUS crypto-agility requirements, as well as development of one or > more Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > > -IEEE 802 attributes. New attributes have been proposed to support IEEE > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. A reliable transport profile for RADIUS will > be developed, as well as specifications for Secure transports, > including TCP/TLS (RADSEC) and UDP/DTLS. > > - Documentation of Status-Server usage. A document describing usage of > the Status-Server facility will be developed. > > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with > RFC4282 in two phases. In first phase, RFC4282bis will be issued to > eliminate fundamental incompatibilities with RADIUS around character > encoding and NAI modifications by proxies. In second phase, a fresh > review of NAI internationalization requirements and behavior will be > undertaken with a clear goal of maintaining compatibility with RADIUS. > > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > Done SIP RADIUS authentication draft submitted as a Proposed > Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a > Proposed > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as > an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out > from Issues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed > Standard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a > Proposed > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > Proposed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Tue Feb 21 08:52:15 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6B521F886A for ; Tue, 21 Feb 2012 08:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_05=-1.11, 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 Ukyy+ZF4mcDC for ; Tue, 21 Feb 2012 08:52:11 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id A003C21F886F for ; Tue, 21 Feb 2012 08:52:08 -0800 (PST) Received: from BLU152-DS11 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 08:52:07 -0800 X-Originating-IP: [76.22.61.46] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Tue, 21 Feb 2012 08:52:22 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032E_01CCF076.204BFDC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczwuIaWV3kRsIMFSi2g60l8HYt5QA== Content-Language: en-us X-OriginalArrivalTime: 21 Feb 2012 16:52:07.0672 (UTC) FILETIME=[25901F80:01CCF0B9] Subject: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:52:16 -0000 ------=_NextPart_000_032E_01CCF076.204BFDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IAB is working on a document entitled "Design Considerations for Protocol Extensions", which includes a RADIUS case study in Appendix A.2. The text of the RADIUS case study is included below. Comments welcome. A.2. RADIUS Extensions The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. ------=_NextPart_000_032E_01CCF076.204BFDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IAB is = working on a document entitled  "Design= Considerations for Protocol Extensions", which includes a = RADIUS case study in Appendix A.2.

The text of the RADIUS case study is included = below.   Comments welcome.

 

A.2.  = RADIUS Extensions

 

   = The RADIUS [RFC2865] protocol was designed to be extensible = via

   addition of = Attributes to a Data Dictionary on the server, without

   requiring code changes.  However, = this extensibility model assumed

   that Attributes would conform to a = limited set of data types and that

   vendor extensions would be limited to use = by vendors, in situations

   in which interoperability was not = required.  Subsequent developments

   have stretched those = assumptions.

 

   From the beginning, uses of the RADIUS = protocol extended beyond the

   scope of the original protocol definition = (and beyond the scope of

   = the RADIUS Working Group charter).  In addition to rampant = self-

   allocation within = the limited RADIUS standard attribute space,

   vendors defined their own RADIUS = commands.  This lead to the rapid

   proliferation of vendor-specific protocol = variants.  To this day,

   many common implementation practices have = not been documented.  As

   noted in "Extended RADIUS = Practices" [RFC2882] Section 1:

 

      The RADIUS Working = Group was formed in 1995 to document the

      protocol of the same = name, and was chartered to stay within a set

      of bounds for dial-in = terminal servers.  Unfortunately the real

      world of Network Access = Servers (NASes) hasn't stayed that small

      and simple, and = continues to evolve at an amazing rate.

 

      This document shows = some of the current implementations on the

      market have already = outstripped the capabilities of the RADIUS

      protocol.  A quite = a few features have been developed completely

      outside the = protocol.  These features use the RADIUS protocol

      structure and format, = but employ operations and semantics well

      beyond the RFC = documents.

 

   The limited set of data types defined in = [RFC2865] has lead to

   = subsequent documents defining new data types.  Since new data = types

   are typically = defined implicitly as part of defining a new attribute,

   and because RADIUS client and server = implementations differ in their

   support of these additional = specifications, there is no definitive

   registry of RADIUS data types and data = type support has been

   = inconsistent.  To catalog commonly implemented data types as well = as

   to provide guidance = for implementers as well as attribute designers,

   "RADIUS Design Guidelines" = [RFC6158] Section 2.1 includes advice on

   basic and complex data types.  = Unfortunately, these guidelines were

   published 14 years after the RADIUS = protocol was first documented in

   [RFC2058].

 

   = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

   for = Vendor-Specific extensions (Attribute 26), and states that use = of

   Vendor-Specific = extensions:

 

      should be encouraged = instead of allocation of global attribute

      types, for functions = specific only to one vendor's implementation

      of RADIUS, where no = interoperability is deemed useful.

 

   = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

   been considerably = broader than this.  In particular, VSAs have been

   used by Standards Development = Organizations (SDOs) to define their

   own extensions to the RADIUS = protocol.  This has caused a number of

   problems.

 

   = One issue concerns the data model for VSAs.  Since it was = not

   envisaged that = multi-vendor VSA implementations would need to

   interoperate, the RADIUS specification = [RFC2865] does not define the

   data model for VSAs, and allows multiple = sub- attributes to be

   = included within a single Attribute of type 26.  Since this = enables

   VSAs to be = defined which would not be supportable by current

   implementations if placed within the = standard RADIUS attribute space,

   this has caused problems in standardizing = widely deployed VSAs, as

   = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 

   Another issue is how implementations = should handle unknown VSAs.

   [RFC2865] Section 5.26 = states:

 

      Servers not equipped to = interpret the vendor-specific information

      sent by a client MUST = ignore it (although it may be reported).

      Clients which do not = receive desired vendor-specific information

      SHOULD make an attempt = to operate without it, although they may do

      so (and report they are = doing so) in a degraded mode.

 

   = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

   and servers may = not know whether it is safe to ignore unknown VSAs.

   For example, in the case where VSAs = pertain to security (e.g.

   Filters), it may not be safe to ignore = them.  As a result, "Common

   Remote Authentication Dial In User = Service (RADIUS) Implementation

   Issues and Suggested Fixes" = [RFC5080] Section 2.5 includes the

   following caution:

 

      To avoid = misinterpretation of service requests encoded within

      VSAs, RADIUS servers = SHOULD NOT send VSAs containing service

      requests to RADIUS = clients that are not known to understand them.

      For example, a RADIUS = server should not send a VSA encoding a

      filter without = knowledge that the RADIUS client supports the VSA.

 

   = In addition to extending RADIUS by use of VSAs, SDOs have = also

   defined new values = of the Service-Type attribute in order to create

   new RADIUS commands.  Since the = RADIUS specification [RFC2865]

   defined Service-Type values as being = allocated First Come, First

   Served (FCFS), this permitted new RADIUS = commands to be allocated

   = without IETF review.  This oversight has since been fixed in = "IANA

   = Considerations for RADIUS" = [RFC3575].

------=_NextPart_000_032E_01CCF076.204BFDC0-- From radext-bounces@ietf.org Tue Feb 21 08:52:18 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F89C21F886A; Tue, 21 Feb 2012 08:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329843138; bh=4FtZPLyDUthvKj+4SDTVSTSU94IiJCIMT8mhjnsaY94=; h=Message-ID:From:To:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=mI0c7/FYHRMUl1DnFguONwGuD0TAAJ/zln8O0NIagfU9S6LbBhnE8uLvgxFTEmSR/ ZKXTSSC1K8LMLg9E1hDWpaWZarlKMWCrppXVQJOZuLy7LIXhvlqN9vPDEhYlxWM5UI w3hbx9uS9yGFy8eDRgm/GEHI/usRJf6xHV1IQ0pw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6B521F886A for ; Tue, 21 Feb 2012 08:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_05=-1.11, 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 Ukyy+ZF4mcDC for ; Tue, 21 Feb 2012 08:52:11 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id A003C21F886F for ; Tue, 21 Feb 2012 08:52:08 -0800 (PST) Received: from BLU152-DS11 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 08:52:07 -0800 X-Originating-IP: [76.22.61.46] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Tue, 21 Feb 2012 08:52:22 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczwuIaWV3kRsIMFSi2g60l8HYt5QA== Content-Language: en-us X-OriginalArrivalTime: 21 Feb 2012 16:52:07.0672 (UTC) FILETIME=[25901F80:01CCF0B9] Subject: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8140781780932007300==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============8140781780932007300== Content-Type: multipart/alternative; boundary="----=_NextPart_000_032E_01CCF076.204BFDC0" Content-Language: en-us ------=_NextPart_000_032E_01CCF076.204BFDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IAB is working on a document entitled "Design Considerations for Protocol Extensions", which includes a RADIUS case study in Appendix A.2. The text of the RADIUS case study is included below. Comments welcome. A.2. RADIUS Extensions The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. ------=_NextPart_000_032E_01CCF076.204BFDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IAB is = working on a document entitled  "Design= Considerations for Protocol Extensions", which includes a = RADIUS case study in Appendix A.2.

The text of the RADIUS case study is included = below.   Comments welcome.

 

A.2.  = RADIUS Extensions

 

   = The RADIUS [RFC2865] protocol was designed to be extensible = via

   addition of = Attributes to a Data Dictionary on the server, without

   requiring code changes.  However, = this extensibility model assumed

   that Attributes would conform to a = limited set of data types and that

   vendor extensions would be limited to use = by vendors, in situations

   in which interoperability was not = required.  Subsequent developments

   have stretched those = assumptions.

 

   From the beginning, uses of the RADIUS = protocol extended beyond the

   scope of the original protocol definition = (and beyond the scope of

   = the RADIUS Working Group charter).  In addition to rampant = self-

   allocation within = the limited RADIUS standard attribute space,

   vendors defined their own RADIUS = commands.  This lead to the rapid

   proliferation of vendor-specific protocol = variants.  To this day,

   many common implementation practices have = not been documented.  As

   noted in "Extended RADIUS = Practices" [RFC2882] Section 1:

 

      The RADIUS Working = Group was formed in 1995 to document the

      protocol of the same = name, and was chartered to stay within a set

      of bounds for dial-in = terminal servers.  Unfortunately the real

      world of Network Access = Servers (NASes) hasn't stayed that small

      and simple, and = continues to evolve at an amazing rate.

 

      This document shows = some of the current implementations on the

      market have already = outstripped the capabilities of the RADIUS

      protocol.  A quite = a few features have been developed completely

      outside the = protocol.  These features use the RADIUS protocol

      structure and format, = but employ operations and semantics well

      beyond the RFC = documents.

 

   The limited set of data types defined in = [RFC2865] has lead to

   = subsequent documents defining new data types.  Since new data = types

   are typically = defined implicitly as part of defining a new attribute,

   and because RADIUS client and server = implementations differ in their

   support of these additional = specifications, there is no definitive

   registry of RADIUS data types and data = type support has been

   = inconsistent.  To catalog commonly implemented data types as well = as

   to provide guidance = for implementers as well as attribute designers,

   "RADIUS Design Guidelines" = [RFC6158] Section 2.1 includes advice on

   basic and complex data types.  = Unfortunately, these guidelines were

   published 14 years after the RADIUS = protocol was first documented in

   [RFC2058].

 

   = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

   for = Vendor-Specific extensions (Attribute 26), and states that use = of

   Vendor-Specific = extensions:

 

      should be encouraged = instead of allocation of global attribute

      types, for functions = specific only to one vendor's implementation

      of RADIUS, where no = interoperability is deemed useful.

 

   = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

   been considerably = broader than this.  In particular, VSAs have been

   used by Standards Development = Organizations (SDOs) to define their

   own extensions to the RADIUS = protocol.  This has caused a number of

   problems.

 

   = One issue concerns the data model for VSAs.  Since it was = not

   envisaged that = multi-vendor VSA implementations would need to

   interoperate, the RADIUS specification = [RFC2865] does not define the

   data model for VSAs, and allows multiple = sub- attributes to be

   = included within a single Attribute of type 26.  Since this = enables

   VSAs to be = defined which would not be supportable by current

   implementations if placed within the = standard RADIUS attribute space,

   this has caused problems in standardizing = widely deployed VSAs, as

   = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 

   Another issue is how implementations = should handle unknown VSAs.

   [RFC2865] Section 5.26 = states:

 

      Servers not equipped to = interpret the vendor-specific information

      sent by a client MUST = ignore it (although it may be reported).

      Clients which do not = receive desired vendor-specific information

      SHOULD make an attempt = to operate without it, although they may do

      so (and report they are = doing so) in a degraded mode.

 

   = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

   and servers may = not know whether it is safe to ignore unknown VSAs.

   For example, in the case where VSAs = pertain to security (e.g.

   Filters), it may not be safe to ignore = them.  As a result, "Common

   Remote Authentication Dial In User = Service (RADIUS) Implementation

   Issues and Suggested Fixes" = [RFC5080] Section 2.5 includes the

   following caution:

 

      To avoid = misinterpretation of service requests encoded within

      VSAs, RADIUS servers = SHOULD NOT send VSAs containing service

      requests to RADIUS = clients that are not known to understand them.

      For example, a RADIUS = server should not send a VSA encoding a

      filter without = knowledge that the RADIUS client supports the VSA.

 

   = In addition to extending RADIUS by use of VSAs, SDOs have = also

   defined new values = of the Service-Type attribute in order to create

   new RADIUS commands.  Since the = RADIUS specification [RFC2865]

   defined Service-Type values as being = allocated First Come, First

   Served (FCFS), this permitted new RADIUS = commands to be allocated

   = without IETF review.  This oversight has since been fixed in = "IANA

   = Considerations for RADIUS" = [RFC3575].

------=_NextPart_000_032E_01CCF076.204BFDC0-- --===============8140781780932007300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============8140781780932007300==-- From radext-bounces@ietf.org Wed Feb 22 04:43:08 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FC221F8702; Wed, 22 Feb 2012 04:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329914588; bh=FHVXcA07H/eXqLt60mGL+voYVsTo25udxxvbR1fhbgc=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=KBTZU5me6y7WT9i+qMwH4YoRgY/CS6o2+5G4Fd/DYSR7kJmWDMBEXbnl/G+mWZ1h/ cn4GfCETovj8dxiK64lb2/YRJKex4TViFU4yBC454GjaMJKWBhpXF+3AQoNuLcB9dQ uoWpx72NQk7HGyYK261W0XC4apomB7NnBvvY8jFY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387421F8702 for ; Wed, 22 Feb 2012 04:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.355 X-Spam-Level: X-Spam-Status: No, score=-103.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XfbfOvgbpnx for ; Wed, 22 Feb 2012 04:43:03 -0800 (PST) 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 79D9421F85C2 for ; Wed, 22 Feb 2012 04:43:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMPhRE/GmAcF/2dsb2JhbABDgk2nAgGJFYEHgXMBAQEBAxIKEQNZAgEIDQQEAQELBgwLAQYBRQkIAQEEARIIGodom1+cH4ligncIFkwDEYUiBUcGGoJZYwSbN4xvgVIFAw X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208,217";a="292689390" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2012 07:42:59 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2012 07:36:14 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Feb 2012 13:42:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADIUS case study Thread-Index: AczwuIaWV3kRsIMFSi2g60l8HYt5QAApsxQg References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1050145191938304792==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============1050145191938304792== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF15F.80A16793" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF15F.80A16793 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 This is an IAB document - what is its status? Was it approved by the IAB? Is it still work-in-progress and you / the IAB are soliciting comments?=20 =20 Dan =20 =20 From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, February 21, 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study =20 The IAB is working on a document entitled "Design Considerations for Protocol Extensions" , which includes a RADIUS case study in Appendix A.2.=20 The text of the RADIUS case study is included below. Comments welcome. =20 A.2. RADIUS Extensions =20 The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. =20 From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: =20 The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. =20 This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. =20 The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. =20 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: =20 should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. =20 However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. =20 One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. =20 Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: =20 Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. =20 However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: =20 To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. =20 In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. ------_=_NextPart_001_01CCF15F.80A16793 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard,

 

This is an IAB document = – what is its status? Was it approved by the IAB? Is it still = work-in-progress and you / the IAB are soliciting comments? =

 

Dan

=

 

 

From:= = radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 = PM
To: radext@ietf.org
Subject: [radext] RADIUS case = study

 

The IAB is = working on a document entitled  "Design= Considerations for Protocol Extensions", which includes a = RADIUS case study in Appendix A.2.

The text of the RADIUS case study is included = below.   Comments welcome.

 

A.2.  = RADIUS Extensions

 

   = The RADIUS [RFC2865] protocol was designed to be extensible = via

   addition of = Attributes to a Data Dictionary on the server, without

   requiring code changes.  However, = this extensibility model assumed

   that Attributes would conform to a = limited set of data types and that

   vendor extensions would be limited to use = by vendors, in situations

   in which interoperability was not = required.  Subsequent developments

   have stretched those = assumptions.

 

   From the beginning, uses of the RADIUS = protocol extended beyond the

   scope of the original protocol definition = (and beyond the scope of

   = the RADIUS Working Group charter).  In addition to rampant = self-

   allocation within = the limited RADIUS standard attribute space,

   vendors defined their own RADIUS = commands.  This lead to the rapid

   proliferation of vendor-specific protocol = variants.  To this day,

   many common implementation practices have = not been documented.  As

   noted in "Extended RADIUS = Practices" [RFC2882] Section 1:

 

      The RADIUS Working = Group was formed in 1995 to document the

      protocol of the same = name, and was chartered to stay within a set

      of bounds for dial-in = terminal servers.  Unfortunately the real

      world of Network Access = Servers (NASes) hasn't stayed that small

      and simple, and = continues to evolve at an amazing rate.

 

      This document shows = some of the current implementations on the

      market have already = outstripped the capabilities of the RADIUS

      protocol.  A quite = a few features have been developed completely

      outside the = protocol.  These features use the RADIUS protocol

      structure and format, = but employ operations and semantics well

      beyond the RFC = documents.

 

   The limited set of data types defined in = [RFC2865] has lead to

   = subsequent documents defining new data types.  Since new data = types

   are typically = defined implicitly as part of defining a new attribute,

   and because RADIUS client and server = implementations differ in their

   support of these additional = specifications, there is no definitive

   registry of RADIUS data types and data = type support has been

   = inconsistent.  To catalog commonly implemented data types as well = as

   to provide guidance = for implementers as well as attribute designers,

   "RADIUS Design Guidelines" = [RFC6158] Section 2.1 includes advice on

   basic and complex data types.  = Unfortunately, these guidelines were

   published 14 years after the RADIUS = protocol was first documented in

   [RFC2058].

 

   = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

   for = Vendor-Specific extensions (Attribute 26), and states that use = of

   Vendor-Specific = extensions:

 

      should be encouraged = instead of allocation of global attribute

      types, for functions = specific only to one vendor's implementation

      of RADIUS, where no = interoperability is deemed useful.

 

   = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

   been considerably = broader than this.  In particular, VSAs have been

   used by Standards Development = Organizations (SDOs) to define their

   own extensions to the RADIUS = protocol.  This has caused a number of

   problems.

 

   = One issue concerns the data model for VSAs.  Since it was = not

   envisaged that = multi-vendor VSA implementations would need to

   interoperate, the RADIUS specification = [RFC2865] does not define the

   data model for VSAs, and allows multiple = sub- attributes to be

   = included within a single Attribute of type 26.  Since this = enables

   VSAs to be = defined which would not be supportable by current

   implementations if placed within the = standard RADIUS attribute space,

   this has caused problems in standardizing = widely deployed VSAs, as

   = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 

   Another issue is how implementations = should handle unknown VSAs.

   [RFC2865] Section 5.26 = states:

 

      Servers not equipped to = interpret the vendor-specific information

      sent by a client MUST = ignore it (although it may be reported).

      Clients which do not = receive desired vendor-specific information

      SHOULD make an attempt = to operate without it, although they may do

      so (and report they are = doing so) in a degraded mode.

 

   = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

   and servers may = not know whether it is safe to ignore unknown VSAs.

   For example, in the case where VSAs = pertain to security (e.g.

   Filters), it may not be safe to ignore = them.  As a result, "Common

   Remote Authentication Dial In User = Service (RADIUS) Implementation

   Issues and Suggested Fixes" = [RFC5080] Section 2.5 includes the

   following caution:

 

      To avoid = misinterpretation of service requests encoded within

      VSAs, RADIUS servers = SHOULD NOT send VSAs containing service

      requests to RADIUS = clients that are not known to understand them.

      For example, a RADIUS = server should not send a VSA encoding a

      filter without = knowledge that the RADIUS client supports the VSA.

 

   = In addition to extending RADIUS by use of VSAs, SDOs have = also

   defined new values = of the Service-Type attribute in order to create

   new RADIUS commands.  Since the = RADIUS specification [RFC2865]

   defined Service-Type values as being = allocated First Come, First

   Served (FCFS), this permitted new RADIUS = commands to be allocated

   = without IETF review.  This oversight has since been fixed in = "IANA

   = Considerations for RADIUS" = [RFC3575].

------_=_NextPart_001_01CCF15F.80A16793-- --===============1050145191938304792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1050145191938304792==-- From dromasca@avaya.com Wed Feb 22 04:43:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387421F8702 for ; Wed, 22 Feb 2012 04:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.355 X-Spam-Level: X-Spam-Status: No, score=-103.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XfbfOvgbpnx for ; Wed, 22 Feb 2012 04:43:03 -0800 (PST) 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 79D9421F85C2 for ; Wed, 22 Feb 2012 04:43:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMPhRE/GmAcF/2dsb2JhbABDgk2nAgGJFYEHgXMBAQEBAxIKEQNZAgEIDQQEAQELBgwLAQYBRQkIAQEEARIIGodom1+cH4ligncIFkwDEYUiBUcGGoJZYwSbN4xvgVIFAw X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208,217";a="292689390" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2012 07:42:59 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2012 07:36:14 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF15F.80A16793" Date: Wed, 22 Feb 2012 13:42:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADIUS case study Thread-Index: AczwuIaWV3kRsIMFSi2g60l8HYt5QAApsxQg References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 12:43:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF15F.80A16793 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 This is an IAB document - what is its status? Was it approved by the IAB? Is it still work-in-progress and you / the IAB are soliciting comments?=20 =20 Dan =20 =20 From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, February 21, 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study =20 The IAB is working on a document entitled "Design Considerations for Protocol Extensions" , which includes a RADIUS case study in Appendix A.2.=20 The text of the RADIUS case study is included below. Comments welcome. =20 A.2. RADIUS Extensions =20 The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. =20 From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: =20 The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. =20 This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. =20 The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. =20 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: =20 should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. =20 However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. =20 One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. =20 Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: =20 Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. =20 However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: =20 To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. =20 In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. ------_=_NextPart_001_01CCF15F.80A16793 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard,

 

This is an IAB document = – what is its status? Was it approved by the IAB? Is it still = work-in-progress and you / the IAB are soliciting comments? =

 

Dan

=

 

 

From:= = radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 = PM
To: radext@ietf.org
Subject: [radext] RADIUS case = study

 

The IAB is = working on a document entitled  "Design= Considerations for Protocol Extensions", which includes a = RADIUS case study in Appendix A.2.

The text of the RADIUS case study is included = below.   Comments welcome.

 

A.2.  = RADIUS Extensions

 

   = The RADIUS [RFC2865] protocol was designed to be extensible = via

   addition of = Attributes to a Data Dictionary on the server, without

   requiring code changes.  However, = this extensibility model assumed

   that Attributes would conform to a = limited set of data types and that

   vendor extensions would be limited to use = by vendors, in situations

   in which interoperability was not = required.  Subsequent developments

   have stretched those = assumptions.

 

   From the beginning, uses of the RADIUS = protocol extended beyond the

   scope of the original protocol definition = (and beyond the scope of

   = the RADIUS Working Group charter).  In addition to rampant = self-

   allocation within = the limited RADIUS standard attribute space,

   vendors defined their own RADIUS = commands.  This lead to the rapid

   proliferation of vendor-specific protocol = variants.  To this day,

   many common implementation practices have = not been documented.  As

   noted in "Extended RADIUS = Practices" [RFC2882] Section 1:

 

      The RADIUS Working = Group was formed in 1995 to document the

      protocol of the same = name, and was chartered to stay within a set

      of bounds for dial-in = terminal servers.  Unfortunately the real

      world of Network Access = Servers (NASes) hasn't stayed that small

      and simple, and = continues to evolve at an amazing rate.

 

      This document shows = some of the current implementations on the

      market have already = outstripped the capabilities of the RADIUS

      protocol.  A quite = a few features have been developed completely

      outside the = protocol.  These features use the RADIUS protocol

      structure and format, = but employ operations and semantics well

      beyond the RFC = documents.

 

   The limited set of data types defined in = [RFC2865] has lead to

   = subsequent documents defining new data types.  Since new data = types

   are typically = defined implicitly as part of defining a new attribute,

   and because RADIUS client and server = implementations differ in their

   support of these additional = specifications, there is no definitive

   registry of RADIUS data types and data = type support has been

   = inconsistent.  To catalog commonly implemented data types as well = as

   to provide guidance = for implementers as well as attribute designers,

   "RADIUS Design Guidelines" = [RFC6158] Section 2.1 includes advice on

   basic and complex data types.  = Unfortunately, these guidelines were

   published 14 years after the RADIUS = protocol was first documented in

   [RFC2058].

 

   = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

   for = Vendor-Specific extensions (Attribute 26), and states that use = of

   Vendor-Specific = extensions:

 

      should be encouraged = instead of allocation of global attribute

      types, for functions = specific only to one vendor's implementation

      of RADIUS, where no = interoperability is deemed useful.

 

   = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

   been considerably = broader than this.  In particular, VSAs have been

   used by Standards Development = Organizations (SDOs) to define their

   own extensions to the RADIUS = protocol.  This has caused a number of

   problems.

 

   = One issue concerns the data model for VSAs.  Since it was = not

   envisaged that = multi-vendor VSA implementations would need to

   interoperate, the RADIUS specification = [RFC2865] does not define the

   data model for VSAs, and allows multiple = sub- attributes to be

   = included within a single Attribute of type 26.  Since this = enables

   VSAs to be = defined which would not be supportable by current

   implementations if placed within the = standard RADIUS attribute space,

   this has caused problems in standardizing = widely deployed VSAs, as

   = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 

   Another issue is how implementations = should handle unknown VSAs.

   [RFC2865] Section 5.26 = states:

 

      Servers not equipped to = interpret the vendor-specific information

      sent by a client MUST = ignore it (although it may be reported).

      Clients which do not = receive desired vendor-specific information

      SHOULD make an attempt = to operate without it, although they may do

      so (and report they are = doing so) in a degraded mode.

 

   = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

   and servers may = not know whether it is safe to ignore unknown VSAs.

   For example, in the case where VSAs = pertain to security (e.g.

   Filters), it may not be safe to ignore = them.  As a result, "Common

   Remote Authentication Dial In User = Service (RADIUS) Implementation

   Issues and Suggested Fixes" = [RFC5080] Section 2.5 includes the

   following caution:

 

      To avoid = misinterpretation of service requests encoded within

      VSAs, RADIUS servers = SHOULD NOT send VSAs containing service

      requests to RADIUS = clients that are not known to understand them.

      For example, a RADIUS = server should not send a VSA encoding a

      filter without = knowledge that the RADIUS client supports the VSA.

 

   = In addition to extending RADIUS by use of VSAs, SDOs have = also

   defined new values = of the Service-Type attribute in order to create

   new RADIUS commands.  Since the = RADIUS specification [RFC2865]

   defined Service-Type values as being = allocated First Come, First

   Served (FCFS), this permitted new RADIUS = commands to be allocated

   = without IETF review.  This oversight has since been fixed in = "IANA

   = Considerations for RADIUS" = [RFC3575].

------_=_NextPart_001_01CCF15F.80A16793-- From bernard_aboba@hotmail.com Wed Feb 22 20:57:35 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB321F854E for ; Wed, 22 Feb 2012 20:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 YdD9ufCDvmCB for ; Wed, 22 Feb 2012 20:57:33 -0800 (PST) Received: from blu0-omc3-s27.blu0.hotmail.com (blu0-omc3-s27.blu0.hotmail.com [65.55.116.102]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5421F854D for ; Wed, 22 Feb 2012 20:57:21 -0800 (PST) Received: from BLU152-W27 ([65.55.116.73]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 20:57:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_29df595e-fae8-42c0-b113-e7aabf443f59_" X-Originating-IP: [76.22.61.46] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Wed, 22 Feb 2012 20:57:19 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 04:57:20.0201 (UTC) FILETIME=[9F76E390:01CCF1E7] Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 04:57:35 -0000 --_29df595e-fae8-42c0-b113-e7aabf443f59_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The document that has completed a 4-week IETF "Call for Comment"=2C and the= IAB has now initiated a two-week "last call" concluding on March 7=2C 2012= =2C after which the document will be considered for approval.=20 Since some questions arose about the RADIUS case study=2C feedback is being= requested from RADEXT WG on that.=20 However=2C comments are also welcome on any other portion of the document. = =20 Comments on the RADIUS case study can be sent to this list.=20 Comments on other aspects can be sent to iab@iab.org or filed in TRAC (see = below).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 Submitting Comments via TRAC =20 =20 1. To submit an issue in TRAC=2C you first need to login on the tools serve= r: http://tools.ietf.org/wg/iab/ =20 trac/login =20 =20 2. If you don't already have a login ID=2C you can obtain one by =20 navigating to this site: http:// =20 trac.tools.ietf.org/newlogin =20 =20 3. Once you have obtained an account=2C and have logged in=2C you can file = =20 an issue by navigating to the ticket entry form: http:// =20 =20 trac.tools.ietf.org/wg/iab/trac/newticket =20 =20 4. When opening an issue: =20 =20 a. The Type: field should be set to "defect" for an issue with the =20 current document text=2C or "enhancement" for a proposed addition of =20 functionality (such as an additional requirement). =20 b. The Priority: field is set based on the severity of the Issue. For =20 example=2C editorial issues are typically "minor" or "trivial". =20 c. The Milestone: field should be set to milestone1 (useless=2C I know). =20 =20 d. The Component: field should be set to the document you are filing =20 the issue on. =20 e. The Version: field should be set to "1.0". =20 f. The Severity: field should be set to based on the status of the =20 document (e.g. "In WG Last Call" for a document in IAB last call) =20 g. The Keywords: and CC: fields can be left blank unless inspiration =20 seizes you. =20 h. The Assign To: field is generally filled in with the email address =20 of the editor. =20 =20 5. Typically it won't be necessary to enclose a file with the ticket=2C =20 but if you need to=2C select "I have files to attach to this ticket". =20 =20 6. If you want to preview your Issue=2C click on the "Preview" button. =20 When you're ready to submit the issue=2C click on the "Create Ticket" butto= n.=20 =20 =20 7. If you want to update an issue=2C go to the "View Tickets" page: =20 http:// =20 trac.tools.ietf.org/wg/iab/trac/report/1 =20 =20 Click on the ticket # you want to update=2C and then modify the ticket fiel= ds=20 as required =20 Date: Wed=2C 22 Feb 2012 13:42:56 +0100 From: dromasca@avaya.com To: bernard_aboba@hotmail.com=3B radext@ietf.org Subject: Re: [radext] RADIUS case study Bernard=2C This is an IAB document =96 what is its status? Was it approved = by the IAB? Is it still work-in-progress and you / the IAB are soliciting c= omments? Dan From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.o= rg] On Behalf Of Bernard Aboba Sent: Tuesday=2C February 21=2C 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study The IAB is working on a document entitl= ed "Design Considerations for Protocol Extensions"=2C which includes a RAD= IUS case study in Appendix A.2. The text of the RADIUS case study is includ= ed below. Comments welcome. A.2. RADIUS Extensions The RADIUS [RFC28= 65] protocol was designed to be extensible via addition of Attributes to = a Data Dictionary on the server=2C without requiring code changes. Howev= er=2C this extensibility model assumed that Attributes would conform to a= limited set of data types and that vendor extensions would be limited to= use by vendors=2C in situations in which interoperability was not requir= ed. Subsequent developments have stretched those assumptions. From th= e beginning=2C uses of the RADIUS protocol extended beyond the scope of t= he original protocol definition (and beyond the scope of the RADIUS Worki= ng Group charter). In addition to rampant self- allocation within the li= mited RADIUS standard attribute space=2C vendors defined their own RADIUS= commands. This lead to the rapid proliferation of vendor-specific proto= col variants. To this day=2C many common implementation practices have n= ot been documented. As noted in "Extended RADIUS Practices" [RFC2882] Se= ction 1: The RADIUS Working Group was formed in 1995 to document the = protocol of the same name=2C and was chartered to stay within a set = of bounds for dial-in terminal servers. Unfortunately the real wor= ld of Network Access Servers (NASes) hasn't stayed that small and simp= le=2C and continues to evolve at an amazing rate. This document shows= some of the current implementations on the market have already outstr= ipped the capabilities of the RADIUS protocol. A quite a few features= have been developed completely outside the protocol. These features = use the RADIUS protocol structure and format=2C but employ operations = and semantics well beyond the RFC documents. The limited set of dat= a types defined in [RFC2865] has lead to subsequent documents defining ne= w data types. Since new data types are typically defined implicitly as p= art of defining a new attribute=2C and because RADIUS client and server i= mplementations differ in their support of these additional specifications= =2C there is no definitive registry of RADIUS data types and data type su= pport has been inconsistent. To catalog commonly implemented data types = as well as to provide guidance for implementers as well as attribute desi= gners=2C "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice= on basic and complex data types. Unfortunately=2C these guidelines were= published 14 years after the RADIUS protocol was first documented in [= RFC2058]. Section 6.2 of the RADIUS specification [RFC2865] defines a me= chanism for Vendor-Specific extensions (Attribute 26)=2C and states that = use of Vendor-Specific extensions: should be encouraged instead of = allocation of global attribute types=2C for functions specific only to= one vendor's implementation of RADIUS=2C where no interoperability is= deemed useful. However=2C in practice usage of Vendor-Specific Attribut= es (VSAs) has been considerably broader than this. In particular=2C VSAs= have been used by Standards Development Organizations (SDOs) to define t= heir own extensions to the RADIUS protocol. This has caused a number of = problems. One issue concerns the data model for VSAs. Since it was no= t envisaged that multi-vendor VSA implementations would need to interop= erate=2C the RADIUS specification [RFC2865] does not define the data mode= l for VSAs=2C and allows multiple sub- attributes to be included within a= single Attribute of type 26. Since this enables VSAs to be defined whic= h would not be supportable by current implementations if placed within th= e standard RADIUS attribute space=2C this has caused problems in standard= izing widely deployed VSAs=2C as discussed in "RADIUS Design Guidelines" = BCP 158 [RFC6158]. Another issue is how implementations should handle un= known VSAs. [RFC2865] Section 5.26 states: Servers not equipped to = interpret the vendor-specific information sent by a client MUST ignore= it (although it may be reported). Clients which do not receive desire= d vendor-specific information SHOULD make an attempt to operate withou= t it=2C although they may do so (and report they are doing so) in a de= graded mode. However=2C since VSAs do not contain a "mandatory" bit=2C R= ADIUS clients and servers may not know whether it is safe to ignore unkno= wn VSAs. For example=2C in the case where VSAs pertain to security (e.g. = Filters)=2C it may not be safe to ignore them. As a result=2C "Common = Remote Authentication Dial In User Service (RADIUS) Implementation Issues= and Suggested Fixes" [RFC5080] Section 2.5 includes the following cautio= n: To avoid misinterpretation of service requests encoded within = VSAs=2C RADIUS servers SHOULD NOT send VSAs containing service reques= ts to RADIUS clients that are not known to understand them. For exampl= e=2C a RADIUS server should not send a VSA encoding a filter without k= nowledge that the RADIUS client supports the VSA. In addition to extendi= ng RADIUS by use of VSAs=2C SDOs have also defined new values of the Serv= ice-Type attribute in order to create new RADIUS commands. Since the RAD= IUS specification [RFC2865] defined Service-Type values as being allocate= d First Come=2C First Served (FCFS)=2C this permitted new RADIUS commands= to be allocated without IETF review. This oversight has since been fixe= d in "IANA Considerations for RADIUS" [RFC3575]. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_29df595e-fae8-42c0-b113-e7aabf443f59_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The document that has completed a 4-week IETF "Call for Comment"=2C and the= IAB has now initiated a two-week "last call" concluding on March 7=2C 2012= =2C after which the document will be considered for approval.

Since= some questions arose about the RADIUS case study=2C feedback is being requ= ested from RADEXT WG on that.

However=2C comments are also welcome = on any other portion of the document. =3B

Comments on the RADIU= S case study can be sent to this list.

Comments on other aspects ca= n be sent to iab@iab.org or filed in TRAC (see below).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =3B
Submitting Comments via TRAC  =3B
 =3B
1. To submit an issue in TRAC=2C you first need to login on the tools serve= r: http://tools= .ietf.org/wg/iab/  =3B
<=3Bhttp://tools.ietf.org/wg/iab/trac/login>=3B trac/login  =3B=
 =3B
2. If you don't already have a login ID=2C you can obtain one by  =3B navigating to this site: http:// <=3Bhttp://trac.tools.ietf.org/newlogin&= gt=3B  =3B
trac.tool= s.ietf.org/newlogin  =3B
 =3B
3. Once you have obtained an account=2C and have logged in=2C you can file =  =3B
an issue by navigating to the ticket entry form: http://  =3B
<=3Bhttp://trac.tools.ietf.org/wg/iab/trac/newticket>=3B=  =3B
trac.tools.ietf.org/wg/iab/trac/newticket  =3B
 =3B
4. When opening an issue:  =3B
 =3B
a. The Type: field should be set to "defect" for an issue with the  =3B=
current document text=2C or "enhancement" for a proposed addition of  = =3B
functionality (such as an additional requirement).  =3B
b. The Priority: field is set based on the severity of the Issue. For  = =3B
example=2C editorial issues are typically "minor" or "trivial".  =3B c. The Milestone: field should be set to milestone1 (useless=2C I know). &n= bsp=3B
 =3B
d. The Component: field should be set to the document you are filing  = =3B
the issue on.  =3B
e. The Version: field should be set to "1.0".  =3B
f. The Severity: field should be set to based on the status of the  =3B=
document (e.g. "In WG Last Call" for a document in IAB last call)  =3B<= br> g. The Keywords: and CC: fields can be left blank unless inspiration  = =3B
seizes you.  =3B
h. The Assign To: field is generally filled in with the email address  = =3B
of the editor.  =3B
 =3B
5. Typically it won't be necessary to enclose a file with the ticket=2C &nb= sp=3B
but if you need to=2C select "I have files to attach to this ticket". &nbs= p=3B
 =3B
6. If you want to preview your Issue=2C click on the "Preview" button. &nbs= p=3B
When you're ready to submit the issue=2C click on the "Create Ticket" butto= n. =3B
 =3B
 =3B
7. If you want to update an issue=2C go to the "View Tickets" page:  = =3B
http:// <=3Bhttp://trac.tools.ietf.org/wg/iab/trac/report/1&g= t=3B  =3B
trac.tools.ietf.org/wg/iab/trac/report/1  =3B
 =3B
Click on the ticket # you want to update=2C and then modify the ticket fiel= ds =3B
as required =3B


=
Date: Wed=2C 22 Feb 2012 13:42:56 +0100
Fr= om: dromasca@avaya.com
To: bernard_aboba@hotmail.com=3B radext@ietf.org<= br>Subject: Re: [radext] RADIUS case study

Bernard=2C

 =3B

This is an IAB document =96 what is its status? Was i= t approved by the IAB? Is it still work-in-progress and you / the IAB are s= oliciting comments?

 =3B

Dan

=  =3B

=  =3B

<= b>From: radext= -bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bern= ard Aboba
Sent: Tuesday=2C February 21=2C 2012 6:52 PM
To:<= /b> radext@ietf.org
Subject: [radext] RADIUS case study

 =3B

The IAB is working on a document entitled  =3B"Design Consider= ations for Protocol Extensions"=2C which includes a RADIUS case study i= n Appendix A.2.

The text of the RADIUS case s= tudy is included below. =3B =3B Comments welcome.

 =3B

A.2. =3B RADIUS Exte= nsions

 =3B

&= nbsp=3B =3B The RADIUS [RFC2865] protocol was designed to be extensible= via

 =3B =3B addition of Attributes t= o a Data Dictionary on the server=2C without

&= nbsp=3B =3B requiring code changes. =3B However=2C this extensibili= ty model assumed

 =3B =3B that Attribu= tes would conform to a limited set of data types and that

 =3B =3B vendor extensions would be limited to use by v= endors=2C in situations

 =3B =3B in wh= ich interoperability was not required. =3B Subsequent developments

<= p class=3D"ecxMsoNormal"> =3B =3B have stretched those assumptions.=

 =3B

 = =3B =3B From the beginning=2C uses of the RADIUS protocol extended beyo= nd the

 =3B =3B scope of the original = protocol definition (and beyond the scope of

&= nbsp=3B =3B the RADIUS Working Group charter). =3B In addition to r= ampant self-

 =3B =3B allocation withi= n the limited RADIUS standard attribute space=2C

 =3B =3B vendors defined their own RADIUS commands. =3B This= lead to the rapid

 =3B =3B proliferat= ion of vendor-specific protocol variants. =3B To this day=2C

 =3B =3B many common implementation practices ha= ve not been documented. =3B As

 =3B&nb= sp=3B noted in "Extended RADIUS Practices" [RFC2882] Section 1:

 =3B

 =3B =3B&nb= sp=3B =3B =3B The RADIUS Working Group was formed in 1995 to docume= nt the

 =3B =3B =3B =3B = =3B protocol of the same name=2C and was chartered to stay within a set

=

 =3B =3B =3B =3B =3B of bound= s for dial-in terminal servers. =3B Unfortunately the real

 =3B =3B =3B =3B =3B world of Network= Access Servers (NASes) hasn't stayed that small

 =3B =3B =3B =3B =3B and simple=2C and continues to = evolve at an amazing rate.

 =3B

 =3B =3B =3B =3B =3B This document s= hows some of the current implementations on the

 =3B =3B =3B =3B =3B market have already outstripped = the capabilities of the RADIUS

 =3B = =3B =3B =3B =3B protocol. =3B A quite a few features have b= een developed completely

 =3B  =3B&nbs= p=3B =3B =3Boutside the protocol. =3B These features use the RA= DIUS protocol

 =3B =3B =3B =3B=  =3B structure and format=2C but employ operations and semantics well

 =3B =3B =3B =3B =3B beyond= the RFC documents.

 =3B

 =3B =3B The limited set of data types defined in [RFC2= 865] has lead to

 =3B =3B subsequent d= ocuments defining new data types. =3B Since new data types

 =3B =3B are typically defined implicitly as part= of defining a new attribute=2C

 =3B = =3B and because RADIUS client and server implementations differ in their

 =3B =3B support of these additional spe= cifications=2C there is no definitive

 =3B=  =3B registry of RADIUS data types and data type support has been

 =3B =3B inconsistent. =3B To catalog c= ommonly implemented data types as well as

&nbs= p=3B =3B to provide guidance for implementers as well as attribute desi= gners=2C

 =3B =3B "RADIUS Design Guide= lines" [RFC6158] Section 2.1 includes advice on

 =3B =3B basic and complex data types. =3B Unfortunately=2C t= hese guidelines were

 =3B =3B publishe= d 14 years after the RADIUS protocol was first documented in

 =3B =3B [RFC2058].

&nb= sp=3B

 =3B =3B Section 6.2 of the RADI= US specification [RFC2865] defines a mechanism

 =3B =3B for Vendor-Specific extensions (Attribute 26)=2C and stat= es that use of

 =3B =3B Vendor-Specifi= c extensions:

 =3B

 =3B =3B =3B =3B =3B should be encouraged instead= of allocation of global attribute

 =3B&nb= sp=3B =3B =3B =3B types=2C for functions specific only to one v= endor's implementation

 =3B =3B = =3B =3B =3B of RADIUS=2C where no interoperability is deemed useful= .

 =3B

 = =3B =3B However=2C in practice usage of Vendor-Specific Attributes (VSA= s) has

 =3B =3B been considerably broa= der than this. =3B In particular=2C VSAs have been

 =3B =3B used by Standards Development Organizations (SDOs= ) to define their

 =3B =3B own extensi= ons to the RADIUS protocol. =3B This has caused a number of

 =3B =3B problems.

&= nbsp=3B

 =3B =3B One issue concerns th= e data model for VSAs. =3B Since it was not

 =3B =3B envisaged that multi-vendor VSA implementations would ne= ed to

 =3B =3B interoperate=2C the RAD= IUS specification [RFC2865] does not define the

 =3B =3B data model for VSAs=2C and allows multiple sub- attribut= es to be

 =3B =3B included within a si= ngle Attribute of type 26. =3B Since this enables

 =3B =3B VSAs to be defined which would not be supportable = by current

 =3B =3B implementations if= placed within the standard RADIUS attribute space=2C

 =3B =3B this has caused problems in standardizing widely d= eployed VSAs=2C as

 =3B =3B discussed = in "RADIUS Design Guidelines" BCP 158 [RFC6158].

 =3B

 =3B =3B Another issue is = how implementations should handle unknown VSAs.

 =3B =3B [RFC2865] Section 5.26 states:

 =3B

 =3B =3B =3B =3B&= nbsp=3B Servers not equipped to interpret the vendor-specific information

 =3B =3B =3B =3B =3B sent b= y a client MUST ignore it (although it may be reported).

 =3B =3B =3B =3B =3B Clients which do not re= ceive desired vendor-specific information

&nbs= p=3B =3B =3B =3B =3B SHOULD make an attempt to operate with= out it=2C although they may do

 =3B = =3B =3B =3B =3B so (and report they are doing so) in a degraded= mode.

 =3B

&= nbsp=3B =3B However=2C since VSAs do not contain a "mandatory" bit=2C R= ADIUS clients

 =3B =3B and servers may= not know whether it is safe to ignore unknown VSAs.

 =3B =3B For example=2C in the case where VSAs pertain to se= curity (e.g.

 =3B =3B Filters)=2C it m= ay not be safe to ignore them. =3B As a result=2C "Common

 =3B =3B Remote Authentication Dial In User Servi= ce (RADIUS) Implementation

 =3B =3B Is= sues and Suggested Fixes" [RFC5080] Section 2.5 includes the

 =3B =3B following caution:

 =3B

 =3B =3B =3B =3B=  =3B To avoid misinterpretation of service requests encoded within

<= p class=3D"ecxMsoNormal"> =3B =3B =3B =3B =3B VSAs=2C R= ADIUS servers SHOULD NOT send VSAs containing service

 =3B =3B =3B =3B =3B requests to RADIUS clients= that are not known to understand them.

 = =3B =3B =3B =3B =3B For example=2C a RADIUS server should n= ot send a VSA encoding a

 =3B =3B = =3B =3B =3B filter without knowledge that the RADIUS client support= s the VSA.

 =3B

 =3B =3B In addition to extending RADIUS by use of VSAs=2C SDOs = have also

 =3B =3B defined new values = of the Service-Type attribute in order to create

 =3B =3B new RADIUS commands. =3B Since the RADIUS specifica= tion [RFC2865]

 =3B =3B defined Servic= e-Type values as being allocated First Come=2C First

 =3B =3B Served (FCFS)=2C this permitted new RADIUS commands= to be allocated

 =3B =3B without IETF= review. =3B This oversight has since been fixed in "IANA

 =3B =3B Considerations for RADIUS" [RFC3575].


_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_29df595e-fae8-42c0-b113-e7aabf443f59_-- From radext-bounces@ietf.org Wed Feb 22 20:57:37 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B531D21F854D; Wed, 22 Feb 2012 20:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329973057; bh=l+IDB/rpFhonLwoa+T+7q9PQQq0XgsNpQhL6IfGHSxw=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=LzdAZ1XChn1S6/o0E9dvlII8u7bFK4rO9lOh6aS1GMl1aeA+NfPoVRDaD/dHi48e4 Nn69tSSvUHF2ORkc9RZqCyPQqzJqaVow+wVLLqBP6yJUkBDZJF3BAXjJo+xTXowFsl xczpmceHlpBucooPXWtuyvpc+YJi6u7sTiTJodyk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB321F854E for ; Wed, 22 Feb 2012 20:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 YdD9ufCDvmCB for ; Wed, 22 Feb 2012 20:57:33 -0800 (PST) Received: from blu0-omc3-s27.blu0.hotmail.com (blu0-omc3-s27.blu0.hotmail.com [65.55.116.102]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5421F854D for ; Wed, 22 Feb 2012 20:57:21 -0800 (PST) Received: from BLU152-W27 ([65.55.116.73]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 20:57:20 -0800 Message-ID: X-Originating-IP: [76.22.61.46] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Wed, 22 Feb 2012 20:57:19 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 04:57:20.0201 (UTC) FILETIME=[9F76E390:01CCF1E7] Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3341063384722141505==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============3341063384722141505== Content-Type: multipart/alternative; boundary="_29df595e-fae8-42c0-b113-e7aabf443f59_" --_29df595e-fae8-42c0-b113-e7aabf443f59_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The document that has completed a 4-week IETF "Call for Comment"=2C and the= IAB has now initiated a two-week "last call" concluding on March 7=2C 2012= =2C after which the document will be considered for approval.=20 Since some questions arose about the RADIUS case study=2C feedback is being= requested from RADEXT WG on that.=20 However=2C comments are also welcome on any other portion of the document. = =20 Comments on the RADIUS case study can be sent to this list.=20 Comments on other aspects can be sent to iab@iab.org or filed in TRAC (see = below).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 Submitting Comments via TRAC =20 =20 1. To submit an issue in TRAC=2C you first need to login on the tools serve= r: http://tools.ietf.org/wg/iab/ =20 trac/login =20 =20 2. If you don't already have a login ID=2C you can obtain one by =20 navigating to this site: http:// =20 trac.tools.ietf.org/newlogin =20 =20 3. Once you have obtained an account=2C and have logged in=2C you can file = =20 an issue by navigating to the ticket entry form: http:// =20 =20 trac.tools.ietf.org/wg/iab/trac/newticket =20 =20 4. When opening an issue: =20 =20 a. The Type: field should be set to "defect" for an issue with the =20 current document text=2C or "enhancement" for a proposed addition of =20 functionality (such as an additional requirement). =20 b. The Priority: field is set based on the severity of the Issue. For =20 example=2C editorial issues are typically "minor" or "trivial". =20 c. The Milestone: field should be set to milestone1 (useless=2C I know). =20 =20 d. The Component: field should be set to the document you are filing =20 the issue on. =20 e. The Version: field should be set to "1.0". =20 f. The Severity: field should be set to based on the status of the =20 document (e.g. "In WG Last Call" for a document in IAB last call) =20 g. The Keywords: and CC: fields can be left blank unless inspiration =20 seizes you. =20 h. The Assign To: field is generally filled in with the email address =20 of the editor. =20 =20 5. Typically it won't be necessary to enclose a file with the ticket=2C =20 but if you need to=2C select "I have files to attach to this ticket". =20 =20 6. If you want to preview your Issue=2C click on the "Preview" button. =20 When you're ready to submit the issue=2C click on the "Create Ticket" butto= n.=20 =20 =20 7. If you want to update an issue=2C go to the "View Tickets" page: =20 http:// =20 trac.tools.ietf.org/wg/iab/trac/report/1 =20 =20 Click on the ticket # you want to update=2C and then modify the ticket fiel= ds=20 as required =20 Date: Wed=2C 22 Feb 2012 13:42:56 +0100 From: dromasca@avaya.com To: bernard_aboba@hotmail.com=3B radext@ietf.org Subject: Re: [radext] RADIUS case study Bernard=2C This is an IAB document =96 what is its status? Was it approved = by the IAB? Is it still work-in-progress and you / the IAB are soliciting c= omments? Dan From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.o= rg] On Behalf Of Bernard Aboba Sent: Tuesday=2C February 21=2C 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study The IAB is working on a document entitl= ed "Design Considerations for Protocol Extensions"=2C which includes a RAD= IUS case study in Appendix A.2. The text of the RADIUS case study is includ= ed below. Comments welcome. A.2. RADIUS Extensions The RADIUS [RFC28= 65] protocol was designed to be extensible via addition of Attributes to = a Data Dictionary on the server=2C without requiring code changes. Howev= er=2C this extensibility model assumed that Attributes would conform to a= limited set of data types and that vendor extensions would be limited to= use by vendors=2C in situations in which interoperability was not requir= ed. Subsequent developments have stretched those assumptions. From th= e beginning=2C uses of the RADIUS protocol extended beyond the scope of t= he original protocol definition (and beyond the scope of the RADIUS Worki= ng Group charter). In addition to rampant self- allocation within the li= mited RADIUS standard attribute space=2C vendors defined their own RADIUS= commands. This lead to the rapid proliferation of vendor-specific proto= col variants. To this day=2C many common implementation practices have n= ot been documented. As noted in "Extended RADIUS Practices" [RFC2882] Se= ction 1: The RADIUS Working Group was formed in 1995 to document the = protocol of the same name=2C and was chartered to stay within a set = of bounds for dial-in terminal servers. Unfortunately the real wor= ld of Network Access Servers (NASes) hasn't stayed that small and simp= le=2C and continues to evolve at an amazing rate. This document shows= some of the current implementations on the market have already outstr= ipped the capabilities of the RADIUS protocol. A quite a few features= have been developed completely outside the protocol. These features = use the RADIUS protocol structure and format=2C but employ operations = and semantics well beyond the RFC documents. The limited set of dat= a types defined in [RFC2865] has lead to subsequent documents defining ne= w data types. Since new data types are typically defined implicitly as p= art of defining a new attribute=2C and because RADIUS client and server i= mplementations differ in their support of these additional specifications= =2C there is no definitive registry of RADIUS data types and data type su= pport has been inconsistent. To catalog commonly implemented data types = as well as to provide guidance for implementers as well as attribute desi= gners=2C "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice= on basic and complex data types. Unfortunately=2C these guidelines were= published 14 years after the RADIUS protocol was first documented in [= RFC2058]. Section 6.2 of the RADIUS specification [RFC2865] defines a me= chanism for Vendor-Specific extensions (Attribute 26)=2C and states that = use of Vendor-Specific extensions: should be encouraged instead of = allocation of global attribute types=2C for functions specific only to= one vendor's implementation of RADIUS=2C where no interoperability is= deemed useful. However=2C in practice usage of Vendor-Specific Attribut= es (VSAs) has been considerably broader than this. In particular=2C VSAs= have been used by Standards Development Organizations (SDOs) to define t= heir own extensions to the RADIUS protocol. This has caused a number of = problems. One issue concerns the data model for VSAs. Since it was no= t envisaged that multi-vendor VSA implementations would need to interop= erate=2C the RADIUS specification [RFC2865] does not define the data mode= l for VSAs=2C and allows multiple sub- attributes to be included within a= single Attribute of type 26. Since this enables VSAs to be defined whic= h would not be supportable by current implementations if placed within th= e standard RADIUS attribute space=2C this has caused problems in standard= izing widely deployed VSAs=2C as discussed in "RADIUS Design Guidelines" = BCP 158 [RFC6158]. Another issue is how implementations should handle un= known VSAs. [RFC2865] Section 5.26 states: Servers not equipped to = interpret the vendor-specific information sent by a client MUST ignore= it (although it may be reported). Clients which do not receive desire= d vendor-specific information SHOULD make an attempt to operate withou= t it=2C although they may do so (and report they are doing so) in a de= graded mode. However=2C since VSAs do not contain a "mandatory" bit=2C R= ADIUS clients and servers may not know whether it is safe to ignore unkno= wn VSAs. For example=2C in the case where VSAs pertain to security (e.g. = Filters)=2C it may not be safe to ignore them. As a result=2C "Common = Remote Authentication Dial In User Service (RADIUS) Implementation Issues= and Suggested Fixes" [RFC5080] Section 2.5 includes the following cautio= n: To avoid misinterpretation of service requests encoded within = VSAs=2C RADIUS servers SHOULD NOT send VSAs containing service reques= ts to RADIUS clients that are not known to understand them. For exampl= e=2C a RADIUS server should not send a VSA encoding a filter without k= nowledge that the RADIUS client supports the VSA. In addition to extendi= ng RADIUS by use of VSAs=2C SDOs have also defined new values of the Serv= ice-Type attribute in order to create new RADIUS commands. Since the RAD= IUS specification [RFC2865] defined Service-Type values as being allocate= d First Come=2C First Served (FCFS)=2C this permitted new RADIUS commands= to be allocated without IETF review. This oversight has since been fixe= d in "IANA Considerations for RADIUS" [RFC3575]. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_29df595e-fae8-42c0-b113-e7aabf443f59_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The document that has completed a 4-week IETF "Call for Comment"=2C and the= IAB has now initiated a two-week "last call" concluding on March 7=2C 2012= =2C after which the document will be considered for approval.

Since= some questions arose about the RADIUS case study=2C feedback is being requ= ested from RADEXT WG on that.

However=2C comments are also welcome = on any other portion of the document. =3B

Comments on the RADIU= S case study can be sent to this list.

Comments on other aspects ca= n be sent to iab@iab.org or filed in TRAC (see below).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =3B
Submitting Comments via TRAC  =3B
 =3B
1. To submit an issue in TRAC=2C you first need to login on the tools serve= r: http://tools= .ietf.org/wg/iab/  =3B
<=3Bhttp://tools.ietf.org/wg/iab/trac/login>=3B trac/login  =3B=
 =3B
2. If you don't already have a login ID=2C you can obtain one by  =3B navigating to this site: http:// <=3Bhttp://trac.tools.ietf.org/newlogin&= gt=3B  =3B
trac.tool= s.ietf.org/newlogin  =3B
 =3B
3. Once you have obtained an account=2C and have logged in=2C you can file =  =3B
an issue by navigating to the ticket entry form: http://  =3B
<=3Bhttp://trac.tools.ietf.org/wg/iab/trac/newticket>=3B=  =3B
trac.tools.ietf.org/wg/iab/trac/newticket  =3B
 =3B
4. When opening an issue:  =3B
 =3B
a. The Type: field should be set to "defect" for an issue with the  =3B=
current document text=2C or "enhancement" for a proposed addition of  = =3B
functionality (such as an additional requirement).  =3B
b. The Priority: field is set based on the severity of the Issue. For  = =3B
example=2C editorial issues are typically "minor" or "trivial".  =3B c. The Milestone: field should be set to milestone1 (useless=2C I know). &n= bsp=3B
 =3B
d. The Component: field should be set to the document you are filing  = =3B
the issue on.  =3B
e. The Version: field should be set to "1.0".  =3B
f. The Severity: field should be set to based on the status of the  =3B=
document (e.g. "In WG Last Call" for a document in IAB last call)  =3B<= br> g. The Keywords: and CC: fields can be left blank unless inspiration  = =3B
seizes you.  =3B
h. The Assign To: field is generally filled in with the email address  = =3B
of the editor.  =3B
 =3B
5. Typically it won't be necessary to enclose a file with the ticket=2C &nb= sp=3B
but if you need to=2C select "I have files to attach to this ticket". &nbs= p=3B
 =3B
6. If you want to preview your Issue=2C click on the "Preview" button. &nbs= p=3B
When you're ready to submit the issue=2C click on the "Create Ticket" butto= n. =3B
 =3B
 =3B
7. If you want to update an issue=2C go to the "View Tickets" page:  = =3B
http:// <=3Bhttp://trac.tools.ietf.org/wg/iab/trac/report/1&g= t=3B  =3B
trac.tools.ietf.org/wg/iab/trac/report/1  =3B
 =3B
Click on the ticket # you want to update=2C and then modify the ticket fiel= ds =3B
as required =3B


=
Date: Wed=2C 22 Feb 2012 13:42:56 +0100
Fr= om: dromasca@avaya.com
To: bernard_aboba@hotmail.com=3B radext@ietf.org<= br>Subject: Re: [radext] RADIUS case study

Bernard=2C

 =3B

This is an IAB document =96 what is its status? Was i= t approved by the IAB? Is it still work-in-progress and you / the IAB are s= oliciting comments?

 =3B

Dan

=  =3B

=  =3B

<= b>From: radext= -bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bern= ard Aboba
Sent: Tuesday=2C February 21=2C 2012 6:52 PM
To:<= /b> radext@ietf.org
Subject: [radext] RADIUS case study

 =3B

The IAB is working on a document entitled  =3B"Design Consider= ations for Protocol Extensions"=2C which includes a RADIUS case study i= n Appendix A.2.

The text of the RADIUS case s= tudy is included below. =3B =3B Comments welcome.

 =3B

A.2. =3B RADIUS Exte= nsions

 =3B

&= nbsp=3B =3B The RADIUS [RFC2865] protocol was designed to be extensible= via

 =3B =3B addition of Attributes t= o a Data Dictionary on the server=2C without

&= nbsp=3B =3B requiring code changes. =3B However=2C this extensibili= ty model assumed

 =3B =3B that Attribu= tes would conform to a limited set of data types and that

 =3B =3B vendor extensions would be limited to use by v= endors=2C in situations

 =3B =3B in wh= ich interoperability was not required. =3B Subsequent developments

<= p class=3D"ecxMsoNormal"> =3B =3B have stretched those assumptions.=

 =3B

 = =3B =3B From the beginning=2C uses of the RADIUS protocol extended beyo= nd the

 =3B =3B scope of the original = protocol definition (and beyond the scope of

&= nbsp=3B =3B the RADIUS Working Group charter). =3B In addition to r= ampant self-

 =3B =3B allocation withi= n the limited RADIUS standard attribute space=2C

 =3B =3B vendors defined their own RADIUS commands. =3B This= lead to the rapid

 =3B =3B proliferat= ion of vendor-specific protocol variants. =3B To this day=2C

 =3B =3B many common implementation practices ha= ve not been documented. =3B As

 =3B&nb= sp=3B noted in "Extended RADIUS Practices" [RFC2882] Section 1:

 =3B

 =3B =3B&nb= sp=3B =3B =3B The RADIUS Working Group was formed in 1995 to docume= nt the

 =3B =3B =3B =3B = =3B protocol of the same name=2C and was chartered to stay within a set

=

 =3B =3B =3B =3B =3B of bound= s for dial-in terminal servers. =3B Unfortunately the real

 =3B =3B =3B =3B =3B world of Network= Access Servers (NASes) hasn't stayed that small

 =3B =3B =3B =3B =3B and simple=2C and continues to = evolve at an amazing rate.

 =3B

 =3B =3B =3B =3B =3B This document s= hows some of the current implementations on the

 =3B =3B =3B =3B =3B market have already outstripped = the capabilities of the RADIUS

 =3B = =3B =3B =3B =3B protocol. =3B A quite a few features have b= een developed completely

 =3B  =3B&nbs= p=3B =3B =3Boutside the protocol. =3B These features use the RA= DIUS protocol

 =3B =3B =3B =3B=  =3B structure and format=2C but employ operations and semantics well

 =3B =3B =3B =3B =3B beyond= the RFC documents.

 =3B

 =3B =3B The limited set of data types defined in [RFC2= 865] has lead to

 =3B =3B subsequent d= ocuments defining new data types. =3B Since new data types

 =3B =3B are typically defined implicitly as part= of defining a new attribute=2C

 =3B = =3B and because RADIUS client and server implementations differ in their

 =3B =3B support of these additional spe= cifications=2C there is no definitive

 =3B=  =3B registry of RADIUS data types and data type support has been

 =3B =3B inconsistent. =3B To catalog c= ommonly implemented data types as well as

&nbs= p=3B =3B to provide guidance for implementers as well as attribute desi= gners=2C

 =3B =3B "RADIUS Design Guide= lines" [RFC6158] Section 2.1 includes advice on

 =3B =3B basic and complex data types. =3B Unfortunately=2C t= hese guidelines were

 =3B =3B publishe= d 14 years after the RADIUS protocol was first documented in

 =3B =3B [RFC2058].

&nb= sp=3B

 =3B =3B Section 6.2 of the RADI= US specification [RFC2865] defines a mechanism

 =3B =3B for Vendor-Specific extensions (Attribute 26)=2C and stat= es that use of

 =3B =3B Vendor-Specifi= c extensions:

 =3B

 =3B =3B =3B =3B =3B should be encouraged instead= of allocation of global attribute

 =3B&nb= sp=3B =3B =3B =3B types=2C for functions specific only to one v= endor's implementation

 =3B =3B = =3B =3B =3B of RADIUS=2C where no interoperability is deemed useful= .

 =3B

 = =3B =3B However=2C in practice usage of Vendor-Specific Attributes (VSA= s) has

 =3B =3B been considerably broa= der than this. =3B In particular=2C VSAs have been

 =3B =3B used by Standards Development Organizations (SDOs= ) to define their

 =3B =3B own extensi= ons to the RADIUS protocol. =3B This has caused a number of

 =3B =3B problems.

&= nbsp=3B

 =3B =3B One issue concerns th= e data model for VSAs. =3B Since it was not

 =3B =3B envisaged that multi-vendor VSA implementations would ne= ed to

 =3B =3B interoperate=2C the RAD= IUS specification [RFC2865] does not define the

 =3B =3B data model for VSAs=2C and allows multiple sub- attribut= es to be

 =3B =3B included within a si= ngle Attribute of type 26. =3B Since this enables

 =3B =3B VSAs to be defined which would not be supportable = by current

 =3B =3B implementations if= placed within the standard RADIUS attribute space=2C

 =3B =3B this has caused problems in standardizing widely d= eployed VSAs=2C as

 =3B =3B discussed = in "RADIUS Design Guidelines" BCP 158 [RFC6158].

 =3B

 =3B =3B Another issue is = how implementations should handle unknown VSAs.

 =3B =3B [RFC2865] Section 5.26 states:

 =3B

 =3B =3B =3B =3B&= nbsp=3B Servers not equipped to interpret the vendor-specific information

 =3B =3B =3B =3B =3B sent b= y a client MUST ignore it (although it may be reported).

 =3B =3B =3B =3B =3B Clients which do not re= ceive desired vendor-specific information

&nbs= p=3B =3B =3B =3B =3B SHOULD make an attempt to operate with= out it=2C although they may do

 =3B = =3B =3B =3B =3B so (and report they are doing so) in a degraded= mode.

 =3B

&= nbsp=3B =3B However=2C since VSAs do not contain a "mandatory" bit=2C R= ADIUS clients

 =3B =3B and servers may= not know whether it is safe to ignore unknown VSAs.

 =3B =3B For example=2C in the case where VSAs pertain to se= curity (e.g.

 =3B =3B Filters)=2C it m= ay not be safe to ignore them. =3B As a result=2C "Common

 =3B =3B Remote Authentication Dial In User Servi= ce (RADIUS) Implementation

 =3B =3B Is= sues and Suggested Fixes" [RFC5080] Section 2.5 includes the

 =3B =3B following caution:

 =3B

 =3B =3B =3B =3B=  =3B To avoid misinterpretation of service requests encoded within

<= p class=3D"ecxMsoNormal"> =3B =3B =3B =3B =3B VSAs=2C R= ADIUS servers SHOULD NOT send VSAs containing service

 =3B =3B =3B =3B =3B requests to RADIUS clients= that are not known to understand them.

 = =3B =3B =3B =3B =3B For example=2C a RADIUS server should n= ot send a VSA encoding a

 =3B =3B = =3B =3B =3B filter without knowledge that the RADIUS client support= s the VSA.

 =3B

 =3B =3B In addition to extending RADIUS by use of VSAs=2C SDOs = have also

 =3B =3B defined new values = of the Service-Type attribute in order to create

 =3B =3B new RADIUS commands. =3B Since the RADIUS specifica= tion [RFC2865]

 =3B =3B defined Servic= e-Type values as being allocated First Come=2C First

 =3B =3B Served (FCFS)=2C this permitted new RADIUS commands= to be allocated

 =3B =3B without IETF= review. =3B This oversight has since been fixed in "IANA

 =3B =3B Considerations for RADIUS" [RFC3575].


_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_29df595e-fae8-42c0-b113-e7aabf443f59_-- --===============3341063384722141505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3341063384722141505==-- From radext-bounces@ietf.org Thu Feb 23 03:16:35 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024621F86A8; Thu, 23 Feb 2012 03:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329995795; bh=sitZIoV1Ew3CGOCxFOHfwW3QENTusq3DtfcWK7AkNvY=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=tlpaV7/K+Jy5SpCU8H+V6THwqyLKhhxL5HgSoVnckJ3sEoDsu/7VkuNaHEJ54Vg20 QP4m3cwcjqw1xQ6H3REE3gsvke450pJfsB76ePtFRYWZaikqsbIVsqfI3TTG7zM1kc BYeScdzO4nPcx6jT6l6AQM174HDPOfu6KDlBK1eM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C035421F8690 for ; Thu, 23 Feb 2012 03:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRuCj8lVMyxc for ; Thu, 23 Feb 2012 03:16:24 -0800 (PST) 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 706AC21F8682 for ; Thu, 23 Feb 2012 03:16:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMGAMMfRk+HCzI1/2dsb2JhbABEglGeV4QvhBkBiGuBB4FzAQEBAQMBAQEPCgEQAz4bAgEIDQQDAQEBCwYFAQEFBAEGAQYBJh8JCAEBBAESCBqHaKJhlCGIf2ODEQIIBwIBBQIBAQUEAwIEAk8RhF8ZDR0FOwwDAwgOBA8DCAGCPmMEmzeFGIdXgVICAwMB X-IronPort-AV: E=Sophos;i="4.73,469,1325480400"; d="scan'208,217";a="332048363" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2012 06:15:52 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Feb 2012 06:01:12 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Feb 2012 12:15:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADIUS case study Thread-Index: Aczx56IKpzPUFCCsQjeCS/Pa4jLz3QANKt2w References: , From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5405224338305620256==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============5405224338305620256== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF21C.80408636" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF21C.80408636 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. I believe that the RADEXT WG folks should review this document, maybe the chairs can designate one or two reviewers.=20 =20 Regards, =20 Dan =20 =20 =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, February 23, 2012 6:57 AM To: Romascanu, Dan (Dan); radext@ietf.org Subject: RE: [radext] RADIUS case study =20 The document that has completed a 4-week IETF "Call for Comment", and the IAB has now initiated a two-week "last call" concluding on March 7, 2012, after which the document will be considered for approval.=20 Since some questions arose about the RADIUS case study, feedback is being requested from RADEXT WG on that.=20 However, comments are also welcome on any other portion of the document. Comments on the RADIUS case study can be sent to this list.=20 Comments on other aspects can be sent to iab@iab.org or filed in TRAC (see below).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 Submitting Comments via TRAC =20 =20 1. To submit an issue in TRAC, you first need to login on the tools server: http://tools.ietf.org/wg/iab/ =20 trac/login =20 =20 2. If you don't already have a login ID, you can obtain one by =20 navigating to this site: http:// =20 trac.tools.ietf.org/newlogin =20 =20 3. Once you have obtained an account, and have logged in, you can file =20 an issue by navigating to the ticket entry form: http:// =20 =20 trac.tools.ietf.org/wg/iab/trac/newticket =20 =20 4. When opening an issue: =20 =20 a. The Type: field should be set to "defect" for an issue with the =20 current document text, or "enhancement" for a proposed addition of =20 functionality (such as an additional requirement). =20 b. The Priority: field is set based on the severity of the Issue. For =20 example, editorial issues are typically "minor" or "trivial". =20 c. The Milestone: field should be set to milestone1 (useless, I know). =20 =20 d. The Component: field should be set to the document you are filing =20 the issue on. =20 e. The Version: field should be set to "1.0". =20 f. The Severity: field should be set to based on the status of the =20 document (e.g. "In WG Last Call" for a document in IAB last call) =20 g. The Keywords: and CC: fields can be left blank unless inspiration =20 seizes you. =20 h. The Assign To: field is generally filled in with the email address =20 of the editor. =20 =20 5. Typically it won't be necessary to enclose a file with the ticket, =20 but if you need to, select "I have files to attach to this ticket". =20 =20 6. If you want to preview your Issue, click on the "Preview" button. =20 When you're ready to submit the issue, click on the "Create Ticket" button.=20 =20 =20 7. If you want to update an issue, go to the "View Tickets" page: =20 http:// =20 trac.tools.ietf.org/wg/iab/trac/report/1 =20 =20 Click on the ticket # you want to update, and then modify the ticket fields=20 as required =20 =20 ________________________________ Date: Wed, 22 Feb 2012 13:42:56 +0100 From: dromasca@avaya.com To: bernard_aboba@hotmail.com; radext@ietf.org Subject: Re: [radext] RADIUS case study Bernard, =20 This is an IAB document - what is its status? Was it approved by the IAB? Is it still work-in-progress and you / the IAB are soliciting comments?=20 =20 Dan =20 =20 From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, February 21, 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study =20 The IAB is working on a document entitled "Design Considerations for Protocol Extensions" , which includes a RADIUS case study in Appendix A.2.=20 The text of the RADIUS case study is included below. Comments welcome. =20 A.2. RADIUS Extensions =20 The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. =20 From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: =20 The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. =20 This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. =20 The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. =20 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: =20 should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. =20 However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. =20 One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. =20 Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: =20 Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. =20 However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: =20 To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. =20 In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCF21C.80408636 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the clarification. I believe that the RADEXT WG folks = should review this document, maybe the chairs can designate one or two = reviewers.

 

Regards,

 

Dan

 

 

 

From:= = Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: = Thursday, February 23, 2012 6:57 AM
To: Romascanu, Dan (Dan); = radext@ietf.org
Subject: RE: [radext] RADIUS case = study

 

The = document that has completed a 4-week IETF "Call for Comment", = and the IAB has now initiated a two-week "last call" = concluding on March 7, 2012, after which the document will be considered = for approval.

Since some questions arose about the RADIUS case = study, feedback is being requested from RADEXT WG on that. =

However, comments are also welcome on any other portion of the = document. 

Comments on the RADIUS case study can be sent to = this list.

Comments on other aspects can be sent to iab@iab.org = or filed in TRAC (see below).

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D  
Submitting Comments via TRAC =  
 
1. To submit an issue in TRAC, you first need to = login on the tools server: http://tools.ietf.org/wg/iab/  
<http://tools.ietf.org/wg/iab/trac/login> = trac/login  
 
2. If you don't already have a login ID, = you can obtain one by  
navigating to this site: http:// <http://trac.tools.ietf.org/newlogin> =  
trac.tools.ietf.org/newlogin =  
 
3. Once you have obtained an account, and have = logged in, you can file  
an issue by navigating to the ticket = entry form: http://  
<http://trac.tools.ietf.org/wg/iab/trac/newticket>= ;  
trac.tools.ietf.org/wg/iab/trac/newticket =  
 
4. When opening an issue:  
 
a. The = Type: field should be set to "defect" for an issue with the =  
current document text, or "enhancement" for a = proposed addition of  
functionality (such as an additional = requirement).  
b. The Priority: field is set based on the = severity of the Issue. For  
example, editorial issues are = typically "minor" or "trivial".  
c. The = Milestone: field should be set to milestone1 (useless, I know). =  
 
d. The Component: field should be set to the = document you are filing  
the issue on.  
e. The = Version: field should be set to "1.0".  
f. The = Severity: field should be set to based on the status of the =  
document (e.g. "In WG Last Call" for a document in = IAB last call)  
g. The Keywords: and CC: fields can be left = blank unless inspiration  
seizes you.  
h. The Assign = To: field is generally filled in with the email address  
of the = editor.  
 
5. Typically it won't be necessary to = enclose a file with the ticket,  
but if you need to, select = "I have files to attach to this ticket". =  
 
6. If you want to preview your Issue, click on the = "Preview" button.  
When you're ready to submit the = issue, click on the "Create Ticket" = button. 
 
 
7. If you want to update an issue, = go to the "View Tickets" page:  
http:// <http://trac.tools.ietf.org/wg/iab/trac/report/1>=  
trac.tools.ietf.org/wg/iab/trac/report/1 =  
 
Click on the ticket # you want to update, and then = modify the ticket fields 
as required  =

 <= /o:p>

Date: Wed, = 22 Feb 2012 13:42:56 +0100
From: dromasca@avaya.com
To: = bernard_aboba@hotmail.com; radext@ietf.org
Subject: Re: [radext] = RADIUS case study

Bernard,<= /span>

 <= /span>

This is an IAB document – what is its status? Was it approved by = the IAB? Is it still work-in-progress and you / the IAB are soliciting = comments? <= /span>

 <= /span>

Dan<= /span>

 <= /span>

 <= /span>

From:= = radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 = PM
To: radext@ietf.org
Subject: [radext] RADIUS case = study

 <= /o:p>

The IAB is = working on a document entitled  "Design Considerations for Protocol = Extensions", which includes a RADIUS case study in Appendix = A.2.

The text of = the RADIUS case study is included below.   Comments welcome. =

 <= /o:p>

A.2.  = RADIUS Extensions

 <= /o:p>

  = The RADIUS [RFC2865] protocol was designed to be extensible = via

  = addition of Attributes to a Data Dictionary on the server, = without

  = requiring code changes.  However, this extensibility model = assumed

  = that Attributes would conform to a limited set of data types and = that

  = vendor extensions would be limited to use by vendors, in = situations

  = in which interoperability was not required.  Subsequent = developments

  = have stretched those assumptions.

 <= /o:p>

  = From the beginning, uses of the RADIUS protocol extended beyond = the

  = scope of the original protocol definition (and beyond the scope = of

  = the RADIUS Working Group charter).  In addition to rampant = self-

  = allocation within the limited RADIUS standard attribute = space,

  = vendors defined their own RADIUS commands.  This lead to the = rapid

  = proliferation of vendor-specific protocol variants.  To this = day,

  = many common implementation practices have not been documented.  = As

  = noted in "Extended RADIUS Practices" [RFC2882] Section = 1:

 <= /o:p>

  =     The RADIUS Working Group was formed in 1995 to = document the

  =     protocol of the same name, and was chartered to stay = within a set

  =     of bounds for dial-in terminal servers.  = Unfortunately the real

  =     world of Network Access Servers (NASes) hasn't stayed = that small

  =     and simple, and continues to evolve at an amazing = rate.

 <= /o:p>

  =     This document shows some of the current = implementations on the

  =     market have already outstripped the capabilities of = the RADIUS

  =     protocol.  A quite a few features have been = developed completely

  =     outside the protocol.  These features use = the RADIUS protocol

  =     structure and format, but employ operations and = semantics well

  =     beyond the RFC documents.

 <= /o:p>

  = The limited set of data types defined in [RFC2865] has lead = to

  = subsequent documents defining new data types.  Since new data = types

  = are typically defined implicitly as part of defining a new = attribute,

  = and because RADIUS client and server implementations differ in = their

  = support of these additional specifications, there is no = definitive

  = registry of RADIUS data types and data type support has = been

  = inconsistent.  To catalog commonly implemented data types as well = as

  = to provide guidance for implementers as well as attribute = designers,

  = "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes = advice on

  = basic and complex data types.  Unfortunately, these guidelines = were

  = published 14 years after the RADIUS protocol was first documented = in

  = [RFC2058].

 <= /o:p>

  = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

  = for Vendor-Specific extensions (Attribute 26), and states that use = of

  = Vendor-Specific extensions:

 <= /o:p>

  =     should be encouraged instead of allocation of global = attribute

  =     types, for functions specific only to one vendor's = implementation

  =     of RADIUS, where no interoperability is deemed = useful.

 <= /o:p>

  = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

  = been considerably broader than this.  In particular, VSAs have = been

  = used by Standards Development Organizations (SDOs) to define = their

  = own extensions to the RADIUS protocol.  This has caused a number = of

  = problems.

 <= /o:p>

  = One issue concerns the data model for VSAs.  Since it was = not

  = envisaged that multi-vendor VSA implementations would need = to

  = interoperate, the RADIUS specification [RFC2865] does not define = the

  = data model for VSAs, and allows multiple sub- attributes to = be

  = included within a single Attribute of type 26.  Since this = enables

  = VSAs to be defined which would not be supportable by = current

  = implementations if placed within the standard RADIUS attribute = space,

  = this has caused problems in standardizing widely deployed VSAs, = as

  = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 <= /o:p>

  = Another issue is how implementations should handle unknown = VSAs.

  = [RFC2865] Section 5.26 states:

 <= /o:p>

  =     Servers not equipped to interpret the vendor-specific = information

  =     sent by a client MUST ignore it (although it may be = reported).

  =     Clients which do not receive desired vendor-specific = information

  =     SHOULD make an attempt to operate without it, = although they may do

  =     so (and report they are doing so) in a degraded = mode.

 <= /o:p>

  = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

  = and servers may not know whether it is safe to ignore unknown = VSAs.

  = For example, in the case where VSAs pertain to security = (e.g.

  = Filters), it may not be safe to ignore them.  As a result, = "Common

  = Remote Authentication Dial In User Service (RADIUS) = Implementation

  = Issues and Suggested Fixes" [RFC5080] Section 2.5 includes = the

  = following caution:

 <= /o:p>

  =     To avoid misinterpretation of service requests = encoded within

  =     VSAs, RADIUS servers SHOULD NOT send VSAs containing = service

  =     requests to RADIUS clients that are not known to = understand them.

  =     For example, a RADIUS server should not send a VSA = encoding a

  =     filter without knowledge that the RADIUS client = supports the VSA.

 <= /o:p>

  = In addition to extending RADIUS by use of VSAs, SDOs have = also

  = defined new values of the Service-Type attribute in order to = create

  = new RADIUS commands.  Since the RADIUS specification = [RFC2865]

  = defined Service-Type values as being allocated First Come, = First

  = Served (FCFS), this permitted new RADIUS commands to be = allocated

  = without IETF review.  This oversight has since been fixed in = "IANA

  = Considerations for RADIUS" = [RFC3575].


________= _______________________________________ radext mailing list = radext@ietf.org = https://www.ietf.org/mailman/listinfo/radext

<= /div>
------_=_NextPart_001_01CCF21C.80408636-- --===============5405224338305620256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============5405224338305620256==-- From dromasca@avaya.com Thu Feb 23 03:16:33 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C035421F8690 for ; Thu, 23 Feb 2012 03:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRuCj8lVMyxc for ; Thu, 23 Feb 2012 03:16:24 -0800 (PST) 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 706AC21F8682 for ; Thu, 23 Feb 2012 03:16:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMGAMMfRk+HCzI1/2dsb2JhbABEglGeV4QvhBkBiGuBB4FzAQEBAQMBAQEPCgEQAz4bAgEIDQQDAQEBCwYFAQEFBAEGAQYBJh8JCAEBBAESCBqHaKJhlCGIf2ODEQIIBwIBBQIBAQUEAwIEAk8RhF8ZDR0FOwwDAwgOBA8DCAGCPmMEmzeFGIdXgVICAwMB X-IronPort-AV: E=Sophos;i="4.73,469,1325480400"; d="scan'208,217";a="332048363" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2012 06:15:52 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Feb 2012 06:01:12 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF21C.80408636" Date: Thu, 23 Feb 2012 12:15:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADIUS case study Thread-Index: Aczx56IKpzPUFCCsQjeCS/Pa4jLz3QANKt2w References: , From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Subject: Re: [radext] RADIUS case study X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 11:16:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF21C.80408636 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. I believe that the RADEXT WG folks should review this document, maybe the chairs can designate one or two reviewers.=20 =20 Regards, =20 Dan =20 =20 =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, February 23, 2012 6:57 AM To: Romascanu, Dan (Dan); radext@ietf.org Subject: RE: [radext] RADIUS case study =20 The document that has completed a 4-week IETF "Call for Comment", and the IAB has now initiated a two-week "last call" concluding on March 7, 2012, after which the document will be considered for approval.=20 Since some questions arose about the RADIUS case study, feedback is being requested from RADEXT WG on that.=20 However, comments are also welcome on any other portion of the document. Comments on the RADIUS case study can be sent to this list.=20 Comments on other aspects can be sent to iab@iab.org or filed in TRAC (see below).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 Submitting Comments via TRAC =20 =20 1. To submit an issue in TRAC, you first need to login on the tools server: http://tools.ietf.org/wg/iab/ =20 trac/login =20 =20 2. If you don't already have a login ID, you can obtain one by =20 navigating to this site: http:// =20 trac.tools.ietf.org/newlogin =20 =20 3. Once you have obtained an account, and have logged in, you can file =20 an issue by navigating to the ticket entry form: http:// =20 =20 trac.tools.ietf.org/wg/iab/trac/newticket =20 =20 4. When opening an issue: =20 =20 a. The Type: field should be set to "defect" for an issue with the =20 current document text, or "enhancement" for a proposed addition of =20 functionality (such as an additional requirement). =20 b. The Priority: field is set based on the severity of the Issue. For =20 example, editorial issues are typically "minor" or "trivial". =20 c. The Milestone: field should be set to milestone1 (useless, I know). =20 =20 d. The Component: field should be set to the document you are filing =20 the issue on. =20 e. The Version: field should be set to "1.0". =20 f. The Severity: field should be set to based on the status of the =20 document (e.g. "In WG Last Call" for a document in IAB last call) =20 g. The Keywords: and CC: fields can be left blank unless inspiration =20 seizes you. =20 h. The Assign To: field is generally filled in with the email address =20 of the editor. =20 =20 5. Typically it won't be necessary to enclose a file with the ticket, =20 but if you need to, select "I have files to attach to this ticket". =20 =20 6. If you want to preview your Issue, click on the "Preview" button. =20 When you're ready to submit the issue, click on the "Create Ticket" button.=20 =20 =20 7. If you want to update an issue, go to the "View Tickets" page: =20 http:// =20 trac.tools.ietf.org/wg/iab/trac/report/1 =20 =20 Click on the ticket # you want to update, and then modify the ticket fields=20 as required =20 =20 ________________________________ Date: Wed, 22 Feb 2012 13:42:56 +0100 From: dromasca@avaya.com To: bernard_aboba@hotmail.com; radext@ietf.org Subject: Re: [radext] RADIUS case study Bernard, =20 This is an IAB document - what is its status? Was it approved by the IAB? Is it still work-in-progress and you / the IAB are soliciting comments?=20 =20 Dan =20 =20 From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, February 21, 2012 6:52 PM To: radext@ietf.org Subject: [radext] RADIUS case study =20 The IAB is working on a document entitled "Design Considerations for Protocol Extensions" , which includes a RADIUS case study in Appendix A.2.=20 The text of the RADIUS case study is included below. Comments welcome. =20 A.2. RADIUS Extensions =20 The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors, in situations in which interoperability was not required. Subsequent developments have stretched those assumptions. =20 From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self- allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This lead to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. As noted in "Extended RADIUS Practices" [RFC2882] Section 1: =20 The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate. =20 This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents. =20 The limited set of data types defined in [RFC2865] has lead to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute, and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers as well as attribute designers, "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on basic and complex data types. Unfortunately, these guidelines were published 14 years after the RADIUS protocol was first documented in [RFC2058]. =20 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use of Vendor-Specific extensions: =20 should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. =20 However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems. =20 One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs, and allows multiple sub- attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158]. =20 Another issue is how implementations should handle unknown VSAs. [RFC2865] Section 5.26 states: =20 Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. =20 However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g. Filters), it may not be safe to ignore them. As a result, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the following caution: =20 To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA. =20 In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575]. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCF21C.80408636 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the clarification. I believe that the RADEXT WG folks = should review this document, maybe the chairs can designate one or two = reviewers.

 

Regards,

 

Dan

 

 

 

From:= = Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: = Thursday, February 23, 2012 6:57 AM
To: Romascanu, Dan (Dan); = radext@ietf.org
Subject: RE: [radext] RADIUS case = study

 

The = document that has completed a 4-week IETF "Call for Comment", = and the IAB has now initiated a two-week "last call" = concluding on March 7, 2012, after which the document will be considered = for approval.

Since some questions arose about the RADIUS case = study, feedback is being requested from RADEXT WG on that. =

However, comments are also welcome on any other portion of the = document. 

Comments on the RADIUS case study can be sent to = this list.

Comments on other aspects can be sent to iab@iab.org = or filed in TRAC (see below).

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D  
Submitting Comments via TRAC =  
 
1. To submit an issue in TRAC, you first need to = login on the tools server: http://tools.ietf.org/wg/iab/  
<http://tools.ietf.org/wg/iab/trac/login> = trac/login  
 
2. If you don't already have a login ID, = you can obtain one by  
navigating to this site: http:// <http://trac.tools.ietf.org/newlogin> =  
trac.tools.ietf.org/newlogin =  
 
3. Once you have obtained an account, and have = logged in, you can file  
an issue by navigating to the ticket = entry form: http://  
<http://trac.tools.ietf.org/wg/iab/trac/newticket>= ;  
trac.tools.ietf.org/wg/iab/trac/newticket =  
 
4. When opening an issue:  
 
a. The = Type: field should be set to "defect" for an issue with the =  
current document text, or "enhancement" for a = proposed addition of  
functionality (such as an additional = requirement).  
b. The Priority: field is set based on the = severity of the Issue. For  
example, editorial issues are = typically "minor" or "trivial".  
c. The = Milestone: field should be set to milestone1 (useless, I know). =  
 
d. The Component: field should be set to the = document you are filing  
the issue on.  
e. The = Version: field should be set to "1.0".  
f. The = Severity: field should be set to based on the status of the =  
document (e.g. "In WG Last Call" for a document in = IAB last call)  
g. The Keywords: and CC: fields can be left = blank unless inspiration  
seizes you.  
h. The Assign = To: field is generally filled in with the email address  
of the = editor.  
 
5. Typically it won't be necessary to = enclose a file with the ticket,  
but if you need to, select = "I have files to attach to this ticket". =  
 
6. If you want to preview your Issue, click on the = "Preview" button.  
When you're ready to submit the = issue, click on the "Create Ticket" = button. 
 
 
7. If you want to update an issue, = go to the "View Tickets" page:  
http:// <http://trac.tools.ietf.org/wg/iab/trac/report/1>=  
trac.tools.ietf.org/wg/iab/trac/report/1 =  
 
Click on the ticket # you want to update, and then = modify the ticket fields 
as required  =

 <= /o:p>

Date: Wed, = 22 Feb 2012 13:42:56 +0100
From: dromasca@avaya.com
To: = bernard_aboba@hotmail.com; radext@ietf.org
Subject: Re: [radext] = RADIUS case study

Bernard,<= /span>

 <= /span>

This is an IAB document – what is its status? Was it approved by = the IAB? Is it still work-in-progress and you / the IAB are soliciting = comments? <= /span>

 <= /span>

Dan<= /span>

 <= /span>

 <= /span>

From:= = radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 = PM
To: radext@ietf.org
Subject: [radext] RADIUS case = study

 <= /o:p>

The IAB is = working on a document entitled  "Design Considerations for Protocol = Extensions", which includes a RADIUS case study in Appendix = A.2.

The text of = the RADIUS case study is included below.   Comments welcome. =

 <= /o:p>

A.2.  = RADIUS Extensions

 <= /o:p>

  = The RADIUS [RFC2865] protocol was designed to be extensible = via

  = addition of Attributes to a Data Dictionary on the server, = without

  = requiring code changes.  However, this extensibility model = assumed

  = that Attributes would conform to a limited set of data types and = that

  = vendor extensions would be limited to use by vendors, in = situations

  = in which interoperability was not required.  Subsequent = developments

  = have stretched those assumptions.

 <= /o:p>

  = From the beginning, uses of the RADIUS protocol extended beyond = the

  = scope of the original protocol definition (and beyond the scope = of

  = the RADIUS Working Group charter).  In addition to rampant = self-

  = allocation within the limited RADIUS standard attribute = space,

  = vendors defined their own RADIUS commands.  This lead to the = rapid

  = proliferation of vendor-specific protocol variants.  To this = day,

  = many common implementation practices have not been documented.  = As

  = noted in "Extended RADIUS Practices" [RFC2882] Section = 1:

 <= /o:p>

  =     The RADIUS Working Group was formed in 1995 to = document the

  =     protocol of the same name, and was chartered to stay = within a set

  =     of bounds for dial-in terminal servers.  = Unfortunately the real

  =     world of Network Access Servers (NASes) hasn't stayed = that small

  =     and simple, and continues to evolve at an amazing = rate.

 <= /o:p>

  =     This document shows some of the current = implementations on the

  =     market have already outstripped the capabilities of = the RADIUS

  =     protocol.  A quite a few features have been = developed completely

  =     outside the protocol.  These features use = the RADIUS protocol

  =     structure and format, but employ operations and = semantics well

  =     beyond the RFC documents.

 <= /o:p>

  = The limited set of data types defined in [RFC2865] has lead = to

  = subsequent documents defining new data types.  Since new data = types

  = are typically defined implicitly as part of defining a new = attribute,

  = and because RADIUS client and server implementations differ in = their

  = support of these additional specifications, there is no = definitive

  = registry of RADIUS data types and data type support has = been

  = inconsistent.  To catalog commonly implemented data types as well = as

  = to provide guidance for implementers as well as attribute = designers,

  = "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes = advice on

  = basic and complex data types.  Unfortunately, these guidelines = were

  = published 14 years after the RADIUS protocol was first documented = in

  = [RFC2058].

 <= /o:p>

  = Section 6.2 of the RADIUS specification [RFC2865] defines a = mechanism

  = for Vendor-Specific extensions (Attribute 26), and states that use = of

  = Vendor-Specific extensions:

 <= /o:p>

  =     should be encouraged instead of allocation of global = attribute

  =     types, for functions specific only to one vendor's = implementation

  =     of RADIUS, where no interoperability is deemed = useful.

 <= /o:p>

  = However, in practice usage of Vendor-Specific Attributes (VSAs) = has

  = been considerably broader than this.  In particular, VSAs have = been

  = used by Standards Development Organizations (SDOs) to define = their

  = own extensions to the RADIUS protocol.  This has caused a number = of

  = problems.

 <= /o:p>

  = One issue concerns the data model for VSAs.  Since it was = not

  = envisaged that multi-vendor VSA implementations would need = to

  = interoperate, the RADIUS specification [RFC2865] does not define = the

  = data model for VSAs, and allows multiple sub- attributes to = be

  = included within a single Attribute of type 26.  Since this = enables

  = VSAs to be defined which would not be supportable by = current

  = implementations if placed within the standard RADIUS attribute = space,

  = this has caused problems in standardizing widely deployed VSAs, = as

  = discussed in "RADIUS Design Guidelines" BCP 158 = [RFC6158].

 <= /o:p>

  = Another issue is how implementations should handle unknown = VSAs.

  = [RFC2865] Section 5.26 states:

 <= /o:p>

  =     Servers not equipped to interpret the vendor-specific = information

  =     sent by a client MUST ignore it (although it may be = reported).

  =     Clients which do not receive desired vendor-specific = information

  =     SHOULD make an attempt to operate without it, = although they may do

  =     so (and report they are doing so) in a degraded = mode.

 <= /o:p>

  = However, since VSAs do not contain a "mandatory" bit, RADIUS = clients

  = and servers may not know whether it is safe to ignore unknown = VSAs.

  = For example, in the case where VSAs pertain to security = (e.g.

  = Filters), it may not be safe to ignore them.  As a result, = "Common

  = Remote Authentication Dial In User Service (RADIUS) = Implementation

  = Issues and Suggested Fixes" [RFC5080] Section 2.5 includes = the

  = following caution:

 <= /o:p>

  =     To avoid misinterpretation of service requests = encoded within

  =     VSAs, RADIUS servers SHOULD NOT send VSAs containing = service

  =     requests to RADIUS clients that are not known to = understand them.

  =     For example, a RADIUS server should not send a VSA = encoding a

  =     filter without knowledge that the RADIUS client = supports the VSA.

 <= /o:p>

  = In addition to extending RADIUS by use of VSAs, SDOs have = also

  = defined new values of the Service-Type attribute in order to = create

  = new RADIUS commands.  Since the RADIUS specification = [RFC2865]

  = defined Service-Type values as being allocated First Come, = First

  = Served (FCFS), this permitted new RADIUS commands to be = allocated

  = without IETF review.  This oversight has since been fixed in = "IANA

  = Considerations for RADIUS" = [RFC3575].


________= _______________________________________ radext mailing list = radext@ietf.org = https://www.ietf.org/mailman/listinfo/radext

<= /div>
------_=_NextPart_001_01CCF21C.80408636-- From leaf.y.yeh@huawei.com Thu Feb 23 08:12:26 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18A21F85A0 for ; Thu, 23 Feb 2012 08:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.693 X-Spam-Level: X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yssfF2cR2P2u for ; Thu, 23 Feb 2012 08:12:22 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6121F87F8 for ; Thu, 23 Feb 2012 08:12:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU005L1SYPQ5@szxga05-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 00:11:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU00G1VSYP7K@szxga05-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 00:11:13 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ06576; Fri, 24 Feb 2012 00:10:59 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 00:10:56 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 00:10:55 +0800 Date: Thu, 23 Feb 2012 16:10:54 +0000 From: Leaf yeh X-Originating-IP: [172.24.1.70] To: "bernard_aboba@hotmail.com" , "aland@deployingradius.com" , "dnelson@elbrys.com" , "stefan.winter@restena.lu" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" Message-id: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/Z/iXVg2ctST89mRVILKJw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "radext@ietf.org" , "dromasca@avaya.com" Subject: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:12:26 -0000 --Boundary_(ID_/Z/iXVg2ctST89mRVILKJw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Dear Radius-Doctors: I presented the following 6+ attribute design at Radext session of IETF82-T= aipei, which can be found in http://www.ietf.org/proceedings/82/slides/rade= xt-2.pptx (RADIUS Accounting Extensions on Traffic Statistics) against dra= ft-yeh-radext-ext-traffic-statistics. Here are their Pros & Cons for our further discussion: Attribute Design =96 1a @ traditional type space in flat mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, based on RFC2865 if the traditional type space still open for= this case, draft-ietf-radext-radius-extensions sounds intend to deprecate = the traditional standard type space. Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets) Attribute Design =96 1b @ traditional type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Traffic-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, data type sounds the same as the one defined in RFC2868; the = design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) & DS= CP(3bits), and even change with (Input/Output) and (Octets/Packets) because= it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type o= f attribute is enough to work. Cons: Sounds complex data type Attribute Design =96 2a @ extended type space in flat mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-r= adext-radius-extensions-04, if we'd need to use the extended type space at = this time Cons: 8 new type @ 241.x Attribute Design =96 2b @ extended type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Traffic-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: Same as Design - 1b if we'd need to use the extended type space at th= is time Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-exte= nsions-04 Attribute Design =96 3 @ extended type space in nesting-TLV mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Traffic-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic-Type(TLV) | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: used the new basic data type of TLV defined in draft-ietf-radext-radi= us-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 = sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above orde= r, and even some of them are not necessary to appear in the container attri= bute. Cons: looks a little complicated, should use the extended-type as per draft= -ietf-radext-radius-extensions, Attribute Design =964a @ traditional type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Traffic-Type | Input-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets | Output-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets | Input-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets |Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+ Pros: explicit and simplified from the design-3 because each field has the = fixed length. Cons: multi-field design, complex data type (not recommended by RFC6158) Pls. feel free to comments on the above designs from your professional pers= pective, then I will update my draft based on your comments. I supposed each design can work for 'Traffic Statistics', maybe Design 1a, = 1b, 2a, 3 could be more acceptable. I recommend design 1b, because it looks much simple, need much less attribu= ts than design 1a, and we can solve the problem on reporting 'Traffic Stati= stics' within the standard type space. If the standard type space is deprecated against this case, then design-2a = might be our choice, because we don't have the space limitation issue in th= e extended type space; or we could try the new basic data type of nesting-TLV, then 'Acct-Traffic = Statistics' could be the 1st attribute in the extended type space with TLV = as its basic data type. But my concern will be that it still needs 3 or more years for the upgrade = of the deployed radius system (NASs + servers) to support the solution of t= he extended type space and its newly-defined attributes. Best Regards, Leaf --Boundary_(ID_/Z/iXVg2ctST89mRVILKJw) Content-id: <148F80E109A84A42B48476AD9B07B135@huawei.com> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Dear Radius-Doctors:

I presented the following 6+ attribute design at Radext session of IETF= 82-Taipei, which can be found in http://www.ietf.org/proceedings/82/slides/radext-2.pptx  (RADIUS A= ccounting Extensions on Traffic Statistics) against draft-yeh-radext-ext-tr= affic-statistics.

 

Here are their Pros & Cons for our further discussion:

Attribute Design =96 1a @ traditional type space in flat mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | =              Va= lue            |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;  Value (cont.)        |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+

Pros: simple, based on RFC2865 if the traditional type space still open for= this case, draft-ietf-radext-radius-extensions sounds intend to deprecate = the traditional standard type space.
Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets)


Attribute Design =96 1b @ traditional type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Traff= ic-Type  |    Value      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;          Value (cont.)&n= bsp;            = ;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

Pros: simple, data type sounds the same as the one defined in RFC2868; the = design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) &= ; DSCP(3bits), and even change with (Input/Output) and (Octets/Packets) bec= ause it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type of attribute is enough to work.
Cons: Sounds complex data type


Attribute Design =96 2a @ extended type space in flat mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type |     Value     |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Value (cont.) &n= bsp;            = ;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+  

Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-r= adext-radius-extensions-04, if we'd need to use the extended type space at = this time
Cons: 8 new type @ 241.x


Attribute Design =96 2b @ extended type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type | Traffic-Type  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

Pros: Same as Design - 1b if we'd need to use the extended type space at th= is time
Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-exte= nsions-04


Attribute Design =96 3 @ extended type space in nesting-TLV mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type | Traffic-Type  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       Traffi= c-Type(TLV)       |    &n= bsp;  Input-Octets(TLV)       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Octets(TLV)       &= nbsp;           &nbs= p;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;   
      |       &= nbsp;           &nbs= p;   Input-Octets(TLV)       &= nbsp;           &nbs= p;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Octets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Octets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |      Output-Octet= s(TLV)       |     &= nbsp; Input-Packets(TLV)      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Packets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Packets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Packets(TLV)       = ;            &n= bsp; |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Packets(TLV)       = ;            &n= bsp; |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Output-Packets(TLV= )       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+

Pros: used the new basic data type of TLV defined in draft-ietf-radext-radi= us-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 = sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above orde= r, and even some of them are not necessary to appear in the container attribute.
Cons: looks a little complicated, should use the extended-type as per draft= -ietf-radext-radius-extensions,


Attribute Design =964a @ traditional type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Traff= ic-Type  | Input-Octets  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Input-Octets      =             &nb= sp;       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;          Input-Octets&nb= sp;            =     | Output-Octets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;   
      |       &= nbsp;           &nbs= p;     Output-Octets      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Output-Octets &n= bsp;            = ;   | Input-Packets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Input-Packets      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Input-Packets &n= bsp;            = ;   |Output-Packets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;    Output-Packets      &nbs= p;            &= nbsp;     |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;        Output-Packets  &= nbsp;           &nbs= p;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-++-+-+-= +-++-+-+-+

Pros: explicit and simplified from the design-3 because each field has the = fixed length.
Cons: multi-field design, complex data type (not recommended by RFC6158)
Pls. feel free to comments on the above designs from your professional pers= pective, then I will update my draft based on your comments.


I supposed each design can work for 'Traffic Statistics', maybe Design 1a, = 1b, 2a, 3 could be more acceptable.

 

I recommend design 1b, because it looks much simple, need much less attr= ibuts than design 1a, and we can solve the problem on reporting 'Traffic St= atistics' within the standard type space.

If the standard type space is deprecated against this case, then de= sign-2a might be our choice, because we don't have the space limitation iss= ue in the extended type space;

 

or we could try the new basic data type of nesting-TLV, then 'Acct-Traff= ic Statistics' could be the 1st attribute in the extended type space with T= LV as its basic data type.

 

But my concern will be that it still needs 3 or more years for= the upgrade of the deployed radius system (NASs + servers) t= o support the solution of the extended type space and its newly-define= d attributes.

 

 

Best Regards,
Leaf

--Boundary_(ID_/Z/iXVg2ctST89mRVILKJw)-- From radext-bounces@ietf.org Thu Feb 23 08:12:28 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BEA21F87F8; Thu, 23 Feb 2012 08:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330013548; bh=LANm+5CMYOECbveN9sOjdVX74j3WcOD2qkYlagvyh4s=; h=Date:From:To:Message-id:MIME-version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=O+w8GT6GdRsJWE04QERxswPVA8OwAxiD58zau01kgE1Fg73SN0R7COhQ4PpElX3+o HGyS1gmpEoxl4KaHSgg2Xol2yWDiWHiktlKkJMKaylSA6/S+W93n+Vq0vxL/QDgwFc JwD760IymoebbM9dQAj6eyUktFH3x/5iNL/8P+MA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18A21F85A0 for ; Thu, 23 Feb 2012 08:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.693 X-Spam-Level: X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yssfF2cR2P2u for ; Thu, 23 Feb 2012 08:12:22 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6121F87F8 for ; Thu, 23 Feb 2012 08:12:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU005L1SYPQ5@szxga05-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 00:11:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU00G1VSYP7K@szxga05-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 00:11:13 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ06576; Fri, 24 Feb 2012 00:10:59 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 00:10:56 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 00:10:55 +0800 Date: Thu, 23 Feb 2012 16:10:54 +0000 From: Leaf yeh X-Originating-IP: [172.24.1.70] To: "bernard_aboba@hotmail.com" , "aland@deployingradius.com" , "dnelson@elbrys.com" , "stefan.winter@restena.lu" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" Message-id: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "radext@ietf.org" , "dromasca@avaya.com" Subject: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8297166025104193142==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============8297166025104193142== Content-type: multipart/alternative; boundary="Boundary_(ID_/Z/iXVg2ctST89mRVILKJw)" Content-language: zh-CN --Boundary_(ID_/Z/iXVg2ctST89mRVILKJw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Dear Radius-Doctors: I presented the following 6+ attribute design at Radext session of IETF82-T= aipei, which can be found in http://www.ietf.org/proceedings/82/slides/rade= xt-2.pptx (RADIUS Accounting Extensions on Traffic Statistics) against dra= ft-yeh-radext-ext-traffic-statistics. Here are their Pros & Cons for our further discussion: Attribute Design =96 1a @ traditional type space in flat mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, based on RFC2865 if the traditional type space still open for= this case, draft-ietf-radext-radius-extensions sounds intend to deprecate = the traditional standard type space. Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets) Attribute Design =96 1b @ traditional type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Traffic-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, data type sounds the same as the one defined in RFC2868; the = design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) & DS= CP(3bits), and even change with (Input/Output) and (Octets/Packets) because= it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type o= f attribute is enough to work. Cons: Sounds complex data type Attribute Design =96 2a @ extended type space in flat mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-r= adext-radius-extensions-04, if we'd need to use the extended type space at = this time Cons: 8 new type @ 241.x Attribute Design =96 2b @ extended type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Traffic-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: Same as Design - 1b if we'd need to use the extended type space at th= is time Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-exte= nsions-04 Attribute Design =96 3 @ extended type space in nesting-TLV mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Traffic-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic-Type(TLV) | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets(TLV) | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets(TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: used the new basic data type of TLV defined in draft-ietf-radext-radi= us-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 = sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above orde= r, and even some of them are not necessary to appear in the container attri= bute. Cons: looks a little complicated, should use the extended-type as per draft= -ietf-radext-radius-extensions, Attribute Design =964a @ traditional type space 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Traffic-Type | Input-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Octets | Output-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Octets | Input-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input-Packets |Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+ Pros: explicit and simplified from the design-3 because each field has the = fixed length. Cons: multi-field design, complex data type (not recommended by RFC6158) Pls. feel free to comments on the above designs from your professional pers= pective, then I will update my draft based on your comments. I supposed each design can work for 'Traffic Statistics', maybe Design 1a, = 1b, 2a, 3 could be more acceptable. I recommend design 1b, because it looks much simple, need much less attribu= ts than design 1a, and we can solve the problem on reporting 'Traffic Stati= stics' within the standard type space. If the standard type space is deprecated against this case, then design-2a = might be our choice, because we don't have the space limitation issue in th= e extended type space; or we could try the new basic data type of nesting-TLV, then 'Acct-Traffic = Statistics' could be the 1st attribute in the extended type space with TLV = as its basic data type. But my concern will be that it still needs 3 or more years for the upgrade = of the deployed radius system (NASs + servers) to support the solution of t= he extended type space and its newly-defined attributes. Best Regards, Leaf --Boundary_(ID_/Z/iXVg2ctST89mRVILKJw) Content-id: <148F80E109A84A42B48476AD9B07B135@huawei.com> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Dear Radius-Doctors:

I presented the following 6+ attribute design at Radext session of IETF= 82-Taipei, which can be found in http://www.ietf.org/proceedings/82/slides/radext-2.pptx  (RADIUS A= ccounting Extensions on Traffic Statistics) against draft-yeh-radext-ext-tr= affic-statistics.

 

Here are their Pros & Cons for our further discussion:

Attribute Design =96 1a @ traditional type space in flat mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | =              Va= lue            |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;  Value (cont.)        |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+

Pros: simple, based on RFC2865 if the traditional type space still open for= this case, draft-ietf-radext-radius-extensions sounds intend to deprecate = the traditional standard type space.
Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets)


Attribute Design =96 1b @ traditional type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Traff= ic-Type  |    Value      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;          Value (cont.)&n= bsp;            = ;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

Pros: simple, data type sounds the same as the one defined in RFC2868; the = design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) &= ; DSCP(3bits), and even change with (Input/Output) and (Octets/Packets) bec= ause it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type of attribute is enough to work.
Cons: Sounds complex data type


Attribute Design =96 2a @ extended type space in flat mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type |     Value     |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Value (cont.) &n= bsp;            = ;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+  

Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-r= adext-radius-extensions-04, if we'd need to use the extended type space at = this time
Cons: 8 new type @ 241.x


Attribute Design =96 2b @ extended type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type | Traffic-Type  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Value (cont.)      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

Pros: Same as Design - 1b if we'd need to use the extended type space at th= is time
Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-exte= nsions-04


Attribute Design =96 3 @ extended type space in nesting-TLV mode

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Exten= ded-Type | Traffic-Type  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       Traffi= c-Type(TLV)       |    &n= bsp;  Input-Octets(TLV)       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Octets(TLV)       &= nbsp;           &nbs= p;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;   
      |       &= nbsp;           &nbs= p;   Input-Octets(TLV)       &= nbsp;           &nbs= p;   |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Octets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Octets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |      Output-Octet= s(TLV)       |     &= nbsp; Input-Packets(TLV)      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Packets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Input-Packets(TLV)       =             &nb= sp;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Packets(TLV)       = ;            &n= bsp; |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;   Output-Packets(TLV)       = ;            &n= bsp; |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Output-Packets(TLV= )       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+

Pros: used the new basic data type of TLV defined in draft-ietf-radext-radi= us-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 = sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above orde= r, and even some of them are not necessary to appear in the container attribute.
Cons: looks a little complicated, should use the extended-type as per draft= -ietf-radext-radius-extensions,


Attribute Design =964a @ traditional type space

       0      &= nbsp;            1&n= bsp;            = ;      2       =             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |     Type  &n= bsp;   |     Length    | Traff= ic-Type  | Input-Octets  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Input-Octets      =             &nb= sp;       |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;          Input-Octets&nb= sp;            =     | Output-Octets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;   
      |       &= nbsp;           &nbs= p;     Output-Octets      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Output-Octets &n= bsp;            = ;   | Input-Packets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;     Input-Packets      = ;            &n= bsp;      |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;         Input-Packets &n= bsp;            = ;   |Output-Packets |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;           &nbs= p;    Output-Packets      &nbs= p;            &= nbsp;     |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;
      |       &= nbsp;        Output-Packets  &= nbsp;           &nbs= p;  |
      +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-++-+-+-= +-++-+-+-+

Pros: explicit and simplified from the design-3 because each field has the = fixed length.
Cons: multi-field design, complex data type (not recommended by RFC6158)
Pls. feel free to comments on the above designs from your professional pers= pective, then I will update my draft based on your comments.


I supposed each design can work for 'Traffic Statistics', maybe Design 1a, = 1b, 2a, 3 could be more acceptable.

 

I recommend design 1b, because it looks much simple, need much less attr= ibuts than design 1a, and we can solve the problem on reporting 'Traffic St= atistics' within the standard type space.

If the standard type space is deprecated against this case, then de= sign-2a might be our choice, because we don't have the space limitation iss= ue in the extended type space;

 

or we could try the new basic data type of nesting-TLV, then 'Acct-Traff= ic Statistics' could be the 1st attribute in the extended type space with T= LV as its basic data type.

 

But my concern will be that it still needs 3 or more years for= the upgrade of the deployed radius system (NASs + servers) t= o support the solution of the extended type space and its newly-define= d attributes.

 

 

Best Regards,
Leaf

--Boundary_(ID_/Z/iXVg2ctST89mRVILKJw)-- --===============8297166025104193142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============8297166025104193142==-- From stefan.winter@restena.lu Thu Feb 23 23:32:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768B721E801E for ; Thu, 23 Feb 2012 23:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 WAVaOEP3xR6C for ; Thu, 23 Feb 2012 23:32:45 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1155921E800C for ; Thu, 23 Feb 2012 23:32:44 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8F91D10580; Fri, 24 Feb 2012 08:32:42 +0100 (CET) Received: from [IPv6:2001:a18:1:8:85d0:7c45:c938:773e] (unknown [IPv6:2001:a18:1:8:85d0:7c45:c938:773e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4D0811057E; Fri, 24 Feb 2012 08:32:42 +0100 (CET) Message-ID: <4F473D1A.3010801@restena.lu> Date: Fri, 24 Feb 2012 08:32:42 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Leaf yeh References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> In-Reply-To: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" , "aland@deployingradius.com" , "dromasca@avaya.com" , "peterd@iea-software.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:32:46 -0000 Leaf, you are trying to re-open an already closed discussion. See the thread on the radext list from 14 nov 2011, immediately following IETF-82 Taipei. Everyone in this thread was *for* extended attributes encoding as per my draft. Everybody was *against* your proposed approaches of encoding the information in a custom way. Greetings, Stefan Winter > Dear Radius-Doctors: > > I presented the following 6+ attribute design at Radext session of > IETF82-Taipei, which can be found in > http://www.ietf.org/proceedings/82/slides/radext-2.pptx (RADIUS > Accounting Extensions on Traffic Statistics) against > draft-yeh-radext-ext-traffic-statistics. > > Here are their Pros & Cons for our further discussion: > > Attribute Design – 1a @ traditional type space in flat mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, based on RFC2865 if the traditional type space still open > for this case, draft-ietf-radext-radius-extensions sounds intend to > deprecate the traditional standard type space. > Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets) > > > Attribute Design – 1b @ traditional type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Traffic-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, data type sounds the same as the one defined in RFC2868; > the design of 'Traffic-Type' can cover the type of change with > (IPv4/IPv6) & DSCP(3bits), and even change with (Input/Output) and > (Octets/Packets) because it has 8 bits in the field of 'Traffic-Type'. > That might mean 1 new type of attribute is enough to work. > Cons: Sounds complex data type > > > Attribute Design – 2a @ extended type space in flat mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, based on Extended type defined in section 2.1 of > draft-ietf-radext-radius-extensions-04, if we'd need to use the extended > type space at this time > Cons: 8 new type @ 241.x > > > Attribute Design – 2b @ extended type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Traffic-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: Same as Design - 1b if we'd need to use the extended type space at > this time > Cons: same as the Design-1b, sounds forbid in > draft-ietf-radext-radius-extensions-04 > > > Attribute Design – 3 @ extended type space in nesting-TLV mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Traffic-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Traffic-Type(TLV) | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: used the new basic data type of TLV defined in > draft-ietf-radext-radius-extensions-04, has one TLV-container (1 new > extended type, 241.x) and 5 sub-TLVs (241.x.1-5). The sub-TLV does not > need to appear in the above order, and even some of them are not > necessary to appear in the container attribute. > Cons: looks a little complicated, should use the extended-type as per > draft-ietf-radext-radius-extensions, > > > Attribute Design –4a @ traditional type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Traffic-Type | Input-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets | Output-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets | Input-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets |Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+ > > Pros: explicit and simplified from the design-3 because each field has > the fixed length. > Cons: multi-field design, complex data type (not recommended by RFC6158) > > Pls. feel free to comments on the above designs from your professional > perspective, then I will update my draft based on your comments. > > > I supposed each design can work for 'Traffic Statistics', maybe Design > 1a, 1b, 2a, 3 could be more acceptable. > > I recommend design 1b, because it looks much simple, need much less > attributs than design 1a, and we can solve the problem on reporting > 'Traffic Statistics' within the standard type space. > > If the standard type space is deprecated against this case, then > design-2a might be our choice, because we don't have the space > limitation issue in the extended type space; > > or we could try the new basic data type of nesting-TLV, then > 'Acct-Traffic Statistics' could be the 1st attribute in the extended > type space with TLV as its basic data type. > > But my concern will be that it still needs 3 or more years for the > upgrade of the deployed radius system (NASs + servers) to support the > solution of the extended type space and its newly-defined attributes. > > Best Regards, > Leaf > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Thu Feb 23 23:32:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1921E801E; Thu, 23 Feb 2012 23:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330068768; bh=VpxBsWiAeuKmg6kNgUE/fX+ni0Xw295OcYEfo10dR0k=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=VrBadam6fMOnN7R/g9S8mDItCpGavl/n/bI4MJDloqcSVkZ8E0sGTs2IM9ubuK1+z Kvw8RXNDG/4S9pmECMApp+rEEQ8Ayc4fhK7nfDFCuIFcwmoVNpBeQHHthkiTXJbtIz oX6X1wXeelEaBl6iKgRjfEizN7Sq+o6DIh4mRT+E= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768B721E801E for ; Thu, 23 Feb 2012 23:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 WAVaOEP3xR6C for ; Thu, 23 Feb 2012 23:32:45 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1155921E800C for ; Thu, 23 Feb 2012 23:32:44 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8F91D10580; Fri, 24 Feb 2012 08:32:42 +0100 (CET) Received: from [IPv6:2001:a18:1:8:85d0:7c45:c938:773e] (unknown [IPv6:2001:a18:1:8:85d0:7c45:c938:773e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4D0811057E; Fri, 24 Feb 2012 08:32:42 +0100 (CET) Message-ID: <4F473D1A.3010801@restena.lu> Date: Fri, 24 Feb 2012 08:32:42 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Leaf yeh References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> In-Reply-To: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" , "aland@deployingradius.com" , "dromasca@avaya.com" , "peterd@iea-software.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf, you are trying to re-open an already closed discussion. See the thread = on the radext list from 14 nov 2011, immediately following IETF-82 Taipei. Everyone in this thread was *for* extended attributes encoding as per my = draft. Everybody was *against* your proposed approaches of encoding the = information in a custom way. Greetings, Stefan Winter > Dear Radius-Doctors: > > I presented the following 6+ attribute design at Radext session of > IETF82-Taipei, which can be found in > http://www.ietf.org/proceedings/82/slides/radext-2.pptx (RADIUS > Accounting Extensions on Traffic Statistics) against > draft-yeh-radext-ext-traffic-statistics. > > Here are their Pros & Cons for our further discussion: > > Attribute Design =96 1a @ traditional type space in flat mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, based on RFC2865 if the traditional type space still open > for this case, draft-ietf-radext-radius-extensions sounds intend to > deprecate the traditional standard type space. > Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets) > > > Attribute Design =96 1b @ traditional type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Traffic-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, data type sounds the same as the one defined in RFC2868; > the design of 'Traffic-Type' can cover the type of change with > (IPv4/IPv6) & DSCP(3bits), and even change with (Input/Output) and > (Octets/Packets) because it has 8 bits in the field of 'Traffic-Type'. > That might mean 1 new type of attribute is enough to work. > Cons: Sounds complex data type > > > Attribute Design =96 2a @ extended type space in flat mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: simple, based on Extended type defined in section 2.1 of > draft-ietf-radext-radius-extensions-04, if we'd need to use the extended > type space at this time > Cons: 8 new type @ 241.x > > > Attribute Design =96 2b @ extended type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Traffic-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value (cont.) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: Same as Design - 1b if we'd need to use the extended type space at > this time > Cons: same as the Design-1b, sounds forbid in > draft-ietf-radext-radius-extensions-04 > > > Attribute Design =96 3 @ extended type space in nesting-TLV mode > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type | Traffic-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Traffic-Type(TLV) | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets(TLV) | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets(TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Pros: used the new basic data type of TLV defined in > draft-ietf-radext-radius-extensions-04, has one TLV-container (1 new > extended type, 241.x) and 5 sub-TLVs (241.x.1-5). The sub-TLV does not > need to appear in the above order, and even some of them are not > necessary to appear in the container attribute. > Cons: looks a little complicated, should use the extended-type as per > draft-ietf-radext-radius-extensions, > > > Attribute Design =964a @ traditional type space > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Traffic-Type | Input-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Octets | Output-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Octets | Input-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input-Packets |Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output-Packets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+ > > Pros: explicit and simplified from the design-3 because each field has > the fixed length. > Cons: multi-field design, complex data type (not recommended by RFC6158) > > Pls. feel free to comments on the above designs from your professional > perspective, then I will update my draft based on your comments. > > > I supposed each design can work for 'Traffic Statistics', maybe Design > 1a, 1b, 2a, 3 could be more acceptable. > > I recommend design 1b, because it looks much simple, need much less > attributs than design 1a, and we can solve the problem on reporting > 'Traffic Statistics' within the standard type space. > > If the standard type space is deprecated against this case, then > design-2a might be our choice, because we don't have the space > limitation issue in the extended type space; > > or we could try the new basic data type of nesting-TLV, then > 'Acct-Traffic Statistics' could be the 1st attribute in the extended > type space with TLV as its basic data type. > > But my concern will be that it still needs 3 or more years for the > upgrade of the deployed radius system (NASs + servers) to support the > solution of the extended type space and its newly-defined attributes. > > Best Regards, > Leaf > -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et = de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Fri Feb 24 01:30:57 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48321F88C1 for ; Fri, 24 Feb 2012 01:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.688 X-Spam-Level: X-Spam-Status: No, score=-6.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xelL7KHLHgq for ; Fri, 24 Feb 2012 01:30:55 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2621F88C6 for ; Fri, 24 Feb 2012 01:30:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00D6C52PL8@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 17:30:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00DHQ51UR7@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 17:30:25 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ71455; Fri, 24 Feb 2012 17:30:22 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 17:30:01 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 17:30:10 +0800 Date: Fri, 24 Feb 2012 09:30:09 +0000 From: Leaf yeh In-reply-to: <4F473D1A.3010801@restena.lu> X-Originating-IP: [10.70.39.113] To: Stefan Winter Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" , "aland@deployingradius.com" , "dromasca@avaya.com" , "peterd@iea-software.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:30:58 -0000 U3RlZmFuIC0geW91IGFyZSB0cnlpbmcgdG8gcmUtb3BlbiBhbiBhbHJlYWR5IGNsb3NlZCBkaXNj dXNzaW9uLiBTZWUgdGhlIHRocmVhZCANCm9uIHRoZSByYWRleHQgbGlzdCBmcm9tIDE0IG5vdiAy MDExLCBpbW1lZGlhdGVseSBmb2xsb3dpbmcgSUVURi04MiBUYWlwZWkuDQoNClllcywgSSB3YW50 IHRvIHRyaWdnZXIgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYywgYW5kIGhlYXIg dGhlIG9waW5pb24gZnJvbSBvdGhlciBleHBlcnRzIGluIHRoZSBXRy4gDQoNCllvdXIgb3Bpbmlv biBhbmQgcHJlZmVyZW5jZSB3YXMgcXVpdGUgY2xlYXIgYW5kIGFyZSBmb3IgdGhlIERlc2lnbiAt IDMuIA0KDQpCdXQgYXMgcGVyIHRoZSBzZWN0aW9uIDYuNCBvZiBkcmFmdC1pZXRmLXJhZGV4dC1y YWRpdXMtZXh0ZW5zaW9ucy0wNCwgDQoNCjxxdW90ZT5UaGUgImludGVnZXI2NCIgZGF0YSB0eXBl IE1BWSBiZSB1c2VkIGluIGFueSBSQURJVVMgYXR0cmlidXRlLg0KVGhlIHVzZSBvZiA2NC1iaXQg aW50ZWdlcnMgaXMgTk9UIFJFQ09NTUVOREVEIGJ5IFtSRkM2MTU4XSwgYnV0DQp0aGVpciB1dGls aXR5IGlzIG5vdyBldmlkZW50LiA8L3F1b3RlPg0KDQp0aGUgYWJvdmUgd29yZHMgbWVhbnMgdGhl IG5ldyBkYXRhIHR5cGUgb2YgJ2ludGVnZXI2NCcgY2FuIGJlIHVzZWQgaW4gYm90aCAnc3RhbmRh cmQnIGFuZCAnZXh0ZW5kZWQnIHR5cGUgc3BhY2UuIFNvIHRoZSBlbXBsb3ltZW50IG9mICdpbnRl Z2VyNjQnIGlzIG5vdCBhIHByb2JsZW0gaW4gRGVzaWduIC0gMWEgJiAxYi4NCg0KMm5kbHksIGFz IHRvIHRoZSBxdWVzdGlvbiBvZiByZS11c2FibGUgY29kZSwgSSBndWVzcyBkZXNpZ24gLSAxYiBt aWdodCByZXVzZSB0aGUgY29kZSBmb3IgdGhlIHRyYWRpdGlvbmFsIGF0dHJpYnV0ZXMgZGVmaW5l ZCBpbiBSRkMyODY4LCB0aG91Z2ggdGhpcyBmb3JtYXQgaXMgJ011c3QgTm90JyBpbiB0aGUgJ2V4 dGVuZGVkJyB0eXBlIHNwYWNlIGFzIHBlciB0aGUgc2VjdGlvbiA2LjQgb2YgZHJhZnQtaWV0Zi1y YWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDQuDQoNCjxxdW90ZT5bUkZDMjg2Nl0gInRhZ2dlZCIg YXR0cmlidXRlcyBNVVNUIE5PVCBiZSBkZWZpbmVkIGluIHRoZQ0KRXh0ZW5kZWQtVHlwZSBzcGFj ZS4gVGhlICJ0bHYiIGRhdGEgdHlwZSBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIHRvDQpncm91cCBh dHRyaWJ1dGVzLiA8L3F1b3RlPg0KDQpJIGludGVuZGVkIHRvIHNvbGljaXQgdGhlIGV4cGVydCdz IGp1ZGdlIG9uIHRoaXMgYXNwZWN0IGhlcmUuDQoNCjNyZGx5LCBpZiBXRyBkZWNpZGVzIHRvIGVt cGxveSAnZXh0ZW5kZWQnIHR5cGUgc3BhY2UgcmlnaHQgbm93IG9yIGVzcGVjaWFsbHkgZm9yIHRo aXMgY2FzZSwgdGhlbiB3ZSBzdGlsbCBoYXZlIG9wdGlvbiBvZiBkZXNpZ24gLSAyYSAmIDMsIHJp Z2h0PyBJIGFtIHN0aWxsIG5vdCBxdWl0ZSBzdXJlIHRoYXQgV0cgZGVjaWRlcyB0byBhZG9wdCBO ZXN0aW5nLVRMViBmb3IgdGhpcyBjYXNlIGlmIHdlIGRvbid0IGhhdmUgdGhlIGxpbWl0YXRpb24g b24gdGhlIHR5cGUgc3BhY2UuIEkgbWVhbiB3ZSBjb3VsZCBkZXNpZ24gaXQgYXMgdXN1YWwuDQoN CjR0aGx5LCBpZiBXRyBwcmVmZXJhIHRvIGVtcGxveSBOZXN0aW5nLVRMViBmb3IgdGhlIHJlcG9y dGluZyAnVHJhZmZpYyBTdGF0aXN0aWNzJyBpbiBBY2NvdW50aW5nLVJlcXVlc3QgbWVzc2FnZSwg SSBzdXBwb3NlZCB3ZSBzdGlsbCBjb3VsZCBtYWtlIHNvbWUgZWZmb3J0IG9uIHRoZSBkZXNpZ24g LTMgKG9yIGRyYWZ0LXdpbnRlcikgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnQgZnJvbSB0aGUgaW5k dXN0cnkgZXhwcmVzc2VkIGluIFNlY3Rpb24gMSBvZiBkcmFmdC15ZWguDQoNCkkgaW50ZW5kZWQg dG8gZG91YmxlLWNoZWNrIHRoZSBkb2N0b3IncyBvcGluaW9uIG9uIHRoZSBBdHRyaWJ1dGUgRGVz aWduIG9uICdUcmFmZmljIFN0YXRpc3RpY3MnIGFnYWluIHdpdGggbXkgY29uY2VybnMgb24gdGhl IHVwZ3JhZGUgb24gUmFkaXVzIHN5c3RlbSB0byBzdXBwb3J0IHRoZSAnZXh0ZW5kZWQnIHR5cGUg c3BhY2UgYW5kIGl0cyBuZXcgTmVzdGluZy1UTFYgZGljdGlvbmFyeSwgaWYgd2Ugc3RpbGwgaGF2 ZSAzMCB1bmFzc2lnbmVkIGNvZGVzLg0KDQoNCkJlc3QgUmVnYXJkcw0KTGVhZg0KDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpyYWRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZhbiBXaW50 ZXINClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgMzozMyBQTQ0KVG86IExlYWYgeWVo DQpDYzogcmFkZXh0QGlldGYub3JnOyBkbmVsc29uQGVsYnJ5cy5jb207IGJlcm5hcmRfYWJvYmFA aG90bWFpbC5jb207IGpvdW5pLmtvcmhvbmVuQG5zbi5jb207IG1hdXJpY2lvLnNhbmNoZXpAaHAu Y29tOyBhbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tOyBkcm9tYXNjYUBhdmF5YS5jb207IHBldGVy ZEBpZWEtc29mdHdhcmUuY29tDQpTdWJqZWN0OiBSZTogW3JhZGV4dF0gQXR0cmlidXRlIERlc2ln biBvbiAnVHJhZmZpYyBTdGF0aXN0aWNzJw0KDQpMZWFmLA0KDQp5b3UgYXJlIHRyeWluZyB0byBy ZS1vcGVuIGFuIGFscmVhZHkgY2xvc2VkIGRpc2N1c3Npb24uIFNlZSB0aGUgdGhyZWFkIA0Kb24g dGhlIHJhZGV4dCBsaXN0IGZyb20gMTQgbm92IDIwMTEsIGltbWVkaWF0ZWx5IGZvbGxvd2luZyBJ RVRGLTgyIFRhaXBlaS4NCg0KRXZlcnlvbmUgaW4gdGhpcyB0aHJlYWQgd2FzICpmb3IqIGV4dGVu ZGVkIGF0dHJpYnV0ZXMgZW5jb2RpbmcgYXMgcGVyIG15IA0KZHJhZnQuIEV2ZXJ5Ym9keSB3YXMg KmFnYWluc3QqIHlvdXIgcHJvcG9zZWQgYXBwcm9hY2hlcyBvZiBlbmNvZGluZyB0aGUgDQppbmZv cm1hdGlvbiBpbiBhIGN1c3RvbSB3YXkuDQoNCkdyZWV0aW5ncywNCg0KU3RlZmFuIFdpbnRlcg0K DQo+IERlYXIgUmFkaXVzLURvY3RvcnM6DQo+DQo+IEkgcHJlc2VudGVkIHRoZSBmb2xsb3dpbmcg NisgYXR0cmlidXRlIGRlc2lnbiBhdCBSYWRleHQgc2Vzc2lvbiBvZg0KPiBJRVRGODItVGFpcGVp LCB3aGljaCBjYW4gYmUgZm91bmQgaW4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84Mi9zbGlkZXMvcmFkZXh0LTIucHB0eCAoUkFESVVTDQo+IEFjY291bnRpbmcgRXh0ZW5zaW9u cyBvbiBUcmFmZmljIFN0YXRpc3RpY3MpIGFnYWluc3QNCj4gZHJhZnQteWVoLXJhZGV4dC1leHQt dHJhZmZpYy1zdGF0aXN0aWNzLg0KPg0KPiBIZXJlIGFyZSB0aGVpciBQcm9zICYgQ29ucyBmb3Ig b3VyIGZ1cnRoZXIgZGlzY3Vzc2lvbjoNCj4NCj4gQXR0cmlidXRlIERlc2lnbiDigJMgMWEgQCB0 cmFkaXRpb25hbCB0eXBlIHNwYWNlIGluIGZsYXQgbW9kZQ0KPg0KPiAwIDEgMiAzDQo+IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGggfCBWYWx1ZSB8DQo+ICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ IHwgVmFsdWUgKGNvbnQuKSB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgVmFsdWUgKGNvbnQuKSB8DQo+ICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiBQcm9zOiBzaW1wbGUsIGJhc2Vk IG9uIFJGQzI4NjUgaWYgdGhlIHRyYWRpdGlvbmFsIHR5cGUgc3BhY2Ugc3RpbGwgb3Blbg0KPiBm b3IgdGhpcyBjYXNlLCBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucyBzb3VuZHMg aW50ZW5kIHRvDQo+IGRlcHJlY2F0ZSB0aGUgdHJhZGl0aW9uYWwgc3RhbmRhcmQgdHlwZSBzcGFj ZS4NCj4gQ29uczogOCBuZXcgdHlwZSBmb3IgKElQdjQvSVA2KSAqIChJbnB1dC9PdXRwdXQpICog KE9jdGV0cy9QYWNrZXRzKQ0KPg0KPg0KPiBBdHRyaWJ1dGUgRGVzaWduIOKAkyAxYiBAIHRyYWRp dGlvbmFsIHR5cGUgc3BhY2UNCj4NCj4gMCAxIDIgMw0KPiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g fCBUeXBlIHwgTGVuZ3RoIHwgVHJhZmZpYy1UeXBlIHwgVmFsdWUgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8 IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+DQo+IFByb3M6 IHNpbXBsZSwgZGF0YSB0eXBlIHNvdW5kcyB0aGUgc2FtZSBhcyB0aGUgb25lIGRlZmluZWQgaW4g UkZDMjg2ODsNCj4gdGhlIGRlc2lnbiBvZiAnVHJhZmZpYy1UeXBlJyBjYW4gY292ZXIgdGhlIHR5 cGUgb2YgY2hhbmdlIHdpdGgNCj4gKElQdjQvSVB2NikgJiBEU0NQKDNiaXRzKSwgYW5kIGV2ZW4g Y2hhbmdlIHdpdGggKElucHV0L091dHB1dCkgYW5kDQo+IChPY3RldHMvUGFja2V0cykgYmVjYXVz ZSBpdCBoYXMgOCBiaXRzIGluIHRoZSBmaWVsZCBvZiAnVHJhZmZpYy1UeXBlJy4NCj4gVGhhdCBt aWdodCBtZWFuIDEgbmV3IHR5cGUgb2YgYXR0cmlidXRlIGlzIGVub3VnaCB0byB3b3JrLg0KPiBD b25zOiBTb3VuZHMgY29tcGxleCBkYXRhIHR5cGUNCj4NCj4NCj4gQXR0cmlidXRlIERlc2lnbiDi gJMgMmEgQCBleHRlbmRlZCB0eXBlIHNwYWNlIGluIGZsYXQgbW9kZQ0KPg0KPiAwIDEgMiAzDQo+ IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGggfCBFeHRlbmRlZC1UeXBlIHwg VmFsdWUgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8 IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+DQo+IFByb3M6IHNpbXBsZSwgYmFzZWQgb24gRXh0ZW5kZWQgdHlwZSBk ZWZpbmVkIGluIHNlY3Rpb24gMi4xIG9mDQo+IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRl bnNpb25zLTA0LCBpZiB3ZSdkIG5lZWQgdG8gdXNlIHRoZSBleHRlbmRlZA0KPiB0eXBlIHNwYWNl IGF0IHRoaXMgdGltZQ0KPiBDb25zOiA4IG5ldyB0eXBlIEAgMjQxLngNCj4NCj4NCj4gQXR0cmli dXRlIERlc2lnbiDigJMgMmIgQCBleHRlbmRlZCB0eXBlIHNwYWNlDQo+DQo+IDAgMSAyIDMNCj4g MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+IHwgVHlwZSB8IExlbmd0aCB8IEV4dGVuZGVkLVR5cGUgfCBU cmFmZmljLVR5cGUgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiBQcm9zOiBTYW1lIGFzIERl c2lnbiAtIDFiIGlmIHdlJ2QgbmVlZCB0byB1c2UgdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2UgYXQN Cj4gdGhpcyB0aW1lDQo+IENvbnM6IHNhbWUgYXMgdGhlIERlc2lnbi0xYiwgc291bmRzIGZvcmJp ZCBpbg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucy0wNA0KPg0KPg0KPiBB dHRyaWJ1dGUgRGVzaWduIOKAkyAzIEAgZXh0ZW5kZWQgdHlwZSBzcGFjZSBpbiBuZXN0aW5nLVRM ViBtb2RlDQo+DQo+IDAgMSAyIDMNCj4gMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgVHlwZSB8IExl bmd0aCB8IEV4dGVuZGVkLVR5cGUgfCBUcmFmZmljLVR5cGUgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFRy YWZmaWMtVHlwZShUTFYpIHwgSW5wdXQtT2N0ZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElu cHV0LU9jdGV0cyhUTFYpIHwNCj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gfCBJbnB1dC1PY3RldHMoVExWKSB8DQo+ ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IHwgT3V0cHV0LU9jdGV0cyhUTFYpIHwNCj4gKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gfCBPdXRw dXQtT2N0ZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1PY3RldHMoVExWKSB8IElu cHV0LVBhY2tldHMoVExWKSB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgSW5wdXQtUGFja2V0cyhUTFYpIHwN Cj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gfCBJbnB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91 dHB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1QYWNrZXRzKFRMVikg fA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCj4NCj4gUHJvczogdXNlZCB0aGUgbmV3IGJhc2ljIGRhdGEg dHlwZSBvZiBUTFYgZGVmaW5lZCBpbg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5z aW9ucy0wNCwgaGFzIG9uZSBUTFYtY29udGFpbmVyICgxIG5ldw0KPiBleHRlbmRlZCB0eXBlLCAy NDEueCkgYW5kIDUgc3ViLVRMVnMgKDI0MS54LjEtNSkuIFRoZSBzdWItVExWIGRvZXMgbm90DQo+ IG5lZWQgdG8gYXBwZWFyIGluIHRoZSBhYm92ZSBvcmRlciwgYW5kIGV2ZW4gc29tZSBvZiB0aGVt IGFyZSBub3QNCj4gbmVjZXNzYXJ5IHRvIGFwcGVhciBpbiB0aGUgY29udGFpbmVyIGF0dHJpYnV0 ZS4NCj4gQ29uczogbG9va3MgYSBsaXR0bGUgY29tcGxpY2F0ZWQsIHNob3VsZCB1c2UgdGhlIGV4 dGVuZGVkLXR5cGUgYXMgcGVyDQo+IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25z LA0KPg0KPg0KPiBBdHRyaWJ1dGUgRGVzaWduIOKAkzRhIEAgdHJhZGl0aW9uYWwgdHlwZSBzcGFj ZQ0KPg0KPiAwIDEgMiAzDQo+IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGgg fCBUcmFmZmljLVR5cGUgfCBJbnB1dC1PY3RldHMgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElucHV0LU9j dGV0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+IHwgSW5wdXQtT2N0ZXRzIHwgT3V0cHV0LU9jdGV0cyB8DQo+ ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IHwgT3V0cHV0LU9jdGV0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgT3V0cHV0LU9j dGV0cyB8IElucHV0LVBhY2tldHMgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElucHV0LVBhY2tldHMgfA0K PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiB8IElucHV0LVBhY2tldHMgfE91dHB1dC1QYWNrZXRzIHwNCj4gKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gfCBPdXRwdXQtUGFja2V0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgT3V0cHV0LVBhY2tldHMg fA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsrLSstKy0rLSsrLSstKy0rDQo+ DQo+IFByb3M6IGV4cGxpY2l0IGFuZCBzaW1wbGlmaWVkIGZyb20gdGhlIGRlc2lnbi0zIGJlY2F1 c2UgZWFjaCBmaWVsZCBoYXMNCj4gdGhlIGZpeGVkIGxlbmd0aC4NCj4gQ29uczogbXVsdGktZmll bGQgZGVzaWduLCBjb21wbGV4IGRhdGEgdHlwZSAobm90IHJlY29tbWVuZGVkIGJ5IFJGQzYxNTgp DQo+DQo+IFBscy4gZmVlbCBmcmVlIHRvIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSBkZXNpZ25zIGZy b20geW91ciBwcm9mZXNzaW9uYWwNCj4gcGVyc3BlY3RpdmUsIHRoZW4gSSB3aWxsIHVwZGF0ZSBt eSBkcmFmdCBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzLg0KPg0KPg0KPiBJIHN1cHBvc2VkIGVhY2gg ZGVzaWduIGNhbiB3b3JrIGZvciAnVHJhZmZpYyBTdGF0aXN0aWNzJywgbWF5YmUgRGVzaWduDQo+ IDFhLCAxYiwgMmEsIDMgY291bGQgYmUgbW9yZSBhY2NlcHRhYmxlLg0KPg0KPiBJIHJlY29tbWVu ZCBkZXNpZ24gMWIsIGJlY2F1c2UgaXQgbG9va3MgbXVjaCBzaW1wbGUsIG5lZWQgbXVjaCBsZXNz DQo+IGF0dHJpYnV0cyB0aGFuIGRlc2lnbiAxYSwgYW5kIHdlIGNhbiBzb2x2ZSB0aGUgcHJvYmxl bSBvbiByZXBvcnRpbmcNCj4gJ1RyYWZmaWMgU3RhdGlzdGljcycgd2l0aGluIHRoZSBzdGFuZGFy ZCB0eXBlIHNwYWNlLg0KPg0KPiBJZiB0aGUgc3RhbmRhcmQgdHlwZSBzcGFjZSBpcyBkZXByZWNh dGVkIGFnYWluc3QgdGhpcyBjYXNlLCB0aGVuDQo+IGRlc2lnbi0yYSBtaWdodCBiZSBvdXIgY2hv aWNlLCBiZWNhdXNlIHdlIGRvbid0IGhhdmUgdGhlIHNwYWNlDQo+IGxpbWl0YXRpb24gaXNzdWUg aW4gdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2U7DQo+DQo+IG9yIHdlIGNvdWxkIHRyeSB0aGUgbmV3 IGJhc2ljIGRhdGEgdHlwZSBvZiBuZXN0aW5nLVRMViwgdGhlbg0KPiAnQWNjdC1UcmFmZmljIFN0 YXRpc3RpY3MnIGNvdWxkIGJlIHRoZSAxc3QgYXR0cmlidXRlIGluIHRoZSBleHRlbmRlZA0KPiB0 eXBlIHNwYWNlIHdpdGggVExWIGFzIGl0cyBiYXNpYyBkYXRhIHR5cGUuDQo+DQo+IEJ1dCBteSBj b25jZXJuIHdpbGwgYmUgdGhhdCBpdCBzdGlsbCBuZWVkcyAzIG9yIG1vcmUgeWVhcnMgZm9yIHRo ZQ0KPiB1cGdyYWRlIG9mIHRoZSBkZXBsb3llZCByYWRpdXMgc3lzdGVtIChOQVNzICsgc2VydmVy cykgdG8gc3VwcG9ydCB0aGUNCj4gc29sdXRpb24gb2YgdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2Ug YW5kIGl0cyBuZXdseS1kZWZpbmVkIGF0dHJpYnV0ZXMuDQo+DQo+IEJlc3QgUmVnYXJkcywNCj4g TGVhZg0KPg0KDQoNCi0tIA0KU3RlZmFuIFdJTlRFUg0KSW5nZW5pZXVyIGRlIFJlY2hlcmNoZQ0K Rm9uZGF0aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0aXF1ZSBkZSBsJ0VkdWNh dGlvbiBOYXRpb25hbGUgZXQgDQpkZSBsYSBSZWNoZXJjaGUNCjYsIHJ1ZSBSaWNoYXJkIENvdWRl bmhvdmUtS2FsZXJnaQ0KTC0xMzU5IEx1eGVtYm91cmcNCg0KVGVsOiArMzUyIDQyNDQwOSAxDQpG YXg6ICszNTIgNDIyNDczDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcmFkZXh0IG1haWxpbmcgbGlzdA0KcmFkZXh0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0K From radext-bounces@ietf.org Fri Feb 24 01:31:00 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF321F88C5; Fri, 24 Feb 2012 01:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330075859; bh=v8qeq87foeOpjOYvFVNRXeojAUChHhRCKV31QghMrlA=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lzy7put2N0DZUL161X/zwCMCFdcAoQ2oscYSut8Rhlse7FYybd+o42QWAtpVBaDWI HHMRhzqnIU4FyFBql0IaKpG6zSwaai5zpng/2VEHjnOLEpHxWdM1JFulqslyt+rZ+N NpRyaji/TDgIKTl71NS+OPSqgQnDJy5Qj4AEYFlw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48321F88C1 for ; Fri, 24 Feb 2012 01:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.688 X-Spam-Level: X-Spam-Status: No, score=-6.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xelL7KHLHgq for ; Fri, 24 Feb 2012 01:30:55 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2621F88C6 for ; Fri, 24 Feb 2012 01:30:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00D6C52PL8@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 17:30:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00DHQ51UR7@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 17:30:25 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ71455; Fri, 24 Feb 2012 17:30:22 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 17:30:01 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 17:30:10 +0800 Date: Fri, 24 Feb 2012 09:30:09 +0000 From: Leaf yeh In-reply-to: <4F473D1A.3010801@restena.lu> X-Originating-IP: [10.70.39.113] To: Stefan Winter Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , "jouni.korhonen@nsn.com" , "mauricio.sanchez@hp.com" , "aland@deployingradius.com" , "dromasca@avaya.com" , "peterd@iea-software.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org U3RlZmFuIC0geW91IGFyZSB0cnlpbmcgdG8gcmUtb3BlbiBhbiBhbHJlYWR5IGNsb3NlZCBkaXNj dXNzaW9uLiBTZWUgdGhlIHRocmVhZCANCm9uIHRoZSByYWRleHQgbGlzdCBmcm9tIDE0IG5vdiAy MDExLCBpbW1lZGlhdGVseSBmb2xsb3dpbmcgSUVURi04MiBUYWlwZWkuDQoNClllcywgSSB3YW50 IHRvIHRyaWdnZXIgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYywgYW5kIGhlYXIg dGhlIG9waW5pb24gZnJvbSBvdGhlciBleHBlcnRzIGluIHRoZSBXRy4gDQoNCllvdXIgb3Bpbmlv biBhbmQgcHJlZmVyZW5jZSB3YXMgcXVpdGUgY2xlYXIgYW5kIGFyZSBmb3IgdGhlIERlc2lnbiAt IDMuIA0KDQpCdXQgYXMgcGVyIHRoZSBzZWN0aW9uIDYuNCBvZiBkcmFmdC1pZXRmLXJhZGV4dC1y YWRpdXMtZXh0ZW5zaW9ucy0wNCwgDQoNCjxxdW90ZT5UaGUgImludGVnZXI2NCIgZGF0YSB0eXBl IE1BWSBiZSB1c2VkIGluIGFueSBSQURJVVMgYXR0cmlidXRlLg0KVGhlIHVzZSBvZiA2NC1iaXQg aW50ZWdlcnMgaXMgTk9UIFJFQ09NTUVOREVEIGJ5IFtSRkM2MTU4XSwgYnV0DQp0aGVpciB1dGls aXR5IGlzIG5vdyBldmlkZW50LiA8L3F1b3RlPg0KDQp0aGUgYWJvdmUgd29yZHMgbWVhbnMgdGhl IG5ldyBkYXRhIHR5cGUgb2YgJ2ludGVnZXI2NCcgY2FuIGJlIHVzZWQgaW4gYm90aCAnc3RhbmRh cmQnIGFuZCAnZXh0ZW5kZWQnIHR5cGUgc3BhY2UuIFNvIHRoZSBlbXBsb3ltZW50IG9mICdpbnRl Z2VyNjQnIGlzIG5vdCBhIHByb2JsZW0gaW4gRGVzaWduIC0gMWEgJiAxYi4NCg0KMm5kbHksIGFz IHRvIHRoZSBxdWVzdGlvbiBvZiByZS11c2FibGUgY29kZSwgSSBndWVzcyBkZXNpZ24gLSAxYiBt aWdodCByZXVzZSB0aGUgY29kZSBmb3IgdGhlIHRyYWRpdGlvbmFsIGF0dHJpYnV0ZXMgZGVmaW5l ZCBpbiBSRkMyODY4LCB0aG91Z2ggdGhpcyBmb3JtYXQgaXMgJ011c3QgTm90JyBpbiB0aGUgJ2V4 dGVuZGVkJyB0eXBlIHNwYWNlIGFzIHBlciB0aGUgc2VjdGlvbiA2LjQgb2YgZHJhZnQtaWV0Zi1y YWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDQuDQoNCjxxdW90ZT5bUkZDMjg2Nl0gInRhZ2dlZCIg YXR0cmlidXRlcyBNVVNUIE5PVCBiZSBkZWZpbmVkIGluIHRoZQ0KRXh0ZW5kZWQtVHlwZSBzcGFj ZS4gVGhlICJ0bHYiIGRhdGEgdHlwZSBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIHRvDQpncm91cCBh dHRyaWJ1dGVzLiA8L3F1b3RlPg0KDQpJIGludGVuZGVkIHRvIHNvbGljaXQgdGhlIGV4cGVydCdz IGp1ZGdlIG9uIHRoaXMgYXNwZWN0IGhlcmUuDQoNCjNyZGx5LCBpZiBXRyBkZWNpZGVzIHRvIGVt cGxveSAnZXh0ZW5kZWQnIHR5cGUgc3BhY2UgcmlnaHQgbm93IG9yIGVzcGVjaWFsbHkgZm9yIHRo aXMgY2FzZSwgdGhlbiB3ZSBzdGlsbCBoYXZlIG9wdGlvbiBvZiBkZXNpZ24gLSAyYSAmIDMsIHJp Z2h0PyBJIGFtIHN0aWxsIG5vdCBxdWl0ZSBzdXJlIHRoYXQgV0cgZGVjaWRlcyB0byBhZG9wdCBO ZXN0aW5nLVRMViBmb3IgdGhpcyBjYXNlIGlmIHdlIGRvbid0IGhhdmUgdGhlIGxpbWl0YXRpb24g b24gdGhlIHR5cGUgc3BhY2UuIEkgbWVhbiB3ZSBjb3VsZCBkZXNpZ24gaXQgYXMgdXN1YWwuDQoN CjR0aGx5LCBpZiBXRyBwcmVmZXJhIHRvIGVtcGxveSBOZXN0aW5nLVRMViBmb3IgdGhlIHJlcG9y dGluZyAnVHJhZmZpYyBTdGF0aXN0aWNzJyBpbiBBY2NvdW50aW5nLVJlcXVlc3QgbWVzc2FnZSwg SSBzdXBwb3NlZCB3ZSBzdGlsbCBjb3VsZCBtYWtlIHNvbWUgZWZmb3J0IG9uIHRoZSBkZXNpZ24g LTMgKG9yIGRyYWZ0LXdpbnRlcikgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnQgZnJvbSB0aGUgaW5k dXN0cnkgZXhwcmVzc2VkIGluIFNlY3Rpb24gMSBvZiBkcmFmdC15ZWguDQoNCkkgaW50ZW5kZWQg dG8gZG91YmxlLWNoZWNrIHRoZSBkb2N0b3IncyBvcGluaW9uIG9uIHRoZSBBdHRyaWJ1dGUgRGVz aWduIG9uICdUcmFmZmljIFN0YXRpc3RpY3MnIGFnYWluIHdpdGggbXkgY29uY2VybnMgb24gdGhl IHVwZ3JhZGUgb24gUmFkaXVzIHN5c3RlbSB0byBzdXBwb3J0IHRoZSAnZXh0ZW5kZWQnIHR5cGUg c3BhY2UgYW5kIGl0cyBuZXcgTmVzdGluZy1UTFYgZGljdGlvbmFyeSwgaWYgd2Ugc3RpbGwgaGF2 ZSAzMCB1bmFzc2lnbmVkIGNvZGVzLg0KDQoNCkJlc3QgUmVnYXJkcw0KTGVhZg0KDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpyYWRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZhbiBXaW50 ZXINClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgMzozMyBQTQ0KVG86IExlYWYgeWVo DQpDYzogcmFkZXh0QGlldGYub3JnOyBkbmVsc29uQGVsYnJ5cy5jb207IGJlcm5hcmRfYWJvYmFA aG90bWFpbC5jb207IGpvdW5pLmtvcmhvbmVuQG5zbi5jb207IG1hdXJpY2lvLnNhbmNoZXpAaHAu Y29tOyBhbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tOyBkcm9tYXNjYUBhdmF5YS5jb207IHBldGVy ZEBpZWEtc29mdHdhcmUuY29tDQpTdWJqZWN0OiBSZTogW3JhZGV4dF0gQXR0cmlidXRlIERlc2ln biBvbiAnVHJhZmZpYyBTdGF0aXN0aWNzJw0KDQpMZWFmLA0KDQp5b3UgYXJlIHRyeWluZyB0byBy ZS1vcGVuIGFuIGFscmVhZHkgY2xvc2VkIGRpc2N1c3Npb24uIFNlZSB0aGUgdGhyZWFkIA0Kb24g dGhlIHJhZGV4dCBsaXN0IGZyb20gMTQgbm92IDIwMTEsIGltbWVkaWF0ZWx5IGZvbGxvd2luZyBJ RVRGLTgyIFRhaXBlaS4NCg0KRXZlcnlvbmUgaW4gdGhpcyB0aHJlYWQgd2FzICpmb3IqIGV4dGVu ZGVkIGF0dHJpYnV0ZXMgZW5jb2RpbmcgYXMgcGVyIG15IA0KZHJhZnQuIEV2ZXJ5Ym9keSB3YXMg KmFnYWluc3QqIHlvdXIgcHJvcG9zZWQgYXBwcm9hY2hlcyBvZiBlbmNvZGluZyB0aGUgDQppbmZv cm1hdGlvbiBpbiBhIGN1c3RvbSB3YXkuDQoNCkdyZWV0aW5ncywNCg0KU3RlZmFuIFdpbnRlcg0K DQo+IERlYXIgUmFkaXVzLURvY3RvcnM6DQo+DQo+IEkgcHJlc2VudGVkIHRoZSBmb2xsb3dpbmcg NisgYXR0cmlidXRlIGRlc2lnbiBhdCBSYWRleHQgc2Vzc2lvbiBvZg0KPiBJRVRGODItVGFpcGVp LCB3aGljaCBjYW4gYmUgZm91bmQgaW4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84Mi9zbGlkZXMvcmFkZXh0LTIucHB0eCAoUkFESVVTDQo+IEFjY291bnRpbmcgRXh0ZW5zaW9u cyBvbiBUcmFmZmljIFN0YXRpc3RpY3MpIGFnYWluc3QNCj4gZHJhZnQteWVoLXJhZGV4dC1leHQt dHJhZmZpYy1zdGF0aXN0aWNzLg0KPg0KPiBIZXJlIGFyZSB0aGVpciBQcm9zICYgQ29ucyBmb3Ig b3VyIGZ1cnRoZXIgZGlzY3Vzc2lvbjoNCj4NCj4gQXR0cmlidXRlIERlc2lnbiDigJMgMWEgQCB0 cmFkaXRpb25hbCB0eXBlIHNwYWNlIGluIGZsYXQgbW9kZQ0KPg0KPiAwIDEgMiAzDQo+IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGggfCBWYWx1ZSB8DQo+ICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ IHwgVmFsdWUgKGNvbnQuKSB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgVmFsdWUgKGNvbnQuKSB8DQo+ICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiBQcm9zOiBzaW1wbGUsIGJhc2Vk IG9uIFJGQzI4NjUgaWYgdGhlIHRyYWRpdGlvbmFsIHR5cGUgc3BhY2Ugc3RpbGwgb3Blbg0KPiBm b3IgdGhpcyBjYXNlLCBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucyBzb3VuZHMg aW50ZW5kIHRvDQo+IGRlcHJlY2F0ZSB0aGUgdHJhZGl0aW9uYWwgc3RhbmRhcmQgdHlwZSBzcGFj ZS4NCj4gQ29uczogOCBuZXcgdHlwZSBmb3IgKElQdjQvSVA2KSAqIChJbnB1dC9PdXRwdXQpICog KE9jdGV0cy9QYWNrZXRzKQ0KPg0KPg0KPiBBdHRyaWJ1dGUgRGVzaWduIOKAkyAxYiBAIHRyYWRp dGlvbmFsIHR5cGUgc3BhY2UNCj4NCj4gMCAxIDIgMw0KPiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g fCBUeXBlIHwgTGVuZ3RoIHwgVHJhZmZpYy1UeXBlIHwgVmFsdWUgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8 IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+DQo+IFByb3M6 IHNpbXBsZSwgZGF0YSB0eXBlIHNvdW5kcyB0aGUgc2FtZSBhcyB0aGUgb25lIGRlZmluZWQgaW4g UkZDMjg2ODsNCj4gdGhlIGRlc2lnbiBvZiAnVHJhZmZpYy1UeXBlJyBjYW4gY292ZXIgdGhlIHR5 cGUgb2YgY2hhbmdlIHdpdGgNCj4gKElQdjQvSVB2NikgJiBEU0NQKDNiaXRzKSwgYW5kIGV2ZW4g Y2hhbmdlIHdpdGggKElucHV0L091dHB1dCkgYW5kDQo+IChPY3RldHMvUGFja2V0cykgYmVjYXVz ZSBpdCBoYXMgOCBiaXRzIGluIHRoZSBmaWVsZCBvZiAnVHJhZmZpYy1UeXBlJy4NCj4gVGhhdCBt aWdodCBtZWFuIDEgbmV3IHR5cGUgb2YgYXR0cmlidXRlIGlzIGVub3VnaCB0byB3b3JrLg0KPiBD b25zOiBTb3VuZHMgY29tcGxleCBkYXRhIHR5cGUNCj4NCj4NCj4gQXR0cmlidXRlIERlc2lnbiDi gJMgMmEgQCBleHRlbmRlZCB0eXBlIHNwYWNlIGluIGZsYXQgbW9kZQ0KPg0KPiAwIDEgMiAzDQo+ IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGggfCBFeHRlbmRlZC1UeXBlIHwg VmFsdWUgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8 IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+DQo+IFByb3M6IHNpbXBsZSwgYmFzZWQgb24gRXh0ZW5kZWQgdHlwZSBk ZWZpbmVkIGluIHNlY3Rpb24gMi4xIG9mDQo+IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRl bnNpb25zLTA0LCBpZiB3ZSdkIG5lZWQgdG8gdXNlIHRoZSBleHRlbmRlZA0KPiB0eXBlIHNwYWNl IGF0IHRoaXMgdGltZQ0KPiBDb25zOiA4IG5ldyB0eXBlIEAgMjQxLngNCj4NCj4NCj4gQXR0cmli dXRlIERlc2lnbiDigJMgMmIgQCBleHRlbmRlZCB0eXBlIHNwYWNlDQo+DQo+IDAgMSAyIDMNCj4g MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+IHwgVHlwZSB8IExlbmd0aCB8IEV4dGVuZGVkLVR5cGUgfCBU cmFmZmljLVR5cGUgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiB8IFZhbHVlIChjb250LikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPg0KPiBQcm9zOiBTYW1lIGFzIERl c2lnbiAtIDFiIGlmIHdlJ2QgbmVlZCB0byB1c2UgdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2UgYXQN Cj4gdGhpcyB0aW1lDQo+IENvbnM6IHNhbWUgYXMgdGhlIERlc2lnbi0xYiwgc291bmRzIGZvcmJp ZCBpbg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucy0wNA0KPg0KPg0KPiBB dHRyaWJ1dGUgRGVzaWduIOKAkyAzIEAgZXh0ZW5kZWQgdHlwZSBzcGFjZSBpbiBuZXN0aW5nLVRM ViBtb2RlDQo+DQo+IDAgMSAyIDMNCj4gMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgVHlwZSB8IExl bmd0aCB8IEV4dGVuZGVkLVR5cGUgfCBUcmFmZmljLVR5cGUgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFRy YWZmaWMtVHlwZShUTFYpIHwgSW5wdXQtT2N0ZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElu cHV0LU9jdGV0cyhUTFYpIHwNCj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gfCBJbnB1dC1PY3RldHMoVExWKSB8DQo+ ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IHwgT3V0cHV0LU9jdGV0cyhUTFYpIHwNCj4gKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gfCBPdXRw dXQtT2N0ZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1PY3RldHMoVExWKSB8IElu cHV0LVBhY2tldHMoVExWKSB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgSW5wdXQtUGFja2V0cyhUTFYpIHwN Cj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gfCBJbnB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91 dHB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1QYWNrZXRzKFRMVikg fA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiB8IE91dHB1dC1QYWNrZXRzKFRMVikgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCj4NCj4gUHJvczogdXNlZCB0aGUgbmV3IGJhc2ljIGRhdGEg dHlwZSBvZiBUTFYgZGVmaW5lZCBpbg0KPiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5z aW9ucy0wNCwgaGFzIG9uZSBUTFYtY29udGFpbmVyICgxIG5ldw0KPiBleHRlbmRlZCB0eXBlLCAy NDEueCkgYW5kIDUgc3ViLVRMVnMgKDI0MS54LjEtNSkuIFRoZSBzdWItVExWIGRvZXMgbm90DQo+ IG5lZWQgdG8gYXBwZWFyIGluIHRoZSBhYm92ZSBvcmRlciwgYW5kIGV2ZW4gc29tZSBvZiB0aGVt IGFyZSBub3QNCj4gbmVjZXNzYXJ5IHRvIGFwcGVhciBpbiB0aGUgY29udGFpbmVyIGF0dHJpYnV0 ZS4NCj4gQ29uczogbG9va3MgYSBsaXR0bGUgY29tcGxpY2F0ZWQsIHNob3VsZCB1c2UgdGhlIGV4 dGVuZGVkLXR5cGUgYXMgcGVyDQo+IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25z LA0KPg0KPg0KPiBBdHRyaWJ1dGUgRGVzaWduIOKAkzRhIEAgdHJhZGl0aW9uYWwgdHlwZSBzcGFj ZQ0KPg0KPiAwIDEgMiAzDQo+IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IFR5cGUgfCBMZW5ndGgg fCBUcmFmZmljLVR5cGUgfCBJbnB1dC1PY3RldHMgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElucHV0LU9j dGV0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+IHwgSW5wdXQtT2N0ZXRzIHwgT3V0cHV0LU9jdGV0cyB8DQo+ ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IHwgT3V0cHV0LU9jdGV0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgT3V0cHV0LU9j dGV0cyB8IElucHV0LVBhY2tldHMgfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8IElucHV0LVBhY2tldHMgfA0K PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiB8IElucHV0LVBhY2tldHMgfE91dHB1dC1QYWNrZXRzIHwNCj4gKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gfCBPdXRwdXQtUGFja2V0cyB8DQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwgT3V0cHV0LVBhY2tldHMg fA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsrLSstKy0rLSsrLSstKy0rDQo+ DQo+IFByb3M6IGV4cGxpY2l0IGFuZCBzaW1wbGlmaWVkIGZyb20gdGhlIGRlc2lnbi0zIGJlY2F1 c2UgZWFjaCBmaWVsZCBoYXMNCj4gdGhlIGZpeGVkIGxlbmd0aC4NCj4gQ29uczogbXVsdGktZmll bGQgZGVzaWduLCBjb21wbGV4IGRhdGEgdHlwZSAobm90IHJlY29tbWVuZGVkIGJ5IFJGQzYxNTgp DQo+DQo+IFBscy4gZmVlbCBmcmVlIHRvIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSBkZXNpZ25zIGZy b20geW91ciBwcm9mZXNzaW9uYWwNCj4gcGVyc3BlY3RpdmUsIHRoZW4gSSB3aWxsIHVwZGF0ZSBt eSBkcmFmdCBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzLg0KPg0KPg0KPiBJIHN1cHBvc2VkIGVhY2gg ZGVzaWduIGNhbiB3b3JrIGZvciAnVHJhZmZpYyBTdGF0aXN0aWNzJywgbWF5YmUgRGVzaWduDQo+ IDFhLCAxYiwgMmEsIDMgY291bGQgYmUgbW9yZSBhY2NlcHRhYmxlLg0KPg0KPiBJIHJlY29tbWVu ZCBkZXNpZ24gMWIsIGJlY2F1c2UgaXQgbG9va3MgbXVjaCBzaW1wbGUsIG5lZWQgbXVjaCBsZXNz DQo+IGF0dHJpYnV0cyB0aGFuIGRlc2lnbiAxYSwgYW5kIHdlIGNhbiBzb2x2ZSB0aGUgcHJvYmxl bSBvbiByZXBvcnRpbmcNCj4gJ1RyYWZmaWMgU3RhdGlzdGljcycgd2l0aGluIHRoZSBzdGFuZGFy ZCB0eXBlIHNwYWNlLg0KPg0KPiBJZiB0aGUgc3RhbmRhcmQgdHlwZSBzcGFjZSBpcyBkZXByZWNh dGVkIGFnYWluc3QgdGhpcyBjYXNlLCB0aGVuDQo+IGRlc2lnbi0yYSBtaWdodCBiZSBvdXIgY2hv aWNlLCBiZWNhdXNlIHdlIGRvbid0IGhhdmUgdGhlIHNwYWNlDQo+IGxpbWl0YXRpb24gaXNzdWUg aW4gdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2U7DQo+DQo+IG9yIHdlIGNvdWxkIHRyeSB0aGUgbmV3 IGJhc2ljIGRhdGEgdHlwZSBvZiBuZXN0aW5nLVRMViwgdGhlbg0KPiAnQWNjdC1UcmFmZmljIFN0 YXRpc3RpY3MnIGNvdWxkIGJlIHRoZSAxc3QgYXR0cmlidXRlIGluIHRoZSBleHRlbmRlZA0KPiB0 eXBlIHNwYWNlIHdpdGggVExWIGFzIGl0cyBiYXNpYyBkYXRhIHR5cGUuDQo+DQo+IEJ1dCBteSBj b25jZXJuIHdpbGwgYmUgdGhhdCBpdCBzdGlsbCBuZWVkcyAzIG9yIG1vcmUgeWVhcnMgZm9yIHRo ZQ0KPiB1cGdyYWRlIG9mIHRoZSBkZXBsb3llZCByYWRpdXMgc3lzdGVtIChOQVNzICsgc2VydmVy cykgdG8gc3VwcG9ydCB0aGUNCj4gc29sdXRpb24gb2YgdGhlIGV4dGVuZGVkIHR5cGUgc3BhY2Ug YW5kIGl0cyBuZXdseS1kZWZpbmVkIGF0dHJpYnV0ZXMuDQo+DQo+IEJlc3QgUmVnYXJkcywNCj4g TGVhZg0KPg0KDQoNCi0tIA0KU3RlZmFuIFdJTlRFUg0KSW5nZW5pZXVyIGRlIFJlY2hlcmNoZQ0K Rm9uZGF0aW9uIFJFU1RFTkEgLSBSw6lzZWF1IFTDqWzDqWluZm9ybWF0aXF1ZSBkZSBsJ0VkdWNh dGlvbiBOYXRpb25hbGUgZXQgDQpkZSBsYSBSZWNoZXJjaGUNCjYsIHJ1ZSBSaWNoYXJkIENvdWRl bmhvdmUtS2FsZXJnaQ0KTC0xMzU5IEx1eGVtYm91cmcNCg0KVGVsOiArMzUyIDQyNDQwOSAxDQpG YXg6ICszNTIgNDIyNDczDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcmFkZXh0IG1haWxpbmcgbGlzdA0KcmFkZXh0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApyYWRleHRAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQK From aland@deployingradius.com Fri Feb 24 02:01:33 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F292221F88FA for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 i48HgwwKaFdr for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6498D21F882F for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) Message-ID: <4F475FDD.2000102@deployingradius.com> Date: Fri, 24 Feb 2012 11:01:01 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , Stefan Winter , "mauricio.sanchez@hp.com" , "dromasca@avaya.com" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:01:33 -0000 Leaf yeh wrote: > Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. What do you have that is NEW to the discussion? The WG has already reached consensus on the topics you brought up. It is recorded in the messages Stefan referred to. Trying to re-open the same discussion is unproductive. Alan DeKok. From radext-bounces@ietf.org Fri Feb 24 02:01:34 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8346421F88FA; Fri, 24 Feb 2012 02:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330077694; bh=K5KAZFqRNJyxV2nX/BGigvNysspQ1LoJo7gu6cdwrbM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=V0TNdACS+AKenB6FBGe2VvBWyeDfO241Ijny58O1y5nNcNa86eq1Om5R7FpUi2XSc cDzxfHYeRhz/wiiRQBKPFDDbVADGrcO2SBHIiRQfCzCVxzIx3vJB8qin/XynrdZqMu HUj/kZSj/MYyvDXGo32Xb4GIoUUIfzEpCNEZzMjY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F292221F88FA for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 i48HgwwKaFdr for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6498D21F882F for ; Fri, 24 Feb 2012 02:01:32 -0800 (PST) Message-ID: <4F475FDD.2000102@deployingradius.com> Date: Fri, 24 Feb 2012 11:01:01 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , Stefan Winter , "mauricio.sanchez@hp.com" , "dromasca@avaya.com" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. What do you have that is NEW to the discussion? The WG has already reached consensus on the topics you brought up. It is recorded in the messages Stefan referred to. Trying to re-open the same discussion is unproductive. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Fri Feb 24 02:09:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29E21F8908 for ; Fri, 24 Feb 2012 02:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 17NNDNz0Vz-p for ; Fri, 24 Feb 2012 02:09:09 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8821F88CA for ; Fri, 24 Feb 2012 02:09:08 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 26AEE10580 for ; Fri, 24 Feb 2012 11:09:08 +0100 (CET) Received: from [IPv6:2001:a18:1:8:85d0:7c45:c938:773e] (unknown [IPv6:2001:a18:1:8:85d0:7c45:c938:773e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 001AC1057E for ; Fri, 24 Feb 2012 11:09:07 +0100 (CET) Message-ID: <4F4761C3.1000901@restena.lu> Date: Fri, 24 Feb 2012 11:09:07 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: radext@ietf.org References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> In-Reply-To: <4F475FDD.2000102@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:09:10 -0000 >> Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. > > What do you have that is NEW to the discussion? > > The WG has already reached consensus on the topics you brought up. It > is recorded in the messages Stefan referred to. > > Trying to re-open the same discussion is unproductive. On that topic: I'll merrily re-submit fancyaccounting and suggest WG adoption as soon as the new charter is out and includes an item to work on this issue. Is there any ETA for the new charter? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Fri Feb 24 02:09:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8EC21F8908; Fri, 24 Feb 2012 02:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330078152; bh=5oL0n4eCipWgqPDCzAMfM59Cr0Jvl2EXJIrhkrQChd0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=YXIWGKTVd5WE4cQz1lRa3FSL+gGTn9KUSgsU6ilU/dZVGXyfaCkP0y/ORRNNy6OFf Rh0qEASY/tn5k6+3fousUGmash2dpB8UTZQ12JTAsmCtykLoHutDaqM7EJlKGQolA6 zIi3AR+tim/HqzvDSqq9aeMpuh7PrDPyLkAiqtiw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29E21F8908 for ; Fri, 24 Feb 2012 02:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 17NNDNz0Vz-p for ; Fri, 24 Feb 2012 02:09:09 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8821F88CA for ; Fri, 24 Feb 2012 02:09:08 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 26AEE10580 for ; Fri, 24 Feb 2012 11:09:08 +0100 (CET) Received: from [IPv6:2001:a18:1:8:85d0:7c45:c938:773e] (unknown [IPv6:2001:a18:1:8:85d0:7c45:c938:773e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 001AC1057E for ; Fri, 24 Feb 2012 11:09:07 +0100 (CET) Message-ID: <4F4761C3.1000901@restena.lu> Date: Fri, 24 Feb 2012 11:09:07 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: radext@ietf.org References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> In-Reply-To: <4F475FDD.2000102@deployingradius.com> X-Virus-Scanned: ClamAV Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org >> Yes, I want to trigger a further discussion on this topic, and hear the = opinion from other experts in the WG. > > What do you have that is NEW to the discussion? > > The WG has already reached consensus on the topics you brought up. It > is recorded in the messages Stefan referred to. > > Trying to re-open the same discussion is unproductive. On that topic: I'll merrily re-submit fancyaccounting and suggest WG = adoption as soon as the new charter is out and includes an item to work = on this issue. Is there any ETA for the new charter? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et = de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Feb 24 02:54:18 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9754E21F88F4; Fri, 24 Feb 2012 02:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330080858; bh=AtPIHDP9X3HjF7gF8uGOMyfc/LZugVE2ypcIeOYttFI=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aoJaEnsJIhpo5kacS07rmF3zW87uVUeDBINrrGdYoV78Ny7uuTO4Sl5LXk8uiyfcQ OEaWTMpMJAH40lg9u5KwPDa07rfzhW/jJKbKhdGDXNAmWtgIkEZ9cPEXpJIxhQ+2DV 0frWB/8U9ePVA3HO+1rqLVh+Zo5UrCQiUkHEyhT4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8121F88F4 for ; Fri, 24 Feb 2012 02:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.684 X-Spam-Level: X-Spam-Status: No, score=-6.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AltHMSu4BAYk for ; Fri, 24 Feb 2012 02:54:16 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C710721F88C9 for ; Fri, 24 Feb 2012 02:54:15 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00FCU8RUPN@szxga03-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 18:50:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00DO98RUAG@szxga03-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 18:50:18 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA88511; Fri, 24 Feb 2012 18:50:17 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 18:49:55 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 18:50:28 +0800 Date: Fri, 24 Feb 2012 10:50:11 +0000 From: Leaf yeh In-reply-to: <4F475FDD.2000102@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnD//5aDgP//bWyA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , Stefan Winter , "mauricio.sanchez@hp.com" , "dromasca@avaya.com" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan - Trying to re-open the same discussion is unproductive. Supposed you prefer design -3. Could we give one more opportunity for the other experts to express their opinion? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Friday, February 24, 2012 6:01 PM To: Leaf yeh Cc: Stefan Winter; radext@ietf.org; dnelson@elbrys.com; bernard_aboba@hotmail.com; jouni.korhonen@nsn.com; mauricio.sanchez@hp.com; dromasca@avaya.com; peterd@iea-software.com Subject: Re: [radext] Attribute Design on 'Traffic Statistics' Leaf yeh wrote: > Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. What do you have that is NEW to the discussion? The WG has already reached consensus on the topics you brought up. It is recorded in the messages Stefan referred to. Trying to re-open the same discussion is unproductive. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Fri Feb 24 02:54:16 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8121F88F4 for ; Fri, 24 Feb 2012 02:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.684 X-Spam-Level: X-Spam-Status: No, score=-6.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AltHMSu4BAYk for ; Fri, 24 Feb 2012 02:54:16 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C710721F88C9 for ; Fri, 24 Feb 2012 02:54:15 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00FCU8RUPN@szxga03-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 18:50:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00DO98RUAG@szxga03-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 18:50:18 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA88511; Fri, 24 Feb 2012 18:50:17 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 18:49:55 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 18:50:28 +0800 Date: Fri, 24 Feb 2012 10:50:11 +0000 From: Leaf yeh In-reply-to: <4F475FDD.2000102@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnD//5aDgP//bWyA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> Cc: "radext@ietf.org" , "dnelson@elbrys.com" , "bernard_aboba@hotmail.com" , Stefan Winter , "mauricio.sanchez@hp.com" , "dromasca@avaya.com" , "peterd@iea-software.com" , "jouni.korhonen@nsn.com" Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:54:16 -0000 Alan - Trying to re-open the same discussion is unproductive. Supposed you prefer design -3. Could we give one more opportunity for the other experts to express their opinion? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Friday, February 24, 2012 6:01 PM To: Leaf yeh Cc: Stefan Winter; radext@ietf.org; dnelson@elbrys.com; bernard_aboba@hotmail.com; jouni.korhonen@nsn.com; mauricio.sanchez@hp.com; dromasca@avaya.com; peterd@iea-software.com Subject: Re: [radext] Attribute Design on 'Traffic Statistics' Leaf yeh wrote: > Yes, I want to trigger a further discussion on this topic, and hear the opinion from other experts in the WG. What do you have that is NEW to the discussion? The WG has already reached consensus on the topics you brought up. It is recorded in the messages Stefan referred to. Trying to re-open the same discussion is unproductive. Alan DeKok. From radext-bounces@ietf.org Fri Feb 24 03:03:55 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBA521F88CC; Fri, 24 Feb 2012 03:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330081435; bh=komfzhoXpxBVhghNyk8YFRfAnvNu01JxpjtEW5vqOfw=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Hz0TuKBjtf3ZYsCDFSgxXwC2na9pGbjclapFDn+2TLeJXZLM1odz8mPouFaPNQ+Yj fAfC+hVf1vVsdPnNY43Stgmd4LXstLOMJsyu5dTnS4JvSMypnlneXAPbFQWuHo6RJ+ AQOrn2O9AngR+jcds8ialOLv5CjhW8/HmVs8ZTXY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008621F88CC for ; Fri, 24 Feb 2012 03:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.68 X-Spam-Level: X-Spam-Status: No, score=-6.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lx7eB9EYcZc for ; Fri, 24 Feb 2012 03:03:53 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B46D321F87B3 for ; Fri, 24 Feb 2012 03:03:53 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW0032H9EG6I@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 19:03:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00F9C9EG5U@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 19:03:52 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA89072; Fri, 24 Feb 2012 19:03:52 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 19:03:27 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 19:03:47 +0800 Date: Fri, 24 Feb 2012 11:03:45 +0000 From: Leaf yeh In-reply-to: <4F4761C3.1000901@restena.lu> X-Originating-IP: [10.70.39.113] To: Stefan Winter , "radext@ietf.org" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnD//5aDgIAAAkOA//9uNhA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> <4F4761C3.1000901@restena.lu> Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org RGVzaWduIC0zIGdvdCAyIHZvdGVzLiBJcyBpdCBvYnZpb3VzIGVub3VnaCB0byBtYWtlIGEgZGVj aXNpb24gaW4gdGhlIFdHPw0KDQpJIGRvbid0IHJlYWxseSBvYmplY3QgdGhhdCBEZXNpZ24tMyBp cyBvbiB0aGUgZGlzY3Vzc2lvbiBsaXN0LCB0aG91Z2ggeW91IGFuZCBBbGFuIHNlZSB0aGUgb2J2 aW91cyBhZHZhbnRhZ2VzIG92ZXIgdGhlIG90aGVyIGFsdGVybmF0aXZlIG9wdGlvbnMuDQoNCg0K QmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiByYWRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3RlZmFuIFdpbnRlcg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwg MjAxMiA2OjA5IFBNDQpUbzogcmFkZXh0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3JhZGV4dF0g QXR0cmlidXRlIERlc2lnbiBvbiAnVHJhZmZpYyBTdGF0aXN0aWNzJw0KDQoNCj4+IFllcywgSSB3 YW50IHRvIHRyaWdnZXIgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYywgYW5kIGhl YXIgdGhlIG9waW5pb24gZnJvbSBvdGhlciBleHBlcnRzIGluIHRoZSBXRy4NCj4NCj4gICAgV2hh dCBkbyB5b3UgaGF2ZSB0aGF0IGlzIE5FVyB0byB0aGUgZGlzY3Vzc2lvbj8NCj4NCj4gICAgVGhl IFdHIGhhcyBhbHJlYWR5IHJlYWNoZWQgY29uc2Vuc3VzIG9uIHRoZSB0b3BpY3MgeW91IGJyb3Vn aHQgdXAuICBJdA0KPiBpcyByZWNvcmRlZCBpbiB0aGUgbWVzc2FnZXMgU3RlZmFuIHJlZmVycmVk IHRvLg0KPg0KPiAgICBUcnlpbmcgdG8gcmUtb3BlbiB0aGUgc2FtZSBkaXNjdXNzaW9uIGlzIHVu cHJvZHVjdGl2ZS4NCg0KT24gdGhhdCB0b3BpYzogSSdsbCBtZXJyaWx5IHJlLXN1Ym1pdCBmYW5j eWFjY291bnRpbmcgYW5kIHN1Z2dlc3QgV0cgDQphZG9wdGlvbiBhcyBzb29uIGFzIHRoZSBuZXcg Y2hhcnRlciBpcyBvdXQgYW5kIGluY2x1ZGVzIGFuIGl0ZW0gdG8gd29yayANCm9uIHRoaXMgaXNz dWUuDQoNCklzIHRoZXJlIGFueSBFVEEgZm9yIHRoZSBuZXcgY2hhcnRlcj8NCg0KR3JlZXRpbmdz LA0KDQpTdGVmYW4gV2ludGVyDQoNCg0KLS0gDQpTdGVmYW4gV0lOVEVSDQpJbmdlbmlldXIgZGUg UmVjaGVyY2hlDQpGb25kYXRpb24gUkVTVEVOQSAtIFLDqXNlYXUgVMOpbMOpaW5mb3JtYXRpcXVl IGRlIGwnRWR1Y2F0aW9uIE5hdGlvbmFsZSBldCANCmRlIGxhIFJlY2hlcmNoZQ0KNiwgcnVlIFJp Y2hhcmQgQ291ZGVuaG92ZS1LYWxlcmdpDQpMLTEzNTkgTHV4ZW1ib3VyZw0KDQpUZWw6ICszNTIg NDI0NDA5IDENCkZheDogKzM1MiA0MjI0NzMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpyYWRleHQgbWFpbGluZyBsaXN0DQpyYWRleHRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0 CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jh ZGV4dAo= From leaf.y.yeh@huawei.com Fri Feb 24 03:03:54 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008621F88CC for ; Fri, 24 Feb 2012 03:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.68 X-Spam-Level: X-Spam-Status: No, score=-6.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lx7eB9EYcZc for ; Fri, 24 Feb 2012 03:03:53 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B46D321F87B3 for ; Fri, 24 Feb 2012 03:03:53 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW0032H9EG6I@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 19:03:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00F9C9EG5U@szxga04-in.huawei.com> for radext@ietf.org; Fri, 24 Feb 2012 19:03:52 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA89072; Fri, 24 Feb 2012 19:03:52 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 19:03:27 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 19:03:47 +0800 Date: Fri, 24 Feb 2012 11:03:45 +0000 From: Leaf yeh In-reply-to: <4F4761C3.1000901@restena.lu> X-Originating-IP: [10.70.39.113] To: Stefan Winter , "radext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [radext] Attribute Design on 'Traffic Statistics' Thread-index: AczyRbvUjxuptwE1SgaPt2wBgmTmAQAPbQgAABJdrnD//5aDgIAAAkOA//9uNhA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <69464F53-A72C-47A7-A4B0-1F14BF2794E0@mimectl> <4F473D1A.3010801@restena.lu> <4F475FDD.2000102@deployingradius.com> <4F4761C3.1000901@restena.lu> Subject: Re: [radext] Attribute Design on 'Traffic Statistics' X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:03:54 -0000 RGVzaWduIC0zIGdvdCAyIHZvdGVzLiBJcyBpdCBvYnZpb3VzIGVub3VnaCB0byBtYWtlIGEgZGVj aXNpb24gaW4gdGhlIFdHPw0KDQpJIGRvbid0IHJlYWxseSBvYmplY3QgdGhhdCBEZXNpZ24tMyBp cyBvbiB0aGUgZGlzY3Vzc2lvbiBsaXN0LCB0aG91Z2ggeW91IGFuZCBBbGFuIHNlZSB0aGUgb2J2 aW91cyBhZHZhbnRhZ2VzIG92ZXIgdGhlIG90aGVyIGFsdGVybmF0aXZlIG9wdGlvbnMuDQoNCg0K QmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiByYWRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3RlZmFuIFdpbnRlcg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwg MjAxMiA2OjA5IFBNDQpUbzogcmFkZXh0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3JhZGV4dF0g QXR0cmlidXRlIERlc2lnbiBvbiAnVHJhZmZpYyBTdGF0aXN0aWNzJw0KDQoNCj4+IFllcywgSSB3 YW50IHRvIHRyaWdnZXIgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYywgYW5kIGhl YXIgdGhlIG9waW5pb24gZnJvbSBvdGhlciBleHBlcnRzIGluIHRoZSBXRy4NCj4NCj4gICAgV2hh dCBkbyB5b3UgaGF2ZSB0aGF0IGlzIE5FVyB0byB0aGUgZGlzY3Vzc2lvbj8NCj4NCj4gICAgVGhl IFdHIGhhcyBhbHJlYWR5IHJlYWNoZWQgY29uc2Vuc3VzIG9uIHRoZSB0b3BpY3MgeW91IGJyb3Vn aHQgdXAuICBJdA0KPiBpcyByZWNvcmRlZCBpbiB0aGUgbWVzc2FnZXMgU3RlZmFuIHJlZmVycmVk IHRvLg0KPg0KPiAgICBUcnlpbmcgdG8gcmUtb3BlbiB0aGUgc2FtZSBkaXNjdXNzaW9uIGlzIHVu cHJvZHVjdGl2ZS4NCg0KT24gdGhhdCB0b3BpYzogSSdsbCBtZXJyaWx5IHJlLXN1Ym1pdCBmYW5j eWFjY291bnRpbmcgYW5kIHN1Z2dlc3QgV0cgDQphZG9wdGlvbiBhcyBzb29uIGFzIHRoZSBuZXcg Y2hhcnRlciBpcyBvdXQgYW5kIGluY2x1ZGVzIGFuIGl0ZW0gdG8gd29yayANCm9uIHRoaXMgaXNz dWUuDQoNCklzIHRoZXJlIGFueSBFVEEgZm9yIHRoZSBuZXcgY2hhcnRlcj8NCg0KR3JlZXRpbmdz LA0KDQpTdGVmYW4gV2ludGVyDQoNCg0KLS0gDQpTdGVmYW4gV0lOVEVSDQpJbmdlbmlldXIgZGUg UmVjaGVyY2hlDQpGb25kYXRpb24gUkVTVEVOQSAtIFLDqXNlYXUgVMOpbMOpaW5mb3JtYXRpcXVl IGRlIGwnRWR1Y2F0aW9uIE5hdGlvbmFsZSBldCANCmRlIGxhIFJlY2hlcmNoZQ0KNiwgcnVlIFJp Y2hhcmQgQ291ZGVuaG92ZS1LYWxlcmdpDQpMLTEzNTkgTHV4ZW1ib3VyZw0KDQpUZWw6ICszNTIg NDI0NDA5IDENCkZheDogKzM1MiA0MjI0NzMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpyYWRleHQgbWFpbGluZyBsaXN0DQpyYWRleHRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo= From radext-bounces@ietf.org Wed Feb 29 02:54:31 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B656D21F8833; Wed, 29 Feb 2012 02:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330512871; bh=4ZLJP1qrP+D9+5LQuoDUF2NViSgsv8z4hZDU/PFTr3w=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=MB5/G/cgphIdoxYKeoOnWS7vTTvEFe9NQT3TyVgPfgtXWPOGRKRv4HMgcnJ7EiV5a 7mDEafz36HeushE+yV0CBikHH4qCapqpCJ6IdnS1io3Nl+dy4el1Lqk1HDXr5hids4 3NqWhoqBrmy3vVKmowdCYe/jmo/90cTvDhq3846Y= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D442F21F86B3; Wed, 29 Feb 2012 02:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQztIQEeeF6N; Wed, 29 Feb 2012 02:54:30 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39321F8827; Wed, 29 Feb 2012 02:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id E08FE5D4DC; Wed, 29 Feb 2012 11:54:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JnaXnfYX5pbv; Wed, 29 Feb 2012 11:54:28 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id 9C3C85D53A; Wed, 29 Feb 2012 11:54:28 +0100 (CET) Message-ID: <4F4E03E3.8070006@um.es> Date: Wed, 29 Feb 2012 11:54:27 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> In-Reply-To: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> Subject: [radext] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6796969356310773736==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============6796969356310773736== Content-Type: multipart/alternative; boundary="------------000101010201040303090306" This is a multi-part message in MIME format. --------------000101010201040303090306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit -------- Original message -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt Fecha: Wed, 29 Feb 2012 02:46:34 -0800 De: internet-drafts@ietf.org A new version of I-D, draft-perez-radext-radius-fragmentation-01.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 01 Title: Support of fragmentation of RADIUS packets Creation date: 2012-02-29 WG ID: Individual Submission Number of pages: 12 Abstract: This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4 KB limit. The IETF Secretariat --------------000101010201040303090306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
-------- Original message --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt
Fecha: Wed, 29 Feb 2012 02:46:34 -0800
De: internet-drafts@ietf.org 


A new version of I-D, draft-perez-radext-radius-fragmentation-01.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 01
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2012-02-29
WG ID:		 Individual Submission
Number of pages: 12

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

                                                                                  


The IETF Secretariat
--------------000101010201040303090306-- --===============6796969356310773736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============6796969356310773736==-- From alex@um.es Wed Feb 29 02:54:30 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D442F21F86B3; Wed, 29 Feb 2012 02:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQztIQEeeF6N; Wed, 29 Feb 2012 02:54:30 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39321F8827; Wed, 29 Feb 2012 02:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id E08FE5D4DC; Wed, 29 Feb 2012 11:54:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JnaXnfYX5pbv; Wed, 29 Feb 2012 11:54:28 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id 9C3C85D53A; Wed, 29 Feb 2012 11:54:28 +0100 (CET) Message-ID: <4F4E03E3.8070006@um.es> Date: Wed, 29 Feb 2012 11:54:27 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> In-Reply-To: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000101010201040303090306" Subject: [radext] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 10:54:31 -0000 This is a multi-part message in MIME format. --------------000101010201040303090306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit -------- Original message -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt Fecha: Wed, 29 Feb 2012 02:46:34 -0800 De: internet-drafts@ietf.org A new version of I-D, draft-perez-radext-radius-fragmentation-01.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 01 Title: Support of fragmentation of RADIUS packets Creation date: 2012-02-29 WG ID: Individual Submission Number of pages: 12 Abstract: This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4 KB limit. The IETF Secretariat --------------000101010201040303090306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
-------- Original message --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt
Fecha: Wed, 29 Feb 2012 02:46:34 -0800
De: internet-drafts@ietf.org 


A new version of I-D, draft-perez-radext-radius-fragmentation-01.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 01
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2012-02-29
WG ID:		 Individual Submission
Number of pages: 12

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

                                                                                  


The IETF Secretariat
--------------000101010201040303090306--